[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): терең диагностика.

Этаптар: аныктоо → эскалация → турукташтыруу → текшерүү → калыбына келтирүү → postmortem → жакшыртуу киргизүү.

4) Postmortem үлгүсү (түзүлүшү)

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 Alert p99> 800ms (gateway)

13: 24:00 IC дайындалган, war-room ачык

13: 27:30 Аныкталган "жай ийгилик" currency-api

13: 30:15 Ficha желеги stale-rates ON (10% жол)

13: 41:00 Stale-rates 100%, p99 туруктуу 290ms

13: 52:40 gateway боюнча retrains чектөө

13: 58:00 окуя жабык, мониторинг 30мин

11. 2 Solutions and Validation (DoD)

Solution: 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) Анти-үлгүлөрү

"Бакшыларга аңчылык кылуу" жана жазалоо → каталарды жашыруу, сигналдарды жоготуу.
Протокол үчүн протокол: иш-аракеттери/ээлери/мөөнөттөрү жок узак документтер.
RCA деңгээл "коддогу мүчүлүштүк" эч кандай системалуу себептер.
Окуяларды ретестсиз жана базлайндарды жаңыртуусуз жабуу.
Компаниянын ичинде коомчулуктун жоктугу: башка командаларда ошол эле каталарды кайталоо.
Саппорттун/өнөктөштөрдүн жана "көрүнбөгөн" деградациялардын пикирлерине көңүл бурбоо (жай ийгилик).
Кыскача "баары оңдолду, биз алдыга жылабыз" - архитектурада/процесстерде өзгөрүүсүз.

13) Архитектордун чек тизмеси

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

Корутунду

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