فحص خدمة النموذج: هل الفشل يوقف المرور أم يعيد التشغيل؟

الخلاصة السريعة

راجع نوع الفحص وشرط نجاحه وإعداده؛ توقف مرور الخدمة ليس هو إعادة تشغيل الحاوية، ولا يثبت أي منهما جودة التنبؤ.

• فشل readiness يخرج عنوان Pod من نقاط الخدمات المطابقة؛ فشل liveness بعد السماحية المهيأة يؤدي إلى إعادة تشغيل وفق السياسة. ^[1]
• في مثالنا يفشل فحص استعداد ملف مطلوب وينجح فحص حيوية العملية؛ عدم الجاهزية لا يعني أننا سجلنا إعادة تشغيل أو فشل دقة.
• إذا تجاوزت إخفاقات liveness السماحية المقررة، يصبح أثره مختلفًا عن حجب المرور؛ لا نحسب وقت الإعادة دون بيانات إعداد وسجل.
• عند إعداد startup لا يبدأ الفحصان قبل نجاحه؛ بعدها يراجع كل منهما شرطه، فلا نستنتج نجاح أحدهما من الآخر. ^[1]

سم الفحص قبل تفسير النتيجة

تشرح Kubernetes أن readiness الفاشل يزيل عنوان Pod من EndpointSlices للخدمات المطابقة، وأن liveness يعيد التشغيل إذا تجاوز الفشل السماحية المهيأة، وفق سياسة الإعادة. ^[1]

نطبق القراءة على خدمة تقدم نموذجًا، لكننا لا نجعل نوعي الفحص اسمين لسؤال واحد. يمكن لصاحب التطبيق اختيار شرط إعداد ملف، واختيار شرط استجابة العملية، ولكل منهما أثر ينبغي أن يكون معلومًا عند مراجعة تقرير.

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

عملية حية لكنها غير جاهزة في تمريننا

نؤلف شرط جاهزية: ملف مرجع مطلوب للتنبؤ متاح للقراءة. ونؤلف شرط حيوية مختلفًا: العملية تجيب عن اختبارها المحدد. نفرض بطاقة تقول إن الملف غير متاح وإن اختبار العملية ناجح.

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

الأثر على مرور الخدمات يقرأ وفق نوع readiness. أما خانة إعادة التشغيل، فلا نملأها من غياب الملف وحده. لم نقدم سجلًا لإعادة التشغيل في البطاقة، ولا نحدد سبب الغياب أو زمن إصلاحه من الإخفاق. الفحص نفسه ليس اختبار دقة لمجموعة أمثلة.

متى يتغير الأثر مع liveness؟

نضيف سيناريو مستقلًا: نتيجة اختبار الحيوية تفشل مرات تتجاوز السماحية المعلنة في إعدادنا. هنا نقرأ الأثر الموثق لفحص الحيوية بدل إسقاط قراءة جاهزية الملف عليه. ليست هذه بطاقة السيناريو السابق الذي نجحت فيه الحيوية.

لا نحسب مدة إلى إعادة التشغيل من عدد إخفاقات مجرد. يحتاج الزمن إلى توقيت الفحوص وإعدادها وسجل الإجراء؛ ولم نزود المثال بهذه البيانات. كذلك بدء إعادة التشغيل لا يخبرنا أن المرجع صار متاحًا أو أن تحميل النموذج انتهى بعدها.

نقترح فصل تقرير قرار الإعادة عن تقرير نجاح الاستعداد اللاحق. إذا لم نر التقرير الثاني، تظل الحالة بعد الإعادة غير محسومة. لا نكرر كلمة «أعيد» بوصفها جوابًا عن توافر الخدمة أو جودة كل تنبؤ.

هل يبدأ الفحصان مع بداية العملية؟

عند إعداد startup، لا ينفذ Kubernetes فحصي liveness و readiness قبل نجاحه. ولا تعتمد الحيوية والجاهزية على نجاح بعضهما بعضًا. ^[1]

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

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