عندما تفشل تغييرات البنية التحتية: خيارات الاسترداد من إعادة التطبيق إلى التبديل الاحتياطي

لقد نفذت للتو terraform apply على البنية التحتية للإنتاج. المخرجات تبدو نظيفة. لا أخطاء. ثم ينطلق تنبيه المراقبة: المستخدمون لا يستطيعون الاتصال بقاعدة البيانات. تغيير مجموعة الأمان الذي قمت به قد منع طبقة التطبيق عن طريق الخطأ.

ماذا تفعل الآن؟

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

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

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

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

إذا كنت تستخدم Terraform، فهذا يعني تشغيل terraform apply مع ملف الحالة السابق أو التكوين. نفس الفكرة تنطبق على Pulumi أو CloudFormation أو أي أداة بنية تحتية ككود. أنت تطلب من النظام استعادة النسخة المعروفة والصحيحة من تعريف البنية التحتية الخاصة بك.

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

إليك تسلسل أوامر ملموس لإعادة تطبيق الحالة القديمة:

# 1. تحقق من وجود ملف الحالة السابق
ls -la terraform.tfstate.backup

# 2. استعادة الحالة السابقة (يكتب فوق الحالة الحالية)
cp terraform.tfstate.backup terraform.tfstate

# 3. معاينة التغييرات التي سيقوم بها Terraform للتراجع
terraform plan -state=terraform.tfstate

# 4. تطبيق الحالة القديمة لاستعادة البنية التحتية
terraform apply -state=terraform.tfstate -auto-approve

ملاحظة: تحقق دائمًا من صحة ملف الحالة الاحتياطي قبل التطبيق. قم بتشغيل terraform state list -state=terraform.tfstate.backup للتأكد من أنه يحتوي على الموارد المتوقعة.

المشكلة: تحتاج إلى أن تكون الحالة القديمة لا تزال موجودة. إذا كان فريقك يحذف ملفات الحالة القديمة أو إذا قام مزود البنية التحتية بجمع القمامة (garbage-collected) لبعض الموارد، فقد لا يكون لديك ما تعيد تطبيقه. أيضًا، هذا النهج يواجه صعوبة مع الموارد ذات الحالة (stateful resources). لا يمكنك فقط إعادة تطبيق تكوين قاعدة بيانات قديم وتتوقع عودة البيانات إلى حالتها السابقة.

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

استعادة اللقطة (Snapshot Restore)

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

قبل إجراء تغيير على قاعدة بيانات أو نظام ملفات أو أي مورد ذي حالة، التقط لقطة. يقدم موفرو الخدمات السحابية هذا للحجوم (volumes) وقواعد البيانات وحاويات التخزين. تلتقط اللقطة حالة المورد في نقطة زمنية محددة.

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

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

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

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

التراجع عبر DNS

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

يعمل التراجع عبر DNS على مستوى توجيه حركة المرور. بدلاً من التراجع عن تغيير البنية التحتية، توجه حركة المرور إلى البنية التحتية القديمة التي لا تزال تعمل.

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

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

لكن هناك شرط حاسم: يجب أن تظل البنية التحتية القديمة موجودة. إذا كانت عملية النشر الخاصة بك تدمر الموارد القديمة عند إنشاء موارد جديدة، فإن التراجع عبر DNS ليس خيارًا. تعمل هذه الاستراتيجية بشكل طبيعي مع عمليات النشر الأزرق-الأخضر (blue-green deployments) أو الإصدارات التجريبية (canary releases)، حيث تعمل الإصدارات القديمة والجديدة جنبًا إلى جنب.

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

التبديل الاحتياطي إلى بيئة بديلة (Failover to a Standby Environment)

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

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

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

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

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

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

اختيار الخيار الصحيح

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

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

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

المخطط الانسيابي التالي يربط سيناريوهات الفشل الشائعة بمسار الاسترداد الموصى به:

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

قائمة تحقق عملية قبل تغيير البنية التحتية التالي

قبل تشغيل terraform apply التالي أو دفع تغيير تكوين، راجع قائمة التحقق هذه:

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

الخلاصة العملية

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

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