إذا كانت المراقبة توقظك في الثالثة فجرًا، فهي ليست مراقبة

كل نظام مراقبة نتسلّمه له الشكل نفسه. آلاف الفحوصات. مئات التنبيهات يوميًا. مجلد بريد مخصص لا يفتحه أحد. ومهندس يستطيع أن يخبرك، دون أن ينظر، أي ثلاثة تنبيهات تعني شيئًا فعلًا.

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

العَرَض الذي يعرفه الجميع

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

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

إرهاق التنبيهات ليس مشكلة انضباط. إنه مشكلة تصميم، ويُحل بحذف التنبيهات.

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

إنها أقدم قصة عن الإنذارات، وقد رويناها على أنها قصة الراعي الكذاب والذئب.

سؤال واحد يحل معظم المشكلة

لكل تنبيه يوقظ شخصًا، اسأل:

عند تطبيق هذا الاختبار بأمانة، فإنه يزيل عادةً ما بين 80 و90% مما يستدعي له نظام المراقبة القديم. والمقاومة التي يواجهها هي نفسها دائمًا: «لكننا نريد أن نعرف بذلك.»

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

نبّه على الأعراض لا على الأسباب

التغيير الثاني هو ما الذي تنبّه عليه أصلًا.

معظم الأنظمة الموروثة تنبّه على الأسباب: المعالج فوق 90%، والذاكرة فوق 80%، وإعادة تشغيل عملية، وطابور يتجاوز ألف رسالة. كل منها يبدو معقولًا، لكنها مجتمعة تولّد ضجيجًا هائلًا، لأن أيًّا منها لا يعني بشكل موثوق أن هناك خطأ ما.

قد يكون ارتفاع استخدام المعالج مجرد مهمة دفعية تؤدي عملها كما ينبغي. وقد تكون إعادة تشغيل العملية مجرد نشر روتيني. وقد تكون ألف رسالة في الطابور أمرًا عاديًا في يوم ثلاثاء.

أما التنبيه القائم على الأعراض فيسأل بدلًا من ذلك: ما الذي سيلاحظه المستخدم؟

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

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

كيف تعيد بناء نظام تنبيهات مزعج

الميل الطبيعي هو ضبط العتبات واحدة تلو الأخرى. هذا يستغرق عامًا ويترك التصميم الأساسي على حاله. نحن نبدأ من الاتجاه المعاكس.

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

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

3. أنشئ تنبيهًا لكل منها، من منظور المستخدم. ليس «هل قاعدة البيانات تعمل» بل «هل يمكن إتمام طلب». المعاملات الاصطناعية ممتازة هنا: سكربت يسجّل الدخول فعلًا وينفّذ المسار الحرج كل دقيقة يخبرك أكثر مما تخبرك به خمسون فحصًا للبنية التحتية.

4. استدعِ لهذه فقط. كل ما عداها يذهب إلى التذاكر أو لوحات المعلومات.

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

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

كل تنبيه يحتاج إلى دليل تشغيل

التنبيه الذي يُطلق في الثالثة فجرًا ويقول DiskSpaceWarning: prod-db-02 هو لغز، لا تعليمات. على المهندس أن يكتشف ما يعنيه، وهل هو مهم، وماذا يفعل، وهو نصف نائم.

يجب أن يرتبط كل تنبيه يستدعي المناوبين بمستند قصير يجيب عن أربعة أسئلة:

• ماذا يعني هذا فعلًا؟ بلغة واضحة.
• ما التأثير على المستخدمين؟ هل يتأثر أحد الآن؟
• ما الذي أفحصه أولًا؟ السببان أو الثلاثة الأكثر احتمالًا، بالترتيب.
• ماذا أفعل حياله، وإلى من أصعّد الأمر؟

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

كيف تقيس نجاح التغيير

تابع ثلاثة أرقام شهريًا:

• عدد الاستدعاءات في كل نوبة مناوبة. المعيار الشائع ألا يتجاوز المتوسط استدعاءين تقريبًا. وفوق ذلك يتراجع الانتباه وتتراجع معه جودة الاستجابة.
• نسبة القابلية للتنفيذ. ما نسبة الاستدعاءات التي أدت إلى أن يفعل أحد شيئًا؟ إذا كانت أقل من 75% تقريبًا، فما زال لديك ضجيج. هذا هو الرقم الأكثر فائدة على الإطلاق.
• حوادث بلا تنبيه. مشكلات أبلغ عنها العملاء قبل أن تكتشفها المراقبة. هذا هو الفحص الذي يكشف التصحيح المفرط: إذا كان هذا الرقم يرتفع، فقد حذفت أكثر مما ينبغي.

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

الهدف بسيط في صياغته ونادر على نحو مفاجئ في الممارسة: عندما يصل استدعاء، يصدّقه الجميع. وهذا أثمن من أي قدر من التغطية لا يقرؤها أحد.