كانت أوامرنا تضيع في الضجيج: كيف أنقذنا ChatOps من جحيم تبديل السياق؟

بتذكرها زي كأنها مبارح… ليلة خميس، والكل بستنى يروّح على بيته. فجأة، التلفونات بلشت ترن، ورسائل السلاك (Slack) صارت تضوي زي شجرة الميلاد. “الموقع واقع!”… “الـ API ما بترد!”… “شو القصة يا جماعة؟!”.

في هذيك اللحظات، بتبدأ الفوضى. المهندس “س” بحاول يعمل SSH على السيرفر، بس كلمة السر تغيرت وما حدا بعرف ليش. المهندسة “ص” بتحاول ترجع لآخر عملية deployment، بس مش عارفة مين اللي عملها أو متى. وأنا؟ كنت زي الأطرش في الزفة، بحاول أجمع الخيوط من عشر قنوات سلاك مختلفة، ورسائل خاصة، وإيميلات. كل واحد شغال في واد، والأوامر والمعلومات بتضيع في ضجيج الهلع.

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

ما هو الـ ChatOps بالضبط يا أبو عمر؟

بكل بساطة، الـ ChatOps هو ممارسة تنفيذ مهام إدارة العمليات (Operations) من خلال واجهة محادثة (Chat). تخيل إنك بتكتب أوامر للسيرفرات، بتعمل deploy للكود، أو بتسحب سجلات الأخطاء (logs)، كل هذا من داخل قناة سلاك أو Microsoft Teams الخاصة بفريقك. بدل ما تكون الأوامر مخفية في شاشة طرفية (terminal) على جهاز مهندس واحد، بتصير مرئية للجميع في سياق محادثة.

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

الركائز الأساسية للـ ChatOps

عشان تفهم الفكرة صح، الـ ChatOps قائم على ثلاث ركائز أساسية:

• المحادثة (The Conversation): هذا هو قلب العملية. قناة المحادثة (زي سلاك) بتصير هي غرفة العمليات المركزية للفريق.
• البوت (The Bot): هذا هو الجندي المجهول. بوت مبرمج خصيصًا بستقبل الأوامر منك وبنفذها بالنيابة عنك. هو الوسيط بينك وبين كل أدواتك وأنظمتك.
• الأدوات (The Tools & Integrations): البوت لحاله ما بعمل اشي. قوته بتيجي من قدرته على التكامل مع الأدوات اللي بتستخدمها يوميًا: أنظمة الـ CI/CD (زي Jenkins أو GitLab CI)، منصات المراقبة (زي Prometheus أو Datadog)، ومزودي الخدمات السحابية (زي AWS, Azure).

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

رحلتنا العملية مع ChatOps: من الفكرة إلى التنفيذ

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

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

كنا بنستخدم سلاك للتواصل الداخلي، فكان الخيار الطبيعي. بالنسبة للبوت، كان أمامنا خيارين: نستخدم إطار عمل جاهز مثل Hubot، أو نبني بوت مخصص. بما أنه فريقنا بحب “يوسخ ايديه” بالكود، قررنا نبني بوت بسيط باستخدام لغة Python ومكتبة Slack Bolt. هذا أعطانا مرونة كاملة لتخصيص كل شيء حسب احتياجاتنا.

المرحلة الثانية: أول أمر “يا هلا!”

أهم قاعدة في أي مشروع جديد: ابدأ صغيرًا. أول مهمة للبوت “زيتون” كانت بسيطة جدًا. عملنا أمر اسمه /zaytoun status. كل اللي بعمله هذا الأمر هو إنه يخلي البوت يرد علينا برسالة “كله تمام والحمل أمانة”.

هذا مثال بسيط جدًا على الكود بلغة Python كيف ممكن يكون:

# Import the necessary components from the Bolt framework
from slack_bolt import App
from slack_bolt.adapter.socket_mode import SocketModeHandler

# Initialize your app with your bot token
app = App(token="xoxb-YOUR-BOT-TOKEN")

# Define a command handler for "/zaytoun status"
@app.command("/zaytoun-status")
def handle_status_command(ack, body, logger, say):
    # Acknowledge the command request
    ack()
    
    # Get the user who triggered the command
    user_id = body["user_id"]
    
    # Send a message back to the channel
    say(text=f"أهلًا <@{user_id}>! كله تمام والحمل أمانة. 👍")

# Start your app
if __name__ == "__main__":
    # You'll also need an App-level token for Socket Mode
    handler = SocketModeHandler(app, "xapp-YOUR-APP-TOKEN")
    handler.start()

هذا الأمر البسيط كان بمثابة انتصار. أثبتنا إنه الفكرة شغالة، والآن صار وقت الشغل الجد.

المرحلة الثالثة: ربط الأدوات وتوسيع القدرات

هنا بدأت المتعة الحقيقية. بدأنا نربط “زيتون” بأدواتنا خطوة بخطوة:

• عمليات النشر (Deployments): بدل ما كل مطور يعمل deploy من جهازه، عملنا أمر /zaytoun deploy [app-name] to [environment]. هذا الأمر بشغل pipeline في GitLab CI، والكل بشوف في القناة مين اللي طلب الـ deploy، وعلى أي بيئة، وشو كانت النتيجة. شفافية كاملة!
• مراقبة السيرفرات (Monitoring): ربطنا “زيتون” مع نظام المراقبة Prometheus. صرنا نقدر نكتب /zaytoun get-logs [service-name] ويجيب لنا آخر 100 سطر من سجلات الأخطاء مباشرة في سلاك، بدل ما نروح نفتح عشر شاشات.
• إدارة الطوارئ (Incident Management): وهذا أهم إشي. عملنا أمر /zaytoun incident start [description]. لما نشغل هالأمر، البوت بيعمل الآتي تلقائيًا:
  1. بينشئ قناة سلاك جديدة مخصصة للحادثة (مثلاً #incident-db-down).
  2. بدعو كل المهندسين المناوبين (On-call) على القناة.
  3. بينشر رسالة في القناة الرئيسية يخبر الجميع بوجود مشكلة ويضع رابط القناة الجديدة.
  4. بيبدأ بتوثيق كل الأوامر والمحادثات في القناة لاستخدامها لاحقًا في تقرير ما بعد الحادثة (Post-mortem).

تخيل الفرق بين هذا السيناريو المنظم والفوضى اللي حكيت عنها في البداية. السماء والأرض!

الثمار التي قطفناها: كيف غير ChatOps طريقة عملنا؟

بعد أشهر من تبني هذه الثقافة، صارت الفوائد واضحة زي عين الشمس:

1. شفافية لا مثيل لها: كل العمليات مرئية للجميع. ما في اشي اسمه “مين عمل ريستارت للسيرفر؟”. افتح القناة وبتعرف كل القصة.
2. وداعًا لتبديل السياق (Context Switching): بطلنا نضيع وقتنا بالتنقل بين الطرفية (terminal)، والمتصفح، وسلاك، والإيميل. كل شغلنا صار في مكان واحد. هذا وفر علينا وقت وطاقة ذهنية هائلة.
3. سرعة الاستجابة في الطوارئ: الأوامر الجاهزة والخطوات الآلية خلت استجابتنا للحوادث أسرع بـ 3-4 مرات على الأقل.
4. توثيق ذاتي للعمليات: سجل المحادثة في القناة أصبح أفضل توثيق ممكن. لما يجي عضو جديد على الفريق، بنحكيله: “اقرأ سجل قناة الـ #ops وشوف كيف بنشتغل”.

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

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

• ابدأ صغيرًا ثم توسع: لا تحاول أتمتة كل شيء من أول يوم. ابدأ بأمر أو أمرين بسيطين ومفيدين. لما فريقك يشوف الفائدة، هم اللي راح يطلبوا منك تضيف المزيد.
• الأمان أولًا يا جماعة: مش أي حدا لازم يكون قادر يكتب /zaytoun deploy to production. تأكد من وجود صلاحيات (Permissions) وتحكم في الوصول (Access Control). خلي الأوامر الخطيرة مقيدة بأدوار معينة أو تتطلب موافقة من شخص آخر.
• اجعل الأوامر سهلة وبشرية: استخدم لغة طبيعية وسهلة الحفظ. /zaytoun get logs for api أفضل ألف مرة من /bot exec --service=api --action=get-logs --tail=100.
• لا تخف من التجربة والفشل: مش كل الأفكار راح تنجح، وهذا طبيعي. المهم تضلوا تجربوا وتحسنوا.

الخلاصة النهائية 🚀

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

الرحلة قد تبدو طويلة، لكن صدقني، كل خطوة فيها تستحق العناء. يلا، شدوا الهمة وابدأوا ببناء “زيتون” الخاص فيكم! 💪