تدريبات الاسترداد: لماذا يجب أن تتدرب على الفشل قبل أن يصل إلى الإنتاج

منذ بضعة أشهر، كان لدى فريق عملت معه خطة استرداد موثقة جيدًا. كانت موجودة في الويكي الخاص بهم، مع رسوم بيانية، وإجراءات خطوة بخطوة، وقائمة بمن يجب الاتصال بهم عندما تسوء الأمور. شعر الجميع بالاستعداد. ثم في أحد أيام الثلاثاء مساءً، أفسد ترحيل قاعدة بيانات (migration) عمودًا يعتمد عليه خدمة الدفع (checkout service). فتح الفريق الويكي، واتبع خطوات الاسترجاع (rollback)، واكتشف أن السكريبت لم يعد يعمل. تغيير حديث في البنية التحتية أعاد تسمية بعض الموارد، لكن لم يقم أحد بتحديث خطة الاسترداد. ما كان يجب أن يكون استرجاعًا لمدة خمس دقائق تحول إلى معركة استمرت ساعتين.

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

المشكلة مع الخطط المكتوبة

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

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

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

كيف تبدو تدريبات الاسترداد

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

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

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

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

أكثر التدريبات قيمة هي تلك التي تلمس الأنظمة الحقيقية في بيئة اختبارية (staging) أو ما قبل الإنتاج (pre-production). هذا هو المكان الذي تعيش فيه الفجوات المخفية.

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

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

لماذا الفشل أثناء التدريبات قيم

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

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

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

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

ما تكشفه التدريبات أبعد من الخطوات التقنية

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

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

كم مرة يجب أن تتدرب

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

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

قائمة مراجعة سريعة لتدريبك الأول

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

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

لا تهدف إلى الكمال في المحاولة الأولى. اهدف إلى التعلم.

الخلاصة

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