[SEV] وصف قصير وتاريخ

1) المبادئ والثقافة

بلا لوم. الخطأ هو خاصية للنظام وليس شخص. نحن نبحث عن «سبب حدوث ذلك» وليس «من يقع اللوم».
الحقائق والثوابت. أي مخرجات تستند إلى الجدول الزمني، SLO، الآثار والسجلات.
الدعاية داخل الشركة. وتتاح المجاميع والدروس للأفرقة ذات الصلة.
الإجراءات أهم من البروتوكولات. المستند الذي لم يتغير ≡ الوقت الضائع.
نشر سريع. مسودة تشريح الجثة - في غضون 48-72 ساعة بعد الحادث.

2) معايير التصنيف والحوادث

• SEV1 - تعذر الوصول الكامل/فقدان الأموال/البيانات ؛
• SEV2 - تدهور كبير (أخطاء> SLO, p99 outside) ؛
• SEV3 - وجود تدهور جزئي/حل بديل.
• التأثير: المناطق المتأثرة/المستأجرين/المنتجات، المدة، مقاييس الأعمال (التحويل، القيمة المضافة العالمية، فشل الدفع).
• ميزانية SLO/خاطئة: مقدار الميزانية المستنفدة، وكيف تؤثر على سرعة الإطلاقات والتجارب.

3) أدوار الحوادث وعملياتها

قائد الحادث (IC): يدير العملية، ويعطي الأولوية للخطوات، ويعين المالكين.
قيادة الاتصالات: إبلاغ أصحاب المصلحة/العملاء بنموذج.
العمليات/تحت الطلب: التصفية، إجراءات التخفيف.
Scribe: يحافظ على الجدول الزمني والتحف.
خبراء الموضوع (SME): التشخيص العميق.

المراحل: الكشف → التصعيد → الاستقرار → التحقق → استعادة → بعد الولادة → إدخال التحسينات.

4) نموذج ما بعد الوفاة (هيكل)

5) RCA Techniques (Root Cause Search)

5 Why - sequential clarification of causes to the system level.
Ishikawa (fish bone) - factors "People/Processes/Tools/Materials/Environment/Dimensions."
Event-Chain/Ripple - a chain of events with probabilities and triggers.
Barrier Analysis - which "fuses" (timeouts, breakers, quotas, tests) were supposed to stop the incident and why they did not work.
Change Correlation - correlation with releases, config digs, feature flags, provider incidents.

Practice: Avoid "root cause = person/one bug." Look for a system combination (debt + lack of guard rails + irrelevant runbooks).

6) Communications and transparency

Internal: single channel (war-room), short updates according to the template: status → actions → ETA of the next update.
External: status page/newsletter with facts without "guilt," with apologies and an action plan.
Sensitivity: do not disclose PD/secrets; legal wording to be agreed.
After the incident: a summary note with human language and a link to a technical report.

External update template (brief):
"31 Oct 2025, 13:40 UTC - some users encountered payment errors (up to 18 minutes). The reason is the degradation of the dependent service. We turned on bypass mode and restored operation at 13:58 UTC. Apologies. Within 72 hours, we will publish a report with actions to prevent recurrence"

7) Actions and implementation management

Each action is owner, deadline, acceptance criteria, risk and priority relationship.
Action classes:
1. Engineering: timeout budgets, jitter retreats, breakers, bulkheads, backprescher, stability/chaos tests.
2. Observability: SLI/SLO, alert guards, saturation, traces, steady-state dashboards.
3. Process: runbook update, on-call workouts, game day, CI gates, bipartisan review for risky changes.
4. Architecture: cache with coalescing, outbox/saga, idempotency, limiters/shading.
Gates: releases fail unless "post-mortem critical actions" are closed (Policy as Code).
Verification: retest (chaos/load) confirms the elimination of the risk.

8) Integration of feedback

Sources:
Telemetry: p99/p99 tails. 9, error-rate, queue depth, CDC lag, retray budget.
VoC/Support: topics of calls, CSAT/NPS, churn signals, "pain points."
Product/Analytics: user behavior, failure/friction, drop-off in funnels.
Partners/Integrators: webhook failures, contract incompatibility, SLA timing.

Signal → decision loop:
1. The signal is classified (severity/cost/frequency).
2. An architectural ticket is created with a hypothesis and the price of the problem.
3. Falls into the engineering portfolio (quarterly/monthly), ranked by ROI and risk.
4. Execute → measure effect → update SLI/SLO/cost baselines.

9) Post-mortem maturity metrics

% postmortems published ≤ 72 h (target ≥ 90%).
Average "lead time" from incident to closure of key actions.
Reopen rate of actions (quality of DoD formulations).
Repeated incidents for the same reason (target → 0).
Proportion of incidents caught by guards (breaker/limiter/timeouts) vs "breakthrough."
Saturation of dashboards (SLI covering critical paths) and "noise" of alerts.
Share of game-day/chaos scenarios that simulate detected failure classes.

10) Example of postmortem (summary)

Event: SEV2. Payment API: up p99 to 1. 8s, 3% 5xx, 31 Oct 2025 (13:22–13:58 UTC).
Impact: 12% of payment attempts with retrays, part - cancellation. Erroneous budget q4: − 7%.
Root Cause: "slow success" of currency dependence (p95 + 400 ms), retrai without jitter → cascade.
Barrier failure: the breaker is configured only for 5xx, not for timeouts; there was no rate-cap for low priority.
What worked: hand shading and stale-rates feature flag.
Actions:
Enter timeout budget and jitter retrays (DoD: p99 <400 ms at + 300 ms to dependency).
Breaker for "slow success" and fallback stale data ≤ 15 minutes.
Update runbook "slow dependency," add chaos script.
Add dashboard "served-stale share" and alert at> 10%.
Enter release-gate: without passing chaos-smoke - prohibit release.

11) Artifact patterns

11. 1 Timeline (example)

13: 22:10 تنبيه p99> 800 م (بوابة)

13: 24:00 IC مخصص، غرفة حرب مفتوحة

13: 27:30 «نجاح بطيء» للعملة

13: 30:15 معدلات Ficha-flag التي لا معنى لها ON (10٪ حركة مرور)

13: 41:00 معدلات قديمة 100٪، استقر p99 290 مللي ثانية

13: 52:40 الحد من الخلوات إلى البوابة

13: 58:00 حادثة مغلقة، مراقبة 30 دقيقة

11. 2 Solutions and Validation (DoD)

الحل: تمكين الكسر (slow_success)

وزارة الدفاع: نص الفوضى «+ 300 م للعملة» - p99 <450 م، error_rate <0. 5٪، stale_share <12٪

11. 3 Policy "gate" (check)

deny_release إن وجدت (postmortem_action. الوضع! = «تم» والعمل. الشدة في [«حرجة»])

12) الأنماط المضادة

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

13) قائمة مرجعية للمهندس المعماري

1. هل لديك نموذج تشريح واحد ونشر SLA ≤ 72 ساعة ؟
2. هل يتم تعيين الأدوار (IC و Comms و Scribe و SME) تلقائيًا ؟
3. تستند الجداول الزمنية إلى القياس عن بعد (المسارات/المقاييس/السجلات) وعلامات الإطلاق/العلم ؟
4. يتم تطبيق أساليب RCA بشكل منهجي (5 لماذا، Ishikawa، Barrier) ؟
5. الإجراءات لها مالكون ومواعيد نهائية ووزارة الدفاع، مرتبطة بالمخاطر وبوابات الإفراج ؟
6. هل يقوم الحادث بتحديث كتاب التشغيل/نصوص/تنبيهات xaoc ؟
7. قنوات VoC/Support المدمجة، هل هناك مراجعة منتظمة لـ «آلام القمة» ؟
8. هل تؤثر الميزانية الخاطئة على سياسة الإطلاقات والتجارب ؟
9. هل يتم تتبع مقاييس النضج (وقت تشريح الجثة، معدل إعادة الفتح، قابلية التكرار) ؟
10. التحليل العام داخل الفريق وقاعدة المعرفة مع البحث متاحة ؟

خامسا - الاستنتاج

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