Un post-mortem intervient en général, comme son nom l’indique, après un incident, qu’il s’agisse d’une indisponibilité de service ou de l'échec d’une opération planifiée par exemple. Le post-mortem est une pratique qui a pour but de vous aider à apprendre de vos erreurs dans une optique d’amélioration continue.
Au cours d’un post-mortem, il est important d’analyser en profondeur les événements et de mettre en place des échanges neutres, sans pointer du doigt d’éventuels coupables. Il est aussi primordial de rédiger le document au plus tôt après la résolution de l’incident, voire pendant pour certaines parties. Il est vivement conseillé de collecter les données factuelles pendant les investigations et sa résolution. Au moment de la rédaction, vous devez essayer de rester clair, concis et donner des descriptions détaillées sur ce qui s’est réellement passé.
Un post-mortem vient apporter une conclusion après la résolution d’un incident. Une personne désignée est en général porteuse du document mais toutes les personnes impliquées doivent contribuer à sa rédaction. L’écriture d’un post-mortem est un travail collaboratif. La désignation d’une personne chargée de la rédaction ne doit pas être vécue comme une punition. Il s’agit d’une bonne pratique à adopter pour les travaux de groupe afin d’éviter l’effet spectateur et obtenir une meilleure coordination des personnes qui auront à intervenir. Il est par contre important que cette personne ait été confrontée à la gestion de l’incident d’au moins une des manières suivantes :
Le document de post-mortem doit être exhaustif et facile à relire. En général, pour chaque revue de post-mortem, les équipes se basent sur un modèle prédéfini permettant de cadrer le contenu et de s’assurer qu’aucun détail important n’est oublié.
Vous trouverez ci-dessous un exemple de modèle de post-mortem que vous pourrez modifier à votre guise selon les besoins de votre équipe. Le modèle est assez exhaustif, certaines sections ne seront peut être pas adaptées à votre contexte. Je l’illustrerai ensuite avec un cas concret de son utilisation.
Faites un résumé en quelques mots à propos de l’incident dans lequel vous devez essayer de faire ressortir les informations suivantes :
Apportez dans cette section une description de la problématique ainsi que d’éventuels changements qui ont conduit à ce comportement inattendu. Dans cette partie, vous pouvez également fournir des captures d’écran ou des extraits de code, de logs ou tout élément permettant une meilleure illustration.
Donnez une description de l’impact côté client final ou utilisateurs. Mentionnez les différents cas qui ont été remontés par les clients à l’équipe support si tel est le cas.
N.B: Les impacts financiers ou sur la réputation peuvent aussi faire partie de cette section.
Évoquez comment l’incident a été détecté par l’équipe chargée de la plateforme. Précisez comment l’équipe a pu confirmer qu’il y a réellement un incident.
Citez les différentes équipes (en cas d’escalade) qui ont pris en charge l’incident et, sans entrer dans les détails, expliquez les actions qui ont été effectuées dans le but de rétablir le service.
Décrivez en détails la chronologie des événements en essayant d’indiquer le plus précisément possible (en format ISO 8601), à quel moment et dans quel ordre ils se sont déroulés.
Tips: Lors de la gestion d’un incident, la personne qui endosse le rôle de coordinateur (“Incident Manager”) peut souvent prendre le temps de remplir cette chronologie “à la volée”. Les avantages sont divers : les horaires de la chronologie sont faciles à déterminer et cela évite de perdre du temps à se rappeler des différents événements et enchaînements plus tard. De plus, le document avec cette chronologie en cours de construction peut être partagé pendant la gestion. D’autres participants peuvent y contribuer librement (ajout d’une ligne de commande utile à la résolution ou sortie de commande / entrées de journaux…). Cela permet de faire entrer rapidement un nouvel acteur sur la gestion de l’incident en cours puisque le détail du contexte et des actions déjà effectuées y figurent.
Dans cette partie, vous pouvez utiliser la méthode classique des Cinq Pourquoi afin d’analyser en profondeur ce qui est à la racine du problème. L’objectif est de trouver comment cela aurait pu être évité. Il faut donc questionner l’origine des actions et ce qui a amené à ce que cela ne se passe pas comme prévu.
Ci-dessous, voici un exemple de la façon dont vous pouvez l’utiliser :
Cependant, cette méthode a tendance à vous faire vous focaliser sur une root cause unique, ce qui n’est pas toujours le cas. Pensez à explorer plusieurs causes quand les incidents sont le résultat concomitant de plusieurs événements. Si cette méthode ne vous donne pas satisfaction, essayez de séparer les causes et éléments contributeurs des événements, des éléments qui ont fait barrage au bon déroulement des opérations.
Dans cette étape, prenez le temps d’expliquer la ou les opérations qui étaient en cours et pourquoi elles n’ont pas pu aboutir en reprenant la ou les root causes identifiées.
Indiquez si l’incident a pu être reproduit dans un environnement de test.
Passez en revue votre backlog pour voir s’il n’y avait pas déjà des actions de prévues qui auraient pu éviter l’incident.
Si tel est le cas, vous devez vous demander pourquoi cela n’a pas été réalisé plus tôt.
Si non, vous devrez mettre en place cette procédure afin d’éviter qu’un tel incident ne se reproduise dans le futur (voir la section 12).
Prenez du recul sur l’incident pour voir s’il peut être relié à des incidents dans le passé, si des incidents similaires avec une même root cause identique ont eu lieu. Essayez de comprendre ce qui a permis à ces incidents de se produire à nouveau.
Dans cette partie très importante, revenez sur les réponses qui ont été apportées à l’incident. Identifiez les bonnes actions, celles qui vous ont ralenti, comment la communication s’est mise en place. S’il y a des axes d’améliorations, profitez-en pour perfectionner votre manière de répondre aux incidents.
Mentionnez ici les actions correctives orchestrées dans le but de corriger et de prévenir un tel incident dans le futur. Si l’incident n’a pas été détecté par les outils de monitoring en place, il faut aussi mentionner comment l’équipe pourrait améliorer l’observabilité pour être en mesure de détecter et d’être alerté de ce type de problème. Des solutions d'auto remédiation peuvent également faire partie des bonnes pratiques d’amélioration quand cela est possible. La résilience du produit doit toujours rester une priorité dans les évolutions apportées.
Tips : Cette partie est souvent remplie à la fin du post-mortem une fois l’incident clos de manière collégiale par l’ensemble des acteurs clés relatifs à l’incident et peut avoir lieu pendant une rencontre entre ces acteurs visant à clore le post-mortem (30 minutes suffisent si la plupart des champs tels que la chronologie ont été remplis en amont). L’avantage d’une telle rencontre est de susciter le brainstorming et travailler en intelligence collective.
Imaginons un éditeur de logiciel qui propose à ses clients une solution SaaS, dans laquelle des utilisateurs peuvent stocker leurs données de santé qui pourront être partagées à des médecins. La solution est déployée sur des clusters Kubernetes On-premise. Le cluster de production est résilient : 3 Master nodes et 5 Worker nodes. La chaîne CICD est opérationnelle et le déploiement de l’application est assuré avec FLUX CD. Des releases de la solution sont livrées 2 ou 3 fois par semaine. Une opération est programmée pour la livraison d’une nouvelle version de l’application dans le but de fixer un bug. L’opération est planifiée en heures ouvrées et l’équipe de Devs est totalement autonome. La nouvelle version est déployée sur la prod mais le dashboard de monitoring côté application signale des pods en CrashLoopBackOff sur le node-prod-01. Le rolling update n’a pas pu aboutir.
Le 16-08-2022 entre 3:30 pm UTC+1 et 4:45 pm UTC+1, l’équipe de DEVs a rencontré des soucis lors de la livraison d’une nouvelle version de l’application. Le déploiement a été effectué avec Flux CD mais le rolling update des pods n’a pas pu aboutir. Il y avait des pods sur le noeud node-prod-01 qui étaient en “CrashLoopBackOff” .
Cet incident a impacté 1/3 des fonctionnalités durant la période.
L’événement a été déclenché suite à une opération de livraison d'une nouvelle version de l’application sur notre cluster en On-premise hébergé dans notre datacenter en Europe qui a débuté à 3:30 pm UTC+1.
L’incident est survenu lors d’une livraison en production sur notre cluster de Kubernetes On-Premise. L’application a été livrée en production avec Flux CD mais le rolling update n’a pas pu aboutir dès le premier nœud. Les pods sur les nœuds node-prod-02 et node-prod-03 étaient toujours en running mais sur l’ancienne version de l’application. Les images embarquées dans les pods sont très lourdes. Lors du rolling update, sur le noeud node-prod-01, il n’y avait plus beaucoup d’espace disque. Le pull de la nouvelle image a échoué faute d’espace, d’où la raison de l’affichage du message d’erreur: “CrashLoopBackOff”. Cela a pu occasionner des latences au niveau applicatif. La procédure est manuelle donc nous n’avions pas pu le détecter sur les autres environnements.
Plusieurs clients ont rapporté des lenteurs et des crash lors des phases de logging puis de consultation de leurs dossiers de santé. Cet incident a impacté 40% des utilisateurs de la solution durant l’incident.
L’incident au niveau applicatif a pu être détecté par nos outils de supervision auxquels les équipes de Devs ont accès pour monitorer les différents composants applicatifs. Cependant la vraie raison n’a pas été détectée par nos outils de supervision car il n’y avait pas de monitoring en place. Il a été remonté par des membres de l’équipe de DEVs à la suite des plaintes des clients et également des alertes niveau applicatifs.
Les investigations à propos de l’incident ont débuté à 4:10 pm UTC+1 du côté de l’équipe OPS. Nous avons remarqué que le rolling update n’aboutissait pas. Nous avons opéré une purge des images sur les 3 nœuds afin qu’il puisse se réaliser correctement. L’incident a été résolu à 4:45 pm UTC+1.
L’incident est survenu le 16-08-2022 à 3:30 pm UTC+1
L’équipe de Devs en charge de la solution a reçu plusieurs plaintes clients,
Parce-qu’ils n’étaient pas en mesure de se logger pour aller consulter leur dossier de santé,
Parce que sur le nœud node-prod-01 les pods n’étaient pas disponibles et étaient en CrashLoopBackOff,
Parce que les pods ne pouvaient pas aller faire le pull de la nouvelle version de l’image embarquée,
Parce qu’il n’y avait plus d’espace disque sur le nœud node-prod-01 et que le pull de nouvelles images n’étaient plus possible.
En réalisant une livraison de la nouvelle version de la solution sur le cluster Kubernetes de production, l’équipe de DEVs a fait une MR pour apporter les modifications nécessaires afin de déclencher le rolling update des pods.
Le rolling update a échoué et la nouvelle version de la solution n’a pas pu être livrée. Les pods sur le noeud node-prod-01 n'étaient plus disponibles et étaient en CrashLoopBackOff.
Les images Docker embarquées dans les pods sont très lourdes et elles occupent beaucoup de place en local sur les disques des nœuds.
Nous avons pu reproduire le comportement en environnement de test.
C’est la première fois que l’on fait face à ce type d’incident. On a mis en place un job de cleaning sur les nœuds afin de supprimer les images locales régulièrement pour que cet incident ne se reproduise plus dans le futur.
Nous devons améliorer notre monitoring en ajoutant des alertes sur les disques pour les nœuds de notre cluster Kubernetes.
Nous sommes en train d’étudier la migration vers le cloud afin de profiter des services Kubernetes managés de l’un des cloud providers du marché.
Nous venons d’aborder de façon synthétique ce qu’est un post-mortem. Nous pouvons affirmer qu’il s’agit d’un document essentiel au sein d’une équipe souhaitant s’améliorer de manière continue dans le but de satisfaire le client final. Cependant un post-mortem reste un document très technique et qui n’est pas destiné au client final. Contrairement au RCA (Root Cause Analysis) qui, lui, s’appuie sur le post-mortem et a pour vocation d’être moins technique car destiné aux entités Produit et de management des opérations.
Il faut aussi noter qu’il existe d’autres modèles de post-mortem (notamment celui issu de l'ouvrage Site Reliability Engineering de Google) et il est bon de l’adapter à ses propres besoins au fur et à mesure de ses expériences.