الحادثة الكبرى انقطاع واسع الأثر يحتاج مسارًا خاصًا لا تصعيدًا عاديًا: إعلان صريح يبدّل قواعد العمل، وقائد حادثة يدير ولا يصلح بيديه، وقناة تواصل واحدة بإيقاع معلن، ومراجعة لاحقة بلا لوم. الفشل فيها غالبًا تنظيمي لا تقني: الجميع يصلح في وقت واحد ولا أحد يقود أو يُبلّغ.
ما يميّز الحادثة الكبرى ليس صعوبتها التقنية بل أثرها وضغطها. الخدمة متوقفة، والإدارة تتصل كل عشر دقائق، وخمسة مهندسين يجرّبون خمسة حلول في وقت واحد دون أن يعرف أحدهم ما يفعله الآخر، وأحدهم يعيد تشغيل خادم بينما زميله يلتقط منه لقطة تشخيصية.
هذه الفوضى لا تُحلّ بمهندسين أفضل، بل بأدوار معرَّفة قبل وقوع الحادثة. ومن يحاول تعريفها أثناءها يكون قد خسر أصلًا.
ما الذي يجعل الحادثة «كبرى»؟
عرّف المعيار كتابةً قبل الحاجة إليه. المعيار الغائب يعني جدالًا وقت الأزمة حول ما إذا كان هذا «كبيرًا بما يكفي» — وهو آخر ما تحتاجه والساعة تجري. المعايير الشائعة في الممارسة:
| المعيار | أمثلة توضيحية | ملاحظة |
|---|---|---|
| اتساع الأثر | خدمة أساسية متوقفة لكل المستخدمين أو لفرع كامل | العدد المطلق أقل أهمية من نسبة المتأثرين |
| حرجية الخدمة | توقف نظام يمسّ الإيراد أو السلامة أو الالتزام النظامي | خدمة حرجة متوقفة لعشرة أشخاص قد تفوق خدمة هامشية لمئة |
| غياب الحل البديل | لا سبيل لمواصلة العمل بأي طريقة أخرى | وجود حل بديل معقول يخفض التصنيف عادةً |
| التوقيت الحرج | عطل في نظام الرواتب يوم صرفها، أو في يوم إقفال | العطل نفسه قد يكون كبرى اليوم وعاديًا غدًا |
| الأثر السمعي أو النظامي | انقطاع خدمة تمسّ المستفيدين مباشرة | يستدعي إشراك جهات خارج التقنية مبكرًا |
الأدوار: من يقود ومن يصلح ومن يتكلم
أهم قرار تنظيمي في هذا المجال كله: فصل القيادة عن الإصلاح. أفضل مهندس لديك هو أسوأ خيار لقيادة الحادثة، لأنه سينغمس في التشخيص خلال دقائق ويتوقف عن القيادة تمامًا — فتضيع الحادثة بلا قائد بينما هو منكبّ على شاشته.
في الفرق الصغيرة قد يجمع شخص واحد بين القيادة والتواصل، وهذا مقبول. لكن القاعدة التي لا تُكسر: من يقود لا يصلح. اللحظة التي يفتح فيها القائد طرفيّة ليجرّب شيئًا بنفسه هي اللحظة التي تصبح فيها الحادثة بلا قائد — والجميع مشغول بالإصلاح ولا أحد يرى الصورة الكاملة أو يتذكر إبلاغ أحد.
آلية التشغيل: من الإعلان إلى الإغلاق
الخطوة الرابعة هي التي تفصل مؤسسة ناضجة عن غيرها. حين يسقط خادم، هل تعرف خلال ثوانٍ ما الخدمات المتأثرة ومن يجب إبلاغه؟ هذا بالضبط ما تشتريه معرفة الاعتماديات، سواء كانت في قاعدة بيانات إدارة التكوين أو حتى في خريطة بسيطة موثّقة للخدمات الحرجة.
أما الخطوة الخامسة فأكثر ما يُساء فهمه. الإدارة لا تتصل لأنها تريد حلًا فوريًا، بل لأنها لا تعرف ما يجري. والإيقاع المعلن — «تحديث كل ثلاثين دقيقة مهما كان» — يحلّ هذا: هي تعرف متى تأتي المعلومة فتتوقف عن السؤال، والفريق يعمل بلا مقاطعة. أما آليات التصعيد العادية فمفصّلة في مسار تصعيد التذاكر، وهي مختلفة عن مسار الحادثة الكبرى ولا تغني عنه.
المراجعة اللاحقة بلا لوم
المراجعة اللاحقة هي المخرج الحقيقي للحادثة الكبرى. الخدمة عادت — تلك كانت مهمة الحادثة — أما القيمة الباقية فهي ألّا تتكرر. وهي مشكلة لا حادثة، فتُدار بمنطق تحليل السبب الجذري لا بمنطق الاستعجال.
وشرط نجاحها الوحيد أن تكون بلا لوم. ليس لطفًا بالفريق، بل لأنها لا تعمل بغير ذلك: حين يخشى المهندس أن يُلام، يخفي التفاصيل التي تحتاجها بالضبط. سيقول «حدث خطأ في الإعداد» بدل «كتبت الأمر على الخادم الخطأ لأن نافذتي متطابقتان ولا شيء يميّزهما» — والجملة الثانية وحدها تقود إلى إصلاح حقيقي، والأولى لا تقود إلى شيء.
- ماذا حدث بالضبط؟ — جدول زمني وقائعي من سجل الحادثة، لا من الذاكرة.
- لماذا استغرق اكتشافه هذا الوقت؟ — الفجوة بين وقوع العطل ومعرفتنا به غالبًا أكبر مما نظن، وأرخص ما يمكن إصلاحه.
- لماذا استغرقت الاستعادة هذا الوقت؟ — أين ضاع الوقت فعلًا: في التشخيص، أم في إيجاد الشخص المناسب، أم في انتظار موافقة؟
- ما الذي جعل الأثر بهذا الاتساع؟ — سؤال عن التصميم لا عن العطل: لماذا لم يُحتوَ في نطاق أضيق؟
- ماذا سار جيدًا؟ — يُغفل دائمًا، وهو ما يجب تعزيزه لا مجرد مجاملة.
- ما الإجراءات؟ — لكل إجراء مالك وموعد. توصية بلا مالك ليست إجراءً بل أمنية.
السؤال الثاني هو الأعلى عائدًا والأقل طرحًا. كثير من الحوادث الكبرى كانت ستبقى صغيرة لو اكتُشفت مبكرًا — واكتشاف العطل من اتصال مستخدم بدل تنبيه آلي يعني أن الأثر بدأ قبل أن تعلم. تحسين الاكتشاف عادةً أرخص وأسرع أثرًا من تحسين الإصلاح، لكنه أقل إثارة فيُهمَل.
وأخيرًا: لا تُغلق مراجعة بلا إجراءات مملوكة ومجدولة. المراجعة التي تنتهي بوثيقة جميلة وتوصيات بلا مالك هي طقس لا ممارسة — وستجلس مع الفريق نفسه بعد ستة أشهر لتكتب الوثيقة نفسها عن الحادثة نفسها. اربط كل إجراء بتذكرة لها مالك وموعد داخل نظام الدعم الفني، فتُتابَع كأي عمل آخر بدل أن تعيش في ملف منسي.
الأسئلة الشائعة
من يجب أن يكون قائد الحادثة؟
ليس بالضرورة الأقدم تقنيًا ولا الأعلى إداريًا. المهارة المطلوبة تنظيمية: توزيع المهام، وضبط الإيقاع، واتخاذ قرار بمعلومات ناقصة. كثير من المؤسسات تدرّب مجموعة من قادة الحوادث بالتناوب مع مناوبة معلنة — والأهم أن يكون القائد معروفًا قبل الحادثة، لا أن يُختار وسط الفوضى.
كم يجب أن يكون إيقاع التحديثات؟
لا يوجد رقم صحيح؛ المهم أن يكون معلنًا ومُلتزمًا به. أعلن الإيقاع في أول تحديث والتزم به حتى لو لم يتغير شيء — «لا جديد» تحديث مشروع ومفيد لأنه يؤكد أن أحدًا يعمل. والخطأ الشائع الوعد بإيقاع سريع لا يُحتمل تحت الضغط ثم الإخلاف به، فتعود الاتصالات أكثر إلحاحًا من ذي قبل.
هل نفتح مشكلة لكل حادثة كبرى؟
نعم، بلا استثناء. الحادثة الكبرى بتعريفها حدث كبير الأثر يستحق فهم سببه، حتى لو بدا السبب واضحًا وقتها — فالسبب «الواضح» أثناء الضغط غالبًا ما يكون العرض الأخير في سلسلة أطول. المشكلة تُفتح عند إغلاق الحادثة وتعيش بمسارها الخاص وميزانيتها الزمنية، ولا تُقاس بسرعة الإغلاق.
ما الفرق بين التصعيد العادي والحادثة الكبرى؟
التصعيد ينقل التذكرة إلى مستوى أعلى مع بقاء قواعد العمل كما هي. أما إعلان الحادثة الكبرى فيبدّل القواعد نفسها: أدوار مختلفة، وقناة مخصّصة، وإيقاع تواصل، وصلاحيات استثنائية، وتعليق للعمل الاعتيادي. الخلط بينهما شائع، ونتيجته أن الحوادث الكبرى تُدار بأدوات التصعيد العادية — فتغرق.
كيف نتدرّب على الحوادث الكبرى قبل وقوعها؟
بتمارين محاكاة قصيرة: اطرح سيناريو افتراضيًا على الفريق ومرّروا الأدوار والقرارات دون لمس أي نظام. الهدف ليس اختبار المعرفة التقنية بل كشف الثغرات التنظيمية — من يعلن؟ من يُبلَّغ خارج الدوام؟ أين القناة؟ هذه الأسئلة إن ظهرت أول مرة أثناء حادثة حقيقية كلّفتك ساعة من أصعب ساعاتك.