ليلة خميس لا تُنسى: حين كادت الفوضى أن تودي بنا
أذكرها وكأنها البارحة، ليلة خميس، حوالي الساعة الثانية فجراً. كنت قد بدأت أغفو حين اهتز هاتفي بسيل من التنبيهات من نظام المراقبة. “CPU Usage at 99% on primary-db-server”. قلبي بدأ يدق أسرع، فهذه ليست مجرد خادم، هذه قاعدة بياناتنا الرئيسية.
فتحت اللابتوب بسرعة، وفي نفس الوقت بدأت الرسائل تنهال على جروب الواتساب الخاص بالفريق. “مين شاف التنبيه؟”، “أنا بحاول أدخل SSH بس بطيء جداً”، “هل حدا عمل deploy جديد؟”. زميل آخر بدأ يتصل بي مباشرة، بينما مدير المشروع يرسل إيميلات للجميع يسأل عن الوضع. كانت فوضى عارمة. معلومات هنا، وسؤال هناك، ومحاولة تشخيص في مكان ثالث. ضاع التركيز، وضاعت نصف ساعة ثمينة فقط في محاولة تنسيق من سيفعل ماذا.
بالآخر، وبعد ساعة ونصف من التوتر والضغط، اكتشفنا أن عملية نسخ احتياطي فاشلة دخلت في حلقة لا نهائية واستنزفت كل موارد المعالج. حللنا المشكلة، ولكن بعد أن جلسنا نتنفس الصعداء، قلت للفريق: “يا جماعة، هيك ما بزبط. شغلنا مرتب، بس طريقة تعاملنا مع الطوارئ فوضوية. لازم نلاقي حل”. كانت تلك الليلة هي الشرارة التي قادتنا لتبني ما يُعرف اليوم بالـ ChatOps.
ما هو الـ ChatOps؟ ليس مجرد “شات” للعمل!
الكثير يظن أن الـ ChatOps هو مجرد استخدام برامج محادثة مثل Slack أو Microsoft Teams للتحدث عن العمل. لكن الحكي أعمق من هيك بكثير. الـ ChatOps هو ممارسة هندسية وثقافية تهدف إلى وضع أدوات العمل، وسير العمليات (workflows)، والتواصل في مكان واحد: نافذة المحادثة.
تخيل معي أن غرفة المحادثة لم تعد مكاناً للثرثرة فقط، بل أصبحت مركز قيادة عملياتك (Command Center). بدلاً من أن تفتح نافذة الـ Terminal لتشغيل أمر، وواجهة AWS لتفقد حالة الخوادم، وأداة CI/CD لترى حالة الـ deployment، يمكنك أن تفعل كل هذا وأكثر عبر أوامر بسيطة تكتبها في الشات.
ببساطة، الـ ChatOps هو تحويل المحادثات من “كلام عن العمل” إلى “تنفيذ للعمل”.
المكونات الأساسية لمنظومة ChatOps
- برنامج المحادثة (Chat Client): هو الواجهة التي يتفاعل معها الفريق. أشهر الأمثلة هي Slack، Microsoft Teams، أو حتى البدائل مفتوحة المصدر مثل Mattermost.
- الروبوت (The Bot): هذا هو قلب النظام النابض. هو “الموظف الآلي” الذي يستمع للأوامر في غرفة المحادثة، وينفذها، ثم يعرض النتائج. أمثلة شهيرة هي Hubot (الكلاسيكي) أو يمكنك بناء روبوتك الخاص.
- الأدوات والسكربتات (Scripts & Integrations): هي “عضلات” الروبوت. هذه هي الأكواد التي تتصل بخوادمك، بمنصات الكلاود، بأنظمة المراقبة، وبأي شيء آخر تحتاجه لتنفيذ الأوامر.
كيف أنقذنا الـ ChatOps من جحيم الفوضى؟
بعد ليلة الخميس تلك، قررنا البدء تدريجياً. لم نهدف لأتمتة كل شيء مرة واحدة. بدأنا بخطوات بسيطة ولكنها أحدثت فرقاً هائلاً.
1. مركزية التنبيهات وشفافية الإجراءات
أول خطوة كانت توجيه كل التنبيهات من نظام المراقبة (Prometheus/Alertmanager) إلى قناة مخصصة في Slack اسمها #alerts-production. الآن، بدلاً من أن تصل التنبيهات بشكل فردي لكل شخص، أصبحت تصل في مكان واحد يراه الجميع.
الأجمل من ذلك، قمنا ببرمجة الروبوت الخاص بنا (أسميناه “زيتون” 🤖) ليضيف أزراراً تفاعلية مع كل تنبيه: “Acknowledge” (أنا أعمل على المشكلة) و “Resolve” (تم حل المشكلة). بمجرد أن يضغط أحد المهندسين على “Acknowledge”، يكتب الروبوت في القناة: “أبو عمر تولى مسؤولية هذه المشكلة”. انتهت حالة “هل أحد يعمل على هذا؟”. أصبح كل شيء شفافاً ومسجلاً.
2. سرعة الوصول للمعلومات (Read-only Commands)
بدأنا بأوامر لا تُحدث أي تغيير، فقط تقرأ البيانات. هذه هي الطريقة الآمنة للبدء.
- بدلاً من سؤال “ما هو آخر إصدار على السيرفر الفلاني؟”، أصبحنا نكتب:
@zaytoun status deployment staging. - بدلاً من فتح واجهة AWS لتفقد صحة قاعدة البيانات، أصبحنا نكتب:
@zaytoun status rds-health.
هذه الأوامر البسيطة وفرت علينا دقائق ثمينة في كل مرة، ومنعت مقاطعة الزملاء للأسئلة المتكررة.
مثال عملي: بناء أمر بسيط باستخدام Python و Slack Bolt
لنفترض أنك تريد بناء أمر بسيط يجلب حالة خدمة معينة. يمكنك استخدام مكتبة Slack Bolt في بايثون. الكود قد يبدو كالتالي:
# app.py
import os
from slack_bolt import App
from slack_bolt.adapter.socket_mode import SocketModeHandler
import requests # لمخاطبة الخدمة التي تريد فحصها
# تهيئة التطبيق باستخدام توكن البوت
app = App(token=os.environ.get("SLACK_BOT_TOKEN"))
# الاستماع لأي رسالة تبدأ بـ "status"
@app.message("status")
def handle_status_command(message, say):
# استخلاص اسم الخدمة من الرسالة
# مثال: "status my-api" -> service_name = "my-api"
parts = message['text'].split()
if len(parts) < 2:
say("من فضلك حدد اسم الخدمة. مثال: `status my-api`")
return
service_name = parts[1]
try:
# هنا تضع منطق فحص حالة الخدمة الحقيقي
# كمثال، سنقوم بعمل طلب HTTP بسيط
response = requests.get(f"https://api.example.com/health/{service_name}")
if response.status_code == 200:
say(f"✅ الخدمة `{service_name}` تعمل بشكل سليم.")
else:
say(f"🚨 مشكلة في الخدمة `{service_name}`! الحالة: {response.status_code}")
except Exception as e:
say(f"😥 لم أستطع فحص حالة الخدمة `{service_name}`. الخطأ: {e}")
# تشغيل التطبيق
if __name__ == "__main__":
handler = SocketModeHandler(app, os.environ["SLACK_APP_TOKEN"])
handler.start()
هذا الكود البسيط يستمع لكلمة “status” في أي قناة يتواجد بها الروبوت، ويقوم بتنفيذ منطق معين بناءً عليها، ثم يرد في نفس القناة. تخيل إمكانيات هذا المبدأ!
3. أتمتة الإجراءات المتكررة (Write/Execute Commands)
بعد أن وثقنا في النظام، انتقلنا للمرحلة التالية والأكثر قوة: الأوامر التي تُحدث تغييراً. هنا يجب أن تكون حذراً جداً وتطبق صلاحيات صارمة.
- إعادة تشغيل خدمة:
@zaytoun restart service auth-service on staging - نشر آخر إصدار:
@zaytoun deploy web-app to production(هذا الأمر لا يعمل إلا للمهندسين المصرح لهم فقط). - تنظيف الكاش:
@zaytoun clear cache redis-main
كل أمر من هذه الأوامر كان يتطلب في السابق فتح SSH، كتابة أوامر طويلة، واحتمالية الخطأ البشري. الآن، أصبح الأمر موثقاً، سريعاً، ويتم من مكان واحد.
نصائح عملية من خبرتي (من أبو عمر)
تبني الـ ChatOps رحلة ممتعة، وهذه بعض النصائح لتجعلها ناجحة:
- الثقافة قبل الأداة: الأداة سهلة، لكن الأهم هو إقناع الفريق بتبني هذه الطريقة الجديدة في العمل. ابدأ بالتدريج وأرِهم القيمة في كل خطوة.
- الأمان أولاً، وثانياً، وثالثاً: عند التعامل مع أوامر حساسة (مثل النشر على production أو حذف شيء)، تأكد من وجود نظام صلاحيات قوي. ليس كل شخص في القناة يجب أن يكون قادراً على تنفيذ كل الأوامر. اربط الصلاحيات بمجموعات المستخدمين في Slack/Teams.
- اجعل الروبوت متحدثاً جيداً: يجب أن تكون ردود الروبوت واضحة ومفيدة. استخدم تنسيق الرسائل (formatting)، الأزرار، والقوائم المنسدلة لجعل التفاعل سهلاً. استخدم الـ “threads” في Slack للحفاظ على نظافة القناة الرئيسية.
- لا تستغنِ عن لوحات المراقبة (Dashboards): الـ ChatOps ممتاز للإجراءات السريعة والتواصل. لكنك ما زلت بحاجة إلى dashboards (مثل Grafana) للتحليل العميق والنظر في البيانات التاريخية. هما يكملان بعضهما البعض.
الخلاصة: من إطفاء الحرائق إلى هندسة العمليات 🚀
في النهاية، الـ ChatOps لم يكن مجرد حل تقني لمشكلة فوضى التنبيهات، بل كان تحولاً ثقافياً عميقاً. لقد نقلنا من فريق يقضي وقته في “إطفاء الحرائق” بشكل عشوائي، إلى فريق “يهندس” عملياته بشكل استباقي ومنظم.
كل أمر يتم تنفيذه موثق في سجل المحادثة، مما يخلق سجلاً تاريخياً حياً يمكن للجميع التعلم منه، خاصة الموظفين الجدد. لقد حررنا عقول مهندسينا من المهام المتكررة والمملة، وأعطيناهم الوقت للتركيز على ما يبرعون فيه حقاً: حل المشاكل المعقدة والإبداع.
نصيحتي لك: ابدأ اليوم. لا تنتظر ليلة خميس كارثية مثل التي مررنا بها. ابدأ بأمر بسيط، أضف قيمة صغيرة، وشاهد كيف ستنمو هذه الثقافة في فريقك وتغير طريقة عملكم للأفضل. جربوها، ومش رح تندموا. ✅
