إدارة الحوادث والمناوبة

قيادة الحوادث

18 دقيقة الدرس 4 من 28

قيادة الحوادث

حين يتعطل نظام الإنتاج، يكون رد الفعل البشري الطبيعي أن يقفز الجميع في وقت واحد — يمتلئ Slack بالأسئلة، يبدأ عدة مهندسين في فحص قاعدة البيانات ذاتها، ينشر أحدهم إصلاحاً سريعاً لم يراجعه أحد، ويستمر الحادث ساعات أطول مما ينبغي. هذه ليست فوضى تقتصر على الفرق الصغيرة؛ إنها تحدث في Google وNetflix وAWS حين يفتقر الحادث إلى هيكل قيادة واضح. نظام قيادة الحوادث (ICS) وجد تحديداً لمنع هذا — وفهمه هو الفارق بين استجابة منسقة تُخفف الأثر في 20 دقيقة، وفوضى تمتد إلى الثالثة فجراً في غرفة حرب.

من أين جاء ICS ولماذا تبنّاه DevOps

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

أضفت FEMA الأمريكية طابع المعيار الوطني على نظام ICS. درس فريق SRE في Google هذا النظام، وجرّد المصطلحات الخاصة بمكافحة الحرائق، وكيّف الهيكل الأساسي لحوادث البرمجيات. تنشر PagerDuty وAtlassian ومعظم منظمات SRE الكبرى الآن نسخها الخاصة — لكن الهيكل الأساسي متطابق تقريباً: قائد حوادث واحد، أدوار وظيفية منفصلة بوضوح، مصدر واحد للحقيقة، وانضباط صارم في التواصل.

ICS بروتوكول تنسيق، ليس تسلسلاً للوم. قائد الحوادث ليس المهندس الأقدم في الغرفة. إنه الشخص الذي يشغل هذا الدور حالياً — ربما مهندس متوسط المستوى أو حتى IC مُدرَّب حديثاً. يُفصل بشكل صريح بين الأقدمية وصلاحية القيادة خلال الحادث، لأن خلطهما يؤدي إلى شغل المهندسين الأقدم بأعمال التنسيق بينما قيمتهم الحقيقية تكمن في التشخيص التقني العميق.

الأدوار الثلاثة الأساسية

يجب تعيين هذه الأدوار الثلاثة لأشخاص مختلفين من لحظة إعلان الحادث في كل حادث يتجاوز SEV-3، وفي جميع حوادث SEV-1 وSEV-2. لا يجوز لشخص واحد أن يشغل أكثر من دور في آنٍ واحد — هذا هو الإخفاق الهيكلي الأكثر شيوعاً في الحوادث الحقيقية.

قائد الحوادث (IC). يمتلك IC الحادث من البداية إلى النهاية. لا يُصلح أي شيء. عمله كله هو الحفاظ على نموذج ذهني مشترك للحادث عبر جميع المشاركين، وضمان أن كل إجراء يُتخذ له مالك وموعد نهائي، والقرار بالتصعيد أو التخفيف، والموافقة على خطوات التخفيف عالية الخطورة (مثلاً: "نعم، أوقف خدمة المدفوعات لتصفية الاتصالات السيئة")، وقيادة الحادث نحو الحل. IC هو آخر من يغادر جسر الحادث. يكتب المسودة الأولى لما بعد الوفاة. في حوادث Slack، يُثبّت IC رسالة الحالة ويتحكم في قناة الحادث. يجب تدريب IC وتناوب الدور خلال التناوب على التأهب — لا يمكنك ارتجال IC خلال SEV-1.

قائد التواصل (Comms). قائد التواصل هو صوت IC للعالم الخارجي. يمتلك جميع التواصل الخارجي والوظيفي المتقاطع: تحديثات صفحة الحالة، إشعارات أصحاب المصلحة، التصعيد التنفيذي، والرسائل الموجهة للعملاء. يقرأ قائد التواصل قناة الحادث ويترجم التطورات التقنية إلى تحديثات حالة بلغة بسيطة بوتيرة منتظمة (عادةً كل 15-30 دقيقة خلال الحوادث النشطة). يحمي قائد التواصل IC وOps Lead من انقطاعات التواصل. في بعض المنظمات يُسمى هذا الدور Scribe حين تكون وظيفته الأساسية التوثيق لا البث — رغم أن أفضل الممارسات تفصل بينهما في الحوادث الكبيرة.

قائد العمليات (Ops Lead). قائد العمليات هو منسق الجانب التقني. يوجّه خبراء الموضوع (SMEs) الذين يشخصون الأعراض فعلياً ويُعالجونها. يترجم Ops Lead القرارات الاستراتيجية للIC ("نحتاج تحديد السبب الجذري خلال 20 دقيقة") إلى مهام تقنية محددة لها مُلاك ("@alice، تحقق من تأخر نسخة قاعدة البيانات؛ @bob، اسحب معرفات التتبع للطلبات الفاشلة"). يحتفظ Ops Lead بالجدول الزمني التقني — ما جُرِّب، ما استُبعد، ما يُختبر حالياً — ويرفع العوائق إلى IC. لا يقوم بالمعالجة اليدوية بنفسه؛ تلك مهمة SMEs.

هيكل القيادة في التطبيق

هيكل قيادة الحوادث: IC واحد، قائد تواصل واحد، قائد عمليات واحد، مع خبراء الموضوع الموجَّهين من قائد العمليات. جميع الأدوار تشترك في قناة حادث واحدة.

انضباط التواصل: قناة الحادث

لا يعمل ICS بدون انضباط صارم في التواصل. يجري كل تواصل في الحادث في قناة Slack واحدة مُنشأة لهذا الغرض (أو ما يعادلها). القواعد ليست اقتراحات — إنها بروتوكول:

كل تحديث حالة يبدأ بطابع زمني ودور: [IC 14:32] السبب الجذري محدد: استنفاد مجموعة اتصالات Redis. Ops Lead يُنسق التصفية وإعادة التشغيل.
الأسئلة الموجهة لأشخاص محددين تستخدم @mention وتتضمن موعداً: @alice — قراءة تأخر قاعدة البيانات بحلول 14:45؟
الفرضيات والأفكار غير المكتملة تذهب إلى خيط منفصل أو جسر صوتي — القناة الرئيسية للحقائق والقرارات وتحديثات الحالة فقط.
يُنشر قائد التواصل تحديثات خارجية كرسائل مُثبَّتة: [COMMS 14:35] تحديث صفحة الحالة: نحقق في ارتفاع معدلات الأخطاء على الدفع. ETA: 15 دقيقة.
لا أحد يقوم بتشخيص الأعطال في قناة الحادث. Ops Lead يُسند المهام؛ SMEs يُبلّغون بالنتائج.

يدعم كل من PagerDuty وJira Service Management إنشاء قناة حادث آلية. حين يُطلق تنبيه ويُعلن حادث، ينشئ التكامل قناة Slack باسم #incident-YYYYMMDD-HHMMSS-service، ويُنشر سياق التنبيه كأول رسالة، وربما يستدعي IC. أعدّ هذا مسبقاً حتى لا تضطر لإنشاء قنوات يدوياً خلال SEV-1 في الساعة الثانية صباحاً.

# PagerDuty Slack integration — auto-create incident channel via webhook
# (Store this in your PagerDuty service extension config)

POST https://slack.com/api/conversations.create
Authorization: Bearer xoxb-YOUR-BOT-TOKEN
Content-Type: application/json

{
  "name": "incident-{{ trigger_time_yyyymmdd }}-{{ service_slug }}",
  "is_private": false
}

# Immediately post context to the new channel:
POST https://slack.com/api/chat.postMessage
{
  "channel": "{{ new_channel_id }}",
  "text": ":rotating_light: *SEV-{{ severity }}* | {{ incident_title }}\n*IC:* Needs assignment\n*Comms:* Needs assignment\n*Ops Lead:* Needs assignment\n*Status:* Investigating\n*Dashboard:* {{ grafana_url }}\n*Runbook:* {{ runbook_url }}"
}

# Pin the message so the status is always visible:
POST https://slack.com/api/pins.add
{
  "channel": "{{ new_channel_id }}",
  "timestamp": "{{ context_message_ts }}"
}

تسليم دور IC

تستلزم الحوادث الطويلة (كل ما يتجاوز ساعتين إلى ثلاث) تسليم دور IC. التعب يُدهور جودة القرار أسرع مما يعترف به معظم المهندسين — IC الذي يُدير SEV-1 لأربع ساعات في منتصف الليل لا يتخذ القرارات بالجودة ذاتها التي كان عليها في الساعة الأولى. يجب أن تكون التسليمات صريحة ومنظمة. يُقدم IC المغادر ملخصاً شفهياً أو مكتوباً يتضمن: الفرضية الراهنة للسبب الجذري، ما جُرِّب واستُبعد، الحالة الراهنة لجميع المهام النشطة وملاكها، أي التزامات مُحدَّدة زمنياً أُعطيت لأصحاب المصلحة، ونقطة القرار التالية التي يحتاج IC القادم إلى اتخاذها. يستغرق هذا الملخص خمس دقائق وهو يستحق كل ثانية. التسليمات غير الموثقة ("أنت مسؤول الآن، حظاً موفقاً") هي التي تحول الحوادث من أربع ساعات إلى ثماني ساعات.

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

توسيع الهيكل حسب حجم الحادث

ليس كل حادث يحتاج الأدوار الثلاثة مُعبَّأة بأشخاص منفصلين. يتوسع ICS:

SEV-3 / ثانوي: IC فقط. يضاعف IC دوره كقائد تواصل (يُنشر تحديث حالة واحد) ويوجّه المهندس أو المهندسَين المعنيَّين مباشرة.
SEV-2 / مهم: IC + قائد تواصل. دور Ops Lead خفيف — يمكن لـ IC تنسيق مجموعة SMEs الصغيرة بشكل غير رسمي.
SEV-1 / حرج: الأدوار الثلاثة، مفصولة بصرامة. قد تُنشأ مجموعات فرعية من SMEs (مثلاً مجموعة قواعد بيانات منفصلة ومجموعة شبكات منفصلة، لكل منها منسقها الذي يُبلّغ Ops Lead).
SEV-0 / وجودي: ICS كامل بالإضافة إلى قائد إحاطة تنفيذية يدير أصحاب المصلحة من مستوى نائب الرئيس فما فوق، وربما قائد قانوني/علاقات عامة إذا تضمّن الحادث تسرب بيانات.

القاعدة الأساسية عبر جميع الأحجام: يجب الإعلان صراحةً عن هوية IC وأن يعلمها كل من في القناة. يجب أن تكون الرسالة الأولى في أي قناة حادث: [IC: @username] أُعلن الحادث. Comms: @username. Ops: @username. الحالة: قيد التحقيق. إذا لم تكن هذه الرسالة موجودة، فليس لديك ICS — لديك حادث بلا رأس.

# Runbook snippet: IC declaration template (paste into incident channel immediately)
# Keep this as a Slack snippet or PD conference template

[IC: @your-name] *Incident declared — {{ service }} — SEV-{{ severity }}*
Comms Lead: @comms-name (or: unassigned — who can take this?)
Ops Lead: @ops-name (or: unassigned)
Current hypothesis: {{ initial_hypothesis }}
Active mitigations: none yet
Next check-in: {{ now + 15 minutes }}
Status page: {{ url }}
Runbook: {{ url }}
Timeline doc: {{ google_doc_or_confluence_url }}

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