من إرهاق التنبيهات إلى نوم هانئ: رحلتي مع دفاتر التشغيل الآلية (Automated Runbooks)

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

كنت أعرف الإجراءات عن ظهر قلب: تسجيل الدخول إلى الخادم، تشغيل أمر df -h للتأكد، ثم البحث عن الملفات الكبيرة التي يمكن حذفها بأمان، عادة ما تكون ملفات سجلات (logs) قديمة أو نسخ احتياطية مؤقتة. عملية روتينية ومملة، لكنها تحت ضغط الوقت وفي منتصف الليل، تبدو كأنها عملية جراحية في القلب. بعد نصف ساعة من التوتر والبحث، تم حل المشكلة. لكنني لم أستطع العودة إلى النوم، ظل الأدرينالين يتدفق في عروقي. في ذلك الصباح، ونحن نحتسي القهوة أنا وفريق العمل، وعلامات الإرهاق بادية على وجوهنا، قلت لهم: “يا جماعة، هذا الوضع لا يمكن أن يستمر. لازم نلاقي حل جذري، إحنا مهندسين مش فنيين طوارئ!”.

من هنا، بدأت رحلتنا مع ما يسمى بـ “دفاتر التشغيل الآلية” (Automated Runbooks)، المفهوم الذي نقلنا من إطفاء الحرائق يدوياً إلى بناء نظام إطفاء ذاتي. دعوني آخذكم في هذه الرحلة.

ما هي دفاتر التشغيل (Runbooks) أصلاً؟

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

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

المشكلة في الدفاتر اليدوية

كانت دفاترنا اليدوية مفيدة، لكنها كانت تعاني من مشاكل قاتلة:

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

هنا أدركنا أن المشكلة ليست في وجود “الوصفة”، بل في أننا ما زلنا نطبخها يدوياً في كل مرة.

الفجر الجديد: دفاتر التشغيل الآلية (Automated Runbooks)

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

الفكرة بسيطة: إذا كانت الخطوات معروفة ومحددة ويمكن كتابتها كأوامر، فلماذا لا نجعل الحاسوب ينفذها بنفسه؟

كيف يعمل هذا السحر؟

الأمر ليس سحراً، بل هو تطبيق ذكي لمبادئ DevOps و SRE (Site Reliability Engineering). العملية تسير كالتالي:

1. التنبيه (Alert): نظام المراقبة (مثل Prometheus أو Datadog) يكتشف مشكلة (مثل استخدام القرص 95%) ويرسل تنبيهاً.
2. الزناد (Trigger): بدلاً من إرسال التنبيه إلى هاتف المهندس مباشرة، يتم إرساله إلى أداة أتمتة (مثل Rundeck, StackStorm, Ansible Tower, أو حتى خدمة AWS Lambda).
3. التنفيذ (Execution): أداة الأتمتة تقوم بتشغيل “دفتر التشغيل الآلي” المخصص لهذا التنبيه. هذا الدفتر هو عبارة عن سكربت يقوم بتنفيذ سلسلة من المهام المبرمجة مسبقاً.
4. الإبلاغ (Reporting): بعد انتهاء التنفيذ (سواء نجح أم فشل)، يقوم السكربت بإرسال تقرير مفصل إلى قناة التواصل الخاصة بالفريق (مثل Slack أو Microsoft Teams) يوضح ما تم عمله والنتيجة.

في 90% من الحالات، يتم حل المشكلة تلقائياً، ويستلم المهندس المناوب رسالة صباحية لطيفة تقول: “مرحباً، حدثت مشكلة X الليلة الماضية، وقد قمت بحلها. إليك التفاصيل. استمتع بقهوتك.” وفي الـ 10% المتبقية، إذا فشل السكربت أو كانت المشكلة معقدة، عندها فقط يتم إيقاظ المهندس، ولكن مع تزويده بكل المعلومات والتشخيصات الأولية التي جمعها السكربت، مما يوفر عليه وقتاً ثميناً.

يلا نشتغل: بناء دفتر تشغيل آلي خطوة بخطوة

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

السيناريو: امتلاء مساحة القرص على خادم ويب

الهدف: أتمتة عملية تنظيف ملفات السجلات القديمة عند وصول استخدام القرص إلى 90%.

الخطوة 1: التشخيص والتأكيد

أولاً، يجب أن يتأكد السكربت من أن المشكلة حقيقية. لا تعتمد على التنبيه بشكل أعمى.

#!/bin/bash

# runbook-disk-cleanup.sh

# المتغيرات الأساسية
THRESHOLD=90
FILESYSTEM="/"
LOG_DIR="/var/log/app"
SLACK_WEBHOOK_URL="https://hooks.slack.com/services/T00000000/B00000000/XXXXXXXXXXXXXXXXXXXXXXXX"

# دالة لإرسال إشعارات إلى Slack
send_slack_notification() {
    local message=$1
    curl -X POST -H 'Content-type: application/json' --data "{"text":"[Automated Runbook] 🤖n$message"}" "$SLACK_WEBHOOK_URL"
}

# الحصول على نسبة استخدام القرص الحالية
CURRENT_USAGE=$(df "$FILESYSTEM" | grep "$FILESYSTEM" | awk '{ print $5 }' | sed 's/%//g')

echo "Current disk usage is $CURRENT_USAGE%"

الخطوة 2: الإجراء العلاجي (مع الأمان أولاً)

إذا تجاوز الاستخدام الحد المسموح، نبدأ في إجراءات التنظيف. من المهم جداً أن تكون هذه الإجراءات “آمنة” و “Idempotent” (أي أن تكرار تنفيذها لا يسبب مشاكل).

# ... (تكملة السكربت السابق)

if [[ "$CURRENT_USAGE" -gt "$THRESHOLD" ]]; then
    
    send_slack_notification "Disk usage at ${CURRENT_USAGE}% on $(hostname), which is above the ${THRESHOLD}% threshold. Starting automated cleanup..."
    
    # إجراء آمن: حذف ملفات السجلات المضغوطة التي يزيد عمرها عن 7 أيام
    # نستخدم -print أولاً في وضع الاختبار (Dry Run) للتأكد
    echo "Looking for log files older than 7 days in $LOG_DIR..."
    FILES_TO_DELETE=$(find "$LOG_DIR" -type f -name "*.log.gz" -mtime +7)

    if [[ -z "$FILES_TO_DELETE" ]]; then
        send_slack_notification "No old log files found to delete. Manual intervention might be required."
        exit 1 # الخروج برمز خطأ لتنبيه المهندس
    fi

    # تنفيذ الحذف الفعلي
    find "$LOG_DIR" -type f -name "*.log.gz" -mtime +7 -delete
    
    echo "Cleanup complete."

    # التحقق مرة أخرى بعد التنظيف
    NEW_USAGE=$(df "$FILESYSTEM" | grep "$FILESYSTEM" | awk '{ print $5 }' | sed 's/%//g')
    
    send_slack_notification "✅ Cleanup successful. Disk usage is now at ${NEW_USAGE}%."

else
    echo "Disk usage is normal. No action taken."
fi

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

نصائح من أبو عمر: كيف تبني دفاتر تشغيل آلية فعّالة؟

بناء هذه الأتمتة رحلة، وخلال رحلتي تعلمت بعض الدروس القاسية التي أود مشاركتها معكم:

• ابدأ صغيراً ومؤلماً: لا تحاول أتمتة كل شيء دفعة واحدة. اختر أكثر تنبيه متكرر ومزعج يوقظك ليلاً، وأتمت عملية حله. هذا الانتصار السريع سيعطيك الدافع للمتابعة.
• اجعلها قابلة للاختبار (Dry Run): أضف دائماً خيار “التشغيل الجاف” الذي يوضح ما كان سيفعله السكربت دون تنفيذه فعلياً. هذا لا يقدر بثمن عند التطوير والاختبار. (مثال: استخدام `echo` قبل أمر الحذف `rm`).
• الأمان أولاً وأخيراً: تعامل مع بيانات الاعتماد (Credentials) و مفاتيح الـ API بحذر شديد. استخدم أدوات مثل HashiCorp Vault أو AWS Secrets Manager. لا تقم أبداً بكتابتها مباشرة في السكربت.
• لا غنى عن التدخل البشري (Human in the loop): ليست كل الإجراءات يجب أن تكون آلية بالكامل. أحياناً، أفضل دفتر تشغيل هو الذي يجمع كل البيانات التشخيصية، ويقدمها للمهندس مع خيارين: “اضغط 1 للموافقة على الحل المقترح” أو “اضغط 2 لتصعيد المشكلة لي”.
• السكربت هو التوثيق الجديد: يجب أن يكون الكود مقروءاً وواضحاً مع تعليقات تشرح “لماذا” تم اتخاذ قرار معين، وليس فقط “ماذا” يفعله الأمر. هذا يساعد في صيانته مستقبلاً.

الخلاصة: نام مرتاح البال 😴

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

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