تنبيهاتنا كانت تصرخ في فراغ: كيف أنقذتنا ‘الـ ChatOps’ من جحيم الاستجابة البطيئة للحوادث؟

يا جماعة الخير، السلام عليكم ورحمة الله. اسمي أبو عمر، وأنا اليوم جاي أحكي لكم قصة صارت معي ومع فريقي قبل كم سنة، قصة من قلب المعاناة التقنية اللي كلنا بنعرفها. كانت ليلة شتوية باردة، والساعة حوالي 2 بعد منتصف الليل. فجأة، بدأ تلفوني يولّع إشعارات زي المطر… “Server Down”, “High CPU Usage”, “Database Connection Lost”.

في ثوانٍ، تحولت غرفة نومي الهادئة إلى غرفة عمليات حربية. أنا على اللابتوب، وزميلي “أحمد” بيبعتلي على الواتساب، ومدير المشروع برن عليّ تلفون، ومهندس الشبكات بيبعت إيميلات للكل. كل واحد فينا شايف جزء من المشكلة، وما حدا شايف الصورة الكاملة. أنا بحاول أدخل على السيرفر بـ SSH، بس الاتصال بطيء. أحمد بقول إنه المشكلة من قاعدة البيانات، وأنا شاكك إنها من الـ Load Balancer. ضاعت المعلومات بين المكالمات والرسائل، وضاع معها وقت ثمين جداً كانت أنظمتنا فيه شبه متوقفة تماماً والعملاء بدأوا يشتكوا.

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

من هداك اليوم، بدأت رحلتنا مع عالم الـ ChatOps، العالم اللي نقلنا من الفوضى إلى النظام، ومن الاستجابة البطيئة إلى الحلول الفورية. خلوني آخذكم معي في هذي الرحلة.

ما هي الـ ChatOps بالضبط؟ هل هي مجرد “شات” للمبرمجين؟

لما يسمع الواحد مصطلح “ChatOps” لأول مرة، ممكن يفكر إنها مجرد مجموعة دردشة على Slack أو Teams بنحكي فيها عن الشغل. لكن الحقيقة أعمق من هيك بكثير.

الـ ChatOps هي منهجية عمل تهدف إلى دمج الأدوات، العمليات، والتواصل في منصة محادثة مركزية واحدة. الفكرة باختصار هي: بدل ما تروح إنت للشغل (تفتح عشرين شاشة وبرنامج)، الشغل هو اللي بيجيك على الشات.

تخيل أنك في قناة Slack المخصصة للحوادث (Incidents). فجأة، يصل تنبيه من نظام المراقبة مباشرة إلى هذه القناة، مع كل التفاصيل والرسوم البيانية. من نفس القناة، وبأمر بسيط تكتبه في الشات، تقدر تعمل الآتي:

• تطلب معلومات إضافية عن حالة السيرفر.
• تعيد تشغيل خدمة معينة.
• تنفذ عملية Rollback لآخر نسخة مستقرة من الكود.
• تفتح تذكرة تلقائياً في نظام إدارة المشاريع (مثل Jira).

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

من الفوضى إلى النظام: كيف غيرت الـ ChatOps طريقة عملنا؟

بعد حادثة “ليلة الرعب” تلك، قررنا أن التغيير حتمي. وهنا بدأت الفوائد الحقيقية للـ ChatOps تظهر لنا بشكل عملي وملموس.

مركزية التواصل والشفافية الكاملة

أول وأهم تغيير هو أن كل شيء صار في مكان واحد. لا مزيد من رسائل الواتساب المشتتة أو سلاسل الإيميلات التي لا تنتهي. أي حادثة تقع، يتم إنشاء قناة مخصصة لها تلقائياً (مثلاً #incident-db-outage-2023-10-26). كل أعضاء الفريق المعنيين تتم إضافتهم، وكل التنبيهات، الأوامر، والنتائج يتم توثيقها في هذه القناة. حتى لو انضم عضو جديد للفريق في منتصف الحادثة، يستطيع ببساطة قراءة تاريخ المحادثة ليفهم كل ما جرى.

سرعة الاستجابة الخارقة

في الماضي، إذا أردت إعادة تشغيل سيرفر، كنت تحتاج لفتح الـ Terminal، كتابة أمر SSH، إدخال كلمة المرور، ثم كتابة أمر إعادة التشغيل. اليوم، من خلال “البوت” (الروبوت) الخاص بنا الذي أسميناه “زعتر”، كل ما نفعله هو كتابة أمر بسيط في القناة:

@زعتر restart web-server-03

يقوم “زعتر” بالتحقق من صلاحياتي، ثم ينفذ الأمر ويعود بالنتيجة إلى القناة. ما كان يأخذ دقائق، أصبح الآن يأخذ ثوانٍ.

توثيق تلقائي لكل شاردة وواردة

من أجمل الأشياء في الـ ChatOps أن سجل المحادثات نفسه يصبح سجلاً زمنياً دقيقاً للحادثة. هذا الكنز لا يقدر بثمن عند عمل جلسات المراجعة بعد الحادثة (Post-mortems). نستطيع أن نرى بالضبط:

• متى بدأ التنبيه الأول؟
• من الذي استجاب أولاً؟
• ما هي الفرضيات التي تم طرحها؟
• ما هي الأوامر التي تم تنفيذها، وماذا كانت نتائجها؟
• كم من الوقت استغرقت كل خطوة؟

هذا يساعدنا على التعلم من أخطائنا وتحسين عملياتنا بشكل مستمر.

رحلتنا العملية مع الـ ChatOps: من وين نبدأ يا أبو عمر؟

الكلام النظري جميل، لكن التطبيق هو الأهم. سأعطيكم خارطة طريق بسيطة ومجربة للبدء.

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

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

الخطوة الثانية: الروبوت (البوت) هو قلب العملية

البوت هو الوسيط بينكم وبين أنظمتكم. هو الذي يستمع لأوامركم وينفذها. يمكنك استخدام أطر عمل جاهزة لبناء البوت الخاص بك مثل Hubot (مكتوب بـ CoffeeScript/JavaScript) أو بناء بوت مخصص باللغة التي تفضلها. نحن في فريقنا فضلنا بناء بوت بسيط باستخدام Python لأنه سهل ومرن.

الخطوة الثالثة: ربط الأدوات الأساسية (Integrations)

ابدأ بالأشياء التي تسبب لك أكبر قدر من الألم. في حالتنا، كانت التنبيهات.

• أنظمة المراقبة (Monitoring): قم بربط نظام المراقبة الخاص بك (مثل Prometheus, Grafana, Datadog) مع قناة مخصصة للتنبيهات (مثلاً #alerts). عندما يتجاوز استخدام المعالج 90%، يجب أن يظهر تنبيه فوري في هذه القناة.
• أنظمة الـ CI/CD: اربط أدوات مثل Jenkins أو GitLab CI. يمكنك إعداد أوامر لتشغيل عمليات البناء (Build) أو النشر (Deploy) مباشرة من الشات. مثلاً: /deploy staging-branch to staging-env.
• مزودي الخدمات السحابية (Cloud Providers): استخدم الـ SDKs الخاصة بـ AWS, Azure, أو GCP لتمكين البوت من تنفيذ أوامر بسيطة مثل التحقق من حالة خدمة معينة أو إعادة تشغيل جهاز افتراضي.

خلينا نشوف كود: مثال عملي بسيط باستخدام Slack و Python

لكي لا يبقى الكلام نظرياً، هذا مثال بسيط جداً لبوت Slack مكتوب بلغة Python باستخدام مكتبة slack_bolt. هذا البوت يستمع لأمر /deploy ويقوم بتنفيذ سكربت وهمي للنشر.

أولاً، ستحتاج لتثبيت المكتبات اللازمة:

pip install slack_bolt slack_sdk

ثم، هذا هو كود البوت (مثلاً app.py):

import os
import subprocess
from slack_bolt import App
from slack_sdk import WebClient

# --- الإعدادات الأولية ---
# تأكد من وضع هذه المتغيرات في بيئة العمل الخاصة بك (Environment Variables)
# لا تضعها مباشرة في الكود أبداً!
app = App(
    token=os.environ.get("SLACK_BOT_TOKEN"),
    signing_secret=os.environ.get("SLACK_SIGNING_SECRET")
)

# --- تعريف أمر النشر ---
# هذا الأمر يستجيب لـ /deploy في سلاك
@app.command("/deploy")
def handle_deployment_command(ack, respond, command):
    # نؤكد استلام الأمر فوراً لتجنب انتهاء المهلة من سلاك
    ack()

    # نستخرج البيئة والفرع من الأمر
    # المثال: /deploy staging main-branch
    text = command.get("text", "")
    parts = text.split()
    if len(parts) != 2:
        respond("عفواً، الصيغة غير صحيحة. الرجاء استخدام: `/deploy [environment] [branch]`")
        return

    environment, branch = parts
    user_id = command["user_id"]

    # رسالة أولية لإعلام المستخدم بأن العملية بدأت
    respond(f"يا <@{user_id}>، جاري البدء بنشر الفرع `{branch}` إلى بيئة `{environment}`... الرجاء الانتظار.")

    try:
        # هنا يتم تنفيذ الأمر الحقيقي
        # في مثالنا، سنقوم بتشغيل سكربت وهمي
        # في الواقع، سيكون هذا السكربت الخاص بك (e.g., ./scripts/deploy.sh)
        # ملاحظة: استخدام shell=True قد يكون خطراً، تأكد من تنقية المدخلات جيداً
        result = subprocess.run(
            ["sh", "./fake_deploy.sh", environment, branch], 
            capture_output=True, 
            text=True,
            timeout=120 # مهلة 2 دقيقة
        )

        # بناء رسالة النتيجة
        if result.returncode == 0:
            # نجحت العملية
            output_message = f"✅ نجحت عملية النشر!n"
            output_message += f"البيئة: `{environment}`nالفرع: `{branch}`n"
            output_message += f"```n{result.stdout}n```"
        else:
            # فشلت العملية
            output_message = f"❌ فشلت عملية النشر!n"
            output_message += f"البيئة: `{environment}`nالفرع: `{branch}`n"
            output_message += f"**رسالة الخطأ:**n```n{result.stderr}n```"
        
        # إرسال النتيجة النهائية إلى القناة
        respond(output_message)

    except subprocess.TimeoutExpired:
        respond(f"⏰ انتهت مهلة العملية بعد 120 ثانية. الرجاء التحقق من حالة النظام يدوياً.")
    except Exception as e:
        respond(f"حدث خطأ غير متوقع أثناء تنفيذ الأمر: {str(e)}")


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

نصيحة من أبو عمر: لاحظ كيف أن الكود يرسل رسالة تأكيد أولية (ack() و respond() الأولى) ثم يقوم بالعملية الطويلة. هذا ضروري لأن Slack يتوقع استجابة خلال 3 ثوانٍ فقط. الرسالة الثانية التي تحتوي على النتيجة يتم إرسالها لاحقاً عند انتهاء العملية.

نصائح من قلب الميدان: خلاصة خبرتي مع الـ ChatOps

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

• ابدأ صغيراً (Start Small): لا تحاول أتمتة كل شيء في يوم وليلة. ابدأ بمشكلة واحدة مؤلمة وواضحة، مثل إرسال تنبيهات أنظمة المراقبة إلى قناة Slack. عندما يرى الفريق قيمة هذا التغيير البسيط، سيتحمسون للمزيد.
• الأمان أولاً وأخيراً (Security First and Last): هذه أهم نصيحة. ليس من المفترض أن يتمكن أي شخص من تنفيذ أمر /deploy production. قم بتطبيق نظام صلاحيات دقيق. يمكنك إنشاء مجموعات مستخدمين (مثل admins, developers) والتحقق من عضوية المستخدم قبل تنفيذ أي أمر حساس.
• اجعل الأوامر واضحة وبسيطة: يجب أن تكون الأوامر سهلة التذكر والفهم. استخدم صيغة واضحة مثل /command action target. وقم بتوفير رسالة مساعدة (help) تشرح كيفية استخدام كل أمر.
• التصميم من أجل الفشل (Design for Failure): ماذا لو فشل الأمر؟ ماذا لو توقف البوت عن العمل؟ يجب أن يكون البوت قادراً على التعامل مع الأخطاء وإبلاغ المستخدم بشكل واضح بما حدث، بدلاً من أن “يموت بصمت”.

الخلاصة: الـ ChatOps ليست أداة، بل ثقافة 🤝

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

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

نصيحتي الأخيرة لك: لا تنتظر “ليلة الرعب” القادمة حتى تبدأ. ابدأ اليوم، ولو بخطوة صغيرة جداً. اربط أول تنبيه لك بقناة محادثة، وشاهد السحر يبدأ. يلا يا جماعة، خلينا نشتغل بذكاء مش بجهد! 💪