ماذا يحدث بعد التراجع: التحقق من نجاح عملية الاسترداد

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

ولكن هل النظام يعمل بالفعل؟

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

المخاطر الخفية للاسترداد

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

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

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

ابدأ باختبارات الدخان

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

قد يتضمن اختبار دخان جيد لتطبيق ويب ما يلي:

• هل يمكن للمستخدمين تسجيل الدخول؟
• هل يمكنهم رؤية لوحة التحكم الرئيسية؟
• هل يمكنهم إرسال نموذج أو إكمال معاملة؟
• هل هناك أي أخطاء في سجلات التطبيق؟

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

على سبيل المثال، قد يبدو اختبار دخان آلي بسيط باستخدام curl كما يلي:

#!/bin/bash
# اختبار دخان بسيط بعد التراجع

BASE_URL="https://my-app.example.com"

# التحقق من نقطة نهاية الصحة
if ! curl -f -s -o /dev/null "$BASE_URL/health"; then
  echo "FAIL: نقطة نهاية الصحة غير قابلة للوصول"
  exit 1
fi

# التحقق من تحميل صفحة تسجيل الدخول
if ! curl -f -s -o /dev/null "$BASE_URL/login"; then
  echo "FAIL: صفحة تسجيل الدخول لا يتم تحميلها"
  exit 1
fi

# التحقق من أن API يعيد 200 لنقطة نهاية حرجة
if ! curl -f -s -o /dev/null "$BASE_URL/api/v1/status"; then
  echo "FAIL: نقطة نهاية حالة API فشلت"
  exit 1
fi

echo "PASS: جميع اختبارات الدخان ناجحة"

قارن المقاييس قبل وبعد

تخبرك اختبارات الدخان أن التطبيق يعمل. تخبرك المقاييس ما إذا كان يعمل بشكل جيد.

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

• الطلبات في الثانية
• معدل الخطأ (نسبة الطلبات الفاشلة)
• متوسط وقت الاستجابة
• استخدام الذاكرة ووحدة المعالجة المركزية
• زمن استجابة استعلام قاعدة البيانات

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

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

التحقق من قاعدة البيانات يتطلب عناية إضافية

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

تحتاج إلى التحقق:

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

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

تحقق من التكاملات مع الأنظمة الأخرى

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

اختبر الاتصالات:

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

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

تحقق من منظور المستخدم

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

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

وثق ما وجدته

بعد اكتمال التحقق، اكتب ما حدث. يخدم هذا التوثيق غرضين:

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

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

قائمة تحقق عملية للتحقق

إليك قائمة تحقق قصيرة لاستخدامها بعد أي استرداد:

يوضح المخطط الانسيابي التالي تسلسل التحقق مع نقاط القرار في كل خطوة:

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

النهاية الحقيقية للحادثة

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

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