عندما تنحرف بنيتك التحتية عن الكود

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

هذا الاختلاف له اسم: الانحراف (Drift).

ما يعنيه الانحراف فعليًا

الانحراف هو الفجوة بين ما يقول كود البنية التحتية الخاص بك أنه يجب أن يوجد وما يوجد فعليًا في مزود السحابة أو الخادم الخاص بك. ملفات Terraform أو Pulumi الخاصة بك تُعرّف الحالة المرغوبة (desired state). الموارد التي تعمل في AWS أو Google Cloud أو Azure تمثل الحالة الفعلية (actual state). عندما لا يتطابق الاثنان، يكون لديك انحراف.

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

ثلاث طرق يتسلل بها الانحراف

الانحراف لا يظهر لأن أحدهم ارتكب خطأ. يظهر لأن البنية التحتية تُدار بواسطة أشخاص حقيقيين تحت ضغط حقيقي.

يُظهر الرسم البياني أدناه كيف تتجاوز كل مسار خط أنابيب IaC المقصود وتؤدي إلى الانحراف.

flowchart TD A[المسار المقصود: خط أنابيب IaC] --> B[الحالة المرغوبة في الكود] C[تغيير يدوي عبر لوحة التحكم] --> D[تعديل مباشر] D --> E[انحراف] F[الاستجابة للحوادث] --> G[تغيير طارئ] G --> E H[أدوات خارجية / أدوات التوسع التلقائي] --> I[تغيير آلي خارج خط الأنابيب] I --> E B -.->|لا يوجد انحراف| J[الحالة الفعلية تطابق الكود] E --> K[الحالة الفعلية != الكود]

التغييرات اليدوية

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

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

الاستجابة للحوادث

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

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

الأدوات والعمليات الخارجية

ليس كل انحراف يأتي من فعل بشري. أدوات التوسع التلقائي (Autoscalers) تضيف وتزيل المثيلات بناءً على الحمل. أدوات الأمان تطبق السياسات من خلال آليات منفصلة. أنظمة إدارة الأسرار (Secrets management) تقوم بتدوير بيانات الاعتماد تلقائيًا. أدوات إدارة التكوين (Configuration management) تحدث المعاملات خارج خط أنابيب IaC الخاص بك.

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

لماذا يهم الانحراف

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

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

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

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

الانحراف ليس علامة فشل

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

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

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

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

إذا كنت تدير بنية تحتية باستخدام IaC، إليك قائمة فحص قصيرة لبدء التعامل مع الانحراف:

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

ما يأتي بعد ذلك

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

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