بتذكرها زي كأنها مبارح. ليلة خميس، الساعة تعدت منتصف الليل، والكل مجتمع على مكالمة “سكايب”. أنا، واثنين من المطورين، ومدير المشروع اللي كان وجهه على الشاشة يوضح قديش هو متوتر. كان عنا تحديث مهم لازم يطلع للعميل قبل بداية يوم العمل، والمهمة كانت “بسيطة”: نشر الإصدار الجديد على الخوادم الإنتاجية.
لكن “بسيطة” هاي كانت كلمة حق يُراد بها باطل. الأجواء كانت مشحونة، كأننا في غرفة عمليات جراحية. أنا كنت ماسك دفة القيادة، فاتح شاشة سوداء (الطرفية)، والكل بنتظرني. “يلا يا أبو عمر، نفّذ الأمر الأول”. أنسخ الأمر، وألصقه، وأضغط Enter وأنا بحكي “بسم الله”. ثواني بتمر كأنها ساعات، وبعدها بتظهر رسالة نجاح. الكل بتنفس الصعداء، “الحمد لله”.
ونكمل على هالحال… “يلا الأمر الثاني”، “هات اللي بعده”. لحد ما وصلنا للأمر الخامس، وفجأة… خطأ! أحمر كبير وواضح على الشاشة. صمت رهيب في المكالمة، كأن الكهرباء انقطعت. مدير المشروع سأل بصوت برتعش: “شو صار؟”. وهون بلش الجحيم الحقيقي. “مين معه صلاحية يفوت على سجلات الأخطاء (logs)؟”، “يا فلان، اعمل SSH على السيرفر الثاني وشوف وضع الخدمة”، ” esp_أنا مش قادر أوصل للسيرفر، حدا غيري يجرب؟”. فوضى عارمة، كل واحد بحاول يعمل إشي، وما حدا عارف الثاني شو بعمل. بعد ساعتين من الشد والجذب، اكتشفنا انه متغير بيئي (Environment Variable) كان ناقص في ملف الإعدادات. مشكلة تافهة ضيعت علينا ليلة كاملة من التوتر والتعب.
بعد هذيك الليلة، جلست مع حالي وصفنت. قلت “يا زلمة، مش معقول نضل هيك. في القرن الواحد والعشرين، ومع كل هالتطور، لسا بنعمل نشر وكأننا بنطلق صاروخ للفضاء يدويًا؟ لازم يكون في طريقة أفضل”. ومن هنا بدأت رحلتي ورحلة فريقي مع ما يسمى بـ “العمليات عبر المحادثة” أو الـ ChatOps.
ما هي ‘العمليات عبر المحادثة’ (ChatOps)؟ وليش بنحكي عنها؟
ببساطة شديدة، الـ ChatOps هي ممارسة أو ثقافة عمل تهدف إلى تنفيذ مهام إدارة الأنظمة والعمليات (DevOps) من خلال منصة محادثة. بدل ما كل واحد يفتح الطرفية (Terminal) على جهازه ويشتغل لحاله، بنجمع كل الأدوات والأوامر والعمليات في مكان واحد مشترك: قناة محادثة (زي Slack, Microsoft Teams, Mattermost).
الفكرة مش بس إنك “تدردش” مع زملائك، الفكرة إنك “تدردش” مع أنظمتك! بتكتب أمر في القناة، وروبوت (Bot) مبرمج خصيصًا بستقبل هذا الأمر، بنفذه، وبرجعلك بالنتيجة في نفس القناة. والجميل في الموضوع؟ كل الفريق بشوف الأمر اللي انكتب، وبشوف النتيجة. شفافية كاملة.
تخيل الـ ChatOps كأنها مساعدك الشخصي الذكي. بدل ما تقوم بنفسك وتفتح الثلاجة وتجيب المي، بتنادي عليه “يا فلان، جيبلي كاسة مي”، وهو بروح وبجيبها وبرجعلك. مساعدك هان هو الـ Bot، والمي هي عملية النشر أو أي مهمة أخرى.
من الفوضى إلى النظام: رحلة التحول نحو ChatOps
التحول ما صار بيوم وليلة، كان عبارة عن رحلة مشيناها خطوة بخطوة، أو زي ما بنحكي “حبة حبة”.
المرحلة الأولى: الاعتراف بالمشكلة
أول خطوة في العلاج هي الاعتراف بالمرض. مشاكلنا كانت واضحة زي عين الشمس بعد ليلة النشر المشؤومة:
- مركزية المعرفة (Bus Factor): المعرفة والصلاحيات كانت محصورة في شخص أو شخصين. إذا أنا كنت نايم أو مسافر، عملية النشر بتتعطل.
- غياب الشفافية والسجل التاريخي: بعد ما تنتهي المكالمة، ما حدا بتذكر بالضبط شو الأوامر اللي تنفذت ومين نفذها. تصحيح الأخطاء المستقبلية بصير كابوس.
- جحيم التنسيق: رسائل لا نهائية على الخاص والعام: “نشرت؟”، “أدمج الكود تبعي؟”، “استنى شوي لا تنشر”. هذا كله بضيع وقت وجهد.
- مخاطر أمنية: مشاركة مفاتيح SSH، وإعطاء المطورين صلاحيات دخول مباشر على خوادم الإنتاج… كلها ممارسات خطيرة.
المرحلة الثانية: اختيار الأدوات المناسبة (العدة تبعتنا)
بعد ما اقتنع الفريق، بدأنا نجهز “العدة”. المعادلة بسيطة:
منصة محادثة + روبوت (Bot) + سكربتات وأتمتة
- منصة المحادثة: اخترنا Slack لأنه كان الأداة المستخدمة في الشركة، لكن المبدأ نفسه ينطبق على Microsoft Teams أو أي أداة أخرى تدعم التكاملات (Integrations).
- الروبوت (Bot): في البداية، فكرنا نستخدم إطار عمل جاهز مثل Hubot. لكن مع الوقت، وجدنا أن بناء تكامل مخصص باستخدام (Slack Apps) وربطه مع خدمات (Serverless) مثل AWS Lambda أو Google Cloud Functions أعطانا مرونة أكبر.
- الأتمتة: هذا هو القلب النابض. الـ Bot ما بعمل سحر، هو مجرد وسيط. الأتمتة الحقيقية كانت في سكربتات الـ CI/CD تبعتنا (كنا نستخدم GitLab CI، واليوم نستخدم GitHub Actions بكثرة).
المرحلة الثالثة: البدء بخطوات صغيرة
وهان بتيجي نصيحة من القلب: لا تحاول أتمتة كل شيء من أول يوم. ستقع في فخ التعقيد وستفشل. بدأنا بأشياء بسيطة جدًا وغير خطيرة:
- أول أمر عملناه كان للقراءة فقط:
@our-bot status staging. هذا الأمر كان يروح يتأكد إذا الموقع على البيئة التجريبية شغال وبرجع برسالة بسيطة. - الأمر الثاني كان:
@our-bot version production. كان يرجع برقم الإصدار الحالي المنشور على البيئة الإنتاجية.
هذه الأوامر البسيطة بنت الثقة عند الفريق. شافوا كيف إنها مفيدة وسهلة، وصاروا هم نفسهم يطلبوا أتمتة مهام جديدة.
مثال عملي: نشر تطبيق باستخدام ChatOps
خلينا نقارن بين الطريقة القديمة وطريقة الـ ChatOps لنفس المهمة: نشر الفرع الرئيسي (main branch) على البيئة التجريبية (staging).
الطريقة القديمة (ملخص الفوضى):
- المطور يفتح الطرفية.
- يعمل SSH على خادم النشر.
- يكتب
git pull origin main. - يشغل سكربت البناء
./build.sh. - يعمل SSH على خادم البيئة التجريبية.
- يشغل أوامر Docker أو Kubernetes.
- يرجع على قناة المحادثة ويكتب: “يا جماعة، تم النشر على staging”.
طريقة الـ ChatOps (شغل مرتب ومنظم):
في قناة المحادثة المخصصة للنشر (مثلاً #deployments)، المطور يكتب أمر واحد فقط:
@deploy-bot deploy my-app to stagingوهنا يبدأ السحر المنظم:
- الـ Bot يستقبل الأمر في القناة.
- (شفافية) الـ Bot يرد في القناة: “طلب نشر تطبيق `my-app` إلى `staging` من المستخدم `[اسم المستخدم]`. جاري البدء…”
- الـ Bot يتأكد من صلاحيات المستخدم (هل مسموح له بالنشر على هذه البيئة؟).
- الـ Bot يقوم بتشغيل مسار عمل (workflow) في نظام الـ CI/CD (مثل GitHub Actions) عبر استدعاء API.
- (شفافية) مسار العمل يبدأ، والـ Bot يرسل تحديثات للقناة: “✅ تم بناء الكود بنجاح”، “🚀 جاري نشر الإصدار الجديد…”
- عند انتهاء النشر، الـ Bot يرسل النتيجة النهائية: “🎉 تم نشر `my-app` بنجاح على `staging`! رابط الموقع: [رابط].”
- إذا حدث خطأ، الـ Bot يرسل رسالة خطأ واضحة مع رابط لسجلات الأخطاء (logs) للمراجعة: “🚨 فشلت عملية النشر! تفاصيل الخطأ: [رابط].”
كل هذا يحدث أمام أعين الفريق بأكمله. لا حاجة للسؤال “شو صار؟”، لأن كل شيء موثق وموجود في المحادثة.
مثال كود (كيف يترجم هذا لواقع؟)
الـ Bot لا يقوم بالنشر بنفسه، بل هو مجرد “مُشغّل” (trigger). يمكن أن يقوم بإرسال طلب HTTP بسيط إلى GitHub API لتشغيل مسار عمل معين باستخدام repository_dispatch. هذا هو شكل مسار العمل في GitHub Actions الذي ينتظر هذا الطلب:
# .github/workflows/chatops-deploy.yml
name: ChatOps Triggered Deploy
# هذا المسار يعمل فقط عند استدعائه عبر الـ API
on:
repository_dispatch:
types: [deploy-staging] # هذا الاسم يجب أن يرسله الـ Bot
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v3
- name: Notify channel - Starting
# هنا يتم استدعاء API لإرسال رسالة إلى Slack/Teams
run: echo "Deployment to staging has started..."
- name: Build and push Docker image
run: echo "Building and pushing image..."
# ... الأوامر الفعلية للبناء والنشر ...
- name: Deploy to Staging
run: echo "Deploying to staging server..."
# ... الأوامر الفعلية للنشر (e.g., kubectl apply, ssh and run script) ...
- name: Notify channel - Success
if: success()
run: echo "✅ Deployment to staging was successful!"
- name: Notify channel - Failure
if: failure()
run: echo "🚨 Deployment to staging failed!"
بهذه الطريقة، منطق النشر المعقد يبقى في مكانه الطبيعي (CI/CD)، والـ Bot دوره بسيط وواضح: التنسيق والتواصل.
نصائح من خبرة أبو عمر
- الأمان أولاً يا جماعة: لا تضع أي معلومات حساسة (مثل مفاتيح API أو كلمات المرور) في كود الـ Bot. استخدم مدير أسرار (Secrets Manager). طبق صلاحيات دقيقة، فلا يستطيع أي شخص نشر الكود على البيئة الإنتاجية مثلاً.
- التوثيق هو الصديق الوفي: يجب أن يكون لدى الـ Bot أمر
@bot helpيعرض كل الأوامر المتاحة وشرحًا بسيطًا لكل منها. لا تجعل فريقك يخمن! - اجعلها محادثة، مش مجرد أوامر: تصميم الـ Bot يجب أن يكون تفاعليًا. استخدم الرموز التعبيرية، رسائل واضحة، وأزرار تفاعلية إن أمكن. هذا يشجع الفريق على استخدامه.
- لا تخف من الفشل: أول Bot ستصنعه لن يكون مثاليًا. لا بأس. المهم أن تبدأ وتتعلم وتطور مع الوقت بناءً على احتياجات فريقك.
- وسّع النطاق تدريجيًا: بعد أن تتقن أتمتة النشر، فكر في المهام الأخرى: إعادة تشغيل خدمة، التحقق من حالة قاعدة البيانات، إنشاء بيئة اختبار مؤقتة لمطور، أو حتى عرض تقارير أداء. الإمكانيات لا حصر لها.
الخلاصة: ودّع اجتماعات النشر! 🚀
الـ ChatOps ليست مجرد أداة تقنية جديدة، بل هي نقلة نوعية في ثقافة العمل. إنها تحول العمليات من كونها غامضة وتعتمد على أفراد، إلى عمليات شفافة، موثقة، وتعاونية. النتيجة ليست فقط توفير الوقت والجهد، بل بناء فريق أقوى وأكثر ثقة، وتقليل الأخطاء البشرية التي تكلفنا ليالٍ طويلة من التوتر.
إذا كنت وفريقك ما زلتم تعقدون “اجتماعات” لنشر تحديث برمجي، أو تعتمدون على شخص واحد ليكون “بطل النشر”، فربما حان الوقت لتجلسوا وتفكروا: “ألا توجد طريقة أفضل؟”. صدقني، الجواب هو نعم، والرحلة نحو هذه الطريقة تبدأ بأمر واحد في قناة محادثة. جربوها، ولن تندموا.
