ماذا يحدث بعد النشر الناجح

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

لكن لا شيء من هذا يخبرك ما إذا كان الإصدار الجديد يعمل فعليًا للمستخدمين.

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

الفجوة بين النشر والتشغيل الطبيعي

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

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

خمسة مؤشرات للفحص بعد النشر

معدل الأخطاء

معدل الأخطاء هو الإشارة الأكثر مباشرة على وجود مشكلة. إذا كانت خدمة API الخاصة بك تعمل عادةً بمعدل فشل 0.1 بالمائة وقفز فجأة إلى 5 بالمائة بعد النشر، فهناك مشكلة.

للتحقق من معدل الأخطاء فورًا بعد النشر، استعلم عن نقطة قياساتك. على سبيل المثال، باستخدام Prometheus:

curl -s 'http://localhost:9090/api/v1/query?query=rate(http_requests_total{status=~"5.."}[5m])'

يعيد هذا الاستعلام معدل أخطاء 5xx خلال الخمس دقائق الأخيرة. قارن النتيجة بخط الأساس قبل النشر لتقرر ما إذا كان التراجع ضروريًا.

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

زمن الاستجابة

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

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

التشبع

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

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

صحة الاعتماديات

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

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

إشارات الأعمال

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

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

ماذا تفعل عندما تسوء الأمور

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

يُظهر مخطط التدفق التالي عملية مراقبة ما بعد النشر وقرار التراجع أو الاستمرار:

flowchart TD A[النشر أخضر] --> B{فحص معدل الأخطاء} B -- حسن --> C{فحص زمن الاستجابة} B -- تنبيه --> R[تراجع] C -- حسن --> D{فحص التشبع} C -- تنبيه --> R D -- حسن --> E{فحص صحة الاعتماديات} D -- تنبيه --> R E -- حسن --> F{فحص إشارات الأعمال} E -- تنبيه --> R F -- حسن --> G[مراقبة] F -- تنبيه --> R

يجب أن يكون التراجع آليًا. تسجيل الدخول إلى الخوادم وتبديل الملفات يدويًا بطيء جدًا وعرضة للأخطاء عندما يكون المستخدمون متأثرين بالفعل.

تعتمد كيفية أتمتة التراجع على استراتيجية النشر الخاصة بك:

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

النقطة الحاسمة هي أنه يجب تحديد حدود التراجع قبل النشر، وليس أثناء حادثة. على سبيل المثال: إذا ظل معدل الأخطاء أعلى من 1 بالمائة لمدة دقيقتين، قم بالتراجع تلقائيًا. أو إذا زاد متوسط زمن الاستجابة بنسبة 50 بالمائة عن خط الأساس، قم بالتراجع.

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

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

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

  • معدل الأخطاء ضمن النطاق المتوقع (قارن بخط الأساس قبل النشر)
  • زمن الاستجابة لم يزد بشكل كبير
  • استخدام موارد الخادم (وحدة المعالجة المركزية، الذاكرة، الاتصالات) مستقر
  • جميع الاعتماديات الحرجة تستجيب بشكل طبيعي
  • إشارات الأعمال (التسجيلات، المعاملات، إلخ) تطابق الأنماط المتوقعة
  • حد التراجع محدد وآلي

النهاية الحقيقية للنشر

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

حدد حدودك، وراقب مؤشراتك، وقم بأتمتة التراجع. شبكة الأمان لا تعمل إلا إذا كانت جاهزة قبل أن تحتاج إليها.