عندما لا تتطابق حالة البنية التحتية مع الواقع

لقد قمت بإعداد البنية التحتية ككود. سواء اخترت Terraform أو Pulumi أو أي أداة أخرى. كل شيء مُتتبع، مُرقّم الإصدارات، وقابل للتكرار. ملف الحالة (state file) يقول إن خادم الإنتاج لديه 4 معالجات و16 جيجابايت من الذاكرة. الحياة جميلة.

ثم في يوم من الأيام، يسجل أحدهم الدخول إلى وحدة التحكم السحابية ويُغيّر حجم ذلك الخادم يدويًا. ربما كانت هناك مشكلة في الأداء، وكان على فريق الدعم التصرف بسرعة. ربما قام شخص ما بتشغيل سكربت لم يكن موجودًا في قاعدة الكود الخاصة بك. مهما كان السبب، ملف الحالة لا يزال يقول 4 معالجات و16 جيجابايت، لكن الخادم الفعلي يعمل الآن بـ 8 معالجات و32 جيجابايت.

هذه الفجوة بين ما يقوله ملف الحالة وما هو موجود بالفعل تُسمى الانحراف (Drift). وهي مشكلة أكبر مما يدركه معظم الفرق.

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

الانحراف ليس نادرًا. يحدث أكثر مما تتصور، وعادةً لأسباب مفهومة:

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

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

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

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

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

اكتشاف الانحراف: الطريقة البسيطة

النهج الأساسي لاكتشاف الانحراف هو المقارنة اليدوية. مع Terraform، يُظهر تشغيل terraform plan الفرق بين الكود الخاص بك، وحالتك، والبنية التحتية الفعلية. أي مورد تم تغييره خارج الكود الخاص بك سيظهر كتعديل غير متوقع.

إليك الأمر الذي يجب تشغيله وما الذي تبحث عنه:

# قم بتشغيل terraform plan بدون تغييرات في الكود لاكتشاف الانحراف
terraform plan

# مثال على الإخراج يظهر انحرافًا (لم يتم إجراء أي تغييرات على الكود)
# Terraform will perform the following actions:
#
#   # aws_instance.web_server will be updated in-place
#   ~ resource "aws_instance" "web_server" {
#       ~ instance_type = "t3.large" -> "t3.medium"
#         id            = "i-0abcd1234efgh5678"
#         tags          = {}
#         # (12 unchanged attributes hidden)
#     }
#
# Plan: 0 to add, 1 to change, 0 to destroy.

# أي تغييرات تظهر عندما لم تقم بتعديل الكود الخاص بك = انحراف

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

أتمتة اكتشاف الانحراف

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

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

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

ماذا تفعل عندما تجد انحرافًا

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

يُلخّص مخطط التدفق التالي المسارين الرئيسيين لمعالجة الانحراف:

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

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

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

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

بناء ممارسة لاكتشاف الانحراف

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

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

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

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

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

الخلاصة

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

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