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

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

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

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

لماذا يفشل الكشف اليدوي عن الانجراف

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

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

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

كيف يعمل الكشف الآلي عن الانجراف

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

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

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

إليك نص Bash بسيط يقوم بإجراء مسح انجراف وتنبيه فريقك عند العثور على انجراف:

#!/bin/bash
# drift-scan.sh - تشغيل مسح انجراف Terraform والإخطار بالتغييرات

set -euo pipefail

cd /path/to/terraform/project

terraform init -input=false

# تحديث الحالة من الموارد الحية، ثم التخطيط مع رمز خروج مفصل
terraform plan -refresh-only -detailed-exitcode -out=drift.tfplan
PLAN_EXIT_CODE=$?

if [ $PLAN_EXIT_CODE -eq 2 ]; then
    # رمز الخروج 2 يعني وجود تغييرات (تم اكتشاف انجراف)
    echo "تم اكتشاف انجراف في $(date)"
    
    # إنشاء ملخص قابل للقراءة البشرية
    terraform show drift.tfplan > drift-summary.txt
    
    # إرسال إشعار إلى Slack (اضبط رابط webhook)
    curl -X POST -H 'Content-type: application/json' \
        --data "{\"text\":\"🚨 تم اكتشاف انجراف في بيئة الإنتاج!\n$(cat drift-summary.txt)\"}" \
        https://hooks.slack.com/services/YOUR/WEBHOOK/URL
elif [ $PLAN_EXIT_CODE -eq 1 ]; then
    echo "حدث خطأ أثناء تنفيذ الخطة"
    exit 1
else
    echo "لم يتم اكتشاف أي انجراف"
fi

يمكن تشغيل هذا النص بواسطة وظيفة cron أو خط أنابيب CI/CD مجدول لتشغيله كل بضع ساعات.

يُظهر مخطط التدفق التالي دورة اكتشاف الانجراف الكاملة:

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

ما وراء الخطة الأساسية: الحصول على نتائج دقيقة

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

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

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

الجدولة والإشعارات

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

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

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

ماذا يحدث بعد الكشف

العثور على الانجراف هو الخطوة الأولى فقط. بمجرد أن تعرف بوجوده، لديك خياران.

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

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

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

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

إذا كنت تقوم بإعداد اكتشاف الانجراف لأول مرة، فإليك قائمة تحقق قصيرة للبدء:

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

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

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

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