یک برنامهٔ Node.js می‌تواند پاسخ بدهد اما هنوز آمادهٔ پذیرش کار اصلی نباشد. Liveness دربارهٔ زنده‌بودنِ قابل‌پاسخِ فرایند است؛ Readiness دربارهٔ آمادگی ارائهٔ خدمت موردنظر. بررسی دیتابیس در هر دو مسیر و restart کردن برنامه برای هر قطع وابستگی می‌تواند تصمیم نامناسبی بسازد.
۱. چه چیزی را می‌خواهید اندازه بگیرید؟
| بررسی | نمونهٔ سؤال | اثر تصمیم در یک سامانهٔ پشتیبان |
|---|---|---|
Liveness |
آیا فرایند می‌تواند پاسخ دهد؟ | ممکن است برای تشخیص نیاز به restart استفاده شود |
Readiness |
آیا این نمونه آمادهٔ ترافیک اصلی است؟ | ممکن است موقتاً از دریافت کار کنار گذاشته شود |
Startup |
آیا شروع اولیه تمام شده؟ | جلوگیری از داوری زودهنگام |
این واژه‌ها در مستند Kubernetes معنای عملی مشخص دارند، اما نام‌گذاری یک URL در هاست اشتراکی خودکار همان رفتار را فعال نمی‌کند. باید بدانید پنل، reverse proxy یا مانیتور شما واقعاً چه پاسخی را می‌خواند و چه اقدامی انجام می‌دهد.
۲. نمونهٔ منطق، بدون endpoint عمومی
function readiness(state) {
return state.started && state.databaseReady;
}
const state = { started: true, databaseReady: false };
console.log({ live: true, ready: readiness(state) });
در این مثال آموزشی، فرض کرده‌ایم فرایند قادر به پاسخ است، پس live را true نمایش می‌دهیم؛ هنوز HTTP server ساخته نشده است. readiness فقط دو وضعیت نمونه را ترکیب می‌کند. آزمون محلی سه حالت شروع‌نشده، شروع‌شده با دیتابیس ناآماده و هر دو آماده را بررسی کرد؛ ready فقط در حالت آخر true شد.
۳. دیتابیس را کجا بسنجیم؟
اگر برنامه بدون دیتابیس نمی‌تواند درخواست اصلی را انجام دهد، وضعیت آن می‌تواند بخشی از readiness باشد. اما در دسترس نبودن یک وابستگی خارجی لزوماً به معنی خراب‌شدن خود فرایند نیست. استفاده از همین شرط برای liveness ممکن است چرخهٔ restart بی‌فایده ایجاد کند.
- کنترل باید سبک، محدود به زمان و بدون نوشتن دادهٔ واقعی باشد.
- probe نباید سفارش، ایمیل یا پرداخت بسازد.
- اگر وضعیت از cache خوانده می‌شود، تازگی و زمان آخرین بررسی روشن باشد.
- وابستگی غیرضروری را بی‌دلیل شرط قطع همهٔ ترافیک نکنید.
۴. پاسخ HTTP قرارداد می‌خواهد
وقتی این منطق واقعاً در endpoint قرار می‌گیرد، status و بدنه باید قرارداد روشن داشته باشند؛ برای نمونه، آماده‌بودن می‌تواند ۲۰۰ و ناآماده‌بودن ۵۰۳ بدهد. این فقط یک قرارداد نمونه است؛ رفتار مصرف‌کننده را از مستند خودش بررسی کنید.
صفحهٔ اصلی که همیشه HTML با کد۲۰۰ می‌دهد، سلامت تمام مسیرهای برنامه را ثابت نمی‌کند. از طرف دیگر، پاسخ health هم نباید نسخهٔ دقیق داخلی، رشتهٔ اتصال، نام میزبان خصوصی یا stack trace را عمومی کند. جزئیات عیب‌یابی در مسیر محافظت‌شده و لاگ مناسب باقی بماند.
۵. خطاهای طراحی که باید جلوشان را گرفت
| خطا | پیامد احتمالی |
|---|---|
query سنگین در هر probe |
خودِ پایش به سرویس بار می‌دهد |
وابستگی خارجی در liveness بدون تحلیل |
restartهای تکراری هنگام قطع وابستگی |
| تایم‌اوت نامحدود | probe و پاسخ‌گویی معطل می‌مانند |
اعلام ready پیش از پایان startup |
کار واقعی زودتر از آمادگی وارد می‌شود |
نکته: قبل از اتصال probe به restart یا حذف ترافیک، اثر خطای مثبت و منفی را در طرح استقرار بررسی کنید. این مقاله هیچ کنترل خودکاری روی سایت یا سرور فعال نمی‌کند.
۶. چک نهایی
نام معیار، شرط موفقیت، timeout، بازهٔ بررسی، مصرف‌کننده و اقدام بعدی را بنویسید. سپس در محیط ایزوله حالت‌های آماده، ناآماده و وابستگی قطع‌شده را امتحان کنید. آزمون تابع این مقاله جای چنین تست یکپارچه‌ای را نمی‌گیرد. برای فهم تفاوت پایش بیرونی سایت با منطق داخلی برنامه، راهنمای آپتایم موجود را هم بخوانید.
۷. مسیر مطالعهٔ مرتبط
۸. منابع و روش بررسی
منابع رسمی در ۲۴ اکتبر ۲۰۲۶ بررسی شدند. مثال‌های کدِ این متن در Node.js نسخهٔ ۲۴.۱۹.۰ روی محیط محلی ایزوله بررسی شده‌اند؛ نصب روی هاست، اتصال دیتابیس یا کارایی تولید با این آزمایش اثبات نشده است.
