من فوضى الاجتماعات إلى الأوامر الذكية: كيف أنقذنا ChatOps من جحيم إدارة الحوادث

أذكرها وكأنها البارحة، ليلة شتاء باردة في مكتبي المنزلي. الساعة الثانية صباحاً، وصوت تنبيه PagerDuty يخترق سكون الليل كصاروخ. “السيستم واقع!”… عبارة كفيلة بتحويل أي ليلة هادئة إلى ساحة معركة رقمية. خلال دقائق، امتلأت قنوات سلاك (Slack) بعشرات الرسائل: “يا جماعة شو اللي بصير؟”، “مين اللي on-call؟”، “هل المشكلة من قاعدة البيانات؟”، “المدير بسأل عن تحديث!”.

كنت أتنقل بجنون بين خمس نوافذ: نافذة المحادثة، نافذة الطرفية (Terminal) لأتصل بالخوادم، لوحة مراقبة Grafana التي كانت بطيئة بسبب الضغط، بريد المدير الذي يطلب تقريراً كل ثلاث دقائق، ومجموعة واتساب أخرى للفريق… فوضى عارمة. كل شخص يحاول المساعدة، لكن لا أحد يعرف ما يفعله الآخر. كنا كمن يحاول إطفاء حريق وكل منا يرش الماء في اتجاه مختلف. بعد ساعتين من التوتر وحرق الأعصاب، وجدنا المشكلة – عملية نسخ احتياطي فاشلة أدت إلى استهلاك كامل لمساحة القرص. حل بسيط، لكن الوصول إليه كان جحيماً من التنسيق اليدوي. في اجتماع ما بعد الحادثة (Post-mortem)، قلت للفريق: “يا جماعة الخير، لازم نلاقي حل. شغلنا هيك ما بمشي”. ومن هنا، بدأت رحلتنا مع المنقذ: الـ ChatOps.

لماذا كانت إدارة الحوادث “جحيماً”؟

قبل أن نغوص في الحل، دعونا نفصّل المشكلة التي كان يعاني منها فريقي، وأراهن أن الكثير من الفرق التقنية تعاني منها أيضاً. كانت إدارة الحوادث لدينا تتلخص في عدة نقاط مؤلمة:

• تشتت التواصل (Communication Silos): المهندسون يتحدثون في قناة تقنية، والمدراء في قناة أخرى، وفريق الدعم في مجموعة ثالثة. المعلومة المهمة تضيع في هذا المثلث، ويصبح نقلها مهمة بحد ذاتها.
• غياب مصدر الحقيقة الواحد (Single Source of Truth): ماذا كان آخر إجراء تم اتخاذه؟ من الذي أعاد تشغيل الخادم؟ هل تم فحص سجلات الأخطاء (Logs)؟ كل هذه الإجابات كانت متناثرة في رؤوس أعضاء الفريق أو في رسائل خاصة. لا يوجد سجل مركزي ومرتب للأحداث.
• بطء الاستجابة بسبب المهام اليدوية: للتحقق من حالة خدمة ما، كان على المهندس فتح الـ VPN، ثم تسجيل الدخول إلى الخادم عبر SSH، ثم كتابة الأمر، ثم نسخ النتيجة ولصقها في المحادثة. كل هذه الخطوات تستغرق دقائق ثمينة في وقت الأزمات.
• صعوبة التحليل بعد الحادثة (Post-mortem): عندما كنا نجلس لتحليل ما حدث، كنا نقضي نصف الوقت في محاولة تجميع القصة من المحادثات المختلفة وذكريات الناس. من الصعب استخلاص الدروس عندما تكون الرواية نفسها مجزأة.

باختصار، كنا نعتمد على “بطولة” الأفراد وقدرتهم على تحمل الضغط، بدلاً من الاعتماد على “نظام” قوي وفعّال.

المنقذ وصل: ما هو الـ ‘ChatOps’ يا أبو عمر؟

بكل بساطة، الـ ChatOps (اختصار لـ Chat Operations) هو نموذج عمل يهدف إلى إدارة وتشغيل المهام التقنية من خلال منصة محادثة (مثل Slack, Microsoft Teams, Mattermost). بدلاً من أن تكون المحادثة مجرد مكان للدردشة، تصبح واجهة تحكم مركزية لكل أدواتك وعملياتك.

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

بدلاً من التنقل بين عشرات الأدوات، أنت تكتب أمراً بسيطاً مثل:

@bot deploy version-1.5 to production

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

كيف طبقنا الـ ChatOps خطوة بخطوة؟

التحول لم يحدث بين عشية وضحاها، بل كان رحلة مدروسة. إليكم الخطوات العملية التي اتبعناها، والتي يمكنكم اتباعها أيضاً.

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

كنا نستخدم Slack بالفعل، لذا كان الخيار سهلاً. الخطوة التالية كانت اختيار “عقل” البوت. هناك أطر عمل جاهزة مثل Hubot (الكلاسيكي) أو Lita، لكننا قررنا بناء بوت مخصص باستخدام Python وإطار عمل Flask. هذا أعطانا مرونة كاملة لتصميمه حسب احتياجاتنا بالضبط.

نصيحة من خبرتي: لا تعقد الأمور. ابدأ بمنصة المحادثة التي يستخدمها فريقك بالفعل. إذا كنت جديداً على الموضوع، جرب بناء بوت بسيط باستخدام Bolt for Python (لـ Slack) أو أي مكتبة مشابهة لمنصتك. المرونة تأتي لاحقاً.

الخطوة الثانية: بناء الأوامر الأولى (ابدأ صغيراً)

أكبر خطأ يمكن أن ترتكبه هو محاولة أتمتة كل شيء دفعة واحدة. اتفقنا على البدء بأكثر المهام إلحاحاً وألماً أثناء الحوادث: مهام الفحص والتشخيص.

أول أمر بنيناه كان بسيطاً جداً: فحص حالة الخدمات (Health Check).

@our-bot status service api-gateway

خلف الكواليس، كان البوت يقوم بتنفيذ الآتي:

1. يستقبل الأمر عبر واجهة برمجية (API) من Slack.
2. يتحقق من صلاحيات المستخدم (هل يحق له تنفيذ هذا الأمر؟).
3. يتصل بنظام المراقبة الخاص بنا (Prometheus) ويستعلم عن حالة الخدمة.
4. ينسق الرد في رسالة واضحة ويرسلها إلى قناة Slack.

هذا الأمر البسيط وحده وفر علينا دقائق ثمينة في كل مرة. لم يعد أحد بحاجة لسؤالي “أبو عمر، هل الخدمة الفلانية تعمل؟”.

مثال كود مبسط (Python + Flask)

لتقريب الصورة، هذا مثال بسيط جداً لواجهة برمجية يمكن أن يستخدمها البوت للتحقق من حالة خادم ما:

from flask import Flask, jsonify, request
import subprocess

app = Flask(__name__)

# هذا مجرد مثال، في الواقع يجب تأمين هذه الواجهة بمفتاح سري أو توثيق
# This is just an example. In reality, you must secure this endpoint.
@app.route('/check-server', methods=['POST'])
def check_server():
    data = request.json
    server_ip = data.get('ip')

    if not server_ip:
        return jsonify({'status': 'error', 'message': 'IP address is missing'}), 400

    # استخدم أمر ping البسيط كمثال للفحص
    # Using a simple 'ping' as a health check example
    try:
        # -c 1 يعني إرسال حزمة واحدة فقط
        # -c 1 means send only one packet
        result = subprocess.run(
            ['ping', '-c', '1', server_ip],
            capture_output=True,
            text=True,
            timeout=5
        )
        if result.returncode == 0:
            response_text = f"✅ Server {server_ip} is UP.n`{result.stdout}`"
        else:
            response_text = f"❌ Server {server_ip} is DOWN.n`{result.stderr}`"
        
        return jsonify({'status': 'success', 'message': response_text})

    except subprocess.TimeoutExpired:
        return jsonify({'status': 'error', 'message': f"❌ Timed out trying to reach {server_ip}."})
    except Exception as e:
        return jsonify({'status': 'error', 'message': f"An unexpected error occurred: {str(e)}"}), 500

if __name__ == '__main__':
    # للإنتاج، استخدم خادم WSGI مثل Gunicorn
    # For production, use a WSGI server like Gunicorn
    app.run(host='0.0.0.0', port=5001)

البوت في Slack سيقوم باستدعاء هذا الـ endpoint (مثلاً: http://bot-backend:5001/check-server) ويرسل له عنوان IP كبيانات JSON.

الخطوة الثالثة: التوسع نحو الأوامر التنفيذية بحذر

بعد نجاح أوامر التشخيص، انتقلنا بحذر إلى الأوامر التي تُحدث تغييراً (مثل إعادة تشغيل خدمة أو نشر إصدار جديد). هنا، الأمان هو الأولوية القصوى.

• التحكم في الوصول القائم على الأدوار (RBAC): قمنا بإنشاء مجموعات مستخدمين داخل البوت (e.g., `devops-admins`, `developers`). أمر مثل `deploy to production` لا يمكن تنفيذه إلا من قبل أعضاء `devops-admins`.
• خطوات التأكيد: للأوامر الخطيرة، أضفنا خطوة تأكيد. عندما يكتب أحدهم أمراً للنشر في البيئة الحية، يرد البوت: “هل أنت متأكد أنك تريد نشر النسخة X على Production؟” مع أزرار “تأكيد” و “إلغاء”.
• التكامل مع أدوات CI/CD: لم نُعد اختراع العجلة. البوت لم يكن ينفذ النشر بنفسه، بل كان يقوم بتشغيل مسار عمل (pipeline) موجود مسبقاً في GitLab CI عبر الـ API الخاص به، مما يضمن أن جميع خطوات الاختبار والفحص تتم كالمعتاد.

الحادثة التالية: من الفوضى إلى السيمفونية المنظمة

بعد بضعة أشهر، وفي ليلة هادئة أخرى، وقعت حادثة جديدة. لكن هذه المرة، كان المشهد مختلفاً تماماً:

1. تنبيه من نظام المراقبة وصل إلى PagerDuty.
2. PagerDuty، عبر webhook، أرسل إشعاراً إلى بوت الـ ChatOps.
3. البوت قام تلقائياً بالآتي:
   • أنشأ قناة سلاك جديدة باسم #incident-db-high-latency-2024-05-21.
   • دعا مهندس قواعد البيانات ومهندس الواجهات الخلفية المناوبين إلى القناة.
   • نشر في القناة تفاصيل التنبيه الأولية مع رابط إلى لوحة المراقبة (Dashboard).
4. انضممت أنا والمهندسون إلى القناة. كل المعلومات الأولية أمامنا.
5. المهندس الأول كتب: @bot get db logs last 10m. ظهرت السجلات مباشرة في القناة.
6. المهندس الثاني كتب: @bot show active db queries. ظهرت قائمة بالاستعلامات البطيئة.
7. بعد تحديد الاستعلام المسبب للمشكلة، كتب أحدنا: @bot kill query 12345.
8. انحلت المشكلة. كتبنا: @bot resolve incident #5432 - reason: slow query from reporting service.

كل هذا حدث في أقل من 15 دقيقة. المدير الذي انضم للقناة لم يحتج أن يسأل “ما هو التحديث؟”؛ كل شيء كان موثقاً أمامه بالترتيب الزمني. كانت المحادثة نفسها هي التقرير الحي للحادثة. شعرت وقتها أننا انتقلنا من العصر الحجري إلى عصر الفضاء في إدارة العمليات.

الخلاصة: مش مجرد أداة، بل ثقافة جديدة 🚀

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

إذا كان فريقك لا يزال يغرق في بحر من الرسائل والاجتماعات أثناء الحوادث، فربما حان الوقت لتبدأ رحلتك مع ChatOps. ابدأ بخطوة صغيرة، أتمتة مهمة واحدة مؤلمة، وشاهد كيف ستنمو هذه البذرة لتغير طريقة عمل فريقك بأكمله.

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