[SEV] توضیحات کوتاه و تاریخ

1) اصول و فرهنگ

بي گناه. خطا یک ویژگی سیستم است، نه یک شخص. ما به دنبال «چرا این اتفاق افتاد» و نه «چه کسی مقصر است».
حقایق و تغییرناپذیر ها هر خروجی بر اساس جدول زمانی، SLO، ردیابی و سیاهههای مربوط است.
تبلیغات در شرکت مجموع و درس به تیم های مرتبط در دسترس هستند.
فعالیت ها مهم تر از پروتکل ها هستند. سند بدون تغییر ≡ زمان از دست رفته.
انتشار سریع پیش نویس پس از مرگ - ظرف 48-72 ساعت پس از حادثه.

2) طبقه بندی و معیارهای حادثه

• SEV1 - عدم دسترسی کامل/از دست دادن پول/داده ها ؛
• SEV2 - تخریب قابل توجه (خطاها> SLO، p99 در خارج) ؛
• SEV3 - تخریب جزئی/راه حل وجود دارد.
• تاثیر: مناطق آسیب دیده/مستاجران/محصولات، مدت زمان، معیارهای کسب و کار (تبدیل، GMV، شکست پرداخت).
• SLO/بودجه اشتباه: چقدر بودجه خسته شده است، چگونه بر سرعت انتشار و آزمایش تاثیر می گذارد.

3) نقش و فرآیند حادثه

فرمانده حادثه (IC): فرآیند را مدیریت می کند، مراحل را اولویت بندی می کند، صاحبان را اختصاص می دهد.
سرب ارتباطات: اطلاع ذینفعان/مشتریان در قالب.
Ops/On-call: انحلال، اقدامات کاهش دهنده.
Scribe: جدول زمانی و مصنوعات را حفظ می کند.
کارشناسان موضوع (SME): تشخیص عمیق.

Stages: detection → escalation → stabilization → verification → restoration → postmorty → introduction of improvements.

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> 800ms (دروازه)

13: 24:00 IC اختصاص داده شده، اتاق جنگ باز است

13: 27:30 currency-api «موفقیت آهسته» شناسایی شده است

13: 30:15 نرخ های قدیمی پرچم Ficha ON (10٪ ترافیک)

13: 41:00 نرخ های پایدار 100٪، p99 290 میلی ثانیه تثبیت شده است

13: 52:40 محدود کردن بازگشت به دروازه

13: 58:00 حادثه بسته شد، نظارت 30 دقیقه

11. 2 Solutions and Validation (DoD)

راه حل: فعال کردن شکن (slow_success)

وزارت دفاع: اسکریپت هرج و مرج «+ 300ms به ارز» - p99 <450ms، 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، مانع) ؟
5. اقدامات دارای صاحبان، مهلت ها و DoD، همراه با دروازه های ریسک و انتشار است ؟
6. آیا رخداد، اسکریپتها/هشدارهای runbook/xaoc را بهروزرسانی میکند ؟
7. ساخته شده در VOC/کانال های پشتیبانی، یک بررسی به طور منظم از «درد بالا» وجود دارد ؟
8. آیا بودجه اشتباه بر سیاست انتشار و آزمایش تاثیر می گذارد ؟
9. آیا معیارهای بلوغ ردیابی می شوند (زمان به بعد از مرگ، نرخ بازگشایی، تکرارپذیری) ؟
10. تجزیه و تحلیل درون تیمی عمومی و پایگاه دانش با جستجو در دسترس هستند ؟

نتیجه گیری

پس از مرگ و بازخورد یک مکانیسم یادگیری معماری است. هنگامی که تجزیه بدون سرزنش، اثر قابل اندازه گیری اقدامات و ادغام سیگنال های تولید به هنجار تبدیل می شود، سیستم هر هفته پایدارتر، سریعتر و واضح تر می شود. حقایق را قابل مشاهده کنید، اقدامات اجباری، و دانش در دسترس، و حوادث تبدیل به سوخت برای تکامل پلت فرم خود را.