[SEV] Қысқаша сипаттамасы және күні

1) Қағидаттар және мәдениет

Blameless. Қате - адам емес, жүйе қасиеті. «Кім кінәлі» емес, «неге осылай болды» деп іздейміз.
Фактілер мен инварианттар. Кез келген қорытындылар таймлайн, SLO, трассировка және логиге сүйенеді.
Компания ішіндегі жариялылық. Қорытындылар мен сабақтар аралас командаларға қолжетімді.
Әрекеттер хаттамалардан да маңызды. Құжат жоғалған уақытты ≡.
Жылдам жариялау. Постмортемнің жобасы - оқиғадан кейін 48-72 сағат ішінде.

2) Инциденттердің таксономиясы мен критерийлері

• SEV1 - ақшаның/деректердің толық қол жетімсіздігі/жоғалуы;
• SEV2 - елеулі тозу (қателер> SLO, p99 шегінен тыс);
• SEV3 - ішінара құлдырау/айналым сценарийі бар.
• Әсері: қозғалған өңірлер/тенанттар/өнімдер, ұзақтығы, бизнес-метрика (конверсия, GMV, төлемдерден бас тарту).
• SLO/қате бюджет: қанша бюджет сарқылды, бұл релиздер мен эксперименттердің жылдамдығына қалай әсер етеді.

3) Инциденттің рөлдері мен процесі

Incident Commander (IC): процесті басқарады, қадамдарға басымдық береді, иелерін тағайындайды.
Communications Lead: үлгі бойынша стейкхолдерлерді/клиенттерді хабардар етеді.
Ops/On-call: жою, кемсітетін әрекеттер.
Scribe: таймлайн мен артефактілерді жүргізеді.
Subject Matter Experts (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> 800ms (gateway)

13: 24:00 IC тағайындалды, war-room ашық

13: 27:30 Сәйкестендірілген «баяу табыс» currency-api

13: 30:15 Фича-туы stale-rates ON (10% трафик)

13: 41:00 Stale-rates 100%, p99 тұрақталған 290ms

13: 52:40 gateway-дегі ретрациялардың шектелуі

13: 58:00 Оқиға жабық, мониторинг 30 мин

11. 2 Solutions and Validation (DoD)

Шешім: breaker (slow_success) қосу

DoD: chaos-сценарий «+ 300ms к currency» - p99 <450ms, error_rate <0. 5%, stale_share < 12%

11. 3 Policy "gate" (check)

deny_release if any(postmortem_action. status!= "Done" and action. severity in ["critical"])

12) Қарсы үлгілер

«Сиқырларды аулау» және жазалау → қателерді жасыру, дабылдарды жоғалту.
Хаттама үшін хаттама: ұзын құжаттар әрекетсіз/иеленушілерсіз/мерзімсіз.
РЦА деңгейі «кодтағы қате» жүйелік факторларсыз.
Базлайндарды ретестерсіз және жаңартусыз инцидентті жабу.
Компания ішінде жариялылықтың болмауы: сол қателерді басқа командаларда қайталау.
Саппорттан/әріптестерден және «көрінбейтін» деградациялардан кері байланысты елемеу (баяу табыс).
«Бәрін жөндедік, одан әрі жылжимыз» деген мәлімет - архитектурада/процестерде өзгеріссіз.

13) Сәулетшінің чек-парағы

1. Постмортем мен SLA жарияланымының бірыңғай үлгісі бар ≤ 72 сағ?
2. Рөлдер (IC, Comms, Scribe, SME) автоматты түрде тағайындала ма?
3. Таймлайндар телеметрияға (трейс/метрика/логи) және релиздер/жалаулар белгілеріне негізделген ба?
4. RCA әдістемелері жүйелі түрде қолданылады (5 Why, Ishikawa, Barrier)?
5. Іс-әрекеттердің иелері, мерзімдері және DoD бар, тәуекелмен және релиздер гейтімен байланысты ма?
6. Оқиға runbook/xaoc-сценарийлерін/қателіктерін жаңартуға әкеледі ме?
7. VoC/Support арналары орнатылған, «топ-ауруларға» тұрақты шолу бар ма?
8. Қате бюджет релиздер мен эксперименттер саясатына әсер ете ме?
9. Жетілу өлшемдері қадағаланады ма (time-to-postmortem, reopen rate, қайталануы)?
10. Жалпы командаішілік талдаулар және іздеу арқылы білім базасы бар ма?

Қорытынды

Постмортемалар мен кері байланыс - бұл архитектураны оқыту тетігі. Айыптаусыз талдаулар, іс-қимылдың өлшенетін әсері және продакшендегі сигналдардың интеграциясы қалыпты жағдайға айналғанда, жүйе апта сайын тұрақтырақ, жылдам және түсінікті болады. Фактілерді көрінетін, іс-қимылдарды міндетті, ал білімді қолжетімді етіңіз, оқыс оқиғалар платформаңыздың эволюциясы үшін отынға айналады.