كانت تنبيهاتنا ضجيجاً: كيف أنقذتنا أتمتة الاستجابة للحوادث من جحيم الإرهاق؟

أذكرها جيداً تلك الليلة، كانت ليلة خميس وكنا معزومين عند دار حماي. رائحة المقلوبة تملأ البيت، والأولاد يلعبون حولي، وأنا أحاول أن أفصل نفسي عن العمل وأستمتع باللحظة. فجأة، اهتز هاتفي. نظرة سريعة، تنبيه من PagerDuty: “CPU Load High on DB-Master”.

تجاهلته. “أكيد إشي عابر”، قلت في نفسي. بعد دقيقتين، اهتزاز آخر. ثم ثالث. بدأت أشعر بالتوتر يتسلل إلى عروقي. وصلني رسالة على Slack من زميلي المناوب معي: “أبو عمر، شفت التنبيهات؟ شكلها مش مزحة هالمرة”.

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

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

ما هي “متلازمة الصبي الذي صرخ ذئباً” في عالم التقنية؟

ما عشناه تلك الليلة له اسم علمي في مجالنا: “Alert Fatigue” أو إرهاق التنبيهات. هي حالة يصل إليها الفريق عندما يتعرض لكم هائل من التنبيهات غير المهمة أو المتكررة، مما يؤدي إلى:

• التجاهل التام: يبدأ المهندسون بتجاهل التنبيهات بشكل تلقائي، بافتراض أنها إنذار كاذب آخر.
• بطء الاستجابة: حتى عند الانتباه للتنبيه، يستغرق الأمر وقتاً أطول للتحقق من صحته، لأن الثقة في نظام المراقبة قد تلاشت.
• الإرهاق والاحتراق الوظيفي: لا يوجد شيء مدمر لمعنويات فريق المناوبة (On-Call) أكثر من الاستيقاظ في منتصف الليل كل مرة بسبب تنبيه يمكن تجاهله.

كانت أنظمتنا تصرخ طوال الوقت، لكنها لا تقول شيئاً مفيداً. كانت مجرد ضجيج في فراغ، ونحن كنا الضحايا.

مرحباً بالأتمتة: كيف بدأنا رحلة الإنقاذ

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

الخطوة الأولى: التصنيف والفرز (Triage and Classification)

أول ما فعلناه هو الجلوس ومراجعة كل تنبيه لدينا. وسألنا أنفسنا سؤالين لكل واحد منهم:

1. هل هذا التنبيه يتطلب تدخلاً بشرياً فورياً؟
2. إذا كان الجواب “نعم”، فما هو الإجراء الذي يجب اتخاذه؟

بناءً على ذلك، قمنا بتقسيم التنبيهات إلى مستويات:

• P1 (كارثي): الموقع معطل، قاعدة البيانات لا تستجيب. هذا يتطلب إيقاظ شخص ما في منتصف الليل فوراً.
• P2 (عاجل): ميزة أساسية لا تعمل، بطء شديد يؤثر على نسبة كبيرة من المستخدمين. هذا يتطلب استجابة سريعة خلال ساعات العمل.
• P3 (تحذيري): مساحة القرص تتجاوز 80%، ارتفاع مؤقت في استخدام الذاكرة. هذا لا يتطلب تدخلاً بشرياً، بل يجب أن يكون مدخلاً لعملية أتمتة.

هذا الفرز وحده خفف عنا الكثير من الضغط. لم يعد كل تنبيه يعامل بنفس درجة الأهمية.

الخطوة الثانية: من التنبيه إلى المعلومة (From Alert to Information)

المشكلة الثانية كانت أن تنبيهاتنا كانت غبية. تنبيه مثل “CPU utilization > 95% on host-123” لا معنى له وحده. لماذا ارتفعت؟ ما هي العمليات التي تسببت بذلك؟ ما هو تأثير ذلك على الخدمة؟

هنا تدخلت الأتمتة لإثراء التنبيهات (Alert Enrichment). بدلًا من إرسال التنبيه الخام، قمنا ببناء سكربتات بسيطة تقوم بالآتي عند إطلاق التنبيه:

1. جمع المعلومات: عند ارتفاع حرارة المعالج، يقوم السكربت بالاتصال بالخادم وتشغيل أوامر مثل top, ps, netstat.
2. إضافة سياق: يقوم السكربت بإرفاق مخرجات هذه الأوامر في نص التنبيه.
3. ربط بالحلول: يضيف السكربت رابطاً إلى “Runbook” (دليل التشغيل) الخاص بهذه المشكلة.

فجأة، تحول التنبيه من هذا:

“Alert: High CPU on web-server-04”

إلى هذا:

“P2 Alert: High CPU (98%) on web-server-04.
– Impact: API latency increased by 300ms.
– Top Processes: `java -jar app.jar` (90% CPU).
– Recent Logs: Showing multiple `OutOfMemoryError`.
– Suggested Action: Restart the application service.
– Runbook: link-to-runbook.com/restart-app“

الفرق شاسع، أليس كذلك؟ الآن، حتى لو استيقظ المهندس في الليل، لديه كل ما يحتاجه لبدء حل المشكلة مباشرة.

أدواتنا في المعركة: بناء مسار الاستجابة الآلي

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

1. التجميع والتصفية (Aggregation & Filtering)

استخدمنا أدوات مثل Prometheus Alertmanager لتجميع التنبيهات المتشابهة. فبدلاً من الحصول على 100 تنبيه بأن “الخدمة X لا يمكن الوصول إليها”، نحصل على تنبيه واحد يقول “تم اكتشاف 100 حالة فشل في الوصول للخدمة X خلال الدقيقة الماضية”.

2. الإثراء والتشخيص الأولي (Enrichment & Initial Diagnosis)

هنا يكمن قلب الأتمتة. أنشأنا خدمة بسيطة (باستخدام Python و Flask) تعمل كـ “Webhook Receiver”. أداة المراقبة (Prometheus) ترسل التنبيهات إليها أولاً بدلاً من إرسالها إلى PagerDuty مباشرة.

السكربت يقوم بالتشخيص الأولي. هذا مثال مبسط جداً لمبدأ العمل:

from flask import Flask, request
import subprocess

app = Flask(__name__)

@app.route('/webhook', methods=['POST'])
def handle_alert():
    alert = request.json
    
    # مثال: إذا كان التنبيه عن مساحة القرص
    if alert['name'] == 'DiskSpaceUsageHigh':
        hostname = alert['labels']['hostname']
        
        # 1. التشخيص: شغل أمر للتحقق من أكبر الملفات
        try:
            # استخدم SSH أو أداة تنفيذ عن بعد مثل Ansible
            result = subprocess.check_output(
                f"ssh user@{hostname} 'du -ah /var/log | sort -rh | head -n 5'",
                shell=True
            ).decode('utf-8')
            
            # 2. الإثراء: أضف النتيجة إلى وصف التنبيه
            alert['annotations']['diagnosis'] = f"Top 5 largest log files:n{result}"
            
        except Exception as e:
            alert['annotations']['diagnosis'] = f"Failed to run diagnosis: {e}"
            
        # 3. أرسل التنبيه المثرى إلى الخطوة التالية (أو إلى مدير التنبيهات)
        send_to_next_step(alert)
        
    return "OK"

# ... بقية الدوال ...

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

3. التنفيذ الآلي (Automated Remediation)

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

لمشكلة مثل “مساحة القرص ممتلئة بسبب ملفات السجل القديمة”، أصبح مسار العمل التلقائي كالتالي:

1. يتم إطلاق تنبيه “Disk Space > 90%”.
2. سكربت الأتمتة يستقبله.
3. يتحقق من أن السبب هو ملفات السجل (Logs).
4. يقوم بتشغيل سكربت لتنظيف/أرشفة ملفات السجل التي يزيد عمرها عن 7 أيام.
5. يتحقق من مساحة القرص مرة أخرى.
6. إذا عادت المساحة إلى طبيعتها، يغلق التنبيه تلقائياً ويرسل إشعاراً إلى قناة Slack يقول: “تم حل مشكلة امتلاء القرص في الخادم X تلقائياً”.

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

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

من خلال هذه الرحلة، تعلمنا دروساً قاسية لكنها ثمينة. إليكم خلاصة خبرتي:

• ابدأ صغيراً: لا تحاول أتمتة كل شيء دفعة واحدة. اختر مشكلة واحدة متكررة ومزعجة (مثل امتلاء القرص) وقم بأتمتة حلها من الألف إلى الياء. نجاحك الأول سيعطيك دفعة قوية.
• الأتمتة تحتاج صيانة: سكربتات الأتمتة هي برامج كأي برامج أخرى. تحتاج إلى مراجعة، تحديث، ومراقبة. “فش إشي ببلاش”.
• وثّق كل شيء: يجب أن يكون كل إجراء آلي موثقاً في Runbook واضح. ماذا يفعل؟ متى يعمل؟ ماذا تفعل إذا فشل؟
• تبنَّ ثقافة “اللوم ممنوع” (Blameless Postmortems): عندما تحدث كارثة، الهدف ليس إيجاد كبش فداء، بل فهم “لماذا” فشلت أنظمتنا (بما في ذلك أنظمة الأتمتة) في منعها، وكيف يمكننا تحسينها.

الخلاصة: من ضجيج التنبيهات إلى سيمفونية الكفاءة 🧘‍♂️

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

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