عندما تؤدي تغييرات البنية التحتية إلى تعطيل الإنتاج: التعافي من كوارث البنية التحتية كرمز

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

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

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

لماذا يختلف استرجاع البنية التحتية

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

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

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

مفتاح استرجاع البنية التحتية الآمن يتلخص في شيئين: إدارة الحالة وإصدار التهيئة.

إدارة الحالة: اعرف ما لديك

أدوات البنية التحتية كرمز مثل Terraform أو Pulumi أو OpenTofu تحتفظ بملف حالة. يسجل هذا الملف كل مورد تديره الأداة، وتهيئته الحالية، وكيفية ارتباط الموارد ببعضها البعض. بدون حالة دقيقة، لا يمكن للأداة معرفة ما هو موجود، ناهيك عن كيفية تغييره.

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

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

إصدار التهيئة: اعرف ما كان لديك

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

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

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

التخطيط للاسترجاع قبل التطبيق

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

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

على سبيل المثال، إذا كان التغيير في مورد واحد مثل مثيل EC2 هو سبب المشكلة، يمكنك استهداف هذا المورد تحديدًا:

# احفظ الحالة الحالية قبل تطبيق أي تغيير
terraform state pull > state-backup-$(date +%Y%m%d-%H%M%S).json

# طبق التهيئة السابقة للمورد الإشكالي فقط
terraform apply -auto-approve -target=aws_instance.web

# تحقق من الاسترجاع باستخدام فحوصات الصحة
terraform output instance_health

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

عندما لا يكون الاسترجاع كافيًا

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

يوضح مخطط التدفق التالي عملية اتخاذ القرار عندما يتسبب تغيير في تعطيل الإنتاج:

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

لهذه الحالات، تحتاج إلى استراتيجيات استرداد تتجاوز الاسترجاع:

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

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

اختبر استرجاعك

خطة الاسترجاع التي لم يتم اختبارها أبدًا ليست خطة. إنها أمنية.

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

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

بعد الاسترجاع: تعلم ووثق

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

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

قائمة التحقق العملية للاستعداد لاسترجاع البنية التحتية

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

الخلاصة الملموسة

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