Un postmortem est facile à organiser et difficile à rendre utile. La réunion a lieu, un document est rédigé, quatre actions sont consignées, et six mois plus tard la même panne se reproduit pendant que quelqu’un retrouve l’ancien document en cherchant autre chose.

Le mot sans blâme concentre l’essentiel de l’attention dans ces discussions, et il compte réellement, mais ce n’est pas là que se situe l’échec. Beaucoup d’organisations mènent des revues scrupuleusement sans blâme qui ne changent rien, parce que la revue a été traitée comme le livrable au lieu d’être ce qui produit un livrable.

Le test qui dit si les vôtres fonctionnent est d’une simplicité embarrassante: quelle proportion des actions des six derniers mois est terminée? Si la réponse est la plupart, le processus fonctionne, quelle que soit son allure. Si elle est inférieure à la moitié, vous tenez des réunions au lieu de mener un processus, et de meilleurs modèles n’y changeront rien. Moins d’actions, avec un responsable et une date, valent mieux qu’une liste exhaustive que personne n’a le temps de traiter.

À quoi sert vraiment un postmortem

Pas à expliquer ce qui s’est passé. Les personnes présentes le savent en général avant même la fin de l’incident.

Il existe pour trouver les conditions qui ont permis à un petit problème de devenir un gros problème, et pour en changer quelques-unes. C’est une autre question que celle de savoir ce qui a cassé, et la distinction saute aux yeux dès la rédaction. “La base de données n’avait plus de connexions” décrit ce qui a cassé. “Rien n’alertait sur la saturation du pool de connexions, et le tableau de bord qui l’aurait montrée ne figure pas dans le runbook d’astreinte” décrit une condition, et une condition se corrige.

La deuxième production, largement sous-estimée, est un récit partagé de l’événement. Sans lui, chacun garde sa propre version, et ces versions dérivent vers ce que chaque personne croyait déjà du système. Un an plus tard, deux équipes se disputent sur un incident qu’elles ont pourtant vécu ensemble.

Sans blâme veut dire quelque chose de précis

Cela ne veut pas dire que personne n’a commis d’erreur. Cela veut dire que l’analyse part du principe qu’une personne agissant raisonnablement avec les informations disponibles a pris une décision qui s’est révélée mauvaise, et qu’elle cherche pourquoi cette décision paraissait correcte sur le moment. Le livre SRE de Google expose cette pratique ainsi que les modes d’échec qui l’accompagnent.

Si ce n’est pas seulement de la bienveillance, c’est parce que le blâme détruit l’information. Dans une organisation où les incidents restent attachés à des individus, les gens décrivent les événements avec précaution, omettent le détail qui les met en difficulté, et retardent le signalement jusqu’à comprendre assez bien pour se présenter sans risque. La revue travaille alors sur un récit retouché par instinct de protection, ce qui est la pire entrée possible.

En pratique, sans blâme est une propriété du langage. “Pourquoi as-tu redémarré le service?” appelle une défense. “Qu’affichait le tableau de bord au moment où tu as décidé de redémarrer?” appelle de l’information. La seconde question est aussi la plus utile, car la réponse est un fait sur votre supervision et non sur un collègue.

S’il existe un vrai problème de performance individuelle, traitez-le séparément et directement. Le faire pendant la revue d’incident corrompt la revue, et c’est de toute façon une mauvaise manière de mener cette conversation.

Construire une chronologie qui apprend quelque chose

La chronologie est la partie la plus précieuse du document et celle qui est le plus souvent mal écrite, sous la forme d’une suite d’événements techniques dont les humains ont disparu.

Notez ce que les gens savaient et à quel moment. Pas seulement “le service a été redémarré à 14:32”, mais ce que la personne pouvait voir à 14:32 et ce qu’elle croyait alors être en train de se produire. C’est là que se trouve la matière exploitable, car un retard de quinze minutes causé par un tableau de bord ambigu est un problème réparable, alors qu’un retard de quinze minutes consigné comme un trou ne l’est pas.

Marquez les moments qui ont compté: le début, le premier constat par qui que ce soit, l’arrivée de la bonne personne, la compréhension de la cause, l’atténuation, la résolution. Les écarts entre ces moments sont l’endroit où vit l’amélioration, et le délai de détection est très souvent le plus grand d’entre eux.

Rédigez la chronologie tant que tout est frais, idéalement dans les un ou deux jours. Le souvenir de ce que quelqu’un croyait à un instant donné s’efface bien plus vite que le souvenir de ce qui s’est produit.

Il y a rarement une cause racine unique

L’expression pousse à s’arrêter à la première explication plausible, alors que les incidents, quelle que soit leur taille, sont des chaînes où plusieurs conditions devaient tenir en même temps.

Une revue utile liste plutôt des facteurs contributifs: le changement qui a déclenché la panne, le test qui l’aurait attrapée et qui n’existait pas, l’alerte partie vers un canal que personne ne regarde, le runbook exact pour une architecture précédente. Chacun est une occasion distincte, et vous pouvez corriger les deux moins chers plutôt que celui qui se trouvait en tête de chaîne.

Cela réduit aussi une distorsion courante. Quand une revue nomme une cause racine unique, cette cause est très souvent “l’erreur humaine”, qui est une description et non une explication, et qui referme l’enquête exactement là où elle aurait dû commencer.

Faire aboutir le suivi

C’est ici que les postmortems vivent ou meurent, et les remèdes n’ont rien de glorieux.

Moins d’actions. Deux qui aboutissent valent mieux que huit qui n’aboutissent pas. Classez-les selon qu’elles réduisent le délai de détection, le rayon d’impact ou la probabilité, et coupez le reste.

Un responsable nommé et une date, dans votre outil de suivi habituel plutôt que dans le document. Les actions qui ne vivent que dans le postmortem sont invisibles pendant la planification, c’est-à-dire au moment où le travail est réellement programmé.

Revoyez les actions ouvertes au postmortem suivant. Cette seule habitude fait plus que n’importe quel modèle. Elle rend l’inachevé visible et transforme une série de réunions sans lien en un processus.

Assumez honnêtement certaines actions. Une équipe qui termine la moitié de ce qu’elle promet devrait promettre moitié moins. Consigner une intention que personne ne financera est pire que consigner une décision de ne rien faire, car la seconde est au moins vraie.

Les améliorations qui en sortent relèvent de la même famille que notre guide de reprise après sinistre et nos stratégies de tests logiciels: détection plus rapide, rayon d’impact réduit, système exploitable par quelqu’un d’autre.

Mecanik mène des revues d’incident sur les systèmes que nous maintenons, dans le cadre de notre analyse de sécurité serveur. Le schéma revient presque toujours: la cause technique a été comprise vite, et le délai de détection a coûté cher.

Questions fréquentes

À quoi sert un postmortem? À trouver les conditions qui ont permis à un petit problème de devenir un gros problème et à en changer quelques-unes, ce qui est une autre question que celle de savoir ce qui a cassé. Il produit aussi un récit partagé de l’événement, faute de quoi chacun garde une version privée qui dérive vers ce qu’il croyait déjà du système.

Que veut dire sans blâme, concrètement? Que l’analyse part du principe qu’une personne agissant raisonnablement avec les informations disponibles a pris une décision qui s’est révélée mauvaise, et qu’elle cherche pourquoi elle paraissait correcte sur le moment. Cela compte parce que le blâme détruit l’information: les gens retouchent leur récit par protection, et la revue travaille alors sur une entrée corrompue.

Un postmortem doit-il désigner une cause racine unique? Non. Les incidents, quelle que soit leur taille, sont des chaînes où plusieurs conditions devaient tenir en même temps, donc lister les facteurs contributifs est plus utile. Cela permet de corriger les deux moins chers plutôt que le premier de la chaîne, et d’éviter de conclure par “erreur humaine”, qui est une description et non une explication.

Que doit contenir une chronologie d’incident? Ce que les gens savaient et quand, pas seulement ce qu’ont fait les systèmes. Notez le début, le premier constat, l’arrivée de la bonne personne, la compréhension de la cause, l’atténuation et la résolution. Les écarts entre ces moments sont l’endroit où vit l’amélioration, et le délai de détection est en général le plus grand.

Pourquoi les actions de postmortem ne sont-elles jamais faites? Parce qu’elles vivent dans le document plutôt que dans l’outil de suivi, donc elles sont invisibles quand le travail est programmé. Corrigez cela avec moins d’actions, un responsable nommé et une date dans l’outil habituel, et une revue des actions ouvertes au début du postmortem suivant, qui rend l’inachevé visible.