لماذا سيفشل خطة التعافي الخاصة بك بدون تدريب عملي

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

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

خطة التعافي تكون جيدة بقدر آخر مرة قام فيها شخص ما بتشغيلها فعليًا.

المشكلة مع الخطط غير المختبرة

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

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

الحل ليس توثيقًا أفضل. الحل هو الممارسة.

الفرق بين خطة غير مختبرة وأخرى مُمارس عليها يمكن رؤيته في هذه المقارنة:

flowchart TD A[خطة التعافي] --> B{مختبرة؟} B -->|لا| C[خطة غير مختبرة] C --> D[خطوات غامضة] D --> E[ثقة زائفة] E --> F[حادث حقيقي] F --> G[فشل تحت الضغط] B -->|نعم| H[خطة مُمارس عليها] H --> I[يوم لعب / محاكاة] I --> J[خطوات مُتحقق منها] J --> K[الفريق يثق بالخطة] K --> L[حادث حقيقي] L --> M[تعافي ناجح]

أيام اللعب: تدريب منظم على الفشل

الشكل الأكثر شيوعًا لاختبار خطط التعافي في فرق DevOps هو "يوم اللعب" (Game Day). يوم اللعب هو جلسة مجدولة حيث يقوم الفريق عمدًا بإنشاء سيناريو فشل في بيئة آمنة، عادةً ما تكون بيئة اختبارية أو بيئة مشابهة للإنتاج.

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

يوم اللعب النموذجي يعمل على النحو التالي:

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

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

هندسة الفوضى: اختبار آلي ومستمر

أيام اللعب هي أحداث مجدولة. هندسة الفوضى (Chaos Engineering) تأخذ نفس الفكرة وتجعلها مستمرة. أدوات مثل Chaos Monkey أو Gremlin يمكنها محاكاة حالات فشل محددة تلقائيًا: خادم يتعطل، اتصال قاعدة بيانات ينقطع، شهادة TLS تنتهي صلاحيتها.

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

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

محاكاة العمليات: اختبار التواصل، وليس فقط الكود

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

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

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

ماذا تفعل بالنتائج

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

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

إذا لم تتغير الخطة أبدًا، فإن الفريق لا يتعلم من التدريب.

قائمة مراجعة سريعة للبدء

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

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

لا تهدف إلى الكمال في الجلسة الأولى. اهدف إلى الاكتشاف. كل ثغرة تجدها هي ثغرة لن تفاجئك أثناء حادث حقيقي.

المقياس الوحيد الذي يهم

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

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