Le post-mortem à plusieurs objectifs :
C’est donc un document important que nous nous efforçons d’écrire au mieux. Mais alors comment écrire un bon post-mortem ?
Il n’y a pas de réponse magique avec un processus d’écriture commun à tous. Chaque entreprise à son approche différente sur l’écriture d’un post-mortem et je vais vous présenter comment, nous, chez Padok, nous rédigeons nos post-mortem.
Le premier pas pour rédiger un bon post-mortem est d'identifier clairement l'incident en question. Décrivez l'incident de manière concise, en incluant les détails tels que la date, l'heure, la durée et les personnes impliquées.
Il est important de déterminer l'impact de l'incident. En effet l’identification des impacts sur l'entreprise, les clients et les équipes, permet de :
Afin de comprendre au mieux ce qu’il s’est passé lors d’un incident il faut retracer les événements. N’hésitez pas à utiliser des données, des logs, des captures d’écran, etc… afin de rendre la situation la plus factuel possible.
N’oubliez pas de mettre les évènements dans l’ordre chronologique et d’ajouter la date et heure précise de l’évènement. Il n’est pas question de désigner ici un coupable ou de dénoncer quelqu’un/une équipe. L’objectif est d’écrire de manière factuelle les évènements.
Après avoir décrit la situation, il est important de comprendre les causes de l'incident. Il peut y avoir plusieurs causes, et il est nécessaire de les identifier toutes afin d’éviter que l'incident ne se reproduise.
Pour identifier une cause, nous utilisons la méthode des 5 pourquoi. Pourquoi cela s'est-il produit ? En faisant ça de manière répétée, on atteint la root cause. Celle-ci est la dernière cause sur laquelle nous nous arrêtons. Une bonne root cause est une cause qui nous apprend quelque chose.
Par exemple, si l'incident est une panne de serveur, on peut commencer par se demander "Pourquoi le serveur a-t-il planté ?" puis continuer à poser des questions jusqu'à ce que nous arrivions à la cause sous-jacente.
Nous détaillons ici toutes les modifications faites pendant la résolution de l’incident, qui sont donc des actions court terme. Puis nous nous posons la question des actions long terme à mettre en place afin de pérenniser nos changements. Maintenant que nous avons compris d’où venait l’incident, nous voulons éviter que cela se reproduise.
Une bonne action se compose d’un owner et une deadline. Grâce à ça, on doit pouvoir identifier rapidement si l’action a bien été prise.
Enfin, chaque incident est source d’apprentissage et il est important de capitaliser dessus. En tant qu’infogéreur, nous maintenons au quotidien des dizaines d’infrastructures différentes. Grâce aux post-mortem nous apprenons des différents incidents et nous sommes force de proposition pour améliorer vos infrastructures et assurer le maintien en condition opérationnel.
Comme je le disais en introduction, le processus d’écriture d’un post-mortem est spécifique à l’entreprise. Vous pouvez vous inspirer de ce que je viens de vous présenter, de la culture du post-mortem de Google ou encore aller voir directement des post-mortems d’entreprise tel que Datadog.
Enfin si vous souhaitez nous faire confiance pour maintenir votre infrastructure, n’hésitez pas à venir voir nos offres ou contactez-nous directement.