Culture du post-mortem et suivi des pannes

À l'échelle et à la vitesse de changement de Google, les incidents et les pannes (outages) ne sont pas des accidents évitables : ils sont inévitables. Des systèmes distribués vastes et complexes, sans cesse enrichis de nouvelles fonctionnalités, finiront toujours par défaillir. La vraie question n'est donc pas d'éviter l'échec à tout prix, mais de s'en servir pour devenir plus robuste. Faute d'un processus formalisé d'apprentissage, un même incident peut se répéter à l'infini (ad infinitum) ; pire, des incidents peuvent se composer, gagner en complexité, voire cascader jusqu'à submerger un système et ses opérateurs. C'est pourquoi le post-mortem (postmortem) est, comme le dit le livre, « un outil essentiel pour le SRE ». Ce chapitre couvre deux pratiques jumelles : écrire de bons post-mortems sans blâme (chapitre 15), puis agréger ces pannes et ces alertes pour en dégager des tendances à l'échelle de l'organisation (chapitre 16).

Qu'est-ce qu'un post-mortem

Le concept est bien connu de l'industrie technologique. Un post-mortem est un compte rendu écrit d'un incident qui consigne : son impact, les actions prises pour l'atténuer ou le résoudre, sa ou ses causes racines (root causes), et les actions de suivi destinées à empêcher sa récurrence. Ses objectifs premiers sont au nombre de trois : garantir que l'incident est documenté, que toutes les causes contributives sont bien comprises, et — surtout — que des mesures préventives efficaces sont mises en place pour réduire la probabilité et l'impact d'une récidive.

Un point de vocabulaire mérite d'être clarifié d'emblée. Chez Google, le terme « post-mortem » désigne, contrairement à son sens littéral, non pas une autopsie morbide mais un dispositif d'apprentissage tourné vers l'avenir. Écrire un post-mortem n'est pas une punition : c'est une opportunité d'apprentissage pour toute l'entreprise. Les équipes recourent à diverses techniques d'analyse de cause racine et choisissent celle qui convient le mieux à leur service ; le détail de ces techniques dépasse le cadre du chapitre, mais l'idée force demeure : on cherche à comprendre le système, pas à instruire un procès.

Quand en écrire un : les déclencheurs

Il est capital de définir les critères avant qu'un incident ne survienne, pour que chacun sache à l'avance quand un post-mortem est nécessaire. Les équipes gardent une certaine latitude interne, mais les déclencheurs (postmortem triggers) habituels sont les suivants :

Déclencheur	Exemple typique
Indisponibilité ou dégradation visible par l'utilisateur au-delà d'un seuil	Service inaccessible plusieurs minutes ; latence hors objectif
Perte de données, de quelque nature que ce soit	Suppression, corruption, réplication divergente
Intervention d'un ingénieur d'astreinte (on-call)	Rollback d'une release, reroutage de trafic
Temps de résolution dépassant un seuil	Incident traînant au-delà de la durée convenue
Défaillance du monitoring	Incident découvert manuellement, sans alerte (implique une cécité du système)

Au-delà de ces déclencheurs objectifs, n'importe quelle partie prenante peut demander un post-mortem pour un événement donné. Cette ouverture évite que la grille de critères ne devienne un prétexte pour enterrer un incident gênant qui n'aurait pas formellement franchi un seuil.

Le post-mortem sans blâme : un pilier de la culture SRE

Le post-mortem sans blâme (blameless postmortem) est un principe fondateur de la culture SRE. Pour être véritablement sans blâme, un post-mortem doit se concentrer sur l'identification des causes contributives de l'incident sans incriminer aucun individu ni aucune équipe pour un comportement « mauvais » ou « inapproprié ». Un post-mortem rédigé sans blâme présume que toute personne impliquée avait de bonnes intentions et a fait ce qui lui semblait juste compte tenu des informations dont elle disposait.

Le raisonnement est aussi simple que puissant : si une culture de la mise en cause (finger pointing) et de l'humiliation publique s'installe — pointer du doigt, faire honte aux individus ou aux équipes pour avoir fait « la mauvaise chose » —, les gens cesseront de remonter les problèmes, par peur de la sanction. On retombe alors dans le travers décrit par d'autres ouvrages du blog (The DevOps Handbook) : les incidents balayés sous le tapis, qui exposent l'organisation à un risque bien plus grand.

Sans blâme ne veut pas dire sans franchise

Un point d'équilibre est essentiel. Le sans-blâme ne signifie pas se contenter d'évacuer la frustration ni passer les problèmes sous silence. Un bon post-mortem doit dire clairement où et comment les services peuvent être améliorés — il est exigeant, factuel, parfois inconfortable. La différence tient au registre : on parle des systèmes et des décisions, pas des personnes. Le livre illustre ce basculement par deux réactions au même problème — un backend qui casse chaque semaine depuis trois trimestres.

Réflexe du blâme (pointing fingers)	Réflexe constructif (blameless)
« Il faut réécrire tout ce backend compliqué ! Ça casse chaque semaine, on en a marre de réparer au coup par coup. Si je me fais paginer une fois de plus, je le réécris moi-même… »	« Une action de réécriture du backend pourrait réellement faire cesser ces pages pénibles ; et son manuel de maintenance est si long qu'on ne peut pas s'y former pleinement. Nos futurs astreints nous remercieront ! »
Vise une personne, ventile une émotion, n'engage rien	Vise le système, propose une action de suivi, anticipe l'avenir

Le contenu factuel est presque identique — un backend fragile, un coût d'astreinte élevé, une réécriture envisageable. Seul change le ciblage : l'un cherche un coupable, l'autre une amélioration actionnable.

Collaborer et partager la connaissance

Le post-mortem est, à toutes ses étapes, un acte collaboratif. Chez Google, les documents sont des Google Docs s'appuyant sur un gabarit (template) maison. Quel que soit l'outil, le livre recommande de rechercher trois fonctionnalités clés.

Fonctionnalité	Pourquoi elle compte
Collaboration en temps réel	Permet la collecte rapide de données et d'idées — indispensable dans la phase précoce de rédaction
Système ouvert de commentaires / annotations	Rend le crowdsourcing des solutions facile et améliore la couverture
Notifications par e-mail	Pour mobiliser les collaborateurs du document ou impliquer d'autres personnes

Vient ensuite la revue formelle et la publication. En pratique, les équipes partagent un premier brouillon en interne et sollicitent un groupe d'ingénieurs seniors pour en évaluer la complétude. Les critères de revue ressemblent à ceci :

Grille de revue d'un post-mortem
────────────────────────────────
[ ] Les données clés de l'incident ont-elles été collectées pour la postérité ?
[ ] L'évaluation de l'impact est-elle complète ?
[ ] La cause racine a-t-elle été creusée assez profondément ?
[ ] Le plan d'action est-il pertinent, et les correctifs sont-ils
    priorisés au bon niveau ?
[ ] A-t-on partagé le résultat avec les parties prenantes concernées ?

Une fois cette revue initiale faite, le document est diffusé plus largement — à l'équipe d'ingénierie élargie ou sur une liste de diffusion interne. L'objectif est d'atteindre le public le plus large susceptible de bénéficier des leçons. Google applique par ailleurs des règles strictes d'accès à toute information identifiant un utilisateur : même les post-mortems internes n'incluent jamais de telles données.

Cultiver la culture du post-mortem

Introduire une culture du post-mortem dans une organisation est plus facile à dire qu'à faire : cela exige une culture et un renforcement continus. Le management peut encourager cette culture — notamment par sa participation active à la revue —, mais les post-mortems sans blâme sont idéalement le produit de l'auto-motivation des ingénieurs. Pour diffuser ce qu'on apprend de l'infrastructure, les SRE de Google ont inventé plusieurs rituels.

Activité	En quoi elle consiste
Post-mortem du mois (postmortem of the month)	Une newsletter mensuelle partage un post-mortem particulièrement intéressant et bien écrit avec toute l'organisation
Groupe post-mortem (réseau social interne)	On y partage et discute post-mortems internes et externes, bonnes pratiques et commentaires
Clubs de lecture de post-mortems (reading clubs)	Réunions régulières (souvent autour de quelques rafraîchissements) où un post-mortem marquant — parfois vieux de plusieurs mois ou années ! — est rejoué en dialogue ouvert avec participants, non-participants et nouveaux arrivants
Roue de l'Infortune (Wheel of Misfortune)	Exercice de jeu de rôle où un ancien post-mortem est rejoué (voir « Disaster Role Playing », p. 401) : des ingénieurs endossent les rôles décrits, et le commandant d'incident d'origine assiste pour rendre l'expérience aussi « réelle » que possible

L'un des plus grands obstacles à l'adoption est que certains contestent la valeur des post-mortems au regard de leur coût de préparation. Trois stratégies aident à relever ce défi.

• Intégrer progressivement les post-mortems au flux de travail : une période d'essai avec quelques post-mortems complets et réussis aide à prouver leur valeur, et à identifier quels critères devraient en déclencher un.
• Récompenser et célébrer la rédaction de post-mortems efficaces — publiquement par les canaux sociaux évoqués, et dans la gestion de la performance individuelle et d'équipe.
• Obtenir l'adhésion et la participation de la direction. Le livre note qu'« even Larry Page » parle de la grande valeur des post-mortems.

Pour éviter que le blâme ne revienne par la fenêtre, Google sonde régulièrement ses équipes : la culture soutient-elle votre travail ? Écrire un post-mortem représente-t-il trop de toil ? Quelles bonnes pratiques recommanderiez-vous ? Quels outils aimeriez-vous voir développés ? Ce retour donne aux SRE de terrain l'occasion de demander des améliorations concrètes. Au fil des ans, la pratique s'est tissée dans la culture au point de devenir une norme : tout incident significatif est suivi d'un post-mortem complet, et le groupe de travail « Postmortems at Google » coordonne l'effort à l'échelle de produits aussi divers que YouTube, Google Fiber, Gmail, Google Cloud, AdWords ou Google Maps.

Suivre les pannes : au-delà du cas par cas

Améliorer la fiabilité dans le temps n'est possible qu'à partir d'une base de référence connue et mesurable. Or les post-mortems, aussi précieux soient-ils, ne donnent qu'une partie de la réponse. Ils ne sont écrits que pour les incidents à fort impact : les problèmes individuellement mineurs mais fréquents et répandus échappent à leur radar. De plus, ils tendent à éclairer un service unique, manquant les opportunités à faible effet local mais à fort impact horizontal — ce changement coûteux sur Bigtable qui ne sert qu'une panne isolée, mais qui, appliqué à de nombreux événements, vaudrait largement l'investissement.

D'autres questions, fondamentales pour mesurer la charge réelle, restent hors de portée d'un post-mortem isolé :

Questions auxquelles un post-mortem seul ne répond pas
──────────────────────────────────────────────────────
• Combien d'alertes par tour d'astreinte (on-call shift) cette équipe reçoit-elle ?
• Quel est le ratio alertes actionnables / non actionnables sur le dernier trimestre ?
• Lequel des services gérés par cette équipe génère le plus de toil ?

Pour y répondre, Google s'appuie sur deux outils complémentaires : Escalator (l'escalade des notifications) et Outalator (l'agrégation des pannes).

Escalator : ne jamais perdre une alerte

Toutes les notifications d'alerte destinées au SRE passent par un système central répliqué, Escalator (« The Escalator »), qui suit si un humain a accusé réception (acknowledged) d'une notification. Sans accusé de réception après un intervalle configuré, le système escalade vers la ou les destinations suivantes — par exemple du primaire (primary on-call) vers le secondaire.

Cycle de vie d'une alerte dans Escalator
─────────────────────────────────────────
  Monitoring ──► notification ──► astreinte PRIMAIRE
                                      │
                          accusé reçu ?  ── oui ──► fin
                                      │
                                     non (délai dépassé)
                                      ▼
                              astreinte SECONDAIRE
                                      │
                          accusé reçu ?  ── non ──► destination(s) suivante(s)…

Détail révélateur de la philosophie d'ingénierie de Google : Escalator fut d'abord conçu comme un outil largement transparent, recevant de simples copies des e-mails envoyés aux alias d'astreinte. Cette discrétion lui permit de s'intégrer aux flux existants sans exiger aucun changement de comportement des utilisateurs ni des systèmes de monitoring de l'époque.

Outalator : de l'alerte à l'incident

À l'image d'Escalator — ajouter des fonctionnalités utiles à une infrastructure existante —, Google a construit Outalator, qui ne traite plus la notification individuelle mais la couche d'abstraction supérieure : la panne. Outalator affiche une liste de notifications entrelacées chronologiquement pour plusieurs files (queues) à la fois, sans obliger à basculer manuellement de l'une à l'autre — utile quand une même équipe SRE est le point de contact primaire de services dont les cibles d'escalade secondaires (souvent les équipes de développement) diffèrent.

Outalator stocke une copie de la notification d'origine, sauvegarde aussi discrètement les réponses e-mail, et permet d'annoter les incidents. Comme certaines réponses sont moins utiles que d'autres (un reply-all dont le seul but est d'ajouter des destinataires en copie), les annotations peuvent être marquées « importantes » : les autres parties du message se replient alors dans l'interface pour réduire l'encombrement. On obtient ainsi bien plus de contexte qu'un fil d'e-mails fragmenté.

Agréger, étiqueter, analyser

La fonction décisive d'Outalator n'est pas l'affichage mais l'agrégation. Un même événement déclenche, et déclenchera souvent, plusieurs alertes : une panne réseau provoque des timeouts et des backends injoignables pour tout le monde — chaque équipe affectée reçoit ses propres alertes, y compris les propriétaires des services backend, pendant que le centre des opérations réseau (NOC) fait sonner ses propres klaxons. Réduire le nombre d'alertes par événement est souhaitable, mais en déclencher plusieurs reste inévitable dans la plupart des arbitrages entre faux positifs et faux négatifs.

D'où le geste central : combiner plusieurs alertes en une seule entité « incident ». Envoyer un e-mail disant « c'est la même chose que cet autre truc, ce sont les symptômes du même incident » fonctionne pour une alerte ponctuelle, mais ne passe pas à l'échelle d'une équipe, encore moins entre équipes ou sur la durée. Le regroupement déclutte les vues et permet d'analyser séparément les « incidents par jour » par opposition aux « alertes par jour » — une distinction qui change tout dans la mesure du bruit.

L'étiquetage (tagging)

Tout événement d'alerte n'est pas un incident : faux positifs, événements de test, e-mails mal adressés existent. Outalator ne distingue pas ces cas par lui-même mais permet l'étiquetage (tagging) libre à n'importe quel niveau. Les tags sont surtout des « mots » uniques en forme libre ; les deux-points y sont interprétés comme séparateurs sémantiques, ce qui promeut subtilement des espaces de noms hiérarchiques et autorise un traitement automatique.

Étiquetage hiérarchique — exemples
───────────────────────────────────
cause:network                  (suffisant pour certaines équipes)
cause:network:switch           ┐ granularité plus fine
cause:network:cable            ┘ pour distinguer les pannes
action:rollback                préfixe « action » suggéré
customer:132456                propre à certaines équipes
bug:76543                      transformé en lien vers le bug tracker
bogus                          très répandu pour les faux positifs
cause:netwrok  (typo)          le revers de la liberté…
problem-went-away              … et les tags peu utiles

Les préfixes suggérés (« cause », « action ») sont propres à chaque équipe et générés d'après l'usage historique. Certes, des fautes de frappe et des tags inutiles apparaissent ; mais éviter une liste prédéterminée et laisser les équipes trouver leurs propres standards produit un outil plus utile et de meilleures données. Aussi trivial qu'il paraisse, l'étiquetage est « probablement l'une des fonctionnalités uniques les plus utiles d'Outalator » : il offre, même sans analyse formelle, une vue d'ensemble des points de douleur d'un service.

L'analyse en couches

Le SRE fait bien plus que réagir aux incidents. L'historique aide pendant un incident (« qu'avons-nous fait la dernière fois ? »), mais il est bien plus utile pour cerner les problèmes systémiques, périodiques ou transverses. L'analyse se construit en strates de valeur croissante.

Couche	Ce qu'elle produit
Comptage et statistiques de base	Incidents par semaine/mois/trimestre ; alertes par incident — le socle du reporting
Comparaison entre équipes/services et dans le temps	Premiers motifs et tendances ; permet de juger si une charge d'alerte est « normale » au regard de son propre historique et de celui des autres
Identification des problèmes larges (analyse sémantique)	Repérer le composant d'infrastructure causant le plus d'incidents, donc le bénéfice potentiel à le stabiliser

La deuxième couche est sous-estimée : « c'est la troisième fois cette semaine » peut être bon ou mauvais — mais savoir si « ça » arrivait cinq fois par jour ou cinq fois par mois rend l'information interprétable. La troisième couche exige une lecture sémantique : deux équipes peuvent avoir des conditions d'alerte « données périmées » (stale data) et « latence élevée », toutes deux causées par une congestion réseau retardant la réplication — ou, au contraire, dans les clous de l'objectif de service (SLO) mais en deçà des attentes des utilisateurs. Examiner cela à travers plusieurs équipes permet d'identifier les problèmes systémiques et la bonne solution — qui peut parfois consister, paradoxalement, à introduire des pannes artificielles pour cesser de sur-performer par rapport au SLO.

Reporting, communication et bénéfices inattendus

D'un usage plus immédiat pour les SRE de terrain : Outalator permet de sélectionner des « outalations » et d'en inclure sujets, tags et annotations « importantes » dans un e-mail à l'astreinte suivante, pour transmettre l'état entre deux tours. Pour les revues périodiques (hebdomadaires chez la plupart des équipes), un mode rapport (report mode) déplie les annotations importantes en ligne, offrant un aperçu rapide des « lowlights ».

Le suivi des pannes recèle aussi des bénéfices non évidents. Constater qu'une alerte coïncide avec une autre panne accélère le diagnostic et réduit la charge. Mieux : si un service souffre d'un apparent incident Bigtable mais qu'on voit que l'équipe SRE Bigtable n'a pas été alertée, l'alerter manuellement est sans doute judicieux. La visibilité inter-équipes fait une vraie différence dans la résolution — ou au moins l'atténuation — des incidents.

À retenir

• Les incidents sont inévitables à l'échelle de Google ; le post-mortem est l'outil qui transforme l'échec en apprentissage durable et empêche la récurrence, en documentant impact, actions, causes racines et actions de suivi.
• Le sans-blâme (blameless) est un pilier : on présume la bonne foi de chacun et on enquête sur les causes systémiques, pas sur les personnes — « on ne répare pas les gens, on répare les systèmes » ; sans cela, les problèmes sont dissimulés et le risque augmente.
• Définissez les déclencheurs (indisponibilité visible, perte de données, intervention d'astreinte, dépassement de seuil de résolution, défaillance du monitoring) avant l'incident, et laissez toute partie prenante en demander un.
• Le post-mortem est collaboratif et revu : « un post-mortem non revu pourrait aussi bien ne jamais avoir existé » ; on le diffuse largement et on l'archive dans un dépôt partagé.
• On cultive la culture par des rituels (post-mortem du mois, clubs de lecture, Roue de l'Infortune), en récompensant visiblement le bon réflexe, et en sondant les équipes pour éviter le retour du blâme.
• Les post-mortems ne couvrant que le fort impact, Escalator (escalade des alertes non acquittées) et Outalator (agrégation des pannes) permettent de regrouper plusieurs alertes en un incident, d'étiqueter librement, et de distinguer « incidents par jour » de « alertes par jour ».
• L'agrégation dégage tendances et problèmes systémiques transverses, mesure la charge et le toil, réduit le bruit d'alerte, et apporte des bénéfices inattendus comme la visibilité inter-équipes et l'usage en système d'enregistrement.