Classez les incidents, coordonnez les updates et transformez la réponse en travail de suivi. — Claude Skill

Patterns postmortem

Structure de postmortem sans blâme, techniques d analyse de cause racine, suivi des actions et patterns de chaos engineering. À utiliser après résolution d incident ou lors de la conception de programmes de test de résilience.

Structure de postmortem sans blâme

Principes cœur

1. Pas de blâme : se concentrer sur systèmes, processus et conditions -- pas sur les individus
2. Supposer la bonne intention : chaque personne impliquée faisait de son mieux avec les informations disponibles
3. Apprendre, ne pas punir : l objectif est la prévention, pas la responsabilité individuelle
4. Partager largement : les postmortems sont un apprentissage organisationnel, pas une honte d équipe

Template de document postmortem

# Incident Postmortem: [Title]

**Date:** [Incident date]
**Severity:** P[0-3]
**Duration:** [Start time] to [End time] ([total duration])
**Incident Commander:** [Name]
**Author:** [Name]
**Status:** [Draft | Review | Final]

## Summary

[1-2 sentence description of what happened and the user impact]

## Impact

- **Users affected:** [Number or percentage]
- **Duration:** [How long users experienced the issue]
- **Revenue impact:** [If applicable]
- **Data impact:** [Any data loss or corruption]
- **SLA impact:** [Any SLA violations]

## Timeline

All times in [timezone].

| Time | Event |
|------|-------|
| HH:MM | [First signal / alert fired] |
| HH:MM | [On-call acknowledged] |
| HH:MM | [Severity classified as P_] |
| HH:MM | [Key investigation finding] |
| HH:MM | [Mitigation applied] |
| HH:MM | [Issue confirmed resolved] |
| HH:MM | [Monitoring confirmed stable] |

## Root Cause

[Detailed description of the root cause. What condition or change led to the failure?]

## Contributing Factors

- [Factor 1: e.g., missing monitoring for this failure mode]
- [Factor 2: e.g., deployment during high-traffic period]
- [Factor 3: e.g., no automated rollback configured]

## What Went Well

- [Thing 1: e.g., alert fired within 2 minutes of impact]
- [Thing 2: e.g., team coordinated effectively in war room]
- [Thing 3: e.g., rollback was smooth and fast]

## What Went Poorly

- [Thing 1: e.g., took 20 minutes to identify the failing service]
- [Thing 2: e.g., no runbook existed for this failure mode]
- [Thing 3: e.g., status page was not updated for 30 minutes]

## Action Items

| ID | Action | Owner | Priority | Due Date | Status |
|----|--------|-------|----------|----------|--------|
| 1 | [Action description] | [Name] | P1 | [Date] | Open |
| 2 | [Action description] | [Name] | P2 | [Date] | Open |

## Lessons Learned

[Key takeaways that should inform future design, process, or tooling decisions]

Facilitation de réunion postmortem

Avant la réunion :

• Rédiger le document postmortem et le partager 24 heures à l avance
• Tous les participants relisent la timeline pour exactitude
• L incident commander prépare l analyse de cause racine

Pendant la réunion (60-90 min) :

1. Revue timeline (15 min) : parcourir les événements, corriger les erreurs, combler les gaps
2. Discussion cause racine (20 min) : appliquer 5 Whys ou analyse fishbone
3. Facteurs contributifs (15 min) : qu est-ce qui a aggravé l incident ou rendu la résolution plus difficile ?
4. Ce qui a bien fonctionné (10 min) : renforcer les pratiques efficaces
5. Actions (20 min) : définir des actions concrètes, assignables et time-bounded

Après la réunion :

• Finaliser le document sous 24 heures
• Le distribuer à l organisation élargie
• Entrer les actions dans le système de suivi
• Planifier une revue de suivi pour l achèvement des actions

Techniques d analyse de cause racine

5 Whys

Demander "pourquoi" de façon répétée pour dépasser les symptômes et atteindre la cause sous-jacente.

Exemple :

Problem: Users received duplicate order confirmation emails.

Why 1: The email service sent the confirmation twice.
Why 2: The order completion event was published twice.
Why 3: The order service retried after a timeout.
Why 4: The message broker acknowledged slowly under load.
Why 5: The broker's disk was 95% full, causing write delays.

Root cause: No disk usage monitoring or alerting on the message broker.
Action: Add disk usage alerting at 80% threshold + auto-scaling.

Guidelines :

• Arrêtez-vous quand vous atteignez une cause systémique corrigeable (processus, tooling, design)
• Ne vous arrêtez pas à "human error" -- demandez pourquoi le système a permis l erreur
• Certains incidents ont plusieurs causes racines; lancez 5 Whys pour chaque branche
• Les réponses doivent être factuelles, pas spéculatives

Diagramme fishbone (Ishikawa)

Catégoriser les facteurs contributifs selon des dimensions standard.

                    ┌─ People: On-call unfamiliar with service
                    ├─ Process: No rollback runbook existed
Duplicate emails ───├─ Technology: No idempotency on email sends
                    ├─ Environment: Broker disk at 95%
                    ├─ Monitoring: No disk usage alerts
                    └─ External: Upstream traffic spike

Catégories standard :

• People : lacunes de connaissance, staffing, communication
• Process : runbooks manquants, procédures floues, goulots d approbation
• Technology : bugs, fonctionnalités manquantes, gaps d architecture
• Environment : infrastructure, capacité, configuration
• Monitoring : alertes manquantes, seuils incorrects, gaps d observabilité
• External : pannes tierces, pics de trafic, attaques

Fault Tree Analysis

Remonter depuis la panne pour identifier toutes les causes possibles.

Top event: Service outage
├── AND: Load balancer failure
│   ├── OR: Config error
│   └── OR: Health check misconfigured
└── AND: No failover triggered
    ├── OR: Failover not configured
    └── OR: Failover health check also failed

Quand l utiliser : incidents complexes avec plusieurs défaillances interactives où 5 Whys est insuffisant.

Suivi des actions

Critères de qualité des actions

Chaque action doit être :

• Spécifique : description claire de quoi faire (pas "improve monitoring")
• Assignable : un owner, pas une équipe
• Time-bounded : date d échéance, pas "quand on aura le temps"
• Vérifiable : définition claire du done
• Priorisée : P1 (avant la prochaine rotation d astreinte), P2 (ce sprint), P3 (ce trimestre)

Catégories d actions

Tracking et suivi

• Entrer toutes les actions immédiatement dans l issue tracker de l équipe
• Taguer avec postmortem et l ID incident pour traçabilité
• Revoir chaque semaine les actions postmortem ouvertes en standup équipe
• Escalader les P1 en retard au manager engineering
• Fermer les actions seulement quand l achèvement est vérifié (pas juste "code merged")

Anti-patterns d actions

Patterns de chaos engineering

Injection de fautes

Introduire volontairement des pannes pour vérifier la résilience.

Types de fautes courants :

Checklist d injection de fautes

• Hypothèse définie : "We believe [X] will happen when [fault]"
• Blast radius limité (instance unique, canary, staging)
• Mécanisme de rollback prêt (kill switch de l expérience)
• Monitoring en place pour observer l effet
• L équipe sait que l expérience est en cours
• Critères d arrêt définis (stop si impact utilisateur réel dépasse N%)

Game Days

Exercices structurés où les équipes pratiquent la réponse incident face à des pannes simulées.

Template de planification Game Day :

## Game Day: [Title]

**Date:** [Date and time]
**Duration:** [Expected duration]
**Facilitator:** [Name]
**Participants:** [Team members]

### Scenario
[Description of the simulated incident]

### Objectives
- [ ] Validate alerting detects the failure within [N] minutes
- [ ] Validate team can triage to correct severity
- [ ] Validate mitigation can be applied within [N] minutes
- [ ] Validate communication protocols are followed

### Ground Rules
- This is practice, not evaluation
- Facilitator controls the scenario progression
- Anyone can call "stop" if real production impact is detected
- Document all observations in real time

### Debrief Questions
1. Did alerts fire as expected?
2. Was the right team engaged quickly enough?
3. Were runbooks adequate?
4. What would we do differently in a real incident?

Cadence game day :

• Trimestrielle pour les services critiques
• Après changements d architecture majeurs
• Lors de l onboarding de nouveaux ingénieurs d astreinte
• Après tout incident P0 (tester les correctifs)

Méthodologie de test de résilience

Niveaux de maturité résilience

Checklist de test de résilience

Pour chaque service critique, valider :

• Défaillance instance unique : le service récupère quand une instance meurt
• Timeout dépendance : le service gère les dépendances lentes gracieusement
• Panne dépendance : le service se dégrade (ne crash pas) quand une dépendance est down
• Partition réseau : le service gère les scénarios split-brain
• Pic de charge : le service shed la charge ou scale sous 3x trafic normal
• Disque plein : le service alerte et se dégrade avant de crasher
• Erreur configuration : le service fail fast avec erreur claire sur mauvaise config
• Rollback : la version précédente peut être déployée sous 5 minutes
• Corruption données : la restauration backup a été testée dans le dernier trimestre

Hypothèse steady-state

Avant toute expérience chaos, définir ce que "normal" signifie :

Steady state:
- Request success rate > 99.9%
- p99 latency < 200ms
- Error rate < 0.1%
- No alerts firing

Experiment: Kill 1 of 3 service instances

Hypothesis: Steady state metrics remain within 10% of baseline
            within 60 seconds of the fault injection.

Abort if: Error rate > 5% for more than 30 seconds.

name: incident-response description: Triage d incident, prévention des cascades et méthodologie postmortem. À utiliser lors d incidents production, de conception de patterns de résilience ou d exercices de chaos engineering. keywords:

• réponse aux incidents
• panne
• postmortem
• triage
• incident
• réponse

Réponse aux incidents

Gestion structurée des incidents depuis la détection jusqu au postmortem, avec patterns de résilience pour prévenir et contenir les défaillances en cascade.

Quand l utiliser

• Incident production en cours (panne, dégradation, perte de données)
• Conception de circuit breakers, bulkheads ou stratégies de fallback
• Conduite ou planification d exercices de chaos engineering
• Rédaction ou revue de documents postmortem
• Mise en place de procédures d astreinte et de chemins d escalade

À éviter quand :

• Le problème est un bug de développement sans impact production
• Vous concevez une architecture système générale (utilisez plutôt system-design)

Référence rapide

Workflow de réponse aux incidents

Phase 1 : Détecter

• Une alerte se déclenche ou un rapport utilisateur arrive
• Confirmer que le problème est réel (pas un faux positif)
• Identifier les services affectés et le périmètre d impact utilisateur

Phase 2 : Trier

• Classer la sévérité (P0-P3)
• Assigner un incident commander
• Ouvrir un canal de communication (war room, canal Slack)
• Démarrer les updates de page de statut

Phase 3 : Contenir

• Arrêter l hémorragie : rollback, feature flag, déplacement de trafic
• Prévenir la cascade : circuit breakers, load shedding, isolation bulkhead
• Communiquer : updates parties prenantes toutes les 15 minutes pour P0/P1

Phase 4 : Résoudre

• Implémenter le correctif (correctif viable minimal en premier)
• Valider en staging si le temps le permet
• Déployer avec monitoring et plan de rollback prêts
• Confirmer la récupération avec des métriques revenues à la baseline

Phase 5 : Postmortem

• Documenter la timeline dans les 48 heures
• Mener une revue sans blâme avec tous les participants
• Identifier cause racine et facteurs contributifs
• Assigner les actions avec owners et échéances
• Mettre à jour runbooks et alerting à partir des leçons apprises

Cadre de sévérité

Sortie

• Timeline d incident et classification de sévérité
• Actions de confinement prises
• Document postmortem avec actions
• Runbooks et règles d alerting mis à jour

Erreurs courantes

• Sauter la classification de sévérité et traiter tout comme P0
• Faire des changements sans plan de rollback
• Oublier de communiquer le statut aux parties prenantes
• Écrire des postmortems qui attribuent la faute au lieu d identifier les problèmes systémiques
• Ne pas suivre les actions issues du postmortem

Cadre de triage

Classification de sévérité, prévention des cascades, protocoles de communication et chemins d escalade pour incidents production. À utiliser pendant les incidents actifs ou lors de la mise en place de procédures de réponse aux incidents.

Classification de sévérité (P0-P3)

P0 -- Critique

Définition : Panne complète de service, perte active de données ou faille sécurité affectant tous les utilisateurs.

Exemples :

• Base de données production injoignable
• Service d authentification complètement down
• Corruption ou perte active de données
• Faille sécurité avec exfiltration confirmée
• Traitement des paiements arrêté

P1 -- Élevé

Définition : Fonctionnalité majeure cassée ou dégradation significative affectant un large sous-ensemble d utilisateurs.

Exemples :

• Paiements échouant pour une région
• Recherche retournant des erreurs pour 20 %+ des requêtes
• Latence API 10x au-dessus de la normale
• Crash de l app mobile au lancement pour une version OS précise

P2 -- Moyen

Définition : Performance dégradée ou perte partielle de fonctionnalité avec contournements disponibles.

Exemples :

• Latence élevée (2-3x normale) sur endpoints non critiques
• Traitement de jobs background retardé
• Intégration tierce non critique down
• Génération de rapports lente mais fonctionnelle

P3 -- Faible

Définition : Problème mineur avec impact utilisateur minimal. Un contournement existe ou le problème est cosmétique.

Exemples :

• Glitch de rendu UI dans un edge case
• Cron non critique échoué (réessaiera)
• Chargement lent d un dashboard interne
• Erreur de logging mineure sans impact fonctionnalité

Arbre de décision de sévérité

Is data being lost or corrupted?
├─ Yes → P0
└─ No
   Is there a security breach?
   ├─ Yes → P0
   └─ No
      Is the primary service completely down?
      ├─ Yes → P0
      └─ No
         Is a major feature broken for many users?
         ├─ Yes → P1
         └─ No
            Is performance significantly degraded?
            ├─ Yes → P2
            └─ No → P3

Prévention des cascades

Circuit Breakers

Arrêter automatiquement les appels à une dépendance défaillante pour prévenir une panne en cascade.

Checklist d implémentation :

• Chaque dépendance externe a un circuit breaker
• Les seuils d échec sont réglés par dépendance (pas one-size-fits-all)
• L état OPEN retourne un fallback utile (données cache, réponse dégradée, erreur)
• Les probes HALF-OPEN sont légers (health check, pas requête complète)
• L état du circuit breaker est observable (métriques, dashboard)
• Des alertes se déclenchent quand un circuit breaker s ouvre

Template de configuration :

Dependency: [service name]
Failure threshold: [N] failures in [T] seconds
Reset timeout: [T] seconds
Fallback: [cached response | error message | degraded mode]

Isolation Bulkhead

Partitionner les ressources pour qu une panne dans une zone ne puisse pas épuiser les ressources d une autre.

Patterns :

• Isolation thread pool : pools de threads séparés par dépendance
• Isolation connection pool : pools dédiés par service downstream
• Isolation process : workloads critiques et non critiques dans des processus séparés
• Isolation infrastructure : clusters séparés pour workloads critiques vs batch

Checklist :

• Les dépendances du chemin critique ont des pools de ressources dédiés
• Le travail background non critique ne peut pas affamer les requêtes critiques
• Les limites sont définies par pool (max connections, max threads)
• L épuisement de pool déclenche des alertes, pas de file silencieuse

Load Shedding

Abandonner intentionnellement du travail basse priorité pour préserver la capacité du trafic haute priorité.

Niveaux de priorité :

Implémentation :

• Utiliser headers de priorité de requête ou classification par path
• Retourner 503 avec header Retry-After pour les requêtes shed
• Suivre le taux de shedding comme métrique (shedding > 0 est une alerte)

Stratégies de dégradation gracieuse

Protocoles de communication

Updates de page de statut

Template d entrée de page de statut :

[TIMESTAMP] - [STATUS: Investigating | Identified | Monitoring | Resolved]

Impact: [Brief description of user-visible impact]
Current status: [What we know and what we're doing]
Next update: [When to expect the next update]

Cadence d update :

• P0 : toutes les 15 minutes jusqu à résolution
• P1 : toutes les 30 minutes jusqu à résolution
• P2 : au début et à la résolution
• P3 : seulement à la résolution

Template de notification parties prenantes

Subject: [P0/P1] [Service] - [Brief impact description]

Severity: P[0-3]
Start time: [ISO 8601 timestamp]
Impact: [Who is affected and how]
Current status: [What we know]
Actions taken: [What we've done so far]
ETA: [If known, otherwise "investigating"]
Next update: [When]
Incident commander: [Name]
War room: [Link/channel]

Règles de communication interne

1. Une source de vérité : tous les updates passent par le canal incident, pas par DM
2. Faits, pas spéculation : partagez ce que vous savez, signalez ce que vous suspectez
3. Timestamp partout : chaque action et observation reçoit un timestamp
4. Pas de blâme : concentrez-vous sur ce qui s est passé, pas sur qui l a causé
5. Handoffs clairs : lors d une rotation, transmettez explicitement le contexte

Chemins d escalade

Déclencheurs d escalade

Checklist d escalade

• Astreinte primaire pagée et acquittée
• Si pas d acquittement en 5 min, astreinte secondaire pagée
• Incident commander assigné
• Leads d équipes pertinents notifiés
• Page de statut mise à jour
• Support client briefé avec talking points
• Parties prenantes exécutives notifiées (P0/P1 seulement)

Responsabilités d astreinte

Pendant l incident :

• Acquitter le page sous 5 minutes
• Évaluer la sévérité et ouvrir le canal incident
• Démarrer l investigation et documenter les découvertes en temps réel
• Coordonner avec les autres équipes si nécessaire
• Fournir les updates de statut à la cadence requise

Après l incident :

• S assurer que le monitoring confirme la résolution
• Rédiger la timeline incident
• Planifier le postmortem si requis
• Mettre à jour les runbooks avec les nouveaux apprentissages
• Transmettre à la prochaine astreinte si le shift finit pendant l incident