فلسفة التنبيهات

فلسفة التنبيهات

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

يكرّس كتاب هندسة موثوقية المواقع (SRE) من Google فصلاً كاملاً لهذه المشكلة. المبدأ الأساسي الذي يظهر: كل تنبيه يجب أن يكون عاجلاً وقابلاً للتصرف ومرئياً من العملاء. إن لم يستوفِ التنبيه المعايير الثلاثة، فليكن تحذيراً في لوحة القيادة أو تذكرة، لا استدعاء هاتفي. يُعلّمك هذا الدرس كيف تبني نظام تنبيهات تثق به فرقة المناوبة، ويلتقط المشكلات الحقيقية قبل أن يلاحظها المستخدمون.

التنبيه المبني على الأعراض

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

• إيجابيات كاذبة: CPU عند 95% لدقيقتين لا يعني دائماً تأثراً على المستخدمين. ربما مهمة دفعية. ربما التوسع التلقائي يتفاعل بالفعل. تستدعي مهندساً دون مبرر.
• سلبيات كاذبة: تسرب ذاكرة صامت يجعل محرك التوصيات يُقدم نتائج قديمة دون أي ارتفاع في CPU أو معدل الأخطاء. لا ينطلق أي تنبيه قائم على السبب. المستخدمون يعانون التدهور لساعات.

التنبيه القائم على الأعراض يعكس هذا. بدلاً من "أنبّه حين تتجاوز CPU نسبة 80%"، تسأل: "أنبّه حين يتجاوز زمن الاستجابة p99 حد اتفاقية مستوى الخدمة" أو "أنبّه حين يكون معدل استهلاك ميزانية الأخطاء مرتفعاً جداً." السبب الداخلي يصبح مدخلاً للتحقيق، لا مُشغِّلاً لإيقاظ شخص ما.

مستويات الخطورة وعقد التصعيد

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

• P1 — حرج / استدعاء فوري: المستخدمون غير قادرين كلياً على استخدام المنتج، أو سلامة البيانات مهددة. تأثير الإيرادات نشط. يتطلب استجابة بشرية فورية بصرف النظر عن الوقت. مثال: خدمة الدفع تُعيد 100% أخطاء، قاعدة البيانات الرئيسية معطلة بلا تبديل تلقائي مكتمل.
• P2 — عالي / استدعاء في ساعات العمل، إيقاظ إن امتد: نسبة كبيرة من المستخدمين متأثرة. خرق اتفاقية مستوى الخدمة وشيك أو جارٍ. يتطلب استجابة خلال 30 دقيقة. مثال: زمن الاستجابة p99 ثلاثة أضعاف حد SLO لأكثر من 10 دقائق، معدل نجاح الدفع انخفض 15%.
• P3 — متوسط / تذكرة، استجابة في يوم العمل التالي: مسار غير حرج متدهور أو حد سعة يقترب. لا تأثير فوري على المستخدمين، لكنه قد يتصاعد إن ترك. مثال: عمق قائمة انتظار المهام في اتجاه تصاعدي نحو الحد، نقطة نهاية API محددة بمعدل أخطاء مرتفع يؤثر على أقل من 0.5% من المستخدمين.
• P4 — منخفض / تحذير لوحة القيادة: إعلامي. يستحق المتابعة لكن لا يتطلب إجراءً اليوم. لا يُرسل إشعاراً أبداً — مرئي فقط لمن يتابع لوحات القيادة بنشاط.

العقد مقدس: إن أُطلق P1 ولم يستجب المهندس خلال 5 دقائق، يُصعَّد تلقائياً إلى قائد الفريق. PagerDuty وOpsGenie وVictorOps تدعم هذه السياسة التصعيدية جاهزةً. اللحظة التي يُطلق فيها P1 لغير طارئ، سيبدأ الفريق بتوجيه تنبيهات P1 إلى الكتم — وهذا بداية انهيار الاستجابة للحوادث.

كتب التشغيل: التنبيه لا يكتمل بدونها

تنبيه بلا كتاب تشغيل كمنبّه بلا تعليمات. حين يُوقَظ مهندس في الساعة الثالثة صباحاً، قدرته الذهنية منخفضة، وضغطه مرتفع، وربما كان مبتدئاً لم يرَ هذا وضع الفشل من قبل. كتاب التشغيل هو الجسر بين "انطلاق التنبيه" و"حل الحادثة."

كل تنبيه إنتاجي يجب أن يرتبط مباشرة بكتاب تشغيله. الرابط يوضع في تعليق التنبيه. يجب أن يجيب الكتاب، بالترتيب:

1. ماذا يعني هذا التنبيه؟ بلغة واضحة: أي عرض مرئي للمستخدم يحدث أو في خطر؟
2. ما خطوة الفرز الفوري؟ الأمر أو لوحة القيادة الأولى للتحقق. يمكن الإجابة خلال أقل من دقيقتين.
3. ما الأسباب الجذرية المحتملة؟ مرتبة بالتكرار التاريخي. كل سبب مرتبط بمعالجته المحددة.
4. ما المعالجات الآمنة؟ أوامر دقيقة للتنفيذ، مصنفة آمنة مقابل مدمرة. الخطوات المدمرة تتطلب تأكيداً صريحاً.
5. متى يُصعَّد؟ إن لم يُحل خلال N دقائق، من تتصل به تالياً وما المعلومات التي تقدمها.

كتب التشغيل تسكن في نظام التحكم بالإصدارات جنباً إلى جنب مع قواعد التنبيه. حين تتغير قاعدة تنبيه، يُحدَّث كتاب التشغيل في نفس الـ PR. كتب التشغيل القديمة التي تشير إلى أوامر بالية أو خدمات غير موجودة أسوأ من انعدامها — تُضيع الوقت وتُقوّض الثقة.

إرهاق التنبيهات: القاتل الصامت لثقافة المناوبة

إرهاق التنبيهات ليس استعارة — إنه ظاهرة قابلة للقياس. تُظهر دراسات أنظمة إنذار المستشفيات (حيث قتل الإرهاق مرضى) وفرق عمليات السحابة النمط ذاته: حين تنخفض نسبة التنبيهات القابلة للتصرف إلى إجمالي التنبيهات عن نحو 50%، يبدأ مهندسو المناوبة في تطوير سلوك قمع تلقائي. يُقرّون التنبيهات دون قراءتها. يُكتّمون PagerDuty للساعة الأولى بعد الاستيقاظ لأنهم يتوقعون أنه ضجيج. حين تُطلق الحادثة الحقيقية، الاستجابة بطيئة.

أسباب إرهاق التنبيهات في الأنظمة الإنتاجية:

• التنبيه على الأسباب لا الأعراض — يقود إلى معدلات إيجابية كاذبة مرتفعة للحالات غير المؤثرة على المستخدمين.
• حدود مضبوطة بعدوانية مفرطة — "أنبّه إن تجاوز p99 200ms أي وقت" يُطلق باستمرار في نظام حد SLO فيه 500ms.
• غياب مدة for — ارتفاع مؤقت لمقياس يدوم 30 ثانية يستدعي مهندساً في الساعة الثالثة صباحاً.
• تكاثر التنبيهات بلا مراجعة — يضيف المهندسون تنبيهات حين يجدون مشكلة جديدة، لكن لا أحد يحذف التنبيهات حين تُصلح المشكلة أو تُوقف الخدمة. عدد التنبيهات يتزايد باستمرار.
• التنبيهات المتذبذبة — تنبيه يتأرجح بين الانطلاق والحل كل بضع دقائق، مُرسلاً إشعارات متعددة.

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

النظافة العملية للتنبيهات على نطاق واسع

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

• لكل تنبيه مالك. تنبيه بلا تصنيف فريق يُكتَّم ويُحذف. الملكية يُطبّقها إعداد التوجيه — إن لم يكن هناك مسار لتصنيف ما، يذهب التنبيه إلى catch-all يفتح تذكرة ضد فريق المنصة لإيجاد المالك.
• يجب أن يكون للتنبيهات مدة for. لا تُطلق أبداً على تقييم واحد. الحد الأدنى for: 2m للحرج، for: 5m لكل شيء آخر. هذا وحده يُقضي على 60-70% من الإيجابيات الكاذبة الناتجة عن الارتفاعات العابرة.
• استخدم معدل الاحتراق متعدد النوافذ لتنبيهات SLO. حد واحد على نافذة 5 دقائق يُفوّت الاحتراقات البطيئة. أنبّه حين يكون معدل الاحتراق خلال ساعة مرتفعاً ومعدل الاحتراق خلال 5 دقائق يؤكد أنه لا يزال جارياً. هذه هي الخوارزمية في كتاب SRE من Google: تلتقط الاحتراقات السريعة مبكراً والبطيئة قبل نفاد الميزانية، بمعدلات إيجابيات كاذبة منخفضة جداً.
• أوقف التنبيهات خلال نوافذ الصيانة. قواعد inhibit_rules وtime_intervals في Alertmanager تتيح كتم التنبيهات المشتقة خلال فترات التوقف المخطط. نسيان هذا يُسبب 50+ تنبيهاً خلال صيانة مجدولة، مُدرّباً الفريق على تجاهلها.
• تتبع نسبة الإشارة إلى الضجيج في تنبيهاتك. صدّر مقياساً: alerts_total{actionable="true|false"}. إن انخفضت نسبة القابل للتصرف عن 70%، جدوّل سبرينت لتدقيق التنبيهات.

بناء الثقافة، لا مجرد الإعداد

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

أضفِ هذا كـمراجعة ربع سنوية للتنبيهات: استخرج تاريخ التنبيهات خلال آخر 90 يوماً، احسب نسبة القابل للتصرف لكل تنبيه، حدد أعلى 10 تنبيهات ضجيجاً بالحجم، وأمضِ سبرينتاً لتقليصها. هذه الحلقة التغذية الراجعة، مطبّقةً باستمرار، تُنتج نظام تنبيهات تثق به الفرقة — مما يعني فريقاً يستجيب حين يهم الأمر.