Apprendre de ses incidents grâce au post-mortem

Pourquoi écrire un post-mortem ?

Le post-mortem à plusieurs objectifs :

• Prendre du recul : Tout d’abord il nous permet de comprendre comment est arrivé un incident en creusant toutes les causes possibles.
• Donner de la visibilité : Ensuite, il nous permet, en tant qu’infogéreur, de communiquer avec nos clients afin d’expliquer comment nous avons réagi au moment de l’incident et comment nous nous assurons que l’incident ne se reproduise plus.
• Améliorer la qualité : Enfin, grâce aux actions que nous prenons lors du post-mortem, nous nous assurons d’améliorer nos infrastructures ou nos process.

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.

Étape 1 : le problème

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.

Étape 2 : les impacts

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 :

• Prioriser : En comprenant les impacts, nous pouvons évaluer l'urgence et l'importance de l'incident par rapport à d'autres priorités. Cela peut influencer la manière dont nous allouons des ressources pour résoudre l'incident.
• Communiquer : En tant qu’infogéreur, la communication est cruciale lors de la gestion d'incidents. En énumérant les impacts, nous pouvons expliquer au mieux aux parties prenantes les conséquences réelles de l'incident. Cela contribue à une communication transparente et à une gestion de crise efficace. Enfin cela permet aussi de mettre du rationnel sur une situation fortement émotionnelle.

Étape 3 : la situation

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.

Étape 4 : les causes

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.

Étape 5 : les actions

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.

Étape 6 : les apprentissages

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.

Conclusion

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.