خطط التعافي للتغييرات عالية المخاطر في البنية التحتية

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

ماذا الآن؟

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

ابدأ بسؤال واحد

تبدأ خطة التعافي بأكملها بسؤال واحد: إذا فشل هذا التغيير، ما الذي نحتاج إلى فعله لإعادة كل شيء إلى حالة آمنة؟

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

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

ثلاثة أشياء تحتاجها كل خطة تعافي

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

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

فيما يلي مثال ملموس لما تبدو عليه خطوات التعافي هذه لتغيير مجموعة أمان على AWS:

# خطة التعافي: التراجع عن تغيير مجموعة الأمان
# الهدف: sg-12345678 (طبقة الويب للإنتاج)

# الخطوة 1: التراجع عن قواعد مجموعة الأمان
aws ec2 revoke-security-group-ingress \
  --group-id sg-12345678 \
  --protocol tcp --port 443 --cidr 0.0.0.0/0

aws ec2 authorize-security-group-ingress \
  --group-id sg-12345678 \
  --protocol tcp --port 443 --cidr 10.0.0.0/16

# الخطوة 2: التحقق من صحة القواعد
aws ec2 describe-security-groups \
  --group-ids sg-12345678 \
  --query 'SecurityGroups[0].IpPermissions'

# الخطوة 3: تأكيد أن الخدمة قابلة للوصول
curl -s -o /dev/null -w "%{http_code}" https://api.example.com/health

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

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

  • على أساس الوقت: إذا لم يستقر النظام في غضون 15 دقيقة بعد تطبيق التغيير، ابدأ التعافي.
  • على أساس التأثير: إذا تجاوزت معدلات الخطأ 5 بالمائة، أو إذا أبلغ المستخدمون أنهم لا يستطيعون الوصول إلى الخدمة، ابدأ التعافي.

قم بتدوين هذه الحدود. لا تعتمد على تذكر الناس لها أثناء الحادث.

قائمة التحقق قبل التطبيق

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

تشمل العناصر الشائعة:

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

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

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

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

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

من يوافق على خطة التعافي

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

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

هذه ليست عملية ختم مطاطي. إذا كان الموافِق لا يفهم الخطة جيداً بما يكفي لتقييمها، فلا ينبغي له الموافقة عليها.

خزّن الخطة حيث يمكن للناس العثور عليها

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

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

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

قبل تطبيق تغيير عالي المخاطر على البنية التحتية، راجع ما يلي:

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

الاختبار الحقيقي يأتي أثناء التنفيذ

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

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