يا جماعة الخير، السلام عليكم ورحمة الله.
بتذكر ليلة من ليالي الشتا الباردة، الساعة كانت حوالي 2 بعد نص الليل. تلفوني برن بنغمة الطوارئ اللي كل مهندس بيعرفها وبيكرهها. لمحة سريعة على الشاشة: “CRITICAL: Database CPU at 100%”. قلبي نزل عند ركبي. هاي مش أول مرة، بس كل مرة إحساس العجز والفوضى هو نفسه.
دخلنا كلنا على مكالمة طارئة: أنا، والمهندس المسؤول عن قواعد البيانات، ومهندسة من فريق البنية التحتية. الأصوات متوترة، وكل واحد فينا بحاول “يتذكر” شو عملنا آخر مرة صارت نفس المشكلة. واحد بدور في ملفات Confluence قديمة ومغبرة، والثاني بحاول يعمل SSH على السيرفر وبيصرخ “مين اللي شغال ع السيرفر معي؟”، والثالث بحاول يلاقي سجلات (logs) مفيدة وسط بحر من البيانات. قضينا ساعة ونص في حالة من الفوضى المنظمة (أو غير المنظمة بالأحرى)، لحد ما واحد فينا بالصدفة تذكر إنه لازم يعمل restart لخدمة معينة كانت عالقة.
بعد ما انحلت المشكلة ورجع كل شي طبيعي، ما قدرت أرجع أنام. ظل سؤال واحد يطن في راسي: “ليش كل مرة بنمر بنفس الجحيم؟ إحنا مهندسين ومبرمجين، شغلنا نحل المشاكل بشكل دائم، مش نضل نطفي حرايق بنفس الطريقة الغبية كل مرة”.
هذيك الليلة كانت نقطة التحول. كانت الليلة اللي قررنا فيها نودع دفاتر التشغيل اليدوية ونتبنى مفهوم غيّر طريقة عملنا تماماً: دفاتر التشغيل كشيفرة (Runbooks as Code).
ما هي دفاتر التشغيل (Runbooks) أصلاً؟ وليش بطلت كافية؟
خلينا نكون صريحين، فكرة الـ Runbook مش جديدة. هي ببساطة مجموعة من التعليمات والإجراءات الموثقة اللي بتساعد المهندسين على التعامل مع حادثة معينة. زمان، كانت هاي الدفاتر عبارة عن ملفات Word أو صفحات Wiki أو حتى مستندات Google Docs.
المشكلة في هاي الطريقة التقليدية، واللي عانينا منها الأمرين، هي:
- بتصير قديمة بسرعة (Outdated): البيئة التقنية بتتغير كل يوم. الكود اللي بتكتبه اليوم، ممكن يتغير بكرة. المستند اللي كتبته قبل 6 أشهر لحل مشكلة، على الأغلب صار عديم الفائدة اليوم.
- صعبة التحديث والمراجعة: مين آخر واحد عدّل على المستند؟ وهل التعديل صحيح؟ ما في طريقة سهلة لمراجعة التغييرات والموافقة عليها زي ما بنعمل مع الكود.
- عرضة للخطأ البشري: في عز التوتر والضغط الساعة 3 الفجر، احتمالية إنك تقرأ خطوة غلط أو تنسخ أمر بشكل خاطئ عالية جداً.
- بطيئة وغير فعالة: البحث عن المستند الصحيح، وقراءة التعليمات خطوة بخطوة، وتطبيقها يدوياً… كل هذا بياخذ وقت ثمين خلال الحادثة.
زي ما بنحكي عنا، “المكتوب بضل مكتوب، بس التكنولوجيا ما بتستنى المكتوب”. دفاتر التشغيل التقليدية صارت مثل خريطة ورقية قديمة في عالم الـ GPS.
المنقذ: دفاتر التشغيل كشيفرة (Runbooks as Code)
الفكرة بكل بساطة وعبقرية: بدل ما نوثق خطوات حل المشكلة في مستند نصي، ليش ما نكتبها على شكل شيفرة (كود) أو سكربت؟ ليش ما نعامل إجراءات التشغيل والاستجابة للحوادث بنفس الطريقة اللي بنعامل فيها كود التطبيق تبعنا؟
هذا يعني أن دفاتر التشغيل بتصير عبارة عن سكربتات (Bash, Python, PowerShell) أو ملفات إعداد (Ansible, Terraform) مخزنة في نظام إدارة إصدارات مثل Git.
ليش هاي الفكرة عبقرية؟
- التحكم في الإصدارات (Version Control): باستخدام Git، بنقدر نعرف مين غيّر وشو غيّر ومتى. لو في تحديث جديد سبب مشكلة، بنقدر نرجع للإصدار القديم بضغطة زر.
- المراجعة والتعاون (Code Review): أي تغيير على دفتر التشغيل بمر عبر عملية Pull Request (أو Merge Request). الفريق كله بيقدر يراجع التغييرات، يقترح تحسينات، ويوافق عليها قبل ما يتم دمجها. هذا بيضمن جودة الإجراءات وبيشارك المعرفة بين أعضاء الفريق.
- الأتمتة (Automation): بما إنها كود، فهي قابلة للتنفيذ! بدل ما المهندس ينسخ ويلصق الأوامر، ممكن يشغّل سكربت واحد وهو بيقوم بكل الخطوات اللازمة. هذا بيقلل الأخطاء البشرية بشكل هائل وبيسرّع عملية الاستجابة.
- الاختبار (Testing): بتقدر تختبر دفاتر التشغيل تبعتك! ممكن تعمل بيئة اختبارية وتشغّل السكربتات عليها بشكل دوري لتتأكد إنها لسا شغالة وبتعمل المطلوب منها قبل ما تحتاجها في حادثة حقيقية.
- مصدر الحقيقة الوحيد (Single Source of Truth): ما في مجال للاختلاف بين التوثيق والتنفيذ. الكود هو التوثيق، والكود هو ما يتم تنفيذه.
كيف نبدأ رحلتنا مع Runbooks as Code؟ (خطوات عملية)
يمكن الموضوع يبين كبير ومعقد في البداية، بس صدقني، البدء أسهل مما بتتخيل. هاي هي الخطوات اللي اتبعناها:
الخطوة الأولى: اختار الحادثة الصح
لا تحاول أتمتة كل شيء من أول يوم. ابدأ بشيء صغير ومتكرر ومؤلم. عنا، كانت مشكلة “امتلاء مساحة القرص” (Disk space full) على أحد السيرفرات مشكلة متكررة ومزعجة. الإجراءات لحلها كانت معروفة: تسجيل الدخول، تحديد الملفات الكبيرة، حذف الملفات المؤقتة، وإرسال تقرير. هاي كانت المرشح المثالي للبدء.
الخطوة الثانية: كتابة الشيفرة (الكود)
اكتب سكربت بسيط يقوم بالخطوات اللي كنت بتعملها يدوياً. مش ضروري يكون مثالي من أول مرة. سكربت Bash بسيط ممكن يكون كافي جداً.
مثال: سكربت بسيط لتشخيص وتنظيف القرص
#!/bin/bash
# runbook-cleanup-disk.sh
# A simple runbook to diagnose and clean up disk space on a given path.
FILESYSTEM=$1
THRESHOLD=90 # Trigger cleanup if usage is above 90%
if [ -z "$FILESYSTEM" ]; then
echo "Usage: $0 <filesystem_path>"
exit 1
fi
# 1. Check current disk usage
USAGE=$(df -h "$FILESYSTEM" | awk 'NR==2 {print $5}' | sed 's/%//')
echo "Current usage for $FILESYSTEM is $USAGE%"
if [ "$USAGE" -lt "$THRESHOLD" ]; then
echo "Disk usage is below threshold. No action needed."
exit 0
fi
# 2. Log the top 10 largest files/directories
echo "Disk usage is high. Finding top 10 largest items in $FILESYSTEM..."
du -ah "$FILESYSTEM" | sort -rh | head -n 10 > "/tmp/large_files_${FILESYSTEM////_}.log"
echo "Report saved to /tmp/large_files_${FILESYSTEM////_}.log"
# 3. Perform cleanup (Example: delete .log files older than 7 days)
echo "Cleaning up old log files..."
find "$FILESYSTEM" -name "*.log" -mtime +7 -exec rm -f {} ;
echo "Cleanup complete."
# 4. Report final disk usage
FINAL_USAGE=$(df -h "$FILESYSTEM" | awk 'NR==2 {print $5}' | sed 's/%//')
echo "Final usage for $FILESYSTEM is $FINAL_USAGE%"
هذا السكربت البسيط يقوم بالتشخيص، تسجيل المعلومات المهمة، اتخاذ إجراء تنظيف بسيط، ثم الإبلاغ عن النتيجة. هذا أفضل بألف مرة من العمل اليدوي.
الخطوة الثالثة: التكامل مع أدواتك
القوة الحقيقية بتظهر لما تربط هاي السكربتات مع أنظمة المراقبة والإشعارات. باستخدام أدوات مثل Prometheus Alertmanager, Jenkins, Rundeck, أو حتى Webhooks بسيطة، بتقدر تخلي التنبيه (Alert) يشغّل الـ Runbook المناسب تلقائياً.
مثلاً، ممكن إعداد تنبيه “Disk Usage > 90%” ليقوم تلقائياً بتشغيل سكربت التشخيص (بدون الحذف)، وإرسال التقرير الناتج إلى قناة Slack المخصصة للحوادث. هذا بيعطي المهندس كل المعلومات اللي بيحتاجها لاتخاذ قرار سريع.
نصائح من قلب الميدان (من خبرة أبو عمر)
بعد ما قطعنا شوط في هاي الرحلة، هاي شوية نصائح من خبرتي الشخصية:
- ابدأ بسيطًا ولا تفرط في الهندسة: مش لازم تبني نظام أتمتة معقد من أول يوم. سكربت بسيط وموثوق أفضل من منصة ضخمة وغير مكتملة.
- اجعلها قابلة للاكتشاف: ضع كل سكربتات الـ Runbooks في مستودع Git واحد وواضح. في وصف التنبيه نفسه، ضع رابط مباشر للـ Runbook المتعلق به.
- الأمان أولاً وأخيراً: السكربتات اللي بتشتغل على بيئة الإنتاج خطيرة. تأكد من أنها لا تحتوي على كلمات سر أو مفاتيح وصول بشكل مباشر. استخدم أدوات إدارة الأسرار (Secrets Management) مثل HashiCorp Vault أو AWS Secrets Manager. أعطِ السكربتات أقل صلاحيات ممكنة لتأدية عملها. زي ما بنحكي، “مش أي واحد معه مفتاح كل الدار”.
- لا تستهدف الأتمتة الكاملة دائماً: أحياناً، أفضل runbook هو اللي بيعمل كل التشخيصات وبيجمع كل المعلومات، وبعدين بيوقف وبينتظر قرار بشري. هذا النهج، اللي يسمى “Human in the loop”، يبني الثقة في النظام ويمنع الأتمتة من اتخاذ قرارات خاطئة في حالات غير متوقعة.
- التوثيق داخل الكود: علّق على الكود تبعك. اشرح ليش عملت هاي الخطوة. تخيل إنه في مهندس جديد، الساعة 3 الفجر، بحاول يفهم شو السكربت بيعمل. ساعده!
الخلاصة: استثمار في راحة البال
التحول إلى “دفاتر التشغيل كشيفرة” ما كان مجرد تغيير تقني، بل كان تغييراً في الثقافة. انتقلنا من فريق بيعيش في حالة “إطفاء حرائق” دائمة إلى فريق بيبني أدوات موثوقة ومستدامة. صرنا نقضي وقتنا في تحسين النظام بدل ما نصلح نفس الأخطاء مراراً وتكراراً.
الليالي اللي بنصحى فيها على طوارئ قلت بشكل كبير، وحتى لما نصحى، بتكون الفوضى أقل والتوتر أخف، لأنه عنا نظام واضح ومؤتمت بيساعدنا. بنضغط زر أو بنكتب أمر واحد، وبنراقب الأتمتة وهي بتقوم بالشغل الممل والمتكرر بدالنا.
يا جماعة، الاستثمار في أتمتة دفاتر التشغيل هو استثمار في راحة بال فريقكم وفي استقرار منتجكم. ابدأوا اليوم، ولو بخطوة صغيرة، وراح تدعولي. 😉
