أذكر تلك الليلة جيداً، كانت الساعة تقارب الثانية صباحاً بتوقيت القدس. الهاتف بجانبي اهتز بعنف، ليس مرة، بل مرات متتالية. صوت تنبيه PagerDuty الحاد كان كفيلاً بإيقاظي من أعمق نوم. فتحت عينيّ بصعوبة لأرى شاشة الهاتف تومض بعشرات التنبيهات الحمراء: “High CPU Utilization on API Gateway”, “Latency Spike in Payment Service”, “Database Connection Pool Exhausted”. باختصار، “ولعت” يا جماعة.
قفزت من سريري، ركضت إلى مكتبي، وفتحت اللابتوب. قناة “الحرائق” (war-room) على سلاك كانت تشتعل بالإشارات (@here, @channel)، والأسئلة تتطاير في كل اتجاه: “شو القصة؟”, “مين اللي مداوم؟”, “هل المشكلة من آخر تحديث؟”. كل مهندس يحاول التشخيص من زاوية، أحدهم يعيد تشغيل الـ “pods” بشكل عشوائي، والآخر يحاول قراءة سجلات (logs) بحجم غيغابايتات، وأنا أحاول يائساً أن أجد وثيقة الـ “Runbook” على Confluence التي كتبها أحدهم قبل سنتين وأكل عليها الدهر وشرب.
بعد ساعتين من الفوضى والتوتر وتضارب المعلومات، تمكنا أخيراً من تحديد السبب وإصلاح المشكلة. لكن بعد أن هدأت العاصفة، ونحن منهكون، نظرنا إلى بعضنا البعض (افتراضياً عبر الكاميرات) وسألنا أنفسنا: هل هذا هو أفضل ما يمكننا فعله؟ لا يمكن أن نستمر بهذه الطريقة. كان لا بد من وجود حل جذري لهذه “الهوشة” التقنية المتكررة. ومن هنا، بدأت رحلتنا الحقيقية مع ما يسمى بـ “دفاتر التشغيل الآلية” (Automated Runbooks).
ما هي دفاتر التشغيل (Runbooks)؟ ولماذا لم تعد كافية؟
قبل أن نخوض في الحل السحري، دعونا نرجع خطوة للوراء. دفتر التشغيل، أو الـ Runbook، هو ببساطة دليل إرشادي يصف الإجراءات خطوة بخطوة للتعامل مع حادثة أو مهمة تشغيلية معينة.
الدفتر التقليدي: ويكيبيديا داخلية منسية
في الماضي، كانت هذه الدفاتر مجرد صفحات على نظام Wiki داخلي (مثل Confluence) أو مستندات Google Docs. تحتوي على شيء من هذا القبيل:
مشكلة: ارتفاع استخدام المعالج (CPU) في الخادم X
1. قم بتسجيل الدخول إلى الخادم عبر SSH:ssh user@server-x
2. استخدم أمرtopلتحديد العملية المستهلكة للموارد.
3. إذا كانت العملية Y، قم بأخذ memory dump.
4. أعد تشغيل الخدمة Z.
5. اتصل بالمهندس المناوب لفريق قواعد البيانات إذا استمرت المشكلة.
تبدو جيدة نظرياً، أليس كذلك؟ لكن في الواقع، هذه الطريقة مليئة بالثغرات:
- التقادم السريع: تتغير الأنظمة بسرعة، وتصبح هذه المستندات قديمة وغير صالحة للاستخدام. من منا لم يفتح وثيقة عمرها سنة ليجد أن الأوامر لم تعد تعمل؟
- صعوبة الوصول تحت الضغط: في منتصف الليل وأنت نصف نائم، آخر ما تريده هو البحث في عشرات الصفحات للعثور على الدليل الصحيح.
- الخطأ البشري: نسخ ولصق الأوامر بشكل خاطئ، أو تخطي خطوة مهمة، كلها أمور واردة جداً تحت الضغط والتوتر.
بالمختصر المفيد، الدفاتر التقليدية كانت أشبه بخريطة قديمة مرسومة باليد في عصر الـ GPS.
القفزة النوعية: دفاتر التشغيل الآلية (Automated Runbooks)
هنا تكمن الثورة. دفتر التشغيل الآلي ليس مجرد “وثيقة”، بل هو “كود قابل للتنفيذ”. إنه يحول الخطوات اليدوية المذكورة أعلاه إلى سكربت أو سير عمل (workflow) مؤتمت يعمل تلقائياً عند وقوع الحادثة.
من وثيقة إلى كود: تعريف الأتمتة
الفكرة بسيطة: بدلاً من أن تقرأ أنت الخطوات وتنفذها، يقوم النظام بتنفيذها نيابة عنك. هذا ما نسميه “الاستجابة ككود” (Response as Code). تبدأ العملية عادةً بـ “خطّاف” (Webhook) يرسله نظام المراقبة (مثل Prometheus أو Datadog) عند إطلاق تنبيه معين.
هذا الخطّاف يقوم بتشغيل منصة أتمتة (مثل Ansible, Rundeck, أو حتى دوال Serverless بسيطة)، والتي تبدأ بتنفيذ دفتر التشغيل الآلي خطوة بخطوة.
كيف تعمل في الواقع؟
- التنبيه يطلق العملية: نظام المراقبة يكتشف مشكلة (مثلاً، استجابة الخدمة بطيئة).
- التشخيص الآلي: يقوم الـ Runbook بتشغيل سلسلة من الأوامر التشخيصية: يفحص حالة الـ pods، يحلل آخر السجلات، يتأكد من حالة قاعدة البيانات، ويضرب على الـ health-check endpoints.
- التواصل الفوري: يقوم الـ Runbook فوراً بنشر رسالة آلية في قناة سلاك المخصصة للحوادث: “🚨 تنبيه: بطء في خدمة الدفعات. جاري الفحص الأولي وجمع المعلومات…”. هذا يطمئن الفريق ويمنع الفوضى الأولية.
- الإصلاح الآمن: بناءً على التشخيص، قد يحاول الـ Runbook إجراء إصلاح آمن ومعروف، مثل إعادة تشغيل خدمة غير حرجة (rolling restart).
- التصعيد الذكي: إذا فشلت كل المحاولات الآلية، أو إذا كانت المشكلة تتطلب تدخلاً بشرياً، يقوم الـ Runbook بتصعيد الأمر. لكنه لا يكتفي بإيقاظك، بل يرسل لك تقريراً كاملاً: “يا أبو عمر، فشلت محاولة الإصلاح الآلي لخدمة الدفعات. إليك نتائج التشخيص الأولية (استخدام الذاكرة، سجلات الأخطاء الأخيرة، حالة قاعدة البيانات). الآن دورك يا بطل!”.
مثال عملي: أتمتة الاستجابة لمشكلة “امتلاء القرص”
هذه المشكلة الكلاسيكية هي مرشح مثالي لأول دفتر تشغيل آلي لك.
السيناريو الكابوس (الطريقة القديمة)
تنبيه: “Disk space on server db-prod-01 is at 95%”. تستيقظ، تسجل دخولك، تشغل df -h، ثم تبدأ رحلة البحث المؤلمة مع du -sh * لتحديد الملفات الكبيرة، وتحذف بعض السجلات القديمة وأنت تدعو الله ألا تحذف شيئاً مهماً.
حلّ أبو عمر: دفتر التشغيل الآلي (باستخدام Ansible كمثال)
الآن، عندما يأتي التنبيه، يقوم Webhook بتشغيل Ansible Playbook بالنيابة عنا. هذا الـ Playbook يقوم بالتالي:
الخطوة الأولى: التشخيص والنشر
يقوم السكربت بالاتصال بالخادم، وجمع معلومات عن المساحة المستخدمة، وتحديد أكبر المجلدات في /var/log، ثم ينشر النتائج في قناة سلاك.
الخطوة الثانية: التنظيف الآمن
يقوم السكربت بتنفيذ إجراء تنظيف آمن ومحدد مسبقاً، مثل أرشفة ملفات السجلات التي يزيد عمرها عن 7 أيام وحذفها.
---
- name: Clean up old logs on critical servers
hosts: db_servers
become: yes
vars:
slack_channel: "#incidents"
slack_token: "{{ lookup('env', 'SLACK_API_TOKEN') }}"
tasks:
- name: Get initial disk space
command: df -h /
register: disk_space_before
- name: Post initial diagnostics to Slack
community.general.slack:
token: "{{ slack_token }}"
channel: "{{ slack_channel }}"
msg: "⚠️ Disk space alert on {{ inventory_hostname }}. Starting automated cleanup.nInitial state:n```{{ disk_space_before.stdout }}```"
- name: Find old log files to archive
find:
paths: /var/log/mysql
patterns: "*.log"
mtime: "+7d"
register: old_logs
- name: Archive and remove old log files
archive:
path: "{{ item.path }}"
dest: "/var/log/archives/{{ item.path | basename }}.{{ ansible_date_time.date }}.gz"
format: gz
remove: yes # This removes the original file after archiving
with_items: "{{ old_logs.files }}"
when: old_logs.files | length > 0
- name: Get final disk space
command: df -h /
register: disk_space_after
- name: Post final status to Slack
community.general.slack:
token: "{{ slack_token }}"
channel: "{{ slack_channel }}"
msg: "✅ Automated cleanup on {{ inventory_hostname }} complete. Archived {{ old_logs.files | length }} files.nFinal state:n```{{ disk_space_after.stdout }}```"
الخطوة الثالثة: التحقق والتصعيد
بعد تنفيذ التنظيف، يفحص السكربت المساحة مرة أخرى. إذا عادت إلى المستوى الطبيعي، يغلق التنبيه. إذا لم تحل المشكلة (ربما لأن هناك ملفاً كبيراً ليس ملف سجلات)، يقوم بتصعيد الأمر إلى المهندس المناوب مع كل المعلومات التي جمعها.
دمج الأتمتة مع ثقافة الفريق: ChatOps
الخوف الأكبر عند تطبيق الأتمتة هو فقدان السيطرة. هنا يأتي دور الـ ChatOps، وهو مفهوم يدمج أدواتك التشغيلية مباشرة في منصات المحادثة مثل Slack أو Microsoft Teams.
بدلاً من أن يقوم الـ Runbook بحذف الملفات مباشرة، يمكنه أن يتوقف ويسأل:
Bot: “لقد وجدت 5 غيغابايت من السجلات القديمة على الخادم
db-prod-01. هل أقوم بأرشفتها وحذفها؟”
[أزرار: نعم، قم بالأرشفة | لا، تجاهل]
بهذه الطريقة، يظل العنصر البشري هو صاحب القرار النهائي، لكن مع تزويده بكل المعلومات اللازمة وبضغطة زر. هذا يبني الثقة في النظام تدريجياً ويجعل عملية التبني أكثر سلاسة.
نصائح من خبرتي (من قلب الميدان)
- ابدأ صغيراً: لا تحاول أتمتة استجابة لانهيار كامل للنظام في اليوم الأول. ابدأ بمشكلة بسيطة، متكررة، ومنخفضة المخاطر مثل امتلاء القرص أو إعادة تشغيل خدمة معروفة.
- الأمان أولاً: أي إجراء يقوم بتعديل (مثل الحذف أو إعادة التشغيل) يجب أن يكون محصناً ضد الأخطاء. استخدم وضع “التشغيل الجاف” (Dry Run) أولاً، وتأكد من أن السكربت لا يسبب ضرراً إذا تم تشغيله عدة مرات (Idempotent).
- التوثيق هو الكود: جمال الأتمتة أن الكود (Ansible Playbook مثلاً) هو بحد ذاته التوثيق. إنه دائماً محدّث، لأنه إذا كان قديماً، ستفشل الأتمتة ببساطة.
- لا تستبدل البشر، بل مكّنهم: الهدف ليس التخلص من مهندسي الـ SRE، بل تحريرهم من الأعمال الروتينية المملة ليتفرغوا لحل المشاكل المعقدة وتحسين النظام على المدى الطويل.
- المراجعة الدورية: تعامل مع دفاتر التشغيل الآلية كأي جزء آخر من قاعدة الكود الخاصة بك. يجب أن تخضع للمراجعة، الاختبار، والتحديث المستمر.
الخلاصة: نوم هانئ للمبرمجين 😴
التحول من الاستجابة اليدوية الفوضوية إلى دفاتر التشغيل الآلية لم يكن مجرد تحسين تقني، بل كان تحولاً ثقافياً. النتائج كانت مذهلة: انخفاض هائل في متوسط وقت الإصلاح (MTTR)، تقليل الأخطاء البشرية بشكل شبه كامل، والأهم من ذلك كله، انخفاض مستوى التوتر في الفريق.
لم نعد نخشى رنين الهاتف في منتصف الليل. في معظم الأحيان، عندما نستيقظ في الصباح، نجد رسالة من البوت تقول: “حدثت مشكلة الليلة الماضية، ولكني قمت بحلها. تصبحون على خير”. هذا هو الهدوء الذي لا يقدر بثمن.
نصيحتي لك: ابدأ اليوم. اختر مهمة واحدة صغيرة ومزعجة، وقم بأتمتتها. قد تكون رحلة طويلة، لكن كل ليلة نوم هانئة ستحصل عليها أنت وفريقك ستكون هي الجائزة الكبرى. استثمروا في الأتمتة، فهي استثمار في أنظمتكم، وفي صحتكم النفسية أيضاً.
