[SEV] Scurtă descriere și dată

1) Principii și cultură

Fără vină. Eroarea este o proprietate a sistemului, nu o persoană. Căutăm „de ce sa întâmplat”, și nu „cine este de vină”.
Fapte şi invarianţi. Orice ieșiri se bazează pe cronologie, SLO, urme și jurnale.
Publicitate în cadrul companiei. Totalurile și lecțiile sunt disponibile echipelor conexe.
Acțiunile sunt mai importante decât protocoalele. Documentul neschimbat ≡ pierdut timp.
Publicare rapidă. Proiectul postmortem - în termen de 48-72 de ore de la incident.

2) Criterii de taxonomie și incidente

• SEV1 - inaccesibilitate completă/pierdere de bani/date;
• SEV2 - degradare semnificativă (erori> SLO, p99 exterior);
• SEV3 - există degradare parțială/soluție.
• Impact: regiuni/chiriași/produse afectate, durată, valori de afaceri (conversie, GMV, eșec de plată).
• SLO/buget eronat: cât de mult bugetul este epuizat, cum afectează viteza de lansări și experimente.

3) Roluri incidente și proces

Incident Commander (IC): gestionează procesul, prioritizează pașii, atribuie proprietarilor.
Communications Lead: informează părțile interesate/clienții cu privire la un șablon.
Ops/On-call: lichidare, atenuarea acțiunilor.
Scrib: Menține cronologie și artefacte.
Subiecte Experți (IMM): diagnosticare profundă.

Etape: detectarea escaladarea stabilizarea verificarea restaurarea postmorty introducerea îmbunătățirilor.

4) Șablon postmortem (structură)

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 atribuite, război-cameră deschisă

13: 27:30 valută-api „succes lent” identificat

13: 30:15 Ficha-pavilion rate vechi ON (10% trafic)

13: 41:00 Rate vechi 100%, p99 stabilizat 290ms

13: 52:40 Limitarea retreas la gateway

13: 58:00 Incident închis, monitorizare 30min

11. 2 Solutions and Validation (DoD)

Soluție: activați întrerupătorul (slow_success)

DoD: script haos „+ 300ms la valută” - p99 <450ms, error_rate <0. 5%, stale_share <12%

11. 3 Policy "gate" (check)

deny_release dacă există (postmortem_action. status! = „Făcut” și acțiune. severitate în [„critică”])

12) Anti-modele

„Vânătoare de vrăjitoare” şi pedeapsă → ascunderea greşelilor, pierderea semnalelor.
Protocol de dragul protocolului: documente lungi fără acțiuni/proprietari/termene limită.
Nivelul OCA „bug în cod” fără factori de sistem.
Închiderea incidentului fără retestarea și actualizarea liniilor de bază.
Lipsa publicității în cadrul companiei: repetarea acelorași greșeli pe alte echipe.
Ignorarea feedback-ului de la suport/parteneri și degradarea „invizibilă” (succes lent).
Rezumatul „a fixat totul, mergând mai departe” - fără modificări în arhitectură/procese.

13) Lista de verificare a arhitectului

1. Aveți un singur șablon postmortem și o publicație SLA ≤ 72 de ore?
2. Rolurile (IC, Comms, Scribe, IMM) sunt atribuite automat?
3. Termenele se bazează pe telemetrie (trasee/metrici/busteni) și etichete de lansare/pavilion?
4. Metodele RCA sunt aplicate sistemic (5 De ce, Ishikawa, Barieră)?
5. Acțiunile au proprietari, termene limită și DoD, asociate cu riscurile și porțile de eliberare?
6. Are incidentul actualiza runbook/xaoc scripturi/alerte?
7. Built-in canale VOC/Suport, există o revizuire regulată a „dureri de top”?
8. Are un buget eronat afectează politica de lansări și experimente?
9. Sunt urmărite valorile maturității (timp-la-post-mortem, rata de redeschidere, repetabilitate)?
10. Analiza publică intra-echipă și baza de cunoștințe cu căutare sunt disponibile?

Concluzie

Postmortems și feedback-ul sunt un mecanism de învățare de arhitectură. Atunci când parsarea fără vină, efectul măsurabil al acțiunilor și integrarea semnalelor din producție devin norme, sistemul devine mai stabil, mai rapid și mai clar în fiecare săptămână. Faceți faptele vizibile, acțiunile obligatorii și cunoștințele accesibile, iar incidentele devin combustibil pentru evoluția platformei dvs.