يا جماعة الخير، اسمحوا لي أن أرجع بالذاكرة معكم لبضع سنوات. كانت الساعة تقريباً الثالثة فجراً في ليلة شتاء باردة، وصوت الهاتف يصرخ بجانبي وكأنه إنذار حرب. لم يكن إنذاراً عادياً، بل كان تنبيه “P1” من نظام المراقبة، يعني “مصيبة وكارثة قومية” بلغة المهندسين. الرسالة كانت واضحة وموجزة كالعادة: “High CPU utilization on primary-db-cluster”.
قفزت من السرير، عيوني نصف مغلقة، وأنا أركض باتجاه مكتبي. قلبي يدق بسرعة، ليس فقط من صحوة النوم المفاجئة، بل من ضغط المسؤولية. فتحت اللابتوب، وبدأت رحلة البحث عن “كتيب التشغيل” (Runbook) الخاص بهذه المشكلة على صفحة Confluence الداخلية للشركة. الصفحة طويلة، مليئة بالخطوات والأوامر التي يجب نسخها ولصقها، وصور الشاشة التي لم تُحدّث منذ شهور. هل أستخدم هذا الأمر أم ذاك؟ هل يجب أن أتصل بالمهندس الأقدم الآن وأوقظه هو الآخر؟ كل ثانية تمر والضغط يزداد، والمستخدمون قد بدأوا يشعرون ببطء في النظام.
بعد حوالي 25 دقيقة من التوتر، والتعرق، ونسخ ولصق الأوامر في الطرفية (Terminal)، تمكنت من تحديد العملية التي تستهلك الموارد وإعادة تشغيلها. عادت الأمور إلى طبيعتها، لكن النوم لم يعد إلى عيوني. بقيت أفكر: “هل يعقل أن نكرر هذه المسرحية المأساوية كل أسبوع؟ ألسنا مبرمجين ومطورين؟ لماذا نتعامل مع أنظمتنا وكأننا في العصر الحجري الرقمي؟” هذه الليلة كانت الشرارة التي أشعلت ثورة الأتمتة في فريقنا، ثورة كان بطلها “كتيب التشغيل الآلي”.
ما هي “كتيبات التشغيل” (Runbooks) أصلاً؟
قبل أن نغوص في عالم الأتمتة، دعونا نوضح المفهوم الأساسي. كتيب التشغيل، أو الـ Runbook، هو ببساطة مجموعة من التعليمات والإجراءات الموثقة التي يشرحها فريق الهندسة لحل مشكلة معينة أو لتنفيذ عملية محددة. فكر فيه كـ “كتيّب وصفات” للمشاكل التقنية.
الكتيب التقليدي (الذي كان يجلطنا):
- عادة ما يكون على شكل صفحة Wiki (مثل Confluence) أو مستند Google Docs.
- يحتوي على خطوات متسلسلة: “1. اتصل بالخادم عبر SSH”، “2. نفّذ الأمر top”، “3. ابحث عن العملية X”… وهكذا.
- مليء بالأوامر التي يجب نسخها ولصقها يدوياً.
مشكلة هذه الكتيبات أنها مثل الخرائط الورقية القديمة في عصر Google Maps. هي مفيدة، لكنها تصبح قديمة بسرعة، ومن الصعب استخدامها تحت الضغط، وتعتمد كلياً على مهارة الشخص الذي يقرأها.
مرحباً بالأتمتة: ولادة “كتيبات التشغيل الآلية” (Automated Runbooks)
كتيب التشغيل الآلي هو النقلة النوعية. بدلاً من أن يكون مجرد “وصفة” يقرأها المهندس، يصبح “طاهياً آلياً” ينفذ الوصفة بنفسه. إنه عبارة عن سكربت أو مجموعة من السكربتات التي تقوم بتنفيذ الخطوات التشخيصية أو حتى العلاجية بشكل تلقائي عند وقوع حادثة معينة.
الفرق الجوهري هو الانتقال من “ماذا تفعل” إلى “دع الآلة تفعل ذلك”.
كيف أنقذتنا كتيبات التشغيل الآلية من جحيم المناوبة؟
عندما بدأنا في تحويل كتيباتنا اليدوية المزعجة إلى سكربتات آلية، بدأت المعجزات تحدث:
1. من دقائق الرعب إلى ثوانٍ من الهدوء
تخيل معي السيناريو الجديد: الساعة الثالثة فجراً، يرن التنبيه. لكن هذه المرة، وقبل أن أفتح اللابتوب حتى، تصلني رسالة أخرى على Slack من البوت الخاص بنا:
“🚨 تنبيه: استخدام عالٍ لوحدة المعالجة المركزية على primary-db-cluster. بدء تشغيل كتيب التشخيص الآلي `diagnose-db-cpu`…“
وبعد 30 ثانية، تصلني رسالة أخرى:
“✅ نتائج التشخيص:
– تحميل المعالج: 95%
– العمليات الأكثر استهلاكاً: عملية `ANALYZE` على جدول `user_events`
– مساحة القرص: 70% (طبيعي)
– الذاكرة: 60% (طبيعي)
– الإجراء المقترح: إنهاء العملية ذات المعرف (PID) 12345. هل أستمر؟ [نعم] [لا]”
بكبسة زر واحدة، حُلّت المشكلة. الفرق في مستوى التوتر والوقت لا يقدر بثمن.
2. توحيد المعايير والقضاء على “شغل فلان أحسن من علان”
في الماضي، كان حل المشكلة يعتمد على خبرة المهندس المناوب. المهندس الخبير قد يحلها في 5 دقائق، بينما المبتدئ قد يستغرق 30 دقيقة وربما يسبب مشكلة أخرى. الأتمتة تضمن أن نفس الخطوات الدقيقة والمُختبرة تُنفذ في كل مرة، بغض النظر عمن يكون في فترة المناوبة. هذا يضمن الاتساق ويقلل من الأخطاء البشرية.
3. توثيق حيّ ومُحدّث دائماً
أجمل ما في كتيبات التشغيل الآلية هو أن “الكود هو التوثيق” (The code is the documentation). عندما نريد تحديث العملية، نقوم بتحديث السكربت. لا مزيد من صفحات الـ Wiki المنسية والتي تحتوي على معلومات خاطئة. أي شخص يستطيع قراءة السكربت ليفهم بالضبط ما الذي يحدث.
رحلتنا العملية: خطوات بناء أول كتيب تشغيل آلي
قد يبدو الأمر معقداً، لكنه ليس كذلك. يمكنك البدء بخطوات بسيطة ومتدرجة. إليك الطريقة التي اتبعناها:
الخطوة 1: تحديد الحادثة الأكثر إزعاجاً
لا تحاول أتمتة كل شيء دفعة واحدة. ابدأ بـ “الفاكهة الدانية” (Low-hanging fruit). اسأل فريقك: ما هو التنبيه الذي يوقظكم من النوم أكثر من غيره؟ ما هي المشكلة المتكررة التي تستهلك معظم وقتكم؟ بالنسبة لنا، كانت مشكلة “استخدام المعالج العالي في قاعدة البيانات”.
الخطوة 2: توثيق الخطوات اليدوية بدقة
قبل كتابة أي كود، اكتب الخطوات التي يقوم بها المهندس يدوياً لحل المشكلة. كن دقيقاً جداً. مثالنا:
- الاتصال بالخادم عبر SSH:
ssh sre-user@db1.example.com - تشغيل
topأوhtopلمعرفة الحمل العام. - الاتصال بقاعدة البيانات
psql. - تنفيذ استعلام لمعرفة العمليات النشطة:
SELECT pid, query FROM pg_stat_activity WHERE state = 'active'; - تحديد العملية المسببة للمشكلة.
- (اختياري) إنهاء العملية:
SELECT pg_terminate_backend(pid);
الخطوة 3: ترجمة الخطوات إلى كود (مثال بسيط)
الآن، حوّل هذه الخطوات إلى سكربت. لغة Bash هي بداية ممتازة لأنها موجودة في كل مكان. هذا مثال توضيحي ومبسط جداً لسكربت تشخيصي:
#!/bin/bash
# ===================================================
# كتيب التشغيل الآلي لتشخيص حمل المعالج على قاعدة البيانات
# إعداد: أبو عمر
# ===================================================
# المتغيرات - لا تضع كلمات المرور هنا أبداً! استخدم أدوات إدارة الأسرار
DB_HOST="db1.example.com"
DB_USER="diagnostics_user"
SSH_USER="sre-user"
echo "🔎 بدء تشخيص الحمل على $DB_HOST..."
# الخطوة 1: الحصول على العمليات الأكثر استهلاكاً للمعالج من الخادم
echo "--- أكثر 5 عمليات استهلاكاً للمعالج (من top) ---"
# نستخدم ssh لتنفيذ الأمر عن بعد
ssh ${SSH_USER}@${DB_HOST} "ps -eo pid,pcpu,pmem,comm --sort=-pcpu | head -n 6"
echo "" # سطر فارغ للترتيب
# الخطوة 2: الحصول على الاستعلامات النشطة من داخل قاعدة البيانات
echo "--- الاستعلامات النشطة حالياً في PostgreSQL ---"
# ملاحظة: هذا الأمر يتطلب إعداد وصول بدون كلمة مرور (مثل .pgpass أو شهادات)
PG_QUERY="SELECT pid, age(clock_timestamp(), query_start) AS duration, query FROM pg_stat_activity WHERE state = 'active' ORDER BY duration DESC LIMIT 5;"
ssh ${SSH_USER}@${DB_HOST} "psql -U ${DB_USER} -d maindb -c "${PG_QUERY}""
echo ""
echo "✅ انتهى التشخيص."
الخطوة 4: دمج الكتيب مع نظام التنبيهات
هذه هي الخطوة السحرية. معظم أنظمة المراقبة وإدارة الحوادث (مثل Prometheus/Alertmanager, PagerDuty, Opsgenie) تسمح لك بتشغيل “webhook” أو سكربت عند إطلاق تنبيه معين. قم بإعداد نظام التنبيهات الخاص بك بحيث يقوم بتشغيل السكربت أعلاه تلقائياً عند حدوث تنبيه “High CPU”.
يمكنك استخدام أدوات متخصصة في هذا المجال مثل Rundeck أو Ansible Tower لتنظيم هذه السكربتات وتشغيلها بشكل آمن ومنظم.
الخطوة 5: التكرار والتحسين المستمر
ابدأ بالتشخيص فقط. اجعل السكربت يجمع المعلومات ويرسلها إلى قناة Slack. عندما يثق الفريق في المعلومات التي يجمعها السكربت، يمكنك الانتقال إلى المستوى التالي: المعالجة الآلية (Auto-remediation). مثلاً، إضافة منطق برمجي يقوم بإنهاء الاستعلام الذي يعمل منذ أكثر من 10 دقائق تلقائياً، ولكن فقط بعد أخذ موافقة من المهندس المناوب عبر رسالة تفاعلية.
نصائح أبو عمر الذهبية ✨
من خلال تجربتي، تعلمت بعض الدروس بالطريقة الصعبة. إليكم خلاصة خبرتي لتجنب نفس الأخطاء:
- ابدأ صغيراً وآمناً: لا تبدأ بالمعالجة الآلية مباشرة. ابدأ بسكربتات التشخيص التي تقرأ البيانات فقط (read-only). ابنِ الثقة أولاً.
- الأمان أولاً، وثانياً، وثالثاً: لا تضع أي بيانات حساسة (مثل كلمات المرور أو مفاتيح API) مباشرة في السكربتات. استخدم أدوات إدارة الأسرار مثل HashiCorp Vault أو AWS Secrets Manager.
- اجعلها قابلة للمقاطعة: يجب أن يكون هناك دائماً “زر إيقاف” كبير وواضح. يجب أن يتمكن المهندس المناوب من إيقاف الأتمتة في أي لحظة إذا شعر أن الأمور لا تسير على ما يرام.
- الشفافية مفتاح الثقة: اجعل البوت أو السكربت يرسل تحديثات واضحة وموجزة لكل خطوة يقوم بها إلى قناة تواصل مشتركة (مثل Slack). هذا يجعل الجميع على دراية بما يحدث ويبني الثقة في النظام الآلي.
الخلاصة: من الإطفاء إلى الإتقان
إن تبني كتيبات التشغيل الآلية لم يكن مجرد حل تقني، بل كان تحولاً ثقافياً في فريقنا. انتقلنا من فريق مرهق يقضي لياليه في إطفاء الحرائق، إلى فريق استباقي يركز على تحسين النظام ومنع المشاكل قبل حدوثها. استعدنا ليالينا، وقلّ التوتر بشكل كبير، والأهم من ذلك، أصبحنا نشعر بأننا مهندسون حقيقيون نبني حلولاً ذكية، لا مجرد فنيي طوارئ.
نصيحتي لك: انظر إلى التنبيه التالي الذي يوقظك في منتصف الليل ليس كلعنة، بل كفرصة. فرصة لأتمتة، لتبسيط، ولإعادة الهدوء إلى حياتك وحياة فريقك. استثمروا في الأتمتة، فهي استثمار في راحة بال فريقكم وإبداعهم. 👨💻
