ماذا يحدث بعد النشر؟ لماذا لم ينتهِ خط أنابيبك بعد

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

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

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

الطبقات الثلاث للتحقق بعد النشر

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

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

فحص الصحة: هل التطبيق حي؟

فحص الصحة هو أبسط أنواع التحقق. يجيب على سؤال واحد: هل الخدمة قيد التشغيل وتستجيب للطلبات؟ عادةً ما يكون هذا نقطة نهاية مخصصة مثل /health أو /status تُرجع رمز HTTP 200 عندما يكون التطبيق حيًا.

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

الاختبار السريع: هل الوظائف الأساسية تعمل؟

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

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

إليك اختبار سريع بسيط بلغة bash يتحقق من نقطة نهاية API حرجة ويخرج برمز غير صفري إذا لم تكن الاستجابة 200:

#!/bin/bash
set -euo pipefail

# اختبار سريع: تحقق من أن نقطة نهاية تسجيل الدخول تُرجع 200
RESPONSE=$(curl -s -o /dev/null -w "%{http_code}" https://myapp.com/api/login)

if [ "$RESPONSE" -ne 200 ]; then
  echo "فشل الاختبار السريع: نقطة نهاية تسجيل الدخول أعادت $RESPONSE"
  exit 1
fi

echo "نجح الاختبار السريع: نقطة نهاية تسجيل الدخول أعادت 200"

المراقبة الاصطناعية: هل تلبي معايير الأداء؟

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

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

ماذا يحدث عندما يفشل التحقق

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

إذا كنت تستخدم النشر التدريجي (canary deployment)، يمكن لخط الأنابيب إيقاف توجيه الحركة إلى الإصدار الجديد وإعادة توجيه جميع المستخدمين إلى الإصدار القديم. إذا كنت تستخدم النشر الأزرق-الأخضر (blue-green deployment)، يمكن لخط الأنابيب تحويل الحركة مرة أخرى إلى البيئة التي لا تزال تعمل بالإصدار القديم. الإجراء المحدد يعتمد على استراتيجية النشر الخاصة بك، لكن المبدأ واحد: أوقف الضرر واستعد الخدمة.

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

لماذا تتخطى الفرق هذه الخطوة

غالبًا ما يُعتبر التحقق بعد النشر اختياريًا أو يتم تخطيه تمامًا. الأسباب متنوعة. بعض الفرق تثق كثيرًا في اختبارات ما قبل النشر. آخرون يعتقدون أن فحوصات الصحة كافية. العديد ببساطة يشعرون بالضغط للتحرك بسرعة ويعتبرون التحقق تباطؤًا.

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

قائمة ممارسات عملية للتحقق بعد النشر

إذا كنت تقوم بإعداد التحقق بعد النشر لأول مرة، إليك نقطة بداية بسيطة:

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

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

المقياس الحقيقي للنشر الناجح

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

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