الاستجابة للحوادث
الـ incident هو تأثير على الـ production لا يحتمل انتظار التدفّق العادي. الهدف تخفيف سريع وتواصل واضح مع العميل — اللوم لا يأتي أبدًا، والتعلّم يأتي لاحقًا.
التدفّق
Section titled “التدفّق”flowchart LR D["Declare<br/>one channel"] --> T["Triage<br/>set severity"] T --> C["Client comms<br/>single voice"] C --> M["Mitigate<br/>stop the bleeding"] M --> R["Resolve<br/>verify fixed"] R --> P["Postmortem<br/>Sev1/Sev2"]
مستويات الـ Severity
Section titled “مستويات الـ Severity”| Sev | المعنى | مثال |
|---|---|---|
| Sev1 | production معطّل أو بيانات في خطر. | التطبيق offline، فشل الشراء لكل المستخدمين، فقدان بيانات. |
| Sev2 | ميزة رئيسية معطّلة بلا workaround كامل. | الـ login يعمل لكن المدفوعات تفشل؛ module أساسي معطّل. |
| Sev3 | بسيط / متدهور مع وجود workaround. | تقرير واحد يعطي خطأ؛ شاشة بطيئة لكن قابلة للاستخدام. |
من يُعلن، وأين
Section titled “من يُعلن، وأين”- أيّ شخص يمكنه الإعلان. غالبًا L1 (نضال) أو الـ team lead. الإفراط في الإعلان ثمّ التراجع أفضل من التغاضي عن Sev1.
- قناة incident واحدة. كل التنسيق يجري في قناة واحدة مُسمّاة لكل incident — لا threads متوازية، ولا رسائل خاصّة للمطوّرين.
- صوت واحد تجاه العميل. جهة الاتصال الأساسية (غالبًا L1 أو الـ PM) تتحدّث مع العميل. المهندسون يُصلحون ولا يديرون محادثات موازية مع العميل. انظر نموذج الدعم.
مسار التواصل مع العميل
Section titled “مسار التواصل مع العميل”sequenceDiagram participant Eng as Incident team participant Lead as Comms owner participant Client Eng->>Lead: Status + ETA Lead->>Client: Acknowledge + impact Lead->>Client: Update on mitigation Lead->>Client: Resolved + next steps
الـ Sev1 والـ Sev2 لهما postmortem بلا لوم — انظر قالب الـ Postmortem. أمّا الـ Sev3 فيُغلَق على الـ board دون واحد.