Postmortem ou comment faire d'un échec un moyen de s'améliorer

The coast of failure is education Devin Carraway (Google)

Les changements perpétuels sur l’infrastructure, les applications génèrent obligatoirement des incidents, ou des dysfonctionnements. C’est inévitable ! Comme le dirait l’agent Smith.

Quand un incident intervient, on corrige la problématique, et le service revient à la normale, that’s it ! En l’absence de postmortem, des incidents peuvent se multiplier et même générer d’autres incidents bien plus graves. Je vais détailler ici les intérêts du postmortem, comment le mettre en place dans votre entreprise efficacement.

La genèse

Est-ce le concept du SRE qui a inventé le post mortem ?

Non, évidemment que non. Que ce soit dans les industries, le médical, ou la tech il y a toujours eu des post mortems. On n’appelait pas forcément ces documents ainsi, mais ils existaient bel et bien, le sens profond de ces documents était de faire état de ce que l’on voyait, et les actions entreprises pour améliorer la situation principalement.

Je me souviens avoir crée mes premiers “comptes rendu d’incident” lorsque je faisais partie d’une équipe d’exploitation dans un centre de service, à mon début de carrière, il y a de ça 10 ans.

Cette pratique n’est pas nouvelle, mais Google a su la démocratiser, l’ancrer dans son ADN.

Quand écrire un post mortem ?

Lorsqu’il y a un incident majeur en priorité, j’entend par là, un impact client (interne ou externe).

Commencer à l’écrire au plus tôt en mode brouillon, dés que l’incident se déclare.

Pourquoi écrire un post mortem ?

Bénéficier d’une chronologie de l’incident, afin d’avoir un niveau de détails permettant à tous d’en connaitre les éléments clés et la remédiation.

Les objectifs majeurs :

• Diffuser la connaissance à travers les équipes (ce qui arrive aux autres peut m’arriver)
• Auto générer une base de connaissance (en attendant de déployer un hotfix, une simple procédure peut aider à court terme)
• Améliorer la détection (sondes monitoring, test auto, unitaire, etc.)
• Participation à la diminution du MTTR
• Lister les axes d’améliorations (que cela soit en scrum / kanban, etc.) et les prioriser
• Bénéficier d’un suivi post-incident pour éviter qu’il se reproduise
• Communiquer aux clients (via une extraction de certains éléments majeurs) les raisons de l’incident
• Faire monter en compétence les SRE, car ils peuvent rejouer les incidents dans leur sandbox, et ainsi s’éviter du stress tout en apprenant à leur rythme
• Mieux identifier un incident qui pourrait être transverse

A qui sont destinés les post mortems ?

• L’équipe produit
• La squad owner du produit
• Les autres squads
• Le CTO
• Les managers

Bref, tous les acteurs du cycle de vie du produit.

Où écrire un post mortem ?

Sur un outil accessible à tous, avec des fonctionnalités collaboratives (commentaires, écriture simultanée)

Cela peut être simplement sur un document Word, Google Doc, vos Wiki d’entreprise, comme Notion, Confluence, etc.

Ou bien sur votre ITSM (GLPI, ServiceNow, Jira, etc.)

Personnellement, je préfère nettement le publier directement dans l’outil d’observabilité (Datadog, Centreon, etc.), ou le robot de gestion d’incident (OpsGenie, PagerDuty, etc.) afin de gagner un temps précieux.

Il existe également des outils entièrement dédiés aux post mortems, tels que Morgue

Modèle de post mortem

Il y a en a des dizaines sur la toile.

Voici les éléments que je considère comme indispensables.

• Date et Heure
• Nom du owner du post mortem
• Impacts sur l’application X (nom de l’application, version)
• Impacts clients (nombre de tickets support, emails, etc.)
• Détection
• Root cause
• Résolution
• Communication client (oui/non)
• Liste des story (si vous êtes en agile) ou la liste des tâches permettant d’éviter un nouvel incident

Exemple de post mortem

• Google
• Cloudflare
• Fastly
• Sentry
• Discord

Etat d’esprit

Ne blâmez pas vos collègues (ou vous même), c’est sûrement le plus important !

Incriminer ses collègues de travail pendant l’incident n’est pas constructif, étant donné que les causes sont multiples et dans la mesure où l’on souhaite avant toute chose clôturer l’incident au plus vite.

Je vous encourage à employer la CNV pour vous permettre de bien vous faire comprendre.

Cette culture du “not blame”, vient essentiellement du milieu médical et du management “positif”, pour s’autoriser le droit à l’erreur, désamorcer la situation, accepter et agir en conséquence.

Ne cherchez pas la faute, cherchez le remède. Henry Ford

Bonnes pratiques

• Lister les actions au fur et à mesure qu’elles sont réalisées en production
• Intégrer dans l’écriture de ce post mortem, tous les acteurs qui participent de près à la résolution de l’incident
• Avoir un scribe ou mieux un gestionnaire d’incident (pour les très grosses structures, surtout dans le monde ITIL, c’est courant). Ecrire et traiter un incident en simultané c’est usant, autant demander à un de vos collègues de réaliser cette tâche pour vous.
• Relire les post mortems pour éventuellement faire des ajustements et échanger avec vos pairs

Comment l’intégrer dans votre équipe ?

• Commencer petit, proposez de réaliser un post mortem pour les applications les plus critiques, celles qui ont un impact business très important.

• Proposer une co-écriture pour diminuer le stress induit

• Relire les post mortems en comité restreint et proposer des axes d’améliorations

• Promouvoir les post mortems dans vos newsletters internes, sur vos canaux de communications (Mattermost, Slack, Discord, Mail, etc.) afin d’acculturer toute l’entreprise

• Définir les rôles de chaque équipe, ce qui peut sembler simple, mais en pratique peut être problématique (enjeux politiques, organisationnels notamment)

Pourquoi et comment réexaminer vos post mortems ?

Relire les post mortems vous aide à corriger les erreurs, à préciser vos pensées ou questionnements.

Sur le comment, cela peut se réaliser lors de vos retro (Agile), ou bien lors de vos points production, comités de suivi.

D’un point de vue purement personnel, j’ai constaté qu’il était profitable de reviewer un post mortem plutôt 24/48h après l’incident, pour avoir plus de recul.

Le bon postmortem

C’est celui qui te permet en 5min :

• De comprendre la situation passée
• La root cause
• Les impacts
• La résolution
• Les actions à réaliser pour s’améliorer, avec une deadline

Le mauvais postmortem

Celui que tu mets 30min à lire :

• sans chronologie
• sans précision sur les impacts, ou bien en inversant la cause de la conséquence
• A ça on peut ajouter aussi les commentaires qui n’ont aucune réponse

Lien avec le processus de gestion des incidents

Il est évident que le post mortem est une des briques du processus de gestion des incidents. Je dirais même qu’il a un rôle central : suite à la publication de vos post mortems, s’en suivra sûrement un état des lieux de l’avancement de vos tâches d’améliorations continues (en comité, ou directement dans vos workflows agile).