عندما يجعل انحراف البنية التحتية خطة Terraform الخاصة بك عديمة الفائدة

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

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

ماذا يعني الانحراف بالضبط

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

البنية التحتية لا تزال تعمل. التطبيقات لا تزال تعمل. لكن الكود الخاص بك لم يعد يصف الواقع. إنه يصف ما كان عليه الواقع في الماضي.

الخطة التي تكذب عليك

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

يوضح مخطط التدفق التالي كيف يخلق الانحراف عدم تطابق بين الكود والحالة والبنية التحتية الفعلية، مما يؤدي إلى خطة غير دقيقة:

flowchart TD A[تعريفات الكود] --> B[خطة Terraform] C[ملف الحالة] --> B D[البنية التحتية الفعلية] -.->|انحراف| C D -.->|غير متزامن| B B --> E[الخطة تظهر تغييرات غير مقصودة] style D fill:#f9f,stroke:#333,stroke-width:2px style E fill:#f96,stroke:#333,stroke-width:2px

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

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

ثلاث طرق يدمر بها الانحراف خط الأنابيب الخاص بك

تدمير غير متوقع

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

إضاعة وقت المراجعة

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

كسر الثقة في الأتمتة

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

لماذا يحدث الانحراف في الفرق الحقيقية

الانحراف ليس سببه مهندسون سيئون. يحدث لأن العمل الحقيقي يخلق مواقف يكون فيها خط الأنابيب ليس المسار الأسرع:

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

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

كشف الانحراف قبل أن يضر

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

تقدم معظم أدوات IaC ميزات كشف الانحراف. يحتوي Terraform Cloud و Enterprise على كشف انحراف يقوم بتشغيل الخطط وفقًا لجدول زمني وينبه عندما تختلف البنية التحتية الحقيقية عن الحالة. يتضمن OpenTofu، الشوكة مفتوحة المصدر لـ Terraform، قدرات مماثلة. يمكنك أيضًا بناء الكشف الخاص بك باستخدام تشغيلات خط أنابيب مجدولة تقارن الحالة بموارد السحابة الفعلية.

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

قائمة فحص عملية لكشف الانحراف

إذا كنت تدير البنية التحتية باستخدام IaC، ففكر في إضافة هذه الفحوصات إلى روتينك:

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

التكلفة الحقيقية لتجاهل الانحراف

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

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