Un postmortem décrit ce qui s’est passé, l’impact observé et les actions à mener après un incident. Il doit aider l’équipe à améliorer ses systèmes et ses décisions. Une méthode factuelle donne de meilleurs résultats qu’une recherche individuelle de responsabilité.
Établir une chronologie vérifiable
Commencez par les événements observables : première alerte, premier signal utilisateur, changement récent, décision de mitigation et retour à un niveau normal. Ajoutez les heures et les sources, en distinguant l’heure du système de l’heure locale si plusieurs équipes interviennent.
Évitez de présenter une hypothèse comme un fait. Les journaux, traces, tickets et messages peuvent diverger. Notez ce qui a été confirmé, ce qui reste incertain et la donnée qui permettrait de trancher. Une chronologie courte et précise vaut mieux qu’un récit rempli de suppositions.
Mesurer l’impact pour l’activité
Indiquez les fonctionnalités touchées, la période, les utilisateurs concernés et les opérations échouées ou retardées. Lorsque les chiffres exacts ne sont pas disponibles, écrivez la limite de la mesure au lieu d’en inventer une. Reliez l’impact technique au processus métier, par exemple une commande impossible à valider ou un document produit avec retard.
L’impact peut continuer après le rétablissement du service. Des messages restés en file, des doublons ou des comptes partiellement mis à jour demandent une vérification séparée. Décrivez les contrôles réalisés et ceux qui restent à faire.
Décrire les décisions prises
Pour chaque action, notez le signal qui l’a déclenchée, la personne qui l’a exécutée et le résultat. Une décision prise avec des informations incomplètes peut être raisonnable au moment de l’incident. Le postmortem doit montrer l’information disponible, puis identifier celle qui manquait.
Documentez les options écartées lorsque cela aide une future permanence. Si l’équipe a désactivé une fonctionnalité pour réduire la charge, précisez les utilisateurs touchés et la procédure de réactivation. Les commandes importantes doivent rester accessibles dans une procédure contrôlée, avec les conditions d’usage.
Chercher les conditions qui ont permis l’incident
Une cause technique ne suffit pas toujours à expliquer pourquoi l’incident a duré. Examinez la détection, les alertes, les permissions, la documentation, la capacité de retour arrière et la communication. Plusieurs conditions peuvent avoir contribué à la même panne.
Utilisez des formulations qui décrivent le système : une alerte ne mentionnait pas la file concernée, une migration n’avait pas de restauration testée, ou une permission empêchait l’accès au journal. Cette forme aide à choisir une action mesurable et évite de résumer le problème par une erreur humaine.
Transformer les constats en actions
Chaque action doit avoir un responsable, une échéance réaliste et un résultat vérifiable. Une action comme « améliorer la supervision » ne permet pas de savoir quand elle est terminée. Écrivez plutôt « ajouter un indicateur de l’âge du message et tester l’alerte sur un environnement isolé ».
Limitez le nombre d’actions immédiates aux risques les plus importants. Classez ensuite les améliorations par effort et par effet attendu. Certaines peuvent être réalisées dans le code, d’autres dans le pipeline, la formation ou la procédure de support.
Partager le document
Les personnes qui ont géré l’incident relisent la chronologie avant diffusion. Donnez aux équipes produit et support les informations dont elles ont besoin pour répondre aux utilisateurs. Retirez les secrets et les données personnelles des captures et des journaux annexés.
Revenez sur les actions lors d’une réunion courte. Fermez une action seulement après un contrôle, un test ou une modification visible. Le guide de documentation d’incident pour PME peut servir de modèle, et notre accompagnement DevOps au Maroc couvre la mise en place des procédures d’exploitation.
Sources : Google SRE, postmortem culture, Atlassian, incident postmortems.