عندما تتعطل تغييرات البنية التحتية: دليل عملي خطوة بخطوة للاسترداد

تحول مسار CI/CD إلى اللون الأحمر. عملية terraform apply التي كان من المفترض أن تستغرق دقيقتين تعمل منذ خمس عشرة دقيقة. لوحة مراقبتك تظهر خمسة موارد فشل إنشاؤها، وفحوصات صحة موازن التحميل ترجع أخطاء 503. قناة الدردشة هادئة الآن، لكنك تعلم أن هذا الصمت لن يدوم.

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

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

الخطوة 1: تأكيد الفشل

لا ينبغي أن تأتي أول علامة على وجود مشكلة من شكوى مستخدم. يجب أن تأتي من مسار CI/CD وأنظمة المراقبة الخاصة بك. يتضمن مسار CI/CD المصمم جيداً لتغييرات البنية التحتية نقاط تفتيش تتحقق من كل خطوة: هل تم إنشاء المورد بنجاح؟ هل التكوين صحيح؟ هل الخدمة لا تزال تستجيب بشكل صحيح؟

إليك ما يبدو عليه تأكيد الفشل النموذجي في الممارسة العملية:

# التحقق من مخرجات خطة Terraplan بحثاً عن الأخطاء
terraform plan -var-file=production.tfvars

# مثال على مخرجات تظهر فشلاً واضحاً
# Error: Error creating security group: InvalidGroup.Duplicate: The security group 'web-sg' already exists
#   on main.tf line 42, in resource "aws_security_group" "web":
#   42: resource "aws_security_group" "web" {

# التحقق من سجلات المسار للوظيفة الفاشلة
curl -s https://pipeline.internal/api/v1/jobs/12345/logs | tail -50

# مقتطف من السجل
# [ERROR] Terraform apply failed: Error creating security group: InvalidGroup.Duplicate
# [INFO] Retry attempt 1/3...
# [ERROR] Terraform apply failed: Error creating security group: InvalidGroup.Duplicate

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

ما يجب التحقق منه:

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

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

الخطوة 2: تحديد استراتيجية الاسترداد

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

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

يلخص المخطط الانسيابي التالي عملية اتخاذ القرار:

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

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

ثلاث استراتيجيات استرداد شائعة:

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

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

الخطوة 3: تنفيذ الاسترداد

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

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

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

الخطوة 4: التحقق من الاسترداد

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

التحقق يعني فحص طبقات متعددة:

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

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

الخطوة 5: الإبلاغ عن النتيجة

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

يجب أن يتضمن الإبلاغ الواضح ما يلي:

  • ما الخطأ الذي حدث
  • ما تم فعله للاسترداد
  • ما إذا كان الاسترداد ناجحاً
  • أي مخاطر أو ملاحظات مستمرة

هذا يمنع التغييرات المتداخلة ويقلل من الارتباك. كما يساعد الفرق الأخرى على تعديل خططها إذا لزم الأمر.

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

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

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

العمل الحقيقي يبدأ بعد الاسترداد

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

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

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