Leçons d'autres industries et conclusion

Après avoir disséqué le fonctionnement du SRE chez Google, une question s'impose naturellement : d'autres industries — qui jouent leur survie, voire des vies humaines, sur la fiabilité de leurs systèmes — abordent-elles le problème de la même manière, ou radicalement autrement ? Pour y répondre, les auteurs ont interrogé des ingénieurs de Google ayant exercé dans l'aviation, le nucléaire, la médecine, le militaire, les télécommunications, l'industrie manufacturière, la finance ou le sauvetage aquatique. Ce dernier chapitre confronte les pratiques du SRE à ces secteurs à haute fiabilité (high-reliability), puis se clôt sur la réflexion de Benjamin Lutch, vice-président SRE chez Google, qui relit dix ans d'évolution de la discipline à travers le prisme de l'aviation — et sur la synthèse des grands principes que Ben Treynor Sloss avait posés en ouverture du livre.

Pourquoi comparer le SRE à d'autres industries

Le SRE de Google n'a pas été inventé dans le vide. Beaucoup de ses pratiques font écho à des disciplines qui géraient déjà la fiabilité critique bien avant l'existence du Web. Pour rendre la comparaison exploitable, les auteurs ont distillé les principes fondamentaux du SRE en quatre grands thèmes, qu'ils confrontent secteur par secteur :

• la préparation et les tests de catastrophe (preparedness and disaster testing) ;
• la culture du post-mortem (postmortem culture) ;
• l'automatisation et la réduction de la charge opérationnelle (automation and reduced operational overhead) ;
• la prise de décision structurée et rationnelle (structured and rational decision making).

Les vétérans interrogés couvrent un spectre saisissant : un ingénieur ayant conçu des systèmes de guidage inertiel pour l'armement, un maître-nageur ayant formé des sauveteurs pendant une décennie, un programmeur des lasers de chirurgie réfractive (LASIK), des ingénieurs ayant maintenu le système d'urgence E911, un ancien Black Belt Six Sigma d'une usine de diamants synthétiques, un consultant en sûreté du nucléaire civil britannique, un officier-mécanicien nucléaire de sous-marin de l'US Navy, un développeur de logiciels de contrôle aérien. Dans tous ces métiers, une défaillance va de la simple gêne à la perte d'équipements à plusieurs millions, jusqu'à la mort d'êtres humains.

La préparation et les tests de catastrophe

La culture SRE est faite de vigilance perpétuelle : qu'est-ce qui pourrait mal tourner, et qu'allons-nous faire avant que cela ne provoque une panne ou une perte de données ? Chez Google, la réponse passe par les exercices annuels DiRT (Disaster and Recovery Testing) : les SRE poussent les systèmes de production jusqu'à leurs limites et provoquent de vraies pannes afin de vérifier que les systèmes réagissent comme on le croit, de débusquer des faiblesses inattendues, et de les rendre plus robustes pour prévenir les pannes incontrôlées.

Les autres industries déploient des stratégies voisines, modulées par leurs enjeux propres :

Stratégie	Exemple sectoriel
Focalisation obsessionnelle sur la sécurité	Dans l'industrie manufacturière, « chaque réunion de direction commençait par un point sécurité » ; processus hautement définis, suivis à tous les niveaux
Attention au détail	Sur les sous-marins nucléaires, un manquement à une petite tâche (l'entretien de l'huile de lubrification) peut entraîner une défaillance majeure : la maintenance de routine empêche les petits problèmes de faire boule de neige
Capacité de débordement (swing capacity)	En télécoms, le SOW (switch on wheels), un central mobile déployable en urgence ou en prévision d'un événement saturant (les Jeux olympiques, une fuite de numéro de célébrité dont les symptômes évoquaient un DDoS)
Simulations et exercices grandeur nature	L'aviation ne peut pas tester « en production » sans risquer passagers et appareils : elle recourt à des simulateurs ultraréalistes alimentés en données réelles
Formation et certification	Les maîtres-nageurs passent une certification rigoureuse et une recertification périodique, avec une formation spécifique à chaque site (piscine, lac, océan)
Recueil des exigences et conception détaillée	Dans la défense, un an de conception pour seulement trois semaines de code ; à l'opposé du « lance et itère » de Google
Défense en profondeur (defense in depth)	Le nucléaire civil empile les systèmes de repli derrière les systèmes primaires, jusqu'à une ultime barrière physique contre tout rejet radioactif

Le contraste de rythme est éclairant. La Navy nucléaire pratique des exercices réels « en cassant pour de vrai, mais avec des paramètres de contrôle », religieusement, deux à trois jours par semaine — car les exercices de pensée (« what if ») ne suffisent pas : une réponse non pratiquée s'oublie. Les maîtres-nageurs, eux, subissent une forme de « client mystère » : un enfant ou un sauveteur incognito met en scène une noyade aussi crédible que possible, pour que l'équipe ne puisse pas distinguer l'urgence réelle de l'exercice.

Conséquence d'une panne          Type de test approprié
─────────────────────────        ──────────────────────────────
Faible / réversible       ───►    test « en production » réel (Google DiRT)
Élevée (vies en jeu)      ───►    simulateur ultraréaliste, jamais le vrai système
                                  (aviation, nucléaire)
Météo / catastrophe       ───►    exercices grandeur nature, sites autonomes
naturelle                         (télécoms : générateurs internes, bâtiments
                                   résistants aux tempêtes)

La culture du post-mortem

Le concept de CAPA (corrective and preventive action) — l'investigation systématique des causes racines pour prévenir la récurrence — est universellement reconnu pour améliorer la fiabilité. Le SRE l'incarne par sa culture des post-mortems sans reproche (blameless postmortems). À l'échelle, à la complexité et au rythme de changement de Google, quelque chose finira toujours par casser ; ce qui compte alors, c'est d'évaluer ce qui s'est passé, l'efficacité de la réponse, ce qu'on ferait différemment, et les actions qui empêcheront la récidive — sans jamais pointer du doigt un individu. S'attarder sur le « qui » est contre-productif. Les post-mortems sont diffusés à toutes les équipes SRE, pour que chacun apprenne.

L'enquête révèle que de nombreux secteurs pratiquent une forme de post-mortem — souvent sous un autre nom, pour d'évidentes raisons — mais que leur motivation diffère :

Moteur du post-mortem	Industrie / illustration
Régulation	Télécoms (FCC), aviation (FAA), manufacture et chimie (OSHA), dispositifs médicaux (FDA), autorités compétentes de l'UE ; avec obligation de rendre des comptes quand les vies sont en jeu
Sécurité	Chez Alcoa, l'ancien PDG Paul O'Neill exigeait d'être prévenu sous 24 h de tout accident avec arrêt de travail, et avait donné son numéro personnel aux ouvriers de l'usine
« Quasi-accidents » (near misses)	Dans la chimie, un événement qui aurait pu nuire est scruté comme un post-mortem préventif ; le CHIRP britannique recueille de façon confidentielle ces signaux faibles en aviation et maritime
Apprentissage sans reproche	Le sauvetage aquatique : « Si les pieds d'un maître-nageur touchent l'eau, il y aura de la paperasse ! » ; analyse collective de bout en bout, et même un psychologue dépêché après un incident traumatisant

L'idée des quasi-accidents mérite d'être soulignée. Comme le formule VM Brasseur, « tout désastre comporte de multiples quasi-accidents, généralement ignorés au moment où ils surviennent. Erreur latente, plus condition déclenchante, égale des choses qui ne fonctionnent pas comme prévu ». Un employé qui s'écarte au dernier moment pour éviter une éclaboussure, une flaque non nettoyée dans un escalier : autant de désastres en sursis, et autant d'occasions d'apprendre avant que la chance ne tourne. Le sauvetage aquatique partage avec Google un principe fondamental : un incident est chaotique et multifactoriel, il n'est jamais utile de blâmer un seul individu.

Automatiser le travail répétitif

Au fond, les SRE de Google sont des ingénieurs logiciels dotés d'une faible tolérance au travail réactif et répétitif. Pourquoi faire tourner un système sur des opérations manuelles à faible valeur quand on peut les automatiser ? L'automatisation abaisse la charge opérationnelle (operational overhead) et libère du temps pour évaluer et améliorer proactivement les services. Mais les autres industries se révèlent partagées, et leur diversité est instructive.

Certaines font davantage confiance à l'humain qu'à la machine. La Navy nucléaire, à l'époque de notre vétéran, écartait l'automatisation au profit de verrouillages mécaniques et de procédures administratives : manœuvrer une vanne mobilisait un opérateur, un superviseur et un membre d'équipage au téléphone avec l'officier de quart machine. Une chaîne de décision humaine — une série de personnes plutôt qu'un seul individu — parce qu'un système automatisé pourrait ne pas repérer un problème qu'un humain remarquerait à coup sûr, et parce que les ordinateurs vont si vite qu'ils sont capables de commettre une erreur énorme et irréparable. Face à un réacteur nucléaire, la lenteur méthodique prime sur la rapidité.

À l'inverse, d'autres secteurs embrassent l'automatisation précisément parce que la machine est plus rapide, plus reproductible et plus régulière que l'humain. Dans le nucléaire britannique, une règle empirique impose que toute réponse à exécuter en < 30 minutes soit automatisée. L'aviation l'applique de façon sélective : le basculement (failover) opérationnel est automatique, mais l'implémentation des systèmes de contrôle aérien doit être inspectée manuellement par des humains — l'automatisation n'est validée qu'une fois vérifiée par une personne.

Le cas de la chirurgie au laser est le plus éloquent. Autrefois, le médecin saisissait à la main les mesures réfractives du patient avant que le laser n'opère — avec un risque d'erreur de saisie ou d'inversion entre l'œil gauche et l'œil droit. Une première automatisation a ajouté une vérification de cohérence des données saisies : toute valeur hors d'une plage attendue est signalée comme inhabituelle. Puis l'iris du patient a été photographié lors du test préliminaire et automatiquement apparié au moment de l'opération, éliminant tout risque de confusion de dossier. Quand cette solution fut déployée, une classe entière d'erreurs médicales a disparu.

La prise de décision structurée et rationnelle

Chez Google, et au SRE en particulier, la donnée est reine. L'équipe vise des décisions structurées et rationnelles en garantissant que la base de la décision est convenue à l'avance plutôt que justifiée a posteriori, que les entrées sont claires, que les hypothèses sont explicites, et que les décisions fondées sur les données l'emportent sur les intuitions, les ressentis ou l'avis de la personne la plus haut placée dans la pièce — ce que Schmidt et Rosenberg surnomment le HiPPO (Highest-Paid Person's Opinion). Le SRE postule que chacun a à cœur l'intérêt des utilisateurs et peut décider de la marche à suivre à partir des données disponibles : les décisions sont éclairées plutôt que prescrites.

Les autres industries déclinent quatre approches contrastées :

Approche	Logique	Secteur
« Si ça marche, n'y touchez pas… jamais »	Réticence à changer une technologie longuement éprouvée	Télécoms (commutateurs longue distance des années 1980, « increvables et massivement redondants ») ; nucléaire
Playbooks et procédures	Chaque scénario concevable consigné dans une checklist ou « le classeur » ; source d'autorité unique en cas de pépin	Industries à évolution lente, ou à niveau de compétence variable des opérateurs
Décision pilotée par les données	Culture d'expérimentation rigoureuse : formuler et tester des hypothèses, n'implémenter un changement que si l'expérience le valide statistiquement	Recherche et manufacture
Décision répartie pour gérer le risque	Séparation des pouvoirs : une équipe distincte des traders surveille et peut tout arrêter	Trading propriétaire

Cette dernière approche illustre un partage des responsabilités radical. Dans le trading propriétaire, une équipe d'application (enforcement team), séparée des traders, surveille la salle et coupe le système à la moindre anomalie. Sa première réponse à toute irrégularité est l'arrêt, et elle seule peut redémarrer. La devise de John Li résume cet arbitrage : « Tant que nous ne passons pas d'ordres, nous ne perdons pas d'argent. Nous n'en gagnons pas non plus, mais au moins nous n'en perdons pas. » Aussi insupportable que soit le délai pour un trader manquant une opportunité, la sécurité prime.

Ce que Google partage — et ce qui le distingue

La synthèse de l'enquête est double. D'une part, la plupart des principes fondamentaux du SRE se retrouvent à travers tout le spectre des industries à haute fiabilité ; les leçons déjà tirées par ces secteurs établis ont vraisemblablement inspiré certaines pratiques de Google. D'autre part, dans une grande partie de son activité logicielle, Google a un appétit pour la vélocité bien supérieur à celui de la plupart des autres acteurs.

                appétit pour le risque / vélocité
  faible ◄──────────────────────────────────────────────► élevé

  nucléaire     aviation     télécoms     finance     Google (Search,
  médecine      militaire                              produits grand public)
  │                                                    │
  vies en jeu → conservatisme,                         pas de vies en jeu →
  zéro tolérance, simulation                           « lance et itère »,
  uniquement                                           budgets d'erreur

La différence n'est pas que Google prendrait la fiabilité moins au sérieux — il la prend très au sérieux — mais qu'il adapte ses approches à son taux de changement élevé. Là où une panne dans le nucléaire, l'aviation ou la médecine peut blesser ou tuer, beaucoup de produits Google opèrent dans un environnement où aucune vie n'est directement menacée. Cette latitude permet d'employer des outils comme le budget d'erreur (error budget) pour « financer » une culture d'innovation et de prise de risque calculée. Google a, en somme, adapté des principes de fiabilité éprouvés ailleurs pour résoudre une équation singulière : concilier échelle, complexité et vélocité avec une haute fiabilité.

La conclusion de Google : du pilote-mécanicien à l'équipage de deux

Benjamin Lutch, vice-président SRE, referme le livre sur une analogie aéronautique qui éclaire la nature même du métier. Il y a un siècle, voler entre deux villes signifiait un monomoteur fragile dont le pilote était aussi le mécanicien, le manutentionnaire et parfois le réparateur en plein vol ; tout système non redondant, toute défaillance catastrophique. Un siècle plus tard, un 747 transporte des centaines de passagers et des tonnes de fret sur 10 000 kilomètres, à la minute près, dans un modèle de sûreté tel qu'on est plus en sécurité en l'air qu'en voiture. Et dans le cockpit ? Toujours seulement deux pilotes.

il y a 100 ans                          aujourd'hui
──────────────                          ───────────────────────────
1 monomoteur fragile, non redondant     747, systèmes redondants et fiables
1 pilote = mécanicien + manutention      des centaines de passagers, des tonnes de fret
quelques centaines de miles, beau temps 10 000 km, à l'heure prévue à la minute près
─────────────────────────────────       ───────────────────────────
                  ↘  l'échelle a explosé,  ↗
                     l'équipage est resté de DEUX

Comment tout — sûreté, capacité, vitesse, fiabilité — a-t-il pu croître aussi magnifiquement alors qu'il n'y a toujours que deux pilotes ? Parce que les interfaces du cockpit ont été conçues par des gens qui comprennent les systèmes complexes et savent les présenter à des humains de façon à la fois assimilable et passante à l'échelle : assez simples pour qu'on apprenne à piloter en conditions normales, assez souples pour que la réponse aux urgences reste robuste et rapide. Sous le cockpit, on retrouve exactement les propriétés traitées tout au long du livre : disponibilité, optimisation des performances, gestion du changement, supervision et alerte, planification de capacité, réponse aux urgences.

C'est précisément la trajectoire visée par une équipe SRE : aussi compacte que possible, opérant à un haut niveau d'abstraction, s'appuyant sur de nombreux systèmes de secours et des API réfléchies pour dialoguer avec l'infrastructure — tout en possédant une connaissance exhaustive des systèmes (comment ils fonctionnent, comment ils échouent, comment répondre à leurs défaillances), connaissance qui ne s'acquiert qu'en les exploitant au quotidien.

La synthèse : pourquoi le modèle SRE est durable

Lutch attribue le succès écrasant du SRE — passé de quelques centaines d'ingénieurs en 2006 à plus d'un millier, sur une douzaine de sites — à la nature de ses principes. Les SRE partagent leur temps entre deux activités d'égale importance : assurer l'astreinte (on-call) — mettre les mains dans les systèmes, observer où et comment ils cassent, comprendre comment les passer à l'échelle — et prendre le recul pour décider quoi construire afin de les rendre plus faciles à exploiter. Ils jouent ainsi à la fois le rôle du pilote et celui de l'ingénieur-concepteur : leur expérience de l'exploitation est codifiée en code, puis empaquetée en produit réutilisable par les autres équipes, par tout Google, et au-delà (Google Cloud).

Deux dynamiques expliquent la longévité du modèle. La première est la constance des responsabilités fondamentales : les systèmes peuvent être mille fois plus grands ou plus rapides, ils doivent toujours rester fiables, flexibles, faciles à gérer en situation d'urgence, bien supervisés et planifiés en capacité. La seconde est l'évolution naturelle des activités : ce qui était « construire un tableau de bord pour 20 machines » est devenu « automatiser la découverte, la construction de tableaux de bord et l'alerte sur une flotte de dizaines de milliers de machines ». La fondation — l'ensemble de règles flexible et largement à l'épreuve du temps esquissé par Ben Treynor Sloss en introduction — reste pertinente dix ans après sa conception, malgré tous les changements.

À retenir

• Les quatre thèmes fondamentaux du SRE — préparation et tests de catastrophe, culture du post-mortem, automatisation, décision structurée — se retrouvent dans toutes les industries à haute fiabilité (aviation, nucléaire, médecine, militaire, télécoms, manufacture).
• « L'espoir n'est pas une stratégie » : la préparation se teste activement, du DiRT de Google aux simulateurs ultraréalistes de l'aviation ; c'est la gravité de l'échec qui dicte si l'on teste sur le système réel ou sur sa réplique.
• Le post-mortem sans reproche est partagé partout (le sauvetage aquatique inclus) ; l'idée des quasi-accidents (near misses) en est l'extension préventive — un désastre en sursis est une occasion d'apprendre avant que la chance ne tourne.
• L'automatisation divise les secteurs : elle élimine des classes entières d'erreurs (chirurgie LASIK), mais mal configurée elle amplifie le désastre à la vitesse de la machine (440 M$ chez Knight Capital, le Flash Crash).
• La grande différence de Google est son appétit supérieur pour la vélocité : sans vies directement en jeu, il « lance et itère » et finance l'innovation par le budget d'erreur — adaptant des principes de fiabilité éprouvés ailleurs à une équation d'échelle, de complexité et de vitesse.
• L'analogie du 747 à deux pilotes capture l'idéal SRE : une équipe compacte, opérant à haut niveau d'abstraction sur des interfaces bien conçues, avec une connaissance intime des systèmes acquise en les exploitant.
• Le modèle est durable parce que ses responsabilités fondamentales sont constantes (fiabilité, flexibilité, urgence, supervision, capacité) tandis que les activités évoluent avec l'échelle — l'ingénierie restant au cœur de l'exploitation, codifiée en code et empaquetée en produit.