📖 Manuel

Guide de Post-Mortem d'Incident

Workflow

1. Documenter : capturer la timeline complète de l'incident.
2. Analyser : identifier les causes racines (pas les symptômes).
3. Proposer : actions correctives concrètes et mesurables.
4. Partager : communication blameless à l'équipe.

Template de post-mortem

# Post-Mortem : [Titre de l'incident]

**Date** : YYYY-MM-DD
**Durée** : HH:MM (de détection à résolution)
**Sévérité** : SEV1 / SEV2 / SEV3
**Auteur** : [Nom]
**Révisé par** : [Nom(s)]

## Résumé

[2-3 phrases décrivant l'incident, son impact et sa résolution]

## Impact

| Métrique | Valeur |
|----------|--------|
| Utilisateurs impactés | X |
| Durée d'indisponibilité | HH:MM |
| Transactions perdues | X |
| Revenu impacté | X € |
| SLA impacté | Oui/Non |

## Timeline

| Heure (UTC) | Événement |
|-------------|-----------|
| 14:00 | Déploiement de la version 2.3.1 en production |
| 14:15 | Première alerte Prometheus : taux d'erreur > 5% |
| 14:18 | L'équipe on-call est notifiée |
| 14:25 | Diagnostic : connexions DB saturées |
| 14:30 | Décision de rollback vers v2.3.0 |
| 14:35 | Rollback effectué, taux d'erreur en baisse |
| 14:45 | Retour à la normale confirmé |

## Causes racines

### Cause immédiate
[Ce qui a directement causé l'incident]

### Causes sous-jacentes (5 Whys)
1. **Pourquoi** le service a crashé ? → Pool de connexions DB saturé
2. **Pourquoi** le pool était saturé ? → Nouvelle requête sans pagination
3. **Pourquoi** la requête n'avait pas de pagination ? → Pas de review perf
4. **Pourquoi** pas de review perf ? → Pas dans la checklist de PR
5. **Pourquoi** pas dans la checklist ? → Jamais formalisé comme exigence

### Facteurs contributifs
- [Facteur 1 : absence de monitoring sur la taille du pool]
- [Facteur 2 : pas de load test avant déploiement]

## Ce qui a bien fonctionné
- Alerte Prometheus déclenchée en 15 minutes
- Procédure de rollback fonctionnelle et rapide
- Communication claire dans le canal #incidents

## Ce qui peut être amélioré
- Délai de 7 minutes entre l'alerte et la notification on-call
- Pas de runbook pour ce type d'incident
- Load tests non automatisés dans la CI

## Actions correctives

| # | Action | Priorité | Responsable | Deadline | Ticket |
|---|--------|----------|-------------|----------|--------|
| 1 | Ajouter une alerte sur la taille du pool de connexions | P1 | @ops | J+3 | #456 |
| 2 | Ajouter la review perf dans la checklist PR | P1 | @lead | J+5 | #457 |
| 3 | Implémenter la pagination sur toutes les requêtes list | P2 | @dev | J+10 | #458 |
| 4 | Créer un runbook pour les incidents DB | P2 | @ops | J+14 | #459 |
| 5 | Automatiser les load tests dans la CI | P3 | @devops | J+30 | #460 |

## Leçons apprises
- [Leçon clé que l'équipe retient de cet incident]

Méthodologie des 5 Whys

Technique pour remonter des symptômes à la cause racine en posant "Pourquoi ?" de manière itérative. S'arrêter quand on atteint une cause systémique (processus, outil, culture) plutôt qu'une erreur humaine.

Niveaux de sévérité

Principes du blameless postmortem

• Se concentrer sur les systèmes et processus, pas sur les personnes
• Chaque erreur humaine est un symptôme d'un problème systémique
• L'objectif est d'apprendre, pas de punir
• Documenter les faits, pas les jugements
• Les actions correctives doivent être mesurables et assignées

Règles

• Un post-mortem doit être rédigé dans les 48 heures suivant la résolution.
• Chaque action corrective doit avoir un responsable, une deadline et un ticket.
• Le post-mortem est blameless — pas de mise en cause individuelle.
• Les causes racines doivent être systémiques, pas "erreur humaine".
• Le post-mortem doit être partagé avec toute l'équipe.