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

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

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

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

المشكلة في افتراض أن كل انحراف سيء

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

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

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

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

عندما يجعل التوقيت الأمور أسوأ

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

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

التحكم في المخاطر دون التخلي عن الأتمتة

الجواب ليس تعطيل المصالحة التلقائية بالكامل. الجواب هو بناء ضوابط تتوافق مع كيفية عمل العمليات الحقيقية.

المخطط الانسيابي التالي يوضح حلقة المصالحة التلقائية الإشكالية وأين تتدخل الضوابط المقترحة.

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

بوابات الموافقة للمصالحة

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

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

نوافذ المصالحة

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

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

تجميد التغييرات

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

قواعد استثناء للموارد الديناميكية

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

على سبيل المثال، في Terraform يمكنك استخدام كتلة lifecycle مع ignore_changes لمنع خط الأنابيب من التراجع عن التعديلات الديناميكية المشروعة:

resource "aws_autoscaling_group" "app" {
  name               = "production-app-asg"
  min_size           = 2
  max_size           = 10
  desired_capacity   = 4
  launch_configuration = aws_launch_configuration.app.id
  vpc_zone_identifier = ["subnet-abc123", "subnet-def456"]

  lifecycle {
    ignore_changes = [
      desired_capacity,
      min_size,
      max_size,
    ]
  }
}

هذا يخبر Terraform بتجاهل التغييرات في باراميترات التوسع، بحيث لا يتم التراجع عن التوسع اليدوي أثناء ارتفاعات الحمل.

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

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

قبل تمكين المصالحة التلقائية لأي مجموعة موارد، تحقق من هذه النقاط:

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

الخلاصة الحقيقية

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

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

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