أذكرها وكأنها البارحة، ليلة شتاء باردة، والساعة تقترب من الثانية صباحاً. رنّ الهاتف بنغمة الطوارئ التي لا تخطئها أذن أي مبرمج مناوب. على الطرف الآخر، صوت مدير المشروع يرتجف قلقاً: “أبو عمر، الموقع واقع! العميل الأكبر في موسم التخفيضات، والمبيعات صفر!”.
قفزت إلى مكتبي، فتحت اللابتوب، ودخلت إلى عالم من الفوضى. مجموعة واتساب تضج بالرسائل، مكالمة فيديو جماعية على تيمز نصف الفريق فيها لا يسمع النصف الآخر، ومهندسون يجرّبون حلولاً بشكل عشوائي. أحدهم أعاد تشغيل خادم قاعدة البيانات دون إعلام أحد، والآخر يبحث في سجلات (logs) قديمة. كانت المعلومات مبعثرة، والقرارات تُتخذ في الظلام. كل واحد “بغني على ليلاه”، وكنا كمن يحاول إطفاء حريق بمسدسات ماء صغيرة متفرقة.
بعد ثلاث ساعات من الجحيم، تم حل المشكلة، لكن الخسائر كانت فادحة، ليس فقط مالياً للعميل، بل معنوياً للفريق. في اجتماع ما بعد الحادثة (Post-mortem)، كان الإجماع واضحاً: المشكلة التقنية كانت بسيطة، لكن “جحيم التنسيق” هو ما حوّلها إلى كارثة. كانت تلك اللحظة هي الشرارة التي دفعتنا للبحث عن طريقة أفضل… طريقة وجدناها في مفهوم الـ ChatOps.
ما هو الـ ChatOps؟ ليس مجرد دردشة!
عندما يسمع البعض مصطلح ChatOps، يظن أنه يعني ببساطة استخدام برامج الدردشة مثل Slack أو Microsoft Teams للتواصل أثناء العمل. هذا جزء من الحقيقة، لكنه ليس كل شيء. الـ ChatOps، يا جماعة الخير، هو فلسفة ومنهجية عمل تهدف إلى وضع المحادثة في قلب عمليات التطوير والتشغيل.
الفكرة هي تحويل منصة الدردشة إلى “غرفة عمليات” أو “مركز قيادة” مركزي. بدلاً من التنقل بين عشرات الأدوات المختلفة – شاشة المراقبة (monitoring dashboard)، الطرفية (terminal) للوصول للخوادم، منصة السحابة (cloud console)، وتطبيق الدردشة – أنت تجمع كل هذه الخيوط في مكان واحد. كيف؟ عن طريق “روبوتات الدردشة” (Chatbots) التي تتلقى الأوامر منك وتنفذها في الأنظمة الأخرى، ثم تعود بالنتائج إلى نفس قناة الدردشة.
باختصار، الـ ChatOps هو “التطوير والعمليات المدفوعة بالمحادثة” (Conversation-Driven Development and Operations). بدل ما “تروح” للأدوات، الأدوات هي اللي “بتيجي لعندك” في الدردشة.
من الفوضى إلى النظام: رحلتنا مع ChatOps في إدارة الحوادث
بعد حادثة تلك الليلة، قررنا تبني الـ ChatOps. كانت رحلة، وليست مجرد تغيير تقني. إليكم مقارنة بين “قبل” و “بعد”.
قبل الـ ChatOps: “جحيم التنسيق”
- صوامع المعلومات (Information Silos): المحادثات المهمة تحدث في رسائل خاصة، القرارات تُتخذ ولا أحد يدري بها.
- غياب المصدر الموحد للحقيقة (Single Source of Truth): لا يوجد مكان واحد لمعرفة “ماذا حدث؟”، “من فعل ماذا؟”، و “ما هي الحالة الآن؟”.
- صعوبة المتابعة: إذا انضم مهندس جديد للمساعدة في منتصف الحادثة، يحتاج إلى نصف ساعة فقط ليفهم ما الذي يجري.
- فقدان السجل الزمني: بعد انتهاء الحادثة، من المستحيل تقريباً تجميع تسلسل زمني دقيق للأحداث لإجراء تحليل صحيح (Post-mortem).
- الإجهاد والضغط: التنقل المستمر بين الأدوات والشاشات يستهلك الطاقة الذهنية ويؤدي إلى أخطاء بشرية.
بعد الـ ChatOps: “الهدوء تحت الضغط”
الآن، عندما يقع حادث، السيناريو مختلف تماماً:
- الإنذار التلقائي: نظام المراقبة (مثلاً Prometheus) يكتشف مشكلة (مثل استهلاك عالٍ لوحدة المعالجة المركزية). بدلاً من إرسال بريد إلكتروني فقط، يقوم بإرسال تنبيه إلى “بوت” الدردشة الخاص بنا.
- إنشاء غرفة عمليات: يقوم البوت فوراً بإنشاء قناة دردشة جديدة ومؤقتة للحادثة (مثلاً
#incident-db-high-cpu-2024-05-20). - جمع الفريق: يدعو البوت تلقائياً المهندس المناوب، وقائد الحادثة (Incident Commander)، وأي أطراف معنية أخرى إلى القناة.
- توفير السياق: أول رسالة في القناة تكون من البوت، وتحتوي على:
- تفاصيل الإنذار الذي بدأ كل شيء.
- رسم بياني يوضح المقياس الذي تسبب في المشكلة (مثل استهلاك CPU).
- رابط إلى دليل التشغيل (Runbook) الخاص بهذا النوع من الحوادث.
- آخر التغييرات التي تم نشرها على النظام المتأثر.
- الأوامر في متناول يدك: داخل القناة، يمكن للمهندسين تنفيذ الأوامر مباشرة. لا حاجة لفتح الـ SSH.
بدلاً من أن أقول للمهندس “شوف لنا الـ logs بالله”، أصبح يكتب مباشرة في القناة:
/bot logs service payments-api --lines 100والبوت يرد في نفس القناة بسجلات الأخطاء لآخر 100 سطر، والجميع يراها.
هل نحتاج لإعادة تشغيل خدمة؟
/bot restart service payments-apiيرد البوت: “أبو عمر طلب إعادة تشغيل خدمة payments-api. جاري التنفيذ…” ثم “تمت إعادة التشغيل بنجاح.”
الجميل في الأمر أن كل شيء موثق، شفاف، ومتاح للجميع في الوقت الفعلي. القناة نفسها أصبحت هي المصدر الموحد للحقيقة.
مثال عملي: “زيتون بوت” في الخدمة
لتقريب الصورة، دعنا نتخيل أننا قمنا ببناء بوت بسيط باستخدام Python وإطار عمل مثل “Slack Bolt”. أسميناه “زيتون بوت” (على اسم شجرة الزيتون المباركة). أحد أوامره هو فحص حالة الخدمات (Health Check).
عندما يكتب المهندس في القناة:
/zaytoon status service-authما يحدث في الكواليس يمكن أن يكون شيئاً كهذا (كود بايثون مبسط للتوضيح):
# هذا الكود هو مجرد مثال توضيحي للفكرة
# It's a simplified example to illustrate the concept
from slack_bolt import App
import requests
app = App(token="xoxb-your-slack-bot-token")
# تعريف الأمر الذي سيتلقاه البوت
@app.command("/zaytoon")
def zaytoon_command(ack, body, client):
ack() # إرسال تأكيد استلام الأمر لـ Slack فوراً
text = body.get('text', '')
parts = text.split() # تقسيم الأمر لفهم المطلوب
# التحقق من أن الأمر هو لفحص الحالة
# Check if the command is for status check
if len(parts) == 2 and parts[0] == 'status':
service_name = parts[1]
channel_id = body['channel_id']
# هنا يبدأ السحر: البوت يتصل بالخدمة لفحص حالتها
# Here's the magic: The bot calls the service's health endpoint
try:
# لنفترض أن لكل خدمة نقطة نهاية (endpoint) لمعرفة حالتها
# Let's assume each service has a health endpoint
response = requests.get(f"https://api.our-system.com/{service_name}/health", timeout=5)
if response.status_code == 200:
status_message = f"✅ خدمة `{service_name}` تعمل بشكل سليم."
else:
status_message = f"🚨 مشكلة في خدمة `{service_name}`! الحالة: {response.status_code}"
except requests.exceptions.RequestException as e:
status_message = f"⚠️ تعذر الوصول لخدمة `{service_name}`. خطأ: {e}"
# إرسال النتيجة إلى القناة
# Post the result back to the channel
client.chat_postMessage(channel=channel_id, text=status_message)
# ... باقي الكود لتشغيل البوت
هذا المثال البسيط يوضح كيف يمكن لأمر واحد في الدردشة أن يطلق سلسلة من الإجراءات في الخلفية ويوفر معلومات قيمة للفريق بأكمله بشكل فوري وشفاف.
نصائح أبو عمر العملية لتبني ChatOps
- ابدأ صغيراً (Start Small): لا تحاول أتمتة كل شيء من اليوم الأول. “شوي شوي يا حبيبي”. ابدأ بأمر واحد بسيط ومفيد، مثل فحص حالة خدمة أو جلب سجلات. بناء الثقة في النظام أهم من بناء كل شيء مرة واحدة.
- الأمان أولاً (Security First): الأوامر التي تغير الحالة (مثل إعادة التشغيل أو التراجع عن نشر
rollback) يجب أن تكون محمية. استخدم صلاحيات محددة. “مش كل من هب ودب بيقدر يعمل ريستارت”. تأكد من أن البوت لا ينفذ إلا أوامر من مستخدمين مصرح لهم. - ركز على القراءة قبل الكتابة (Read-Only First): ابدأ بالأوامر التي تقرأ المعلومات فقط (Read-only commands). هذا يجعل الفريق يثق في البوت ويرى قيمته دون خوف من التسبب في مشكلة. بعد ذلك، يمكنك الانتقال تدريجياً للأوامر التي تعدل الحالة (Write commands).
- الـ ChatOps ثقافة قبل أن يكون أداة: يجب أن يقتنع الفريق بالعمل في العلن والشفافية. شجع الجميع على طرح الأسئلة وتنفيذ الأوامر في القنوات العامة المخصصة للحوادث بدلاً من الرسائل الخاصة.
- وثّق كل شيء: يجب أن يكون لكل أمر شرح واضح. أمر مثل
/zaytoon helpيجب أن يعرض قائمة بكل الأوامر المتاحة وشرحها. هذا يجعل النظام سهل الاستخدام للجميع.
الخلاصة: أكثر من مجرد سرعة
في النهاية، الانتقال إلى ChatOps لم يجعلنا أسرع في حل المشاكل فحسب، بل غيّر طريقة عملنا كفريق. لقد قلل من الضغط، وزاد من الشفافية، وحوّل كل حادثة إلى فرصة تعلم لا تقدر بثمن، لأن كل خطوات الحل موثقة بالكامل في قناة الدردشة.
لم نعد نسبح كل واحد في اتجاه، بل أصبحنا فريقاً متناغماً يتحرك بثقة وهدوء في “غرفة عمليات” واحدة. لم يعد الهاتف يرن في الثانية صباحاً بنبرة هلع، بل بنبرة تنبيه لبدء عملية منظمة ومعروفة.
نصيحتي لك: لا تنظر إلى ChatOps على أنه ترف تقني، بل استثمار استراتيجي في هدوء فريقك النفسي، وفعالية عملياتك، واستقرار أنظمتك. الهدف ليس فقط أن نصلّح المشكلة أسرع، الهدف أن نعود بعدها لنشرب فنجان القهوة أو كأس الشاي بالنعناع ونحن مرتاحو البال. 😉
