سرویس آماده نیست یا گیر کرده؟ یک Healthcheck برای همه تصمیم‌ها کافی نیست

منبع فنی: مستند رسمی Probeها در Kubernetes. پیشنهاد طراحی زیر مستقل است و عین پیکربندی آماده نیست.

یک پرسش می‌گوید «آیا برنامه می‌تواند درخواست تازه بگیرد؟» و دیگری «آیا برنامه آن‌قدر گیر کرده که راه‌اندازی دوباره لازم است؟». یکی‌گرفتن این دو می‌تواند از یک مشکل کوتاه، اختلال بزرگ‌تری بسازد.

نقش‌ها را جدا بنویسیم

• Readiness برای تصمیم دریافت ترافیک است.
• Liveness برای تشخیص وضعیتی است که سیاست اجرا ممکن است به ری‌استارت واکنش دهد.
• Startup به زمان لازم برای شروع برنامه مربوط است.

این نام‌ها را نباید به هر محیطی بدون بررسی تعمیم داد. یک برچسب unhealthy در ابزار دیگر الزاماً همان واکنش را ندارد؛ سیاست همان محیط باید خوانده شود.

مثال فرضی

پایگاه داده برای مدت کوتاهی در دسترس نیست. اگر هر شکست اتصال باعث ناموفق‌شدن آزمون زنده‌بودن شود، برنامه‌های سالم هم ممکن است پشت سر هم راه‌اندازی شوند. در این وضعیت، مشکل وابستگی با ازبین‌رفتن وضعیت گرم برنامه تشدید می‌شود.

پیشنهاد من این است که آزمون زنده‌بودن، وابستگی‌های غیرضروری را وارد تصمیم سخت نکند. آمادگی نیز باید با نیاز واقعی سرویس طراحی شود، نه فقط بازبودن پورت.

پیش از فعال‌سازی

سناریوی شروع کند، ازدحام و قطع موقت وابستگی را در محیط آزمایش بررسی کنید. هزینه خود آزمون را هم بسنجید. سپس معیار موفقیت، زمان انتظار و مسئول بررسی هشدار را مستند کنید.

مطالعه مکمل: سلامت واقعی سرویس فراتر از Ping.

بررسی منبع: 2 نوامبر 2026. مثال فرضی است؛ آستانه یکسان و توصیه ری‌استارت برای همه سرویس‌ها ارائه نمی‌شود.