بنيتك التحتية السحابية تبتعد عن الكود الخاص بك. إليك كيفية اكتشاف ذلك.

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

لكن هل انتهى حقًا؟

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

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

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

كيف يحدث الانجراف عمليًا

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

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

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

اكتشاف الانجراف قبل أن يسبب مشاكل

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

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

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

إليك أمر بسيط يمكنك تشغيله في خط أنابيب CI الخاص بك لاكتشاف الانجراف تلقائيًا:

#!/bin/bash
# Run terraform plan and exit with a non-zero code if drift is detected
terraform init -input=false
terraform plan -detailed-exitcode -input=false -out=tfplan
PLAN_EXIT_CODE=$?

if [ $PLAN_EXIT_CODE -eq 2 ]; then
  echo "Drift detected! Infrastructure does not match code."
  # Send alert to Slack or your incident management tool
  curl -X POST -H 'Content-type: application/json' \
    --data '{"text":"Drift detected in production environment. Run terraform apply to reconcile."}' \
    YOUR_SLACK_WEBHOOK_URL
  exit 1
elif [ $PLAN_EXIT_CODE -eq 1 ]; then
  echo "Error running terraform plan."
  exit 1
else
  echo "No drift detected. Infrastructure matches code."
fi

يستخدم هذا البرنامج النصي -detailed-exitcode للتمييز بين حالة نظيفة (رمز الخروج 0)، وخطأ (رمز الخروج 1)، وانجراف (رمز الخروج 2).

بناء اكتشاف الانجراف في خط الأنابيب الخاص بك

يبدو خط أنابيب اكتشاف الانجراف العملي كما يلي:

إليك نظرة عامة مرئية لخط أنابيب اكتشاف الانجراف:

flowchart TD A[Code Commit] --> B[Plan] B --> C[Apply] C --> D{Drift Check} D -- Periodic or Event-Triggered --> E{Drift Found?} E -- No --> D E -- Yes --> F[Alert Team] F --> G{Decision} G -- Revert --> H[Reconcile] G -- Accept --> I[Update Code] H --> D I --> D

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

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

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

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

التوفيق التلقائي: توخ الحذر

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

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

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

قائمة ممارسة عملية لاكتشاف الانجراف

إليك قائمة مختصرة لمساعدتك في البدء باكتشاف الانجراف:

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

ما يمنحك إياه اكتشاف الانجراف

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

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

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