Introduction au SRE et l'environnement de production Google

« L'espoir n'est pas une stratégie » (Hope is not a strategy), dit un adage des équipes SRE de Google. Les systèmes ne se gèrent pas tout seuls, et la question de savoir comment faire tourner un système informatique complexe, à très grande échelle, n'a pas de réponse évidente. Ce livre — écrit par les ingénieurs de Google qui ont inventé la discipline — propose la leur : le Site Reliability Engineering (ingénierie de la fiabilité des sites, SRE). Ce chapitre fondateur en pose la définition, le contraste avec le modèle d'administration système classique, les principes directeurs (tenets), puis dresse le décor matériel et logiciel de la production Google — un vocabulaire que tout le reste de l'ouvrage présuppose.

Le modèle sysadmin et ses limites

Historiquement, les entreprises ont confié leurs systèmes complexes à des administrateurs système (systems administrators, ou sysadmins). L'approche est simple : on assemble des composants logiciels existants, on les déploie pour produire un service, puis on charge les sysadmins de le faire tourner et de réagir aux événements et aux mises à jour à mesure qu'ils surviennent. Quand le système gagne en complexité et en trafic — donc en événements à traiter —, l'équipe d'exploitation grossit pour absorber la charge supplémentaire. Comme le métier réclame des compétences nettement différentes de celles des développeurs du produit, on sépare les deux en équipes distinctes : le développement (Development) d'un côté, l'exploitation (Operations, ou « ops ») de l'autre.

Ce modèle a des avantages réels. Il est facile à mettre en œuvre car c'est un paradigme familier : on dispose d'innombrables exemples à imiter, d'un vivier de talents déjà constitué, et d'une panoplie d'outils, de composants et de sociétés d'intégration pour ne pas réinventer la roue. Mais il porte aussi des coûts, que le livre range en deux catégories : directs et indirects.

Les coûts directs ne sont ni subtils ni ambigus. Faire tourner un service avec une équipe qui s'appuie sur l'intervention manuelle pour la gestion du changement comme pour le traitement des incidents devient onéreux à mesure que le service et son trafic croissent, car la taille de l'équipe croît nécessairement avec la charge générée par le système. C'est une mise à l'échelle linéaire : si le produit réussit, on embauche pour faire encore et encore les mêmes tâches.

Les coûts indirects de la scission dev/ops sont plus discrets, mais souvent plus chers pour l'organisation. Les deux équipes diffèrent par leur formation, leurs compétences et surtout leurs incitations. Elles emploient un vocabulaire distinct, portent des hypothèses divergentes sur le risque, sur les solutions techniques possibles, sur le niveau de stabilité visé. La scission cesse d'être seulement une affaire d'incitations pour devenir une affaire de communication, d'objectifs, et finalement de confiance et de respect. Le livre nomme cela une pathologie.

Aucun des deux camps n'osant énoncer crûment son intérêt (« nous voulons tout lancer, n'importe quand, sans entrave » contre « nous ne voulons plus jamais rien changer une fois que ça marche »), ils basculent dans une guerre de tranchées feutrée. L'ops érige des barrières de lancement (launch gates) : la revue de lancement contient une case à cocher pour chaque problème ayant jamais causé une panne — une liste potentiellement interminable où tous les points ne se valent pas. Le dev apprend vite à riposter : il fait moins de « lancements » et plus de « bascules de drapeau » (flag flips), de mises à jour incrémentales, de cherry-picks, et il découpe le produit en éclats pour soustraire un maximum de fonctionnalités à la revue.

L'approche Google : demander à un ingénieur de concevoir l'exploitation

Le conflit n'est pas une fatalité. Google a choisi une voie différente : ses équipes SRE recrutent des ingénieurs logiciels pour faire tourner les produits et pour bâtir les systèmes qui accompliront le travail que des sysadmins feraient, souvent à la main. La définition canonique vient de Ben Treynor Sloss, vice-président chez Google et inventeur du terme : « le SRE, c'est ce qui arrive quand on demande à un ingénieur logiciel de concevoir une équipe d'exploitation. » Arrivé en 2003 à la tête d'une « équipe de production » de sept ingénieurs, et venant lui-même du logiciel, il a conçu le groupe comme il aurait voulu travailler s'il en avait fait partie.

La composition des équipes en est le premier pilier. Entre 50 et 60 % des SRE sont des ingénieurs logiciels recrutés selon la procédure standard de Google ; les 40 à 50 % restants sont des candidats qui frôlaient cette qualification (85 à 99 % du bagage requis) et possédaient en plus une compétence technique rare et utile au SRE — le plus souvent l'expertise des internes UNIX et du réseau (couches 1 à 3). Tous partagent la conviction et l'aptitude de développer des systèmes logiciels pour résoudre des problèmes complexes. Le résultat : une équipe de gens qui (a) s'ennuieront vite à faire des tâches à la main et (b) ont le bagage pour écrire le logiciel qui remplace ce travail manuel, même quand la solution est compliquée.

Le plafond de 50 % : le cœur du dispositif

Sans ingénierie constante, la charge opérationnelle augmente et il faut toujours plus de monde rien que pour suivre le rythme : on retombe dans la mise à l'échelle linéaire du modèle ops. « L'équipe qui gère un service doit coder, sinon elle se noie. » Google impose donc un plafond de 50 % sur le travail opérationnel agrégé de tous les SRE : tickets, astreinte (on-call), tâches manuelles. Ce plafond est une borne supérieure — laissée à elle-même, l'équipe devrait converger vers une charge opérationnelle très faible. Les 50 % restants doivent être consacrés à du développement réel.

Comment faire respecter ce seuil ? D'abord en mesurant comment le temps SRE est dépensé. Ensuite, quand une équipe passe durablement moins de 50 % de son temps en développement, on corrige : on renvoie une partie de la charge opérationnelle vers l'équipe de développement — réassignation de tickets et de bugs, réintégration des développeurs dans la rotation d'astreinte — jusqu'à ce que la charge ops retombe à 50 % ou moins. C'est une soupape de sécurité, et un puissant mécanisme de rétroaction : il guide les développeurs vers des systèmes qui ne réclament pas d'intervention manuelle.

Aspect	Modèle sysadmin (dev/ops)	Modèle SRE
Profil de l'équipe	Compétences ops distinctes de celles du dev ; équipes séparées	Ingénieurs logiciels (50-60 %) + experts systèmes/réseau (40-50 %)
Réaction à la charge	Travail manuel ; on embauche pour suivre	On code pour automatiser ; le système se répare
Mise à l'échelle du coût	Linéaire avec la taille du service	Sous-linéaire : moins de SRE pour un service plus gros
Charge opérationnelle	Non bornée, croît avec le trafic	Plafonnée à 50 % (≥ 50 % d'ingénierie garanti)
Rapport au changement	Conflit structurel dev contre ops	Conflit résolu par le budget d'erreur
Vision de la panne	« Zéro panne » comme but	Panne attendue, gérée plutôt que crainte

Cette approche a de nets avantages : innovation rapide et grande acceptation du changement, équipes relativement peu coûteuses, mise à l'échelle sous-linéaire du nombre de SRE par rapport à la taille du système, et fin de la dysfonction dev/ops. Les transferts faciles entre développement produit et SRE forment de surcroît tout le monde. Le modèle a ses propres défis : le recrutement est ardu (la barre est haute à la fois en codage et en ingénierie système), et certaines décisions — comme geler les mises en production jusqu'à la fin du trimestre lorsqu'un budget d'erreur est épuisé — exigent un fort soutien du management pour être acceptées par le produit.

Les principes (tenets) du SRE

Au-delà des variations de flux et de priorités d'une équipe à l'autre, toutes les équipes SRE partagent la responsabilité de la disponibilité, de la latence, de la performance, de l'efficience, de la gestion du changement, de la surveillance, de la réponse d'urgence et de la planification de capacité de leurs services. Voici les principes correspondants.

Un engagement durable sur l'ingénierie. C'est le plafond de 50 % décrit plus haut, avec sa soupape de redirection. En régime opérationnel, un SRE d'astreinte devrait recevoir au maximum deux incidents par shift de 8 à 12 heures : assez pour traiter chacun correctement, restaurer le service, puis rédiger un post-mortem (postmortem). Au-delà, l'enquête bâcle et la fatigue d'alerte (pager fatigue) s'installe ; en deçà d'un incident par shift, l'astreinte gâche le temps de l'ingénieur. Tout incident significatif donne lieu à un post-mortem — y compris ceux qui n'ont pas déclenché d'alerte, d'autant plus précieux qu'ils révèlent une lacune de surveillance. Google pratique une culture du post-mortem sans blâme (blameless), qui cherche à exposer les défauts et à les corriger par l'ingénierie plutôt qu'à les masquer.

Maximiser la vélocité de changement sans violer le SLO, grâce au budget d'erreur (error budget). C'est l'idée la plus structurante. Elle part d'un constat : 100 % est le mauvais objectif de fiabilité pour à peu près tout (les stimulateurs cardiaques et les freins ABS font exception). Aucun utilisateur ne distingue un système disponible à 100 % d'un système à 99,999 % : entre lui et le service s'interposent son ordinateur, son WiFi, son FAI, le réseau électrique — autant de maillons collectivement bien moins fiables que 99,999 %. L'effort colossal pour gagner le dernier 0,001 % se perd dans le bruit.

Si 100 % est le mauvais objectif, quel est le bon ? Ce n'est pas une question technique, mais une question produit : quel niveau de disponibilité satisfait les utilisateurs vu leur usage ? quelles alternatives ont-ils en cas d'insatisfaction ? comment leur usage évolue-t-il selon le niveau de disponibilité ? Une fois la cible fixée par le métier, le budget d'erreur en découle :

budget d'erreur = 1 − objectif de disponibilité

Exemple : objectif 99,99 % de disponibilité
        →  indisponibilité tolérée = 0,01 %
        →  ce 0,01 % EST le budget d'erreur de la période.

On peut le dépenser comme on veut — tant qu'on ne le dépasse pas :
déploiements risqués, lancements rapides, expériences à 1 %,
déploiements progressifs (phased rollouts)...

Ce cadre dissout le conflit d'incitations. L'objectif du SRE n'est plus « zéro panne » : SRE et développeurs visent désormais ensemble à dépenser le budget d'erreur pour obtenir un maximum de vélocité fonctionnelle. Une panne cesse d'être « mauvaise » : elle devient une part attendue du processus d'innovation, que les deux équipes gèrent au lieu de la redouter.

La surveillance (monitoring). Une surveillance qui envoie un courriel dès qu'un seuil est franchi est fondamentalement défaillante : exiger qu'un humain lise un courriel et décide s'il faut agir ne tient pas. La surveillance ne devrait jamais demander à un humain d'interpréter quoi que ce soit — c'est au logiciel d'interpréter, et l'humain ne devrait être notifié que lorsqu'il doit agir. D'où trois sorties valides, et seulement trois :

Sortie	Sens	Délai d'action
Alerte (alert)	Un humain doit agir immédiatement sur quelque chose qui se produit ou va se produire	Tout de suite
Ticket (ticket)	Un humain doit agir, mais pas dans l'urgence ; sans dommage si traité sous quelques jours	Différé
Journal (logging)	Personne ne le lit ; conservé à des fins de diagnostic ou de forensique	Aucune (consulté à la demande)

La réponse d'urgence (emergency response). La fiabilité est fonction du temps moyen entre pannes (MTTF) et du temps moyen de réparation (MTTR) ; la métrique la plus pertinente pour juger la réponse d'urgence est le MTTR — à quelle vitesse l'équipe ramène le système à la santé. Or les humains ajoutent de la latence : un système qui évite l'intervention humaine sera plus disponible, même s'il connaît davantage de défaillances réelles. Quand l'humain est nécessaire, un guide d'intervention (playbook) rédigé à l'avance produit une amélioration du MTTR d'environ 3× par rapport à l'improvisation. À cela s'ajoutent des exercices comme la « Roue de l'Infortune » (Wheel of Misfortune) pour entraîner les ingénieurs d'astreinte.

La gestion du changement (change management). Environ 70 % des pannes proviennent d'un changement sur un système en service. Les bonnes pratiques s'appuient sur l'automatisation pour : déployer progressivement, détecter vite et précisément les problèmes, et revenir en arrière (rollback) sans risque quand un souci surgit. En retirant l'humain de la boucle, on évite la fatigue, l'excès de confiance et l'inattention propres aux tâches répétitives — gagnant à la fois en vélocité et en sûreté.

La prévision de la demande et la planification de capacité (capacity planning) doivent garantir une capacité suffisante, redondante, pour servir la demande future au niveau de disponibilité requis. Elles exigent une prévision exacte de la croissance organique (adoption naturelle) et inorganique (lancements, campagnes marketing), et des tests de charge réguliers pour relier la capacité brute (serveurs, disques) à la capacité de service. Parce que la capacité conditionne la disponibilité, le SRE en a la charge — donc aussi du provisionnement.

Le provisionnement combine gestion du changement et planification de capacité. Il doit être rapide, fait seulement quand c'est nécessaire (la capacité coûte cher), et correct (sinon elle ne tient pas le jour J). Ajouter de la capacité — démarrer une instance ou un site, reconfigurer répartiteurs de charge et réseau, valider les résultats — est plus risqué qu'un simple déplacement de charge (load shifting), opéré plusieurs fois par heure ; il appelle donc une prudence accrue.

L'efficience et la performance (efficiency and performance). Comme le SRE contrôle le provisionnement, il doit s'impliquer dans l'utilisation des ressources, qui dépend du fonctionnement et du dimensionnement du service. L'usage des ressources est fonction de la demande (charge), de la capacité et de l'efficience logicielle — trois leviers que le SRE manie (prévoir, provisionner, modifier le code). Un système ralentit quand la charge monte ; un ralentissement équivaut à une perte de capacité, et un système assez lent finit par ne plus servir (lenteur infinie). Le SRE provisionne pour atteindre une cible de capacité à une vitesse de réponse donnée — d'où son intérêt aigu pour la performance.

L'environnement de production Google, vu par un SRE

Le reste de l'ouvrage suppose un vocabulaire propre à Google. Premier point : on distingue rigoureusement le matériel du logiciel. Une machine (machine) est un bout de matériel (ou une VM) ; un serveur (server) est un bout de logiciel qui implémente un service. N'importe quelle machine peut faire tourner n'importe quel serveur : aucune machine n'est dédiée à un programme particulier — l'allocation des ressources revient au système d'exploitation de cluster, Borg.

PILE DE PRODUCTION GOOGLE (du matériel vers les applications)

Campus                  plusieurs bâtiments proches
  └─ Bâtiment           plusieurs clusters
       └─ Cluster       une ou plusieurs rangées de racks
            └─ Rangée   plusieurs racks
                 └─ Rack   dizaines de machines (commutateur top-of-rack)

Réseau    Jupiter (fabric Clos intra-DC, jusqu'à 1,3 Pbps de bissection)
          B4 (backbone mondial inter-DC, SDN/OpenFlow)
          BwE (Bandwidth Enforcer : alloue la bande passante)
          GSLB (équilibrage de charge global, 3 niveaux)

Orchestration   Borg  →  jobs  →  tasks  (binpacking, domaines de panne)
                BNS (Borg Naming Service : nom de task → IP:port)
                Chubby (verrous, élection de maître, Paxos)
                Borgmon (surveillance : scrape de métriques)

Stockage   D (fileserver par machine, disques + flash)
            └─ Colossus (système de fichiers cluster, succ. de GFS)
                 ├─ Bigtable (NoSQL pétaoctets, cohérence à terme)
                 ├─ Spanner (interface SQL, cohérence mondiale)
                 └─ Blobstore, etc.

Logiciel   Protocol buffers (sérialisation) · RPC Stubby (gRPC) · GFE (reverse proxy)
            Dépôt unique partagé · revue de code (CL) · build & tests distribués

Organiser le matériel : Borg, BNS, le réseau

Les pannes matérielles sont gérées par logiciel, car elles sont fréquentes : dans un seul cluster, sur une année type, des milliers de machines et de disques tombent en panne. Borg est un système d'exploitation de cluster distribué (proche d'Apache Mesos, et ancêtre de Kubernetes). Il fait tourner des jobs — serveurs perpétuels ou traitements par lots type MapReduce —, chaque job se composant d'une à des milliers de tasks identiques, pour la fiabilité et parce qu'un seul processus n'absorbe pas tout le trafic. Borg trouve les machines, lance les programmes, surveille en continu ; si une task défaille, elle est tuée et redémarrée, possiblement ailleurs.

Comme les tasks se déplacent entre machines, on ne peut les désigner par IP et port. Le Borg Naming Service (BNS) ajoute un niveau d'indirection : Borg attribue à chaque task un nom et un index ; les autres processus se connectent via le nom BNS (du type /bns/cluster/utilisateur/nom-du-job/numero-de-task), résolu en IP:port. Borg gère aussi l'allocation des ressources : chaque job déclare ses besoins (cœurs CPU, RAM), et Borg empile (binpacking) les tasks de façon optimale en tenant compte des domaines de panne — il ne placera pas toutes les tasks d'un job sur le même rack, car le commutateur de tête de rack serait alors un point unique de défaillance. Une task qui dépasse les ressources demandées est tuée et redémarrée.

Côté réseau, Google emploie un réseau défini par logiciel (SDN) fondé sur OpenFlow : du matériel de commutation « bête » et bon marché, piloté par un contrôleur central (dupliqué) qui précalcule les meilleurs chemins. À l'intérieur d'un datacenter, Jupiter est un très grand commutateur virtuel en fabric Clos, supportant jusqu'à 1,3 Pbps de bande passante de bissection. Entre datacenters, le backbone mondial B4 (SDN/OpenFlow) délivre une bande passante massive à un nombre modeste de sites avec allocation élastique. Le Bandwidth Enforcer (BwE) répartit la bande passante comme Borg répartit le calcul. Enfin, le Global Software Load Balancer (GSLB) équilibre la charge à trois niveaux : géographique pour le DNS, au niveau d'un service utilisateur (YouTube, Maps), et au niveau des appels RPC.

Stockage, surveillance, infrastructure logicielle

Le stockage est en couches. Tout en bas, D est un fileserver présent sur presque toutes les machines (disques tournants et flash). Au-dessus, Colossus crée un système de fichiers à l'échelle du cluster — sémantique de fichiers classique, réplication, chiffrement — successeur de GFS. Au-dessus encore, plusieurs services de bases de données : Bigtable (NoSQL pétaoctets, carte multidimensionnelle triée, cohérence à terme et réplication inter-datacenters) et Spanner (interface SQL avec vraie cohérence à l'échelle mondiale), entre autres. La surveillance repose sur de nombreuses instances de Borgmon, qui « scrape » régulièrement les métriques des serveurs surveillés, pour l'alerte instantanée comme pour les historiques essentiels à la planification de capacité.

L'infrastructure logicielle est pensée pour exploiter au mieux le matériel. Le code est fortement multithreadé ; chaque serveur expose un serveur HTTP de diagnostics. Toute la communication passe par l'infrastructure d'appel de procédure distant Stubby (dont gRPC est la version open source) — on fait souvent un RPC même là où un appel local suffirait, pour pouvoir refactoriser plus tard vers un autre serveur. Les données transitent en protocol buffers (protobufs), 3 à 10× plus compacts et 20 à 100× plus rapides que XML. Côté développement, à part quelques exceptions (Android, Chrome), les ingénieurs travaillent depuis un dépôt unique partagé : tout changement passe en revue (une changelist, ou CL), les builds s'exécutent en parallèle sur des serveurs de datacenter, et chaque CL déclenche des tests continus sur tout ce qui en dépend ; certains projets pratiquent le push-on-green (mise en production automatique après tests verts).

Le service fil rouge : Shakespeare

Pour incarner tout cela, le livre suit un service hypothétique : déterminer où un mot donné apparaît dans toute l'œuvre de Shakespeare. Il se divise en deux. Un composant par lots (un MapReduce) lit les textes, en construit un index et l'écrit dans un Bigtable — exécuté une fois, ou très rarement. Le MapReduce a trois phases : map (lire les textes et les découper en mots, en parallèle), shuffle (trier les tuples par mot), reduce (produire des tuples (mot, liste de positions) écrits chacun dans une ligne du Bigtable, le mot servant de clé). Un frontend applicatif sert ensuite les requêtes utilisateur, toujours actif.

VIE D'UNE REQUÊTE — shakespeare.google.com (quelques centaines de ms)

(1) Le navigateur résout le DNS → serveur DNS de Google ↔ GSLB
    (GSLB connaît la charge des frontends par région → choisit une IP)
(2) Connexion HTTP au GFE (Google Frontend), reverse proxy qui termine le TCP ;
    le GFE identifie le service requis (ici Shakespeare)
(3) Via GSLB, le GFE trouve un frontend Shakespeare dispo → lui envoie un RPC
(4) Le frontend construit un protobuf (le mot cherché) ;
    via GSLB il obtient l'adresse BNS d'un backend Shakespeare peu chargé
(5) Ce backend interroge un serveur Bigtable pour les données
    → réponse en protobuf remontée backend → frontend → HTML → utilisateur

Beaucoup de maillons, donc beaucoup de points de défaillance possibles — un GSLB en panne ferait des ravages. Mais des tests rigoureux, un déploiement prudent et la dégradation gracieuse (graceful degradation) permettent de tenir la fiabilité attendue. La planification le montre concrètement : le backend tenant ~100 requêtes par seconde (QPS) et le pic attendu étant ~3 470 QPS, il faut au moins 35 tasks — mais on en prévoit 37 (N + 2), car une task est indisponible pendant les mises à jour et une panne machine peut survenir au même moment. Le trafic étant réparti dans le monde, on distribue les backends par région avec une redondance N + 2 (17 tasks aux USA, 16 en Europe, 6 en Asie) — sauf en Amérique du Sud où l'on accepte N + 1 (4 tasks) pour économiser 20 % de matériel, quitte à tolérer un petit risque de latence si GSLB redirige le trafic. Enfin, on réplique le Bigtable dans chaque région : un backend asiatique contactant un Bigtable américain ajouterait trop de latence, et la réplication offre en prime de la résilience.

Le SRE représente une rupture nette avec les pratiques établies de gestion des grands services. Né d'une intuition simple — « voici comment, en tant qu'ingénieur logiciel, je voudrais investir mon temps pour des tâches répétitives » —, il est devenu un ensemble de principes, de pratiques, d'incitations, et un champ à part entière du génie logiciel. Le reste de l'ouvrage en détaille la voie.

À retenir

• Le SRE, c'est « ce qui arrive quand on demande à un ingénieur logiciel de concevoir une équipe d'exploitation » (Ben Treynor Sloss) : on remplace le travail manuel des sysadmins par du logiciel, écrit par des ingénieurs.
• Le modèle sysadmin souffre de coûts directs (l'équipe croît linéairement avec la charge) et indirects (conflit structurel dev/ops sur la vitesse de mise en production, source de pannes) ; le SRE met à l'échelle sous-linéairement et dissout ce conflit.
• Le dispositif central est le plafond de 50 % sur le travail opérationnel (≥ 50 % d'ingénierie garanti), mesuré et appliqué par redirection de la charge ops vers le développement : on vise des systèmes automatiques, pas seulement automatisés.
• Le budget d'erreur (error budget = 1 − SLO) part du fait que 100 % est le mauvais objectif de fiabilité ; il transforme la panne en ressource à dépenser pour maximiser la vélocité, alignant enfin SRE et développeurs.
• Les principes (tenets) couvrent ingénierie durable, vélocité sans violer le SLO, surveillance (alerte / ticket / journal, jamais d'interprétation humaine), réponse d'urgence (MTTR, playbooks ~3× meilleurs), gestion du changement (~70 % des pannes viennent d'un changement), prévision/capacité, provisionnement, efficience.
• Le SRE est une implémentation concrète de la philosophie DevOps, avec ses extensions propres (plafond opérationnel, budget d'erreur, post-mortems sans blâme).
• L'environnement de production Google distingue machine (matériel) et serveur (logiciel), et repose sur Borg (jobs/tasks, binpacking, domaines de panne), BNS, Chubby (verrous/élection, Paxos), le stockage (D → Colossus → Bigtable/Spanner), le réseau (Jupiter, B4, GSLB) et l'infra logicielle (protobufs, RPC Stubby, dépôt unique) — illustrés par le service fil rouge Shakespeare.