إدارة الحوادث كانت جحيمًا: كيف أنقذتنا ChatOps من فوضى “مين المسؤول؟”

يا جماعة الخير، السلام عليكم.

اسمحوا لي أن أرجع بالذاكرة ليلة ما بنساها، كانت الساعة حوالي 3 الفجر في ليلة شتوية باردة، وأنا أحاول أن أدفئ يدي بكوب من الشاي بالمرمية. فجأة، بدأ هاتفي بالاهتزاز كالمجنون… إشعارات من نظام المراقبة، رسائل واتساب من الفريق، مكالمات من مدير المشروع. الخادم الرئيسي المسؤول عن عمليات الدفع “وقع”.

خلال دقائق، تحولت مجموعة الواتساب الخاصة بالفريق إلى ساحة حرب. “مين اللي عمل آخر deployment؟”، “حدا يرجع النسخة الاحتياطية بسرعة!”، “أنا مش شايف أي مشكلة عندي!”، “خالد، اعمل restart للسيرفر!”. كل شخص يقترح حلاً، ولا أحد يعرف ماذا يفعل الآخر. ضاعت المسؤوليات، وتضاربت الإجراءات، وكل دقيقة تأخير كانت تكلفنا الكثير. بعد ساعتين من الجحيم، تمكنا من حل المشكلة، لكننا كنا منهكين ومحبطين. في اجتماع اليوم التالي، كان السؤال الذي يطرح نفسه بإلحاح: “كيف نمنع هذه الفوضى من الحدوث مرة أخرى؟”. كان الجواب يكمن في مصطلح سمعت عنه وبدأت أبحث فيه بجدية: ChatOps.

ما هي الـ ChatOps؟ وليش هي مش مجرد “شات”؟

لما تسمع كلمة “ChatOps”، يمكن أول شيء يخطر ببالك هو Slack أو Microsoft Teams. وهذا صحيح جزئياً، لكنه ليس كل القصة. الـ ChatOps، زي ما بنحكي بالبلدي، هي “شغل من خلال الشات”. هي ممارسة ربط كل أدواتك، أنظمتك، وعملياتك في منصة محادثة مركزية، وتحويلها من مجرد مكان للدردشة إلى غرفة عمليات تفاعلية.

الفكرة بسيطة وعبقرية: بدلاً من أن يقفز المهندس بين عشرات النوافذ والتطبيقات (نافذة لمراقبة الأداء، نافذة للوصول للسيرفر، نافذة لنشر الكود، نافذة للتوثيق)، يمكنه تنفيذ كل هذه المهام من خلال كتابة أوامر بسيطة في قناة محادثة مخصصة. كل شيء يتم في مكان واحد، أمام أعين الجميع، ومسجل وموثق تلقائياً.

الـ ChatOps لا تعني استبدال البشر بالروبوتات، بل تعني تمكين البشر من خلال تزويدهم بأدوات قوية وموحدة تجعل عملهم أسرع وأكثر شفافية.

رحلتنا نحو الـ ChatOps: من الفوضى إلى النظام

بعد حادثة تلك الليلة، قررنا في الفريق أن نتبنى الـ ChatOps بشكل جدي. لم تكن الطريق سهلة بالكامل، ولكنها كانت مجدية بشكل لا يصدق. وهذه هي الخطوات التي اتبعناها:

الخطوة الأولى: اختيار المنصة المناسبة

أول قرار كان اختيار “غرفة العمليات” الرقمية. الخيارات كانت كثيرة، أشهرها Slack، Microsoft Teams، و Mattermost (وهو خيار مفتوح المصدر لمن يهتم بالخصوصية الكاملة).

نصيحة أبو عمر: عند اختيار المنصة، لا تفكر فقط في ميزات الدردشة. ركز على قوة الـ API وقدرات التكامل (Integrations). هل تدعم المنصة ربط الأدوات التي تستخدمها حالياً بسهولة؟ هل مجتمع المطورين حولها نشط؟ احنا بوقتها اخترنا Slack لقوة تطبيقاته وسهولة بناء “Bots” مخصصة عليه.

الخطوة الثانية: ربط الأدوات الأساسية (The “Hello, World!” of ChatOps)

لم نحاول أتمتة كل شيء من اليوم الأول. بدأنا بالخطوة الأبسط والأكثر أهمية: مركزية التنبيهات.

قمنا بإنشاء قناة جديدة اسمها #alerts-critical وربطنا بها كل أنظمة المراقبة لدينا (مثل Prometheus و Grafana و Sentry). بدلاً من أن تصل التنبيهات على البريد الإلكتروني أو رسائل SMS متفرقة، أصبحت كلها تصب في مكان واحد، مع تنسيق موحد وواضح. مجرد هذه الخطوة الصغيرة خففت الكثير من الضوضاء ووفرت رؤية شاملة وفورية لأي مشكلة تحدث.

الخطوة الثالثة: بناء الأوامر التفاعلية (هون بلش الشغل الجد)

هنا يبدأ السحر الحقيقي للـ ChatOps. بدأنا في بناء “بوت” (Bot) خاص بنا، وأطلقنا عليه اسم “الختيار” (كناية عن الحكمة والخبرة 😄). هذا البوت هو مساعدنا الرقمي الذي ينفذ الأوامر نيابة عنا.

كان أول أمر قمنا ببنائه بسيطاً جداً: أمر للتحقق من حالة خدمة معينة.

مثال على الكود (باستخدام Python وإطار عمل Slack Bolt):

# استيراد المكتبات اللازمة
from slack_bolt import App
import os
import requests

# تهيئة التطبيق باستخدام توكن البوت
app = App(token=os.environ.get("SLACK_BOT_TOKEN"))

# تعريف أمر جديد اسمه /check-status
@app.command("/check-status")
def check_service_status(ack, respond, command):
    # تأكيد استلام الأمر فوراً لتجنب انتهاء المهلة
    ack()

    # استخلاص اسم الخدمة من الأمر الذي أدخله المستخدم
    service_name = command['text']
    
    if not service_name:
        respond("يا ورد، نسيت تحدد اسم الخدمة. مثال: /check-status api-gateway")
        return

    # هنا يتم استدعاء دالة للتحقق الفعلي من حالة الخدمة
    # في هذا المثال، سنقوم بمحاكاة العملية
    try:
        # مثلاً، يمكن أن يكون لديك endpoint خاص يعطي حالة الخدمات
        # response = requests.get(f"https://status.yourcompany.com/{service_name}")
        # status = response.json()['status']
        
        # محاكاة لغرض التوضيح
        status = "UP"
        cpu = "15%"
        memory = "45%"
        
        respond(f"حالة الخدمة `{service_name}`:n"
                f"الحالة: *{status}* :white_check_mark:n"
                f"استخدام المعالج (CPU): {cpu}n"
                f"استخدام الذاكرة (Memory): {memory}")

    except Exception as e:
        respond(f"حدث خطأ أثناء فحص الخدمة `{service_name}`. :x:")

# تشغيل التطبيق
if __name__ == "__main__":
    app.start(port=int(os.environ.get("PORT", 3000)))

الآن، أي شخص في الفريق يمكنه ببساطة كتابة /check-status api-gateway في سلاك، وخلال ثوانٍ، يرد “الختيار” بتقرير مفصل عن حالة الخدمة. هذا الأمر البسيط وحده وفر علينا دقائق ثمينة من تسجيل الدخول إلى لوحات المراقبة المختلفة.

إدارة الحوادث على طريقة الـ ChatOps: سيناريو عملي

لنتخيل نفس سيناريو “ليلة الجحيم” مرة أخرى، ولكن هذه المرة مع وجود نظام ChatOps فعال.

1. الإنذار يصل

الساعة 3:01 فجراً: يصل تنبيه آلي من Prometheus إلى قناة #incidents. الرسالة واضحة ومفصلة:

🔴 High Severity Alert: API Gateway Unhealthy
Service: api-gateway
Error Rate: 95% (Threshold: 10%)
View Dashboard

2. إعلان الحادثة وتعيين المسؤول

الساعة 3:02 فجراً: المهندس المناوب (On-call) يرى التنبيه ويكتب الأمر التالي في القناة:

/incident declare --title "API Gateway is down" --severity 1 --lead @abu.omar

يقوم البوت (“الختيار”) فوراً بتنفيذ سلسلة من الإجراءات الآلية:

• إنشاء قناة محادثة جديدة ومؤقتة باسم #incident-2024-05-21-api-gateway.
• دعوة المهندس المناوب و”أبو عمر” (قائد الحادثة) وخبراء النظام تلقائياً إلى القناة.
• نشر رسالة مثبتة في القناة الجديدة تحتوي على كل تفاصيل الحادثة الأولية ورابط لوحة المراقبة.
• إرسال إشعار عام في قناة #announcements لإعلام باقي الشركة بوجود مشكلة جاري العمل على حلها.

انتهى عصر “مين المسؤول؟”. الآن كل شيء واضح ومحدد.

3. التشخيص والتعاون

من الساعة 3:03 إلى 3:15 فجراً: داخل القناة الجديدة، يبدأ العمل. كل شيء موثق ومرئي للجميع.

• أبو عمر: /bot get-logs api-gateway --lines 100 --filter "error" (للحصول على آخر 100 سطر من سجلات الأخطاء).
• خالد (مهندس آخر): “الخطأ يشير إلى مشكلة في الاتصال بقاعدة البيانات. سأتحقق من حالة قاعدة البيانات.” /bot check-db-connections
• البوت: “عدد الاتصالات بقاعدة البيانات prod-db-1 هو 500/500 (MAXED OUT)”.
• أبو عمر: “وجدنا السبب. يبدو أن هناك تسريب في الاتصالات بعد التحديث الأخير. خالد، هل يمكنك إعادة تشغيل الخدمة لتفريغ الاتصالات مؤقتاً بينما أعمل على الإصلاح الدائم؟”
• خالد: “بالتأكيد. سأقوم بإعادة التشغيل.” /bot restart-service api-gateway (هذا الأمر يتطلب صلاحيات خاصة للتنفيذ).

لاحظ كيف أن كل خطوة، كل أمر، وكل نتيجة، مسجلة في مكان واحد. لا مجال للارتباك أو تضارب الجهود.

4. حل المشكلة وتوثيقها

الساعة 3:20 فجراً: الخدمة تعود للعمل بعد إعادة التشغيل. أبو عمر يجد المشكلة في الكود ويقوم بنشر إصلاح سريع.

الساعة 3:25 فجراً: يكتب أبو عمر في القناة: /incident resolve --root-cause "Database connection leak in v2.5.1" --action "Rolled back to v2.5.0 and deployed hotfix."

يقوم البوت بما يلي:

• يعلن عن حل المشكلة في قناة #announcements.
• يقوم بأرشفة قناة الحادثة (#incident-2024-05-21-api-gateway) لجعلها للقراءة فقط.
• الأهم: يقوم بتجميع كل المحادثات والأوامر التي تم تنفيذها في القناة وإنشاء مسودة لتقرير ما بعد الحادثة (Post-mortem report) تلقائياً، مما يوفر ساعات من العمل اليدوي لاحقاً.

نصائح من “أبو عمر” لتبني ChatOps ناجح

من خلال تجربتنا، تعلمت بعض الدروس التي أود مشاركتها معكم:

1. ابدأ صغيراً ثم توسع: لا تحاول أتمتة عمليات معقدة من اليوم الأول. ابدأ بالتنبيهات، ثم أوامر القراءة (Read-only commands) مثل التحقق من الحالة، ثم انتقل تدريجياً إلى أوامر الكتابة (Write commands) التي تحدث تغييراً.
2. الأمان أولاً يا جماعة: الأوامر التي تغير في النظام (مثل إعادة تشغيل خادم أو نشر كود) يجب أن تكون محمية. استخدم صلاحيات محددة (Role-Based Access Control) وتأكد من أن البوت يتطلب تأكيداً قبل تنفيذ أي إجراء خطير.
3. التوثيق هو مفتاح النجاح: اجعل للبوت أمراً مثل /help يعرض قائمة بكل الأوامر المتاحة وشرحاً لكيفية استخدامها. كلما كان البوت أسهل في الاستخدام، زاد تبني الفريق له.
4. شجع الفريق على الاستخدام: اجعل البوت مفيداً وممتعاً. يمكنك إضافة أوامر غير متعلقة بالعمل، مثل /bot tell-a-joke أو /bot coffee-time. هذه اللمسات البسيطة تجعل الفريق يحب استخدام الأداة.
5. لا تستبدل التواصل البشري: الـ ChatOps هي أداة للمساعدة، وليست بديلاً عن الحوار. أحياناً، مكالمة فيديو سريعة مدتها 5 دقائق تكون أكثر فعالية من 30 دقيقة من الكتابة.

الخلاصة: ChatOps ليست ترفاً، بل ضرورة 🚀

التحول إلى ChatOps لم يكن مجرد تغيير تقني، بل كان تحولاً ثقافياً في طريقة عملنا. لقد حولنا الفوضى إلى نظام، وردود الفعل المتأخرة إلى استجابة استباقية وسريعة، واللوم إلى تعاون شفاف. أصبح سجل المحادثات هو المصدر الموثوق للحقيقة (Single Source of Truth) لكل ما يحدث في أنظمتنا.

إذا كان فريقك لا يزال يعاني من “جحيم إدارة الحوادث”، فأنصحك بشدة أن تبدأ رحلتك مع الـ ChatOps. ابدأ اليوم، ابدأ ببساطة، وشاهد كيف يمكن للمحادثة المنظمة أن تنقذ يومك (وليلتك!).

ودمتم سالمين.