Ingénierie du chaos, incidents et apprentissage sans reproche

S’exercer à la défaillance, volontairement

Tout ce que contient ce chapitre jusqu’ici est une promesse sur la manière dont le système se comportera quand quelque chose tournera mal : les délais d’expiration se déclencheront, les disjoncteurs s’ouvriront, la charge sera délestée, les répliques prendront le relais, les alertes parviendront à quelqu’un qui sait quoi faire. Le chapitre 2 avertissait qu’un failover jamais exercé échoue souvent le jour où l’on en a enfin besoin (section 2.5). Cette section explique comment transformer ces promesses en preuves, et comment les organisations réagissent aux défaillances qui surviennent malgré tout et en tirent des leçons.

Deux pratiques vont de pair. Avant les défaillances, l’ingénierie du chaos et les game days provoquent délibérément de petites défaillances maîtrisées pour trouver des faiblesses et former les personnes. Après les défaillances, la gestion des incidents limite les dégâts et les revues post-incident sans reproche transforment chaque incident en amélioration durable. Les deux reposent sur la même conviction : les systèmes complexes sont toujours en partie défaillants, et la résilience vient de la capacité à découvrir comment, tôt et sans risque.

Ingénierie du chaos

L’ingénierie du chaos est née de la migration de Netflix de ses propres centres de données vers Amazon Web Services, entamée après une grave corruption de base de données en 2008. Des instances cloud individuelles pouvaient disparaître à tout moment ; Netflix a donc créé Chaos Monkey, un outil qui arrêtait aléatoirement des instances de production pendant les heures de bureau, quand les ingénieurs étaient à leur poste pour remarquer et corriger tout problème qui en résultait. Netflix l’a décrit, avec une famille d’outils apparentés appelée Simian Army, dans un billet de blog de juillet 2011. Des outils ultérieurs sont allés plus loin : Chaos Kong simulait la perte d’une région AWS entière en évacuant le trafic de celle-ci.

Des ingénieurs de Netflix et d’autres ont ensuite formalisé la discipline dans les Principles of Chaos Engineering (principlesofchaos.org, dernière révision en 2019), qui la définissent comme le fait d’expérimenter sur un système pour gagner confiance dans sa capacité à résister à des conditions turbulentes en production. Le mot qui compte est expérimenter : l’ingénierie du chaos ne consiste pas à casser des choses au hasard pour voir ce qui se passe, mais à appliquer la méthode scientifique à la résilience. Les principes énumèrent cinq pratiques :

Formulez une hypothèse autour du comportement en état stable. Choisissez une sortie mesurable qui indique un fonctionnement normal, comme le nombre de commandes passées par minute ou le SLI de l’étape de paiement, plutôt que des métriques internes comme le CPU. L’hypothèse d’état stable prédit que cette sortie restera dans des limites définies pendant l’injection de la défaillance. Variez les événements du monde réel. Injectez les défaillances qui se produisent réellement : des instances qui meurent, une dépendance qui ralentit, une perte de paquets, un disque plein, un certificat expiré, une dérive d’horloge, un pic de trafic. Menez les expériences en production. Seule la production a le vrai trafic, les vraies données et la vraie configuration. Automatisez les expériences pour qu’elles s’exécutent en continu. Une expérience ponctuelle prouve la résilience une fois ; les systèmes changent tous les jours. Réduisez au minimum le rayon d’impact. Commencez par la plus petite expérience capable d’apprendre quelque chose (une instance, un faible pourcentage du trafic) et gardez un bouton d’arrêt à portée de main.

Mener des expériences en production est le principe le plus débattu. Ses défenseurs font valoir que les environnements de staging diffèrent par le trafic, les données, l’échelle et la configuration, que seules les expériences en production révèlent les vraies faiblesses, et qu’une petite expérience maîtrisée à 15:00 est bien plus clémente pour les utilisateurs que la même défaillance survenant sans contrôle à 03:00. Les critiques soulignent que de nombreuses organisations n’ont pas l’observabilité, l’automatisation et la confiance interne nécessaires pour le faire sans risque. Le consensus pratique est une progression : commencer dans un environnement de staging, puis passer en production avec un rayon d’impact minime et des conditions d’arrêt automatique liées aux SLO, et n’élargir qu’à mesure que la confiance grandit. Ne commencez jamais par un système que vous savez déjà fragile ; corrigez d’abord les faiblesses connues, car une expérience dont vous pouvez prédire le résultat n’apprend rien.

Les outils sont désormais largement disponibles : les fournisseurs cloud proposent l’injection de fautes managée (AWS Fault Injection Service, Azure Chaos Studio), Chaos Mesh et LitmusChaos sont des projets open source de la CNCF pour Kubernetes, et des plateformes commerciales comme Gremlin fournissent des bibliothèques d’attaques avec des contrôles de sécurité. Les service meshes et les proxys peuvent injecter de la latence et des erreurs dans un pourcentage des appels sans toucher au code de l’application. Les outils sont la partie facile ; le plus dur est de choisir des hypothèses pertinentes et d’agir sur les résultats.

Les game days

Un game day (journée d’exercice) est un exercice planifié au cours duquel une équipe provoque ou simule délibérément une défaillance importante et s’entraîne à y répondre. Jesse Robbins a popularisé cette pratique chez Amazon, où son intitulé de poste aurait été Master of Disaster. Google organise de grands exercices de tests de reprise après sinistre (Disaster Recovery Testing, DiRT), et son livre SRE décrit la Wheel of Misfortune, un jeu de rôle dans lequel des ingénieurs d’astreinte revivent un incident passé tandis qu’un maître du jeu révèle ce que la supervision aurait montré.

Les game days testent plus que le logiciel. Ils vérifient si les alertes parviennent aux bonnes personnes, si celles-ci disposent des accès nécessaires à 03:00, si les runbooks sont à jour, si la procédure de failover fonctionne réellement, si les sauvegardes se restaurent et si le plan de communication atteint les clients. Un game day typique de la plateforme de livraison de repas pourrait basculer la base de données des commandes vers son instance de secours pendant un après-midi calme, sous les yeux de toute l’équipe d’astreinte, avec un animateur qui injecte des surprises (la personne qui connaît le runbook est en congé) et un observateur qui note chaque retard et chaque confusion pour la revue qui suivra. Avant une grosse ouverture de billetterie, la même équipe pourrait répéter la perte du prestataire de paiement et le passage au prestataire de secours en pleine vente.

La gestion des incidents

Un incident est un événement imprévu qui perturbe un service, ou menace de le perturber, et qui exige une réponse coordonnée. La gestion des incidents est la pratique qui consiste à conduire cette réponse de façon rapide, calme et bien communiquée. La plupart des pratiques modernes s’inspirent de l’Incident Command System, conçu pour la lutte contre les feux de forêt en Californie dans les années 1970, et adapté au logiciel dans le chapitre du livre SRE de Google consacré à la gestion des incidents.

L’idée centrale est la séparation des rôles. Le coordinateur d’incident (incident commander) est responsable de l’incident : il fixe les priorités, attribue les rôles, prend les décisions et garde la vue d’ensemble, et il ne débogue délibérément pas, car un coordinateur plongé dans un fichier journal ne coordonne plus rien. Le responsable des opérations et les intervenants diagnostiquent et atténuent. Le responsable de la communication est l’unique porte-parole auprès de tous ceux qui sont extérieurs à la réponse : équipes de support, dirigeants et clients, via la page de statut, avec des mises à jour au rythme promis même quand il n’y a rien de nouveau. Un scribe consigne la chronologie, les décisions et les hypothèses. Dans une petite entreprise, une même personne peut tenir plusieurs rôles, mais ces rôles doivent tout de même être nommés. Les rôles sont transmis explicitement lors des changements d’équipe.

Plusieurs habitudes font la différence. Déclarez les incidents tôt et sans formalités : mieux vaut lever une fausse alerte que découvrir au bout d’une heure que trois équipes déboguent le même problème chacune de leur côté. Classez chaque incident selon un niveau de gravité défini par l’impact sur les utilisateurs, et non par la cause, pour que chacun sache qui appeler et avec quelle ampleur communiquer. Atténuez avant de diagnostiquer : annulez le dernier déploiement, basculez, désactivez le feature flag ou délestez la charge d’abord, et cherchez le pourquoi ensuite. Utilisez un seul canal d’incident. Et n’oubliez pas les obligations externes : une violation de données à caractère personnel peut devoir être notifiée à l’autorité de contrôle dans les 72 heures en vertu du RGPD, c’est pourquoi les incidents de sécurité suivent le processus correspondant décrit à la section 8.8.

Les revues post-incident sans reproche

Après l’incident vient la partie la plus précieuse : l’apprentissage. Une revue post-incident (souvent appelée postmortem) reconstitue ce qui s’est passé, pourquoi cela paraissait logique aux personnes impliquées sur le moment et ce qui va changer. Le chapitre du livre SRE de Google consacré à la culture du postmortem fixe les attentes : un compte rendu écrit pour chaque incident important, couvrant l’impact, la chronologie, les causes contributives et les actions de suivi, relu et partagé, et rédigé sans reproche.

Le billet de John Allspaw de 2012, Blameless PostMortems and a Just Culture, écrit lorsqu’il dirigeait les opérations techniques chez Etsy, explique pourquoi l’absence de reproche est pragmatique et pas seulement bienveillante. Les ingénieurs qui s’attendent à être sanctionnés cessent de rendre pleinement compte de ce qu’ils ont vu et fait, si bien que l’organisation perd précisément l’information dont elle a besoin pour prévenir le prochain incident. Allspaw s’appuie sur les sciences de la sécurité, notamment les travaux de Sidney Dekker sur la culture juste, et sur l’idée de seconds récits : le premier récit dit un ingénieur a lancé la mauvaise commande ; le second demande pourquoi la commande était si facile à lancer, pourquoi l’outil n’a pas averti, pourquoi la procédure semblait raisonnable sous la pression du temps, et met au jour des conditions qui piégeront aussi la personne suivante. Sans reproche ne veut pas dire sans responsabilité : chacun doit toujours rendre pleinement compte, et l’organisation est responsable de corriger les conditions.

Les bonnes revues évitent le biais rétrospectif (le dénouement n’était pas évident sur le moment), les raisonnements contrefactuels (aurait dû, n’a pas su) et la recherche d’une cause racine unique. Le court article de Richard Cook, How Complex Systems Fail (1998), soutient que les défaillances graves des systèmes complexes exigent l’alignement de plusieurs failles : il n’y a donc pas de cause racine unique, seulement des facteurs contributifs. Une chaîne des cinq pourquoi qui aboutit à l’erreur humaine s’est arrêtée trop tôt. Notez aussi ce qui a bien fonctionné : l’expertise et l’improvisation qui ont limité les dégâts font partie de ce qui maintient réellement le système en marche, et elles restent invisibles si personne ne les consigne.

Apprendre des incidents, et les limites du MTTR

Les organisations veulent naturellement un chiffre qui montre si la réponse aux incidents s’améliore, et le temps moyen de rétablissement (MTTR) est le candidat habituel. Le chapitre 2 a utilisé le MTTR dans A = MTBF / (MTBF + MTTR), où il a du sens pour un composant unique dont les défaillances se répètent. Comme métrique organisationnelle couvrant de nombreux incidents différents, il est bien plus faible. Les durées des incidents sont très asymétriques : la plupart sont courts et quelques-uns très longs, si bien que la moyenne est dominée par une poignée de valeurs extrêmes. Les analyses de milliers de rapports d’incidents publics menées par Courtney Nash dans la Verica Open Incident Database (rapports VOID publiés à partir de 2021) ont constaté exactement cette asymétrie, et un rapport de Google de 2021 signé Štěpán Davidovič, Incident Metrics in SRE, a montré par simulation qu’avec un nombre réaliste d’incidents, les variations du MTTR sont surtout du bruit et ne permettent pas de savoir de façon fiable si une amélioration a fonctionné.

De meilleurs signaux sont l’impact sur les SLO et les budgets d’erreur (qui pondèrent les incidents selon ce qu’ont ressenti les utilisateurs), les thèmes récurrents d’une revue à l’autre (le même type de modification de configuration qui pose problème trois fois), les quasi-incidents, la rapidité de détection des incidents, la fréquence à laquelle les revues aboutissent à des modifications du système menées à bien, et des éléments qualitatifs, par exemple le fait que les ingénieurs trouvent les revues utiles. De nombreuses organisations publient les revues en interne dans une bibliothèque consultable et tiennent régulièrement des réunions de revue des incidents, afin que la leçon d’une équipe profite aux autres.

Des actions qui changent réellement le système

Une revue ne vaut que par les changements qu’elle produit. Les actions diffèrent fortement par leur efficacité. Les plus fortes sont celles qui suppriment le danger (supprimer la commande dangereuse, rendre l’état non sûr impossible), puis les garde-fous qui empêchent l’erreur de se propager (validation de la configuration, déploiements progressifs et canaris, limites de débit sur les modifications, retour arrière automatique en cas de consommation du SLO), puis une détection et une atténuation plus rapides (une nouvelle alerte de SLO, un runbook testé, un failover automatisé). Les plus faibles sont la formation, la documentation et les rappels. Faire plus attention n’est pas une action corrective ; cela ne change rien aux conditions qui attendent la personne suivante.

Chaque action a besoin d’un responsable, d’une priorité et d’une échéance, et doit figurer dans le backlog habituel de l’équipe plutôt que dans un document oublié. La politique de budget d’erreur de la section 9.5 fournit le levier : un incident qui a consommé une large part du budget fait passer ses correctifs avant les fonctionnalités. Gardez la liste courte ; cinq actions terminées valent mieux que vingt actions ouvertes. Lorsqu’une action modifie l’architecture, par exemple en ajoutant un cloisonnement (bulkhead) ou en supprimant une dépendance synchrone, consignez-la dans un enregistrement de décision d’architecture qui cite l’incident, et liez les runbooks (procédures d’exploitation) pertinents aux alertes qui se déclencheront la prochaine fois.