Le Pompier

Ni l'un ni l'autre ne peut demander s'il en a envie.

Un incident, dans le vocabulaire d'ITIL, c'est une interruption non planifiée d'un service ou une réduction de sa qualité. Un pompier ne décide pas ce qui brûle ni pourquoi. Il sait juste que quelque chose est en feu et que des gens ont besoin d'aide, vite. Un gestionnaire d'incidents se fait avertir à 2h du matin parce que la production est tombée, les paiements échouent, ou un service crache des erreurs à un million d'utilisateurs à la minute. La cause est inconnue, les enjeux sont réels, et le chronomètre tourne déjà.

Une affaire de coordination sous pression, pas d'héroïsme.

Un pompier qui arrive devant un bâtiment en feu ne fonce pas tout seul à l'intérieur avec un seau. Il évalue la scène, repère où le feu se propage, détermine s'il s'agit d'un sauvetage ou d'une opération de confinement, et dirige son équipe — une partie sur le boyau, une autre en recherche et sauvetage, une autre qui ventile le toit.

Le gestionnaire d'incidents fait pareil avec les ingénieurs : qui regarde la base de données, qui vérifie les répartiteurs de charge, qui parle au soutien à la clientèle, qui rédige la mise à jour de la page d'état. Ce n'est généralement pas la personne qui tape le correctif — c'est celle qui garde la réponse cohérente pour que cinq personnes intelligentes ne déboguent pas toutes la même chose pendant que le vrai problème continue de couver ailleurs.

Traduire le chaos en quelque chose sur lequel le reste du monde peut agir.

Les deux doivent gérer le flux d'information vers l'extérieur. Le chef pompier parle au propriétaire, à la police, à la presse. Le gestionnaire d'incidents parle aux dirigeants qui demandent « est-ce que c'est réglé », aux équipes de soutien qui croulent sous les billets, aux affaires juridiques si c'est une question de données.

Ils traduisent un chaos technique en quelque chose sur lequel le reste du monde peut agir, tout en protégeant les intervenants du bruit pour qu'ils puissent réellement travailler. Un bon gestionnaire d'incidents est, en partie, un coupe-feu humain.

Le travail, ce n'est pas de comprendre pourquoi. C'est de faire en sorte que ça arrête.

C'est là que la plupart des gens se trompent sur le rôle. La gestion des incidents ITIL se mesure sur une seule chose : le rétablissement du fonctionnement normal du service. MTTR, pas MTTU — temps moyen de réparation, pas temps moyen de compréhension. Un retour arrière qui remet les paiements en marche à 04:12, c'est une victoire, même si personne ne sait encore ce que le mauvais déploiement a vraiment fait.

Le pompier ne s'arrête pas pour inspecter le filage avant d'abattre les flammes. Il abat les flammes. Un contournement bat une cause racine à tous coups, parce que le client brûle maintenant. Cause et origine peuvent attendre que tout le monde soit en sécurité.

Quand le feu est éteint, le pompier s'en va.

C'est ici que l'analogie devient tranchante, et c'est là que beaucoup d'organisations brouillent une ligne qu'ITIL a tracée exprès. Quand le feu est éteint, le pompier remballe et rentre. Il ne fouille pas la cendre avec une planchette à pince. C'est une autre personne — un commissaire aux incendies, un enquêteur en incendie criminel — avec un autre mandat, un autre uniforme, et un autre patron.

ITIL trace la même ligne. Une fois le service normal rétabli, l'incident est clos. Ce qui reste — le pourquoi, le défaut sous-jacent, le comment on empêche que ça se reproduise — devient un problème. Et c'est la gestion des problèmes qui en est responsable. Pas la gestion des incidents.

Les notes du gestionnaire d'incidents sur le pont deviennent le dossier d'ouverture du gestionnaire de problèmes. Le passage de relais compte. Confondez les deux rôles et vous obtenez l'un de deux modes d'échec : l'incident s'étire sur des heures pendant que tout le monde débat de la cause racine et que les clients restent en panne, ou le post-mortem ne s'écrit jamais parce que les intervenants sont déjà sur la prochaine alerte.

Un gestionnaire d'incidents combat ce feu-ci. Un SRE s'assure que la ville n'a pas été bâtie pour brûler.

Un pompier, c'est une unité d'intervention. Un service incendie, c'est l'institution au complet : la formation, la répartition, les codes de prévention, l'entretien des bornes-fontaines, les exercices, les ententes d'entraide, la réunion budgétaire à l'hôtel de ville. La ville qui finance seulement les camions obtient un certain résultat. La ville qui finance le service en obtient un autre.

La gestion des incidents ITIL vous donne les camions. Le Site Reliability Engineering — quand il est fait comme Google l'a écrit à l'origine — vous donne la caserne. Même forme que le service incendie, surface plus grande : le travail entre les feux qui détermine la gravité du prochain.

Trois pratiques porteuses du SRE, en vocabulaire de service incendie :

La règle du 50 % d'ingénierie. Un service où chaque quart est en appels toute la journée s'épuise. L'équipe a besoin d'heures qui ne sont pas passées à entrer dans des bâtiments — pour la formation, la prévention, l'entretien de l'équipement. Google a dit la même chose des SRE : plafonner le travail répétitif à la moitié du rôle. L'autre moitié, c'est de faire de l'ingénierie pour éliminer la prochaine alerte.

Les budgets d'erreurs. Zéro feu, ce n'est pas le but. Zéro feu, c'est le but d'une ville sans bâtiments. Un service qui promet une disponibilité à quatre neuf a droit à environ cinquante minutes d'indisponibilité par trimestre — et à l'intérieur de ce budget, on livre avec audace. À l'extérieur, on gèle et on consolide. Le budget, c'est la négociation entre la vitesse et la sécurité, rendue explicite et partagée.

Les quatre signaux d'or. Latence, trafic, erreurs, saturation. Les quatre jauges que chaque répartiteur surveille. Les quatre lectures que le chef demande en premier. Tout le reste, c'est de la décoration.

Les post-mortems sans blâme. Même forme que le rapport du commissaire : ce qui s'est passé, ce qu'on ferait autrement, ce que le système devrait rendre impossible la prochaine fois. Les noms apparaissent; le blâme, non. Parce que la prochaine personne à faire la même erreur, c'est le système, pas la personne.

Un gestionnaire d'incidents combat ce feu-ci. Un SRE s'assure que la ville n'a pas été bâtie pour brûler.

Une ville budgète le feu comme si elle pouvait brûler. La plupart des entreprises budgètent la fiabilité comme si elles ne le pouvaient pas.

Regardez les postes budgétaires de n'importe quelle ville américaine. Les gouvernements des États et des municipalités dépensent environ cinquante milliards de dollars par année en protection incendie — soit à peu près cent cinquante dollars par Américain, en moyenne — et de l'ordre de cinq à dix pour cent du fonds général municipal typique. Plus pour les grandes villes à service complet. Moins pour les villages qui s'appuient sur des volontaires. Personnel jour et nuit. Casernes dédiées. Équipement dédié. Ententes d'entraide avec les voisins. C'est obligatoire. C'est obligatoire depuis que les grands incendies urbains du dix-neuvième siècle ont montré à tout le monde de quoi a l'air l'alternative — et le budget s'est fait défendre, férocement, à chaque cycle budgétaire depuis.

Le feu est contagieux. Une maison enflamme la suivante. Le coût retombe sur le public, peu importe à qui appartenait le poêle. Les régimes d'assurance ont passé cent cinquante ans à forcer la question. Le coût politique d'un pâté de maisons qui brûle parce que le conseil municipal a coupé le budget incendie met fin à une carrière. Alors le budget se fait défendre.

Maintenant, regardez l'organisation d'ingénierie. Le Site Reliability Workbook de Google le dit, noir sur blanc : le SRE a historiquement représenté cinq à dix pour cent du personnel d'ingénierie. Les autres maisons matures — AWS, Netflix, les quelques-unes qui ont appris la leçon à la dure — se regroupent dans le même voisinage. Même forme qu'un budget incendie municipal. C'est ça, la chute.

L'entreprise médiane n'en est nulle part proche. Beaucoup ont zéro fonction dédiée à la fiabilité. La garde, c'est la tâche secondaire qui est tombée sur la personne qui a écrit le code. Les postes d'outillage — Datadog, PagerDuty — sont réels mais des erreurs d'arrondi à côté des dépenses de vélocité de développement. La fiabilité se fait couper en premier quand le trimestre est serré.

L'asymétrie n'est pas un accident. Le coût d'une panne est diffus. Le départ de clients après un incident de quatre heures n'apparaît pas sur la même ligne du compte de résultat que le poste de SRE qui l'aurait prévenu. Il n'y a pas de conseil municipal qui surveille. Le coût politique de ne pas financer la fiabilité retombe sur la personne qui hérite du téléavertisseur le prochain trimestre — pas sur l'exécutif qui a bloqué l'embauche. Alors le budget se fait couper.

Une ville qui dépenserait pour le feu ce que la plupart des entreprises dépensent pour la fiabilité serait en cendres avant mardi.

Là où l'analogie se relâche un peu.

Les feux d'un pompier sont surtout des événements indépendants. Une maison brûle; celle d'à côté, généralement non. Les incidents dans un système distribué complexe ne sont pas comme ça. Une petite flamme dans un graphe de dépendances peut enflammer la moitié de l'organisation en quelques secondes — une base de données lente ralentit l'API, ce qui ralentit le frontal, ce qui déclenche la tempête de réessais, ce qui fait tomber un service qui ne savait même pas que la base de données existait.

Alors la ligne entre un incident et plusieurs incidents qui remontent à un seul problème devient plus difficile à tracer. Le gestionnaire d'incidents doit penser davantage comme un chef pompier qui commande un feu de forêt que comme une intervention à un seul camion. Lignes de confinement. Feux satellites. Direction du vent. Le brasier que vous ne regardez pas encore. Et parfois, le passage de relais à la gestion des problèmes doit se faire pendant que des parties du feu brûlent encore — parce que le défaut sous-jacent est la seule chose qui explique pourquoi trois services apparemment sans lien ont tous pris feu en même temps.

Breffez le chef.

Le feu est éteint. Le pont est fermé. Le runbook est ouvert. Votre tâche maintenant, c'est de breffer. Le commissaire a besoin de la chronologie. Le COO a besoin du langage. La prochaine personne de garde a besoin de la leçon.

Transférez cette dépêche aux gens qui fixent le budget pour la prochaine.