[SEV] Brève description et date

1) Principes et culture

Blameless. L'erreur est une propriété du système, pas une personne. On cherche « pourquoi c'est arrivé », pas « qui est responsable ».
Faits et invariants. Toutes les conclusions sont basées sur le temps, le SLO, les traces et les logs.
Publicité en interne. Les résultats et les leçons sont disponibles pour les équipes associées.
Les actions sont plus importantes que les protocoles. Le document est inchangé ≡ le temps perdu.
Publication rapide. Brouillon post-mortem - dans les 48 à 72 heures suivant l'incident.

2) Taxonomie et critères d'incident

• SEV1 - indisponibilité totale/perte d'argent/données ;
• SEV2 - dégradation significative (erreurs> SLO, p99 au-delà) ;
• SEV3 - la dégradation partielle/scénario de contournement existe.
• Impact : régions/tenants/produits touchés, durée, métriques d'entreprise (conversion, GMV, refus de paiement).
• SLO/budget erroné : combien le budget est épuisé, comment cela affecte la vitesse des sorties et des expériences.

3) Rôles et processus d'incident

Commandant d'incident (IC) : gère le processus, priorité les étapes, désigne les propriétaires.
Communication Lead : informe les opérateurs/clients par le modèle.
Ops/On-call : liquidation, action mitrailleuse.
Scribe : conduit le temps et les artefacts.
Subject Matter Experts (SME) : diagnostic profond.

Les étapes : la détection → l'escalade → la stabilisation → la vérification → la restitution → постмортем → l'introduction des améliorations.

4) Modèle postmortem (structure)

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)

13h22 : 10 Alert p99> 800 ms (gateway)

13h24 : IC désigné, salle de guerre ouverte

13h27 : 30 Identifie le « succès lent » de currency-api

13h30 : 15 Ficha-drapeau stale-rates ON (trafic 10%)

13: 41:00 Stale-rates 100 %, p99 stabilisé 290ms

13h52 : 40 Limitation des retraits à la passerelle

13: 58:00 Incident fermé, surveillance 30min

11. 2 Solutions and Validation (DoD)

Solution : inclure breaker (slow_success)

DoD : scénario 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) Anti-modèles

« Chasse aux sorcières » et punitions → dissimulation d'erreurs, perte de signaux.
Protocole pour le protocole : documents longs sans action/propriétaires/délais.
L'ARC de niveau « bug dans le code » sans facteurs système.
Fermez l'incident sans retest et mettez à jour les baslines.
Manque de publicité au sein de l'entreprise : répétition des mêmes erreurs dans les autres équipes.
Ignorer la rétroaction de Sapport/partenaires et les dégradations « invisibles » (succès lent).
Le résumé « tout le monde a réparé, on passe à autre chose » - aucun changement dans l'architecture/les processus.

13) Chèque de l'architecte

1. Y a-t-il un modèle unique de publication postmortem et SLA ≤ 72 h ?
2. Les rôles (IC, Comms, Scribe, SME) sont-ils attribués automatiquement ?
3. Les temporisations sont basées sur la télémétrie (tracks/métriques/logs) et les étiquettes de sortie/drapeaux ?
4. Les techniques RCA sont appliquées de manière systémique (5 Why, Ishikawa, Barrier) ?
5. Les actions ont des propriétaires, des échéances et des DoD, sont-elles liées aux risques et aux jeux de sortie ?
6. L'incident entraîne-t-il une mise à jour des scripts runbook/xaoc/alerts ?
7. Les canaux VoC/Support sont intégrés, avez-vous un aperçu régulier des « meilleures douleurs » ?
8. Un budget erroné affecte-t-il la politique de libération et d'expérimentation ?
9. Les métriques de maturité sont-elles suivies (time-to-postmortem, reopen rate, répétabilité) ?
10. L'analyse intra-équipe publique et la base de connaissances avec la recherche sont disponibles ?

Conclusion

Les postmortems et la rétroaction sont un mécanisme d'apprentissage de l'architecture. Lorsque l'analyse sans frais, l'effet mesurable des actions et l'intégration des signaux de production deviennent la norme, le système devient plus stable, plus rapide et plus clair chaque semaine. Rendre les faits visibles, les actions obligatoires et les connaissances accessibles, et les incidents deviendront le carburant de l'évolution de votre plateforme.