كنا نعيش في سجن الـ SSH: كيف حررنا ChatOps من جحيم الأوامر اليدوية؟

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

قفزت من سريري إلى مكتبي، وفتحت عشرات النوافذ الطرفية (Terminals). كنت أتنقل بينها كالمجنون، نافذة لكل خادم أتصل به عبر SSH. كنت أكتب الأوامر بسرعة، ssh user@server1، ثم tail -f /var/log/syslog، ثم أنسخ الناتج وألصقه في قناة “سلاك” (Slack) ليسهل على سامر المتابعة. كان سامر يسألني كل دقيقة: “شو صار أبو عمر؟”، “شو نتيجة الأمر هاد؟”. كانت فوضى عارمة، سباق مع الزمن مليء بالتوتر والأوامر المتكررة والنسخ واللصق.

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

تلك الليلة كانت نقطة التحول. كانت الشرارة التي قادتنا لاكتشاف وتبني ثقافة الـ ChatOps، وتحرير أنفسنا من سجن الـ SSH الذي كنا نعيش فيه.

ما هو الـ ChatOps؟ ليس مجرد بوت للدردشة!

عندما يسمع البعض مصطلح “ChatOps”، يظنون أنه مجرد بوت لطيف يلقي النكات في قناة الفريق. لكن الحقيقة أعمق من ذلك بكثير. الـ ChatOps هو ممارسة وثقافة عمل تهدف إلى وضع أدواتك، أوامرك، وخطوات عملك (workflows) مباشرة داخل منصة المحادثة التي يستخدمها فريقك (مثل Slack, Microsoft Teams, وغيرها).

تخيل أن منصة الدردشة لم تعد مجرد مكان للتواصل، بل أصبحت مركز عملياتك (Operations Center). بدلاً من أن تفتح نافذة طرفية للاتصال بالخادم، ولوحة تحكم لمراقبة الأداء، وموقعاً آخر لمراجعة سجلات الأخطاء، يمكنك تنفيذ كل هذا من خلال أوامر بسيطة تكتبها في نفس المكان الذي تتحدث فيه مع فريقك.

الـ ChatOps يحوّل المحادثة من “كلام عن العمل” إلى “العمل نفسه”.

لماذا يجب أن تهتم؟ فوائد حقيقية لمسناها بأيدينا

الانتقال إلى ChatOps لم يكن مجرد “موضة تقنية” نتبعها. لقد كانت له فوائد عملية غيرت طريقة عملنا بشكل جذري. إليك أهمها:

1. الشفافية والوضوح الكامل

في الماضي، عندما كنت أقوم بعملية deployment أو إعادة تشغيل خدمة عبر SSH، لم يكن أحد ليعرف ما فعلته بالضبط إلا إذا سألني. مع ChatOps، كل شيء يحدث في العلن. عندما أكتب الأمر /bot deploy staging api-service في قناة #deployments، يرى الفريق بأكمله:

• من الذي نفذ الأمر (أبو عمر).
• متى تم تنفيذه (التوقيت الدقيق).
• ما هو الأمر بالضبط.
• وما هي نتيجة التنفيذ (نجاح أم فشل، مع رابط للسجلات).

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

2. السرعة والكفاءة الخارقة

كم من الوقت تستهلك عملية بسيطة مثل إعادة تشغيل خدمة؟ عليك أن:

1. تجد اسم الخادم.
2. تفتح الـ Terminal.
3. تكتب أمر SSH وتدخل كلمة المرور أو تستخدم مفتاحك.
4. تكتب أمر إعادة التشغيل sudo systemctl restart my-service.
5. تتأكد من أن الخدمة تعمل بشكل صحيح.

مع ChatOps، أصبحت العملية عبارة عن أمر واحد: /bot restart service my-service on production. البوت يقوم بكل الخطوات الخلفية في ثوانٍ ويعطيك النتيجة. هذا هو الفرق بين العمل اليدوي والعمل المؤتمت.

3. سجل تاريخي وتدقيق لا يقدر بثمن

أصبحت قناة الدردشة لدينا بمثابة سجل حي وموثوق لجميع العمليات التي تمت على أنظمتنا. هل تريد أن تعرف من الذي قام بآخر عملية نشر على الخادم الرئيسي ومتى؟ ببساطة ابحث في تاريخ القناة. هذا أفضل من البحث في سجلات Bash المبعثرة على عشرات الخوادم.

4. تعزيز الأمان والتحكم بالصلاحيات

بدلاً من إعطاء صلاحيات SSH كاملة لكل مطور في الفريق (وهو كابوس أمني)، يمكننا الآن التحكم بدقة فيمن يمكنه تنفيذ أي أمر. يمكننا إعطاء المطورين المبتدئين صلاحية تنفيذ أوامر القراءة فقط (مثل /bot status ...)، بينما يمتلك كبار المطورين فقط صلاحية تنفيذ الأوامر الخطيرة (مثل /bot deploy production ...).

كيف تبدأ رحلتك مع ChatOps؟ (الدليل العملي)

الكلام النظري جميل، لكن كيف نبدأ فعلياً؟ الموضوع أبسط مما تتخيل. امشِ معي خطوة بخطوة.

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

أولاً، استخدم منصة الدردشة التي يستخدمها فريقك بالفعل، سواء كانت Slack، MS Teams، أو Mattermost. لا تعقّد الأمور بإدخال أداة جديدة.

ثانياً، اختر إطار عمل (framework) لبناء البوت. الخيارات كثيرة:

• Hubot: من GitHub، هو الجد الأكبر لبوتات الـ ChatOps، لكنه قديم بعض الشيء ويعتمد على CoffeeScript/JavaScript.
• Lita (Ruby) / Errbot (Python): خيارات ممتازة إذا كان فريقك يفضل هذه اللغات.
• Slack Bolt / Microsoft Teams Toolkit: الأطر الرسمية من المنصات نفسها. هي الخيار الأحدث والأنسب للمبتدئين، وتوفر تكاملاً سلساً.

نصيحة من أبو عمر: ابدأ ببساطة. لا تحاول بناء “الرجل الحديدي” من اليوم الأول. اختر أسهل إطار عمل بالنسبة لفريقك، حتى لو كان مجرد دالة سحابية (Serverless Function) تستجيب لـ webhooks.

الخطوة الثانية: أول أمر برمجي لك

لنبدأ بأتمتة شيء بسيط جداً ولكنه مفيد. مثلاً، أمر للتحقق من حالة موقع معين. سأستخدم هنا مثالاً بسيطاً باستخدام Python وإطار عمل Slack Bolt.

لنفترض أننا نريد إنشاء أمر /check-status [url] يقوم بفحص حالة موقع معين ويرجع لنا الـ status code.

# main.py - يتطلب تثبيت: pip install slack_bolt requests
import os
import requests
from slack_bolt import App

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

# الاستماع لأمر `/check-status`
@app.command("/check-status")
def check_website_status(ack, say, command):
    # أولاً، نؤكد استلام الأمر فوراً لتجنب انتهاء المهلة من سلاك
    ack()

    # نستخرج الرابط من نص الأمر
    url = command.get("text")

    if not url:
        say("يا حبيب، نسيت تحط الرابط! الاستخدام: /check-status example.com")
        return

    # نتأكد من أن الرابط يبدأ بـ http
    if not url.startswith("http"):
        url = f"https://{url}"

    try:
        response = requests.get(url, timeout=5)
        status_code = response.status_code
        
        if 200 <= status_code < 300:
            say(f"✅ الموقع {url} شغال تمام! (Status Code: {status_code})")
        else:
            say(f"⚠️ انتبه! الموقع {url} رجّع حالة غريبة. (Status Code: {status_code})")

    except requests.exceptions.RequestException as e:
        say(f"❌ فشل الاتصال بالموقع {url}. الخطأ: {e}")


# تشغيل التطبيق
if __name__ == "__main__":
    # تحتاج أيضاً لـ SLACK_APP_TOKEN إذا كنت تستخدم Socket Mode
    from slack_bolt.adapter.socket_mode import SocketModeHandler
    handler = SocketModeHandler(app, os.environ["SLACK_APP_TOKEN"])
    handler.start()

هذا الكود البسيط هو بوابتك لعالم الـ ChatOps. يمكنك الآن توسيعه لتنفيذ أوامر أكثر تعقيداً. بدلاً من استدعاء مكتبة `requests`، يمكنك استدعاء `subprocess` لتنفيذ سكربتات Shell، أو استخدام مكتبات AWS/Azure/GCP للتفاعل مع البنية التحتية السحابية.

تحذير أمني هام: عند تنفيذ أوامر Shell، لا تقم أبداً بتمرير مدخلات المستخدم مباشرة إلى الأمر. هذا يفتح ثغرة أمنية خطيرة (Command Injection). قم دائماً بتنقية وتعقيم المدخلات، واستخدم قوائم بيضاء (allow-lists) للأوامر المسموح بها.

الخطوة الثالثة: تطور من البسيط إلى المعقد

لا تتوقف عند الأوامر البسيطة. تطور تدريجياً:

1. مرحلة جلب المعلومات: ابدأ بأوامر لا تغير أي شيء في النظام (read-only). مثل: /bot list-pods, /bot show-logs [service], /bot db-size. هذا يبني الثقة في البوت.
2. مرحلة الإجراءات البسيطة: انتقل إلى أوامر تقوم بفعل شيء واحد ومحدد. مثل: /bot clear-cache [service], /bot restart-pod [pod-name].
3. مرحلة العمليات المعقدة: اربط عدة إجراءات معاً في أمر واحد. أمر مثل /bot deploy production api يمكنه أن يقوم بالتالي:
   • إرسال إشعار في القناة بأن عملية النشر قد بدأت.
   • سحب آخر التحديثات من Git.
   • تشغيل الاختبارات (Unit & Integration tests).
   • بناء حاوية Docker جديدة.
   • نشر الحاوية على Kubernetes.
   • الانتظار للتأكد من أن النسخة الجديدة تعمل.
   • إرسال إشعار نهائي بالنجاح أو الفشل.

نصيحة من أبو عمر: “امشِ حبة حبة”. كلما أتمتت مهمة يدوية مملة، كلما كسبت تأييد فريقك وحماسهم للمزيد.

فخاخ ومطبات يجب الانتباه لها

الرحلة ليست كلها وروداً. هناك بعض الفخاخ التي وقعنا فيها وتعلمنا منها:

• فخ الإزعاج (Noise): إذا كان البوت يكتب كل تفصيلة صغيرة في القناة الرئيسية، سيبدأ الناس بتجاهله. استخدم قنوات متخصصة (مثل #ops-alerts)، واستخدم الـ Threads في سلاك لتجميع مخرجات الأمر الواحد، ولا ترسل إشعاراً عاماً إلا للنتائج النهائية المهمة.
• فخ “الصندوق الأسود”: يجب أن يكون كود البوت نفسه متاحاً للفريق للمراجعة والتطوير. لا تجعله مشروعاً لشخص واحد فقط.
• فخ الاعتمادية الكاملة: ماذا لو تعطل البوت؟ يجب أن يكون لديك دائماً طريقة يدوية بديلة للوصول إلى الأنظمة في حالات الطوارئ القصوى. الـ ChatOps هو طبقة لتسهيل العمل، وليس بديلاً كاملاً عن كل شيء.

الخلاصة يا جماعة الخير 👍

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

إذا كان فريقك لا يزال يقضي وقته في الاتصال اليدوي بالخوادم، وكتابة نفس الأوامر مراراً وتكراراً، فأنت تعيش في سجن رقمي وأنت لا تدري.

نصيحتي الأخيرة لك: لا تنتظر الوضع المثالي أو موافقة الجميع. ابدأ اليوم. اختر مهمة واحدة صغيرة ومملة يقوم بها فريقك يدوياً، وقم بأتمتتها عبر أمر بسيط في منصة الدردشة. عندما يرى زملاؤك كيف وفرت عليهم 5 دقائق من عمل روتيني، سيتحمسون هم أنفسهم لأتمتة المهمة التالية. ومن هناك، ستبدأ ثورة الأتمتة في فريقك.