التقنية / تحليل ورؤى عملية

الخدمة غير جاهزة أم عالقة؟ فحص واحد لا يكفي لكل القرارات

افصل جاهزية الترافيك عن حياة التطبيق، كي لا يتحول انقطاع اعتماد مؤقت إلى حلقة إعادة تشغيل.

ADأردشير دارياني··1 دقائق للقراءة
تصور لتنسيق الحاويات واختيار إدارة الخدمة
صورة مفاهيمية أصلية مولّدة بالذكاء الاصطناعي؛ لا تمثل بدقة منتجًا تجاريًا أو بنية فعلية.

المصدر التقني: توثيق فحوص Kubernetes الرسمي. التصميم المقترح مستقل، لا إعداد جاهز.

«هل يستقبل التطبيق طلبًا؟» تختلف عن «هل علق لدرجة تستدعي إعادة تشغيل؟». الجمع قد يحول مشكلة قصيرة إلى انقطاع أكبر.

افصل الأدوار

  • Readiness تقرر قبول الترافيك.
  • Liveness تكشف حالات قد تستدعي إعادة التشغيل بحسب السياسة.
  • Startup تخص الوقت المطلوب لبدء التطبيق.

لا تعمم الأسماء على كل بيئة. وسم unhealthy في أداة أخرى لا يضمن الإجراء نفسه؛ اقرأ سياستها.

مثال افتراضي

تغيب قاعدة البيانات قليلًا. إذا فشل اختبار الحياة لكل فشل اتصال، قد تعاد التطبيقات السليمة مرارًا. وفقد حالتها الدافئة قد يزيد المشكلة.

أقترح إخراج الاعتماديات غير الضرورية من قرار الحياة الصارم. وصمّم الجاهزية بحسب الخدمة لا منفذ مفتوح فقط.

قبل التفعيل

اختبر البداية البطيئة والازدحام وفقد الاعتماد المؤقت. قِس كلفة الفحص نفسه، ووثّق النجاح والانتظار ومالك التنبيه.

قراءة مكملة: سلامة الخدمة خارج Ping.

مراجعة المصدر: 2 نوفمبر 2026. مثال افتراضي بلا عتبة عامة أو دعوة لإعادة كل الخدمات.

تحليل تقني لاتخاذ قرارات أكثر وعيًا.جميع المنشورات →