Qu'est-ce qui rend un post mortem sans blâme, et que doit-il contenir ?

Sans blâme veut dire que le compte rendu demande comment le système a permis à une personne raisonnable de faire ce geste, pas qui a cassé quoi. Incluez une chronologie, l'impact utilisateur quantifié face au SLO, les facteurs contributifs, ce qui a bien marché, et des actions avec des responsables nommés et des échéances. Bannissez les contrefactuels du type aurait dû savoir. Le vrai test, c'est de savoir si les actions sont réellement menées à bien, donc suivez-les comme n'importe quel autre travail.

Le sans blâme, ce n'est pas être gentil, c'est obtenir la vérité. Si les gens s'attendent à être punis, vous récupérez des chronologies aseptisées et vous n'apprenez jamais ce qui s'est vraiment passé, donc l'incident suivant est identique. Concrètement, je veux une chronologie horodatée, un impact quantifié (on a consommé 60% du budget d'erreur mensuel et 12 000 paiements ont échoué), des facteurs contributifs plutôt qu'une cause racine unique, et une section sur ce qui a bien marché, que les gens sautent et qui est pourtant la façon de découvrir que le runbook ou l'outillage de retour arrière vous a sauvés. Les actions ont besoin d'un responsable et d'une date, et elles partent dans le backlog normal avec une vraie priorité, sinon vous avez écrit un joli document qui ne change rien. La règle de langage que j'impose, c'est zéro contrefactuel : pas l'ingénieur aurait dû remarquer, mais l'outil de déploiement a laissé partir un changement sans canary et sans confirmation. Ce recadrage produit presque toujours un meilleur correctif qu'un rappel de formation.