إدارة الحوادث: كيف أنقذنا ChatOps من جحيم الإيميلات والتنسيق البطيء؟

ليلة لا تُنسى: حين كاد “التنسيق” أن يقتلنا

أذكرها وكأنها البارحة، كانت ليلة شتاء باردة، والساعة تقترب من الثانية صباحًا. رنّ هاتفي بصوتٍ أعرفه جيدًا، صوت تنبيه من نظام المراقبة يُعلن عن كارثة: “API Gateway – Critical Failure”. شعرت ببرودة تسري في عروقي، فهذا يعني أن كل خدماتنا الرئيسية قد توقفت.

في دقائق، تحولت قناة السلاك (Slack) الخاصة بالفريق إلى ساحة حرب رقمية. الإشعارات تتوالى، والأسئلة تتطاير: “مين شاف آخر deployment؟”، “حدا يفحص سجلات الأخطاء (logs) بالله!”، “الدعم الفني بحكوا الزباين بشتكوا!”، “فتحت تذكرة على Jira، رقمها PROD-12345”.

كنت أتنقل بجنون بين أربع شاشات: شاشة الإيميلات التي تحمل تحديثات تذكرة Jira، شاشة السلاك المليئة بالنقاشات غير المنظمة، شاشة طرفية (Terminal) أحاول فيها الوصول للسيرفرات، وشاشة Grafana التي تُظهر رسومًا بيانية حمراء بالكامل. كان كل فرد في الفريق يعمل في جزيرة معزولة، نكرر نفس الأوامر، ونسأل نفس الأسئلة. ضاع وقت ثمين في محاولة فهم “من يفعل ماذا؟”. كانت شغلة بتجلط من الآخر.

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

ما هو جحيم التنسيق البطيء؟

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

• تشتت المعلومات (Information Silos): المعلومات الحيوية مبعثرة. فريق الدعم لديه شكاوى العملاء، المطورون لديهم سياق الكود، وفريق العمليات (Ops) لديه الوصول إلى البنية التحتية. تجميع هذه الأجزاء معًا أثناء أزمة يشبه تجميع أحجية في الظلام.
• القفز بين السياقات (Context Switching): كل مرة تنتقل فيها من الإيميل إلى Jira إلى Slack إلى أداة المراقبة، فإنك تفقد تركيزك وطاقتك الذهنية. هذا التبديل المستمر يستهلك وقتًا ثمينًا ويبطئ من عملية حل المشكلات.
• الاستجابة اليدوية البطيئة: إنشاء تذكرة، تعيينها، طلب السجلات، إعادة تشغيل خدمة، إعلام أصحاب المصلحة… كل خطوة هي عملية يدوية تنتظر شخصًا ما ليقوم بها. هذه الدقائق تتراكم بسرعة لتصبح ساعات من التوقف عن العمل.
• انعدام الشفافية: من الصعب على الجميع، وخاصة المدراء أو الفرق الأخرى، الحصول على رؤية واضحة ومباشرة لما يحدث. من يعمل على المشكلة؟ ما هي الإجراءات التي تم اتخاذها؟ ما هي النتائج؟

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

المنقذ: ChatOps، أو “العمليات المُدارة عبر المحادثة”

كثيرون يظنون أن ChatOps هو مجرد استخدام برامج الدردشة مثل Slack أو Microsoft Teams في العمل. لكن المفهوم أعمق من ذلك بكثير.

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

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

كيف يعمل هذا السحر؟

1. المهندس يكتب أمرًا: في قناة مخصصة للحوادث (مثلاً #incidents)، يكتب المهندس أمرًا مثل /incident check-status api-gateway.
2. البوت يستجيب: البوت، الذي هو عبارة عن تطبيق متصل بمنصة الدردشة، يرى هذا الأمر.
3. البوت ينفذ المهمة: يتصل البوت بأدوات المراقبة الخاصة بك (مثل Prometheus)، أو بالبنية التحتية (مثل Kubernetes)، أو بأي نظام آخر، وينفذ المهمة المطلوبة.
4. البوت يعرض النتيجة: يقوم البوت بنشر الرد في القناة: “✅ API Gateway is UP and running.” أو “🚨 CRITICAL: API Gateway is responding with 503 errors!”.

الجمال هنا أن كل هذا يحدث في مكان واحد، ويكون مرئيًا لجميع أعضاء الفريق المعنيين. لا مزيد من “هل فحص أحدكم الحالة؟”، فالجواب موجود أمام الجميع.

رحلتنا العملية في بناء نظام ChatOps

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

المرحلة الأولى: اختيار الأدوات والبدء بالبسيط

اخترنا الأدوات التي نستخدمها بالفعل: Slack كمنصة محادثة، وPython مع مكتبة Slack Bolt لبناء البوت الخاص بنا (أسميناه “زيتون” 🤖).

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

مثال كود بسيط (Python – Slack Bolt):

import os
import requests
from slack_bolt import App

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

# تعريف أمر السلاش /health
@app.command("/health")
def check_service_health(ack, respond, command):
    ack()  # إرسال تأكيد فوري للسلاك أن الأمر تم استلامه

    service_url = command['text']
    if not service_url:
        respond("الرجاء تحديد رابط الخدمة، مثال: /health https://api.example.com")
        return

    try:
        response = requests.get(service_url, timeout=5)
        if response.status_code == 200:
            respond(f"✅ الخدمة {service_url} تعمل بشكل سليم (Status: 200 OK)")
        else:
            respond(f"⚠️ الخدمة {service_url} تواجه مشكلة (Status: {response.status_code})")
    except requests.exceptions.RequestException as e:
        respond(f"🚨 لا يمكن الوصول إلى الخدمة {service_url}. الخطأ: {e}")

# ... (كود بدء التطبيق)

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

المرحلة الثانية: التشخيص وجمع المعلومات

بعد بناء الثقة في البوت، انتقلنا إلى الأهم: جلب المعلومات التشخيصية إلى قناة السلاك.

• جلب السجلات (Logs): أنشأنا أمرًا مثل /logs get-service my-app --lines 100. يقوم البوت بالاتصال بنظام تجميع السجلات (Loki/Elasticsearch) وجلب آخر 100 سطر من سجلات التطبيق ونشرها كملف نصي في القناة.
• جلب الرسوم البيانية: أمر مثل /grafana get-graph cpu-usage-prod-db يقوم بجلب صورة للرسم البياني من Grafana مباشرة إلى المحادثة. أصبح بإمكاننا رؤية ارتفاع استهلاك المعالج بأعيننا دون مغادرة Slack.

المرحلة الثالثة (الأخطر والأقوى): اتخاذ الإجراءات

هنا تكمن القوة الحقيقية لـ ChatOps، ولكنها تتطلب حذرًا شديدًا. بدأنا بأتمتة الإجراءات التصحيحية الشائعة.

• إعادة تشغيل الخدمات: أمر مثل /kube restart deployment/my-app-deployment. هذا الأمر لا ينفذ مباشرة، بل يطلب تأكيدًا من مهندس آخر في القناة عبر الضغط على زر “Approve”. هذا يضمن عدم اتخاذ إجراءات خطيرة بشكل فردي.
• توسيع نطاق الخدمات (Scaling): أمر مثل /kube scale deployment/my-app-deployment --replicas=5 لمواجهة الأحمال العالية.

كل أمر يتم تنفيذه، وكل نتيجة، وكل موافقة تُسجل تلقائيًا في القناة. أصبحت قناة السلاك هي السجل الزمني الدقيق للحادث، وهو كنز لا يقدر بثمن عند كتابة تقارير ما بعد الحادث (Post-mortems).

نصائح أبو عمر العملية من القلب

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

1. ابدأ صغيرًا يا جماعة: لا تحاول أتمتة كل شيء دفعة واحدة. ابدأ بأوامر القراءة فقط (read-only) مثل التحقق من الحالة وجلب المعلومات. ابنِ الثقة في النظام تدريجيًا.
2. الأمان أولًا وأخيرًا: الإجراءات التي تعدّل على النظام (مثل إعادة التشغيل) يجب أن تكون محمية. استخدم صلاحيات محددة (RBAC)، واجعل الإجراءات الخطيرة تتطلب موافقة من شخص آخر (two-person rule). سجل كل أمر ومن قام بتنفيذه.
3. لا تستبدل البشر، بل مكّنهم: الهدف ليس التخلص من المهندسين، بل تحريرهم من المهام الروتينية المملة ليركزوا على حل المشكلات الحقيقية والإبداع. ChatOps هو مساعد ذكي، وليس بديلاً.
4. الثقافة أهم من الكود: يمكنك كتابة أفضل بوت في العالم، ولكن إذا لم يتبنى الفريق هذه الطريقة الجديدة في العمل، فسيفشل المشروع. كن قدوة، وشجع على استخدام البوت، واحتفل بالنجاحات الصغيرة.
5. وثّق أوامر البوت الخاص بك: يجب أن يكون لدى البوت أمر /help واضح يشرح كل الأوامر المتاحة وكيفية استخدامها. اعتبر أوامر البوت واجهة سطر أوامر (CLI) جديدة لفريقك.

الخلاصة: من الفوضى إلى التناغم оркеسترا 🎶

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

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