عندما لا يعني خط أنابيب أخضر نشرًا صحيًا

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

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

ماذا حدث؟ قال خط الأنابيب أن كل شيء على ما يرام.

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

ما تخبرك به إشارة الصحة فعليًا

إشارة الصحة هي كيفية إبلاغ تطبيقك عن حالته الخاصة. الشكل الأكثر شيوعًا هو نقطة نهاية صحية: عنوان URL مخصص يمكن لخط الأنابيب أو موازن التحميل أو فريق العمليات الاتصال به للتحقق مما إذا كان التطبيق يعمل. ربما رأيت نقاط نهاية باسم /health أو /healthz. عند الاتصال بها، يُرجع التطبيق الصحي HTTP 200. بينما يُرجع غير الصحي 500 أو رمز خطأ آخر.

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

الجاهزية مقابل الحيوية: سؤالان مختلفان

هناك نوعان متميزان من الفحوصات الصحية، ويجيبان على أسئلة مختلفة.

يوضح مخطط التدفق التالي الفرق بين فحوصات الحيوية والجاهزية وكيفية توجيهها لقرارات النشر:

flowchart TD A[طلب فحص صحي] --> B{هل عملية التطبيق قيد التشغيل؟} B -->|لا| C[فشل الحيوية: إعادة تشغيل الحاوية] B -->|نعم| D{هل التطبيق جاهز لخدمة الزيارات؟} D -->|لا| E[فشل الجاهزية: إزالة من موازن التحميل] D -->|نعم| F[نجاح الجاهزية: إرسال الزيارات] C --> G[محاولة استرداد تلقائية] E --> H[انتظر وأعد محاولة الجاهزية] F --> I[التطبيق يخدم المستخدمين بشكل طبيعي] H --> D G --> B

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

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

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

إليك مثال عملي بتنسيق YAML يقوم بتكوين كلا الفحصين لنشر Kubernetes:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  template:
    spec:
      containers:
      - name: app
        image: my-app:1.0.0
        ports:
        - containerPort: 8080
        readinessProbe:
          httpGet:
            path: /ready
            port: 8080
          initialDelaySeconds: 5
          periodSeconds: 10
          failureThreshold: 3
        livenessProbe:
          httpGet:
            path: /live
            port: 8080
          initialDelaySeconds: 15
          periodSeconds: 20
          failureThreshold: 3

في هذا المثال، يتحقق فحص الجاهزية من /ready كل 10 ثوانٍ بعد تأخير قدره 5 ثوانٍ. إذا فشل ثلاث مرات، يتوقف Kubernetes عن إرسال الزيارات إلى الحاوية. يتحقق فحص الحيوية من /live بشكل أقل تكرارًا ويعيد تشغيل الحاوية إذا فشل.

ما يتحقق منه الفحص الصحي الجيد فعليًا

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

  • الاتصال بقاعدة البيانات: هل يمكن للتطبيق الوصول إلى قاعدة البيانات وتشغيل استعلام بسيط؟
  • واجهات برمجة التطبيقات الخارجية الهامة: هل الخدمات التي يعتمد عليها تطبيقك متاحة؟
  • الموارد الداخلية: هل تجمع الخيوط سليم؟ هل استخدام الذاكرة ضمن الحدود؟

لكن هناك مفاضلة. الفحص الصحي الذي يختبر كل تبعية في كل استدعاء يمكن أن يصبح عبئًا على النظام. إذا كان خط الأنابيب أو موازن التحميل يستدعي نقطة النهاية كل بضع ثوانٍ، يمكن لفحص ثقيل أن يقلل الأداء أو حتى يسبب فشلًا متتاليًا.

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

إشارات الصحة في استراتيجيات النشر التدريجي

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

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

ماذا يحدث عندما تكون الفحوصات الصحية مفقودة أو ضعيفة

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

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

قائمة مرجعية عملية سريعة

إذا كنت تقوم بإعداد فحوصات صحية لتطبيقك، إليك قائمة قصيرة من الأشياء للتحقق منها:

  • هل تتحقق نقطة النهاية الصحية الخاصة بك من شيء ذي معنى، أم أنها تُرجع 200 فقط؟
  • هل لديك فحوصات جاهزية وحيوية منفصلة بأعماق مختلفة؟
  • هل يستخدم خط الأنابيب الخاص بك فحص الجاهزية لتحديد ما إذا كان يجب المتابعة في النشر أو التراجع؟
  • هل فحوصاتك الصحية خفيفة بما يكفي بحيث لا تقلل الأداء عند استدعائها بشكل متكرر؟
  • هل تستخدم استراتيجيات النشر التدريجي إشارات الصحة لاكتشاف المشكلات مبكرًا؟

الاختبار الحقيقي للنشر

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

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