كيف تعرف أن بيئتك سليمة بعد النشر

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

ولكن هل التطبيق يعمل فعليًا؟

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

هذه الفجوة بين "تم النشر" و"يعمل" هي المكان الذي يقع فيه العديد من الفرق. أنت بحاجة إلى طريقة لمعرفة الحالة الحقيقية لبيئتك بعد كل إصدار.

ما تحتاجه حقًا: إشارات الصحة

عندما تنشر إصدارًا جديدًا، تحتاج إلى إجابات لسؤال بسيط: هل كل شيء على ما يرام؟

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

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

إليك مثال عملي لما يبدو عليه فحص الصحة أثناء العمل:

curl -f http://localhost:8080/health

قد يستجيب تطبيق سليم بـ JSON مثل هذا:

{
  "status": "ok",
  "version": "2.4.1",
  "uptime": 3600,
  "dependencies": {
    "database": "connected",
    "cache": "connected",
    "external_api": "reachable"
  }
}

لكن ليست كل فحوصات الصحة متساوية. يمكنك الفحص على مستويات مختلفة، وكل مستوى يمنحك درجة مختلفة من الثقة.

مستويات فحوصات الصحة

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

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

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

يُظهر المخطط الانسيابي التالي كيف تبني هذه المستويات على بعضها البعض وماذا يحدث عندما يفشل الفحص:

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

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

المراقبة: مراقبة الإشارة بمرور الوقت

فحص صحة واحد يخبرك بالحالة في لحظة واحدة. لكن الظروف تتغير. قد ينقطع اتصال قاعدة البيانات بعد خمس دقائق من نجاح الفحص. قد يتسرب الذاكرة ببطء حتى يتعطل التطبيق بعد ساعة.

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

المراقبة الجيدة تجيب على أسئلة مثل:

  • هل كانت البيئة سليمة فورًا بعد النشر؟
  • هل تدهورت الصحة ببطء خلال الساعة الماضية؟
  • هل تظهر جميع البيئات (الاختبار، الإنتاج) نفس النمط؟

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

التنبيه: معرفة متى تتصرف

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

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

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

الهدف هو تقليل الوقت بين حدوث مشكلة وعلم الفريق بها. كل دقيقة من عدم الوعي هي دقيقة قد يتأثر فيها المستخدمون.

استخدام إشارات الصحة في خط الأنابيب الخاص بك

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

في إعداد CI/CD أكثر نضجًا، يمكن لخط الأنابيب التحقق تلقائيًا من إشارات الصحة بعد النشر. التسلسل يبدو كالتالي:

  1. نشر الإصدار الجديد.
  2. انتظار بدء التطبيق.
  3. تشغيل فحوصات الصحة ضد الإصدار الجديد.
  4. إذا نجحت فحوصات الصحة، وضع علامة على النشر على أنه ناجح.
  5. إذا فشلت فحوصات الصحة، تشغيل تراجع تلقائي أو إيقاف الإصدار.

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

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

قائمة مراجعة عملية لصحة ما بعد النشر

بعد كل نشر، راجع قائمة المراجعة السريعة هذه لتأكيد أن بيئتك سليمة:

  • هل يمكن الوصول إلى عملية التطبيق؟ (فحص العملية الأساسي)
  • هل تعيد نقطة نهاية الصحة استجابة ناجحة؟ (فحص على مستوى التطبيق)
  • هل جميع التبعيات الحرجة (قاعدة البيانات، ذاكرة التخزين المؤقت، واجهات API الخارجية) قابلة للوصول؟ (فحص التبعية)
  • هل معدلات الخطأ مستقرة أو متناقصة مقارنة بما قبل النشر؟
  • هل أوقات الاستجابة ضمن النطاق الطبيعي؟
  • هل تم تكوين التنبيهات لإخطار الفريق إذا فشل أي من هذه الفحوصات؟

قائمة المراجعة هذه ليست شاملة، لكنها تغطي الحد الأدنى من الإشارات التي تحتاجها لتأكيد نشر سليم.

الخلاصة

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

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