4 min lecture • Guide 723 of 877
Analyse Post-Mortem pour Équipes de Développement
Les incidents sont inévitables - échouer à en tirer des leçons ne l'est pas. GitScrum aide les équipes à documenter, analyser et suivre les résultats des post-mortems pour construire des systèmes et processus plus résilients.
Principes du Post-Mortem
Culture Sans Blâme
CULTURE BLÂME VS SANS BLÂME:
┌─────────────────────────────────────────────────────────────┐
│ │
│ CULTURE DU BLÂME: │
│ │
│ "Qui a poussé le mauvais code ?" │
│ "Pourquoi n'as-tu pas testé ça ?" │
│ "C'est ta responsabilité" │
│ │
│ RÉSULTAT: │
│ • Les gens cachent les erreurs │
│ • Les incidents ne sont pas rapportés │
│ • Les causes profondes restent cachées │
│ • Les problèmes se répètent │
│ • Culture de la peur │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ CULTURE SANS BLÂME: │
│ │
│ "Qu'est-ce qui dans notre système a permis cela ?" │
│ "Comment rendre la bonne chose facile à faire ?" │
│ "Qu'avons-nous appris ?" │
│ │
│ RÉSULTAT: │
│ • Les incidents sont rapportés tôt │
│ • Les vraies causes profondes sont trouvées │
│ • Les systèmes s'améliorent │
│ • Les problèmes ne se répètent pas │
│ • Culture d'apprentissage │
│ │
│ INSIGHT CLÉ: │
│ "La personne qui a fait l''erreur' est souvent celle │
│ la plus proche du problème et la mieux placée pour │
│ le corriger." │
└─────────────────────────────────────────────────────────────┘
Quand Mener des Post-Mortems
DÉCLENCHEURS POST-MORTEM:
┌─────────────────────────────────────────────────────────────┐
│ │
│ ABSOLUMENT POST-MORTEM: │
│ • Panne de production │
│ • Perte de données ou brèche │
│ • Impact utilisateur significatif │
│ • SLA manqué │
│ • Incident de sécurité │
│ │
│ CONSIDÉRER POST-MORTEM: │
│ • Quasi-accident (presque eu incident) │
│ • Incident mineur avec valeur d'apprentissage │
│ • Échec de processus │
│ • Deadline significativement manquée │
│ │
│ REVUE LÉGÈRE: │
│ • Bug qui a atteint production │
│ • Petits problèmes de processus │
│ • Opportunité d'apprentissage │
│ │
│ DÉFINITIONS DE SÉVÉRITÉ: │
│ │
│ SEV-1: Critique - Post-mortem complet requis │
│ Système down, perte données, impact majeur │
│ │
│ SEV-2: Majeur - Post-mortem recommandé │
│ Panne partielle, impact utilisateur significatif │
│ │
│ SEV-3: Mineur - Revue brève │
│ Petit impact, récupération rapide │
│ │
│ SEV-4: Bas - Optionnel │
│ Impact minimal, principalement interne │
└─────────────────────────────────────────────────────────────┘
Processus Post-Mortem
Chronologie
CHRONOLOGIE POST-MORTEM:
┌─────────────────────────────────────────────────────────────┐
│ │
│ INCIDENT │
│ │ │
│ ▼ │
│ RÉPONDRE (Minutes à Heures) │
│ • Atténuer l'impact │
│ • Communiquer le statut │
│ • Documenter au fur et à mesure │
│ │ │
│ ▼ │
│ RÉSOUDRE (Heures à Jours) │
│ • Corriger le problème immédiat │
│ • Vérifier la résolution │
│ • Déclarer incident clos │
│ │ │
│ ▼ │
│ PÉRIODE DE RECUL (1-3 Jours) │
│ • Laisser les émotions retomber │
│ • Rassembler données et logs │
│ • Rédiger chronologie │
│ │ │
│ ▼ │
│ POST-MORTEM (Jour 3-5) │
│ • Réunion d'équipe │
│ • Analyse des causes profondes │
│ • Définir items d'action │
└─────────────────────────────────────────────────────────────┘