عندما ينحرف البنية التحتية: كيف تقرر إصلاحه أم قبوله

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

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

السؤال ليس ما إذا كان الانحراف سيحدث. سيحدث. السؤال الحقيقي هو ما الذي تفعله بعد اكتشافه.

المسارات الثلاثة للتصحيح (Reconciliation)

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

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

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

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

الخيار الأكثر وضوحًا هو تشغيل الأنبوب مرة أخرى دون تغيير أي كود. تأخذ البنية التحتية ككود (IaC) الحالية، وتبقيها كما هي، وتنفذ خطوة التطبيق. ستقارن أدوات مثل Terraform أو Pulumi أو AWS CloudFormation ملف الحالة مقابل الموارد الفعلية وتجري التعديلات اللازمة لاستعادة كل شيء إلى ما يحدده الكود.

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

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

المسار الثاني: تبني الانحراف

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

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

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

المسار الثالث: التصحيح اليدوي

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

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

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

من يجب أن يقرر؟

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

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

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

قائمة مراجعة عملية لقرارات التصحيح

قبل أن تتصرف بناءً على تنبيه اكتشاف الانحراف، راجع هذه الأسئلة:

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

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

التصحيح ليس النهاية

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

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

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

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