Tester la fiabilité et l'ingénierie logicielle en SRE

L'une des responsabilités cardinales du SRE est de quantifier la confiance que l'on peut accorder aux systèmes que l'on maintient. Cette confiance se mesure dans deux directions : la fiabilité passée, lue dans les données de la supervision (monitoring) d'un comportement historique, et la fiabilité future, déduite par projection de ces mêmes données. Pour qu'une telle prédiction soit assez solide pour être utile, il faut soit que le site reste rigoureusement inchangé dans le temps, soit que l'on sache décrire avec certitude tous les changements apportés. C'est précisément le rôle du test (testing) : démontrer qu'à chaque changement, certaines zones d'équivalence sont préservées. Ce chapitre couvre d'abord les niveaux de test au service de la fiabilité — jusqu'aux tests menés directement en production — puis bascule sur une facette moins attendue du métier : le SRE n'est pas seulement un exploitant, il construit du logiciel, comme l'illustre le projet Auxon.

Le test, mécanisme de réduction de l'incertitude

Chaque test qui passe avant et après un changement réduit l'incertitude que l'analyse doit absorber. Plus la part du code couverte par des tests croît, plus la baisse de fiabilité potentielle induite par chaque modification diminue — donc plus l'on peut multiplier les changements avant que la fiabilité prédite n'approche son seuil d'acceptabilité. Quand ce seuil approche, mieux vaut suspendre les changements le temps que de nouvelles données de supervision s'accumulent et viennent valider les chemins d'exécution révisés. La quantité de tests nécessaire dépend donc directement des exigences de fiabilité : un système critique pour la vie ou le chiffre d'affaires réclame une couverture bien supérieure à un script jetable à courte durée de vie.

Les tests traditionnels : une hiérarchie

Les tests logiciels se rangent en deux grandes familles : les tests traditionnels, qui évaluent hors ligne la justesse du code pendant le développement, et les tests de production, qui vérifient sur un service vivant qu'un système déployé fonctionne correctement. Les tests traditionnels s'empilent en une hiérarchie, du plus petit au plus large.

                  ┌──────────────────────────┐
                  │   Tests SYSTÈME           │   end-to-end, lents, coûteux
                  │  (smoke, perf, régression)│
              ┌───┴──────────────────────────┴───┐
              │      Tests d'INTÉGRATION          │   composants assemblés
          ┌───┴───────────────────────────────────┴───┐
          │            Tests UNITAIRES                  │   rapides, nombreux
          └─────────────────────────────────────────────┘
   coût & durée croissants vers le haut · nombre de tests croissant vers le bas

Le test unitaire (unit test) est la forme la plus petite et la plus simple : il évalue une unité séparable — une classe, une fonction — indépendamment du système qui la contient. Il sert aussi de spécification vivante, garantissant qu'une fonction exécute exactement le comportement attendu ; c'est le socle du développement piloté par les tests (test-driven development). Le test d'intégration (integration test) assemble des composants ayant passé leurs tests unitaires et vérifie qu'ils coopèrent ; l'injection de dépendances (dependency injection) y est une technique puissante pour substituer aux dépendances complexes des doublures (mocks) au comportement précisément spécifié — par exemple remplacer une base de données à état par une simple maquette. Le test système (system test) est le plus large que l'on exécute sur un système non encore déployé : il vérifie la fonctionnalité de bout en bout. Il se décline en plusieurs saveurs.

Type de test	Échelle	Ce qu'il trouve
Unitaire (unit)	Une classe, une fonction	Erreurs de logique locale ; sert aussi de spécification du comportement attendu
Intégration (integration)	Composants assemblés	Mauvaise coopération entre modules ; contrats d'interface rompus
Système (system)	Système complet, de bout en bout	Régressions globales ; comportement end-to-end incorrect
Fumée (smoke / sanity)	Comportement critique, très simple	Logiciel « manifestement cassé » ; court-circuite des tests plus coûteux
Performance (performance)	Système sur tout son cycle de vie	Dégradation lente : 8 Go → 32 Go de mémoire, 10 ms → 50 ms → 100 ms de latence
Régression (regression)	Système ou intégration	Réapparition de bugs déjà corrigés (une « galerie de bugs notoires »)

Le test de fumée vérifie un comportement critique mais minimal ; c'est l'un des plus simples et il court-circuite des tests plus onéreux quand le système est déjà cassé. Le test de performance garantit qu'un système ne devient pas insidieusement plus lent ou plus gourmand au fil du développement, avant d'atteindre les utilisateurs. Le test de régression se compare à une galerie de bugs historiques : en documentant chaque défaut passé sous forme de test, on s'assure qu'un futur remaniement ne réintroduit pas un problème déjà éliminé à grands frais.

Les tests en production : sortir du bocal hermétique

On répète souvent que les tests devraient se dérouler dans un environnement hermétique (hermetic). Or la production, elle, ne l'est jamais : les déploiements la modifient en continu, par petits incréments bien compris, en décalant progressivement les utilisateurs et en surveillant chaque étape. L'environnement de production n'est donc volontairement représentatif d'aucune version précise d'un binaire figé en gestion de version — il peut même coexister plusieurs versions d'un binaire et de sa configuration. C'est pourquoi les tests de production, parents proches de la supervision « boîte noire » (black-box monitoring), sont indispensables et irremplaçables.

Test de production	Question à laquelle il répond
Test de configuration (configuration test)	Le binaire en production est-il configuré comme le décrit le fichier versionné ?
Test de charge / stress (stress test)	Jusqu'où peut-on aller avant la rupture : combien de requêtes par seconde, base de données pleine à quel point ?
Sonde de production (production probe)	La combinaison frontal/dorsal réellement servie reste-t-elle équivalente à celle testée en release ?
Canari (canary)	Une fraction du trafic réel révèle-t-elle un défaut avant le déploiement complet ?

Le test de configuration examine la production pour rapporter les écarts entre la configuration effective d'un binaire et son fichier de référence en gestion de version. Intrinsèquement non hermétique, il est d'autant plus précieux dans une solution de supervision distribuée : le motif des succès et des échecs à travers la production révèle les chemins de la pile qui combinent mal les configurations locales. Le test de stress cerne les limites du système, car nombre de composants ne se dégradent pas en douceur au-delà d'un certain point — ils cassent catastrophiquement : à quel taux de remplissage une base refuse-t-elle les écritures ? à combien de requêtes par seconde un serveur applicatif s'effondre-t-il ?

La règle empirique de Google illustre la prudence du déploiement canari : commencer à 0,1 % du trafic, puis monter d'un ordre de grandeur toutes les 24 heures (jour 2 : 1 %, jour 3 : 10 %, jour 4 : 100 %) en variant la localisation géographique des serveurs mis à niveau. Le livre va plus loin et propose un modèle quantitatif : pour un déploiement exponentiel, le nombre cumulé d'anomalies signalées permet d'estimer l'ordre du défaut sous-jacent. La plupart des bugs sont d'ordre 1 — leur impact croît linéairement avec le trafic, et on les retrouve facilement en transformant les requêtes aux réponses anormales en tests de régression. Les bugs d'ordre supérieur (une requête qui corrompt des données qu'une requête future verra) sont bien plus retors : un déroulé qui échoue dans l'ordre passe soudain si l'on omet certaines requêtes. Il est vital de les attraper dès le déploiement, sous peine de voir la charge opérationnelle exploser.

Tester à l'échelle, et tester les outils du SRE

Avant même de tester à grande échelle, encore faut-il bâtir un environnement de test et de build. Le SRE rejoint souvent une équipe alors que le projet est déjà bien avancé et que la couverture est faible, voire nulle : viser d'emblée un test unitaire pour chaque fonction est alors écrasant. Mieux vaut commencer par ce qui rapporte le plus pour le moindre effort, en priorisant le code — car si tout est prioritaire, rien ne l'est : on classe les composants par importance, on isole les fonctions critiques pour la vie ou le chiffre d'affaires (la facturation, par exemple, souvent nettement séparable), et l'on identifie les API contre lesquelles d'autres équipes s'intègrent. Quelques tests de fumée à exécuter à chaque release, puis la conversion systématique de chaque bug rapporté en cas de test, ouvrent la voie à une suite de régression complète. Le socle de toute cette démarche est un système de gestion de version doublé d'un build continu qui reconstruit et teste à chaque soumission : dès qu'un changement casse le projet, l'ingénieur en est averti et lâche tout pour réparer, car la dernière version doit toujours fonctionner intégralement. C'est ici que se révèle un insight contre-intuitif : stabilité et agilité sont traditionnellement en tension, mais la stabilité du build est précisément ce qui dope l'agilité — quand le build est fiable et prévisible, les développeurs itèrent plus vite (« stability drives agility »).

Un petit test unitaire dépend d'une courte liste d'éléments : un fichier source, la bibliothèque de test, les bibliothèques d'exécution, le compilateur, le matériel local. Un environnement robuste exige que chacune de ces dépendances ait elle-même sa couverture ; sinon, un changement sans rapport dans l'environnement peut faire passer un test indéfiniment alors même que le code testé est fautif. À l'inverse, un test de release peut dépendre transitivement de chaque objet du dépôt : en principe, chaque correctif imposerait une itération complète de reprise après sinistre. En pratique, on choisit des points de branchement parmi les versions et les fusions, de façon à lever le maximum d'incertitude dépendante pour le minimum d'itérations.

Les outils que développent les SRE — récupérer et propager des métriques, prévoir l'usage pour la capacité, remanier des données dans une réplique non servie, modifier des fichiers sur un serveur — sont aussi du logiciel et exigent donc des tests. Les outils d'automatisation posent un problème plus subtil encore : l'opération qu'ils réalisent s'effectue contre une API robuste et bien testée, mais leur finalité est un effet de bord — une discontinuité invisible pour un autre client de l'API. On teste alors que l'état interne, vu à travers l'API, reste constant de part et d'autre de l'opération.

Les outils d'automatisation peuvent même se déplacer ou se mettre à niveau les uns les autres — un outil de rééquilibrage de conteneurs voudra déplacer l'outil de mise à niveau de flotte, qui devra à son tour mettre à niveau le rééquilibreur : cette dépendance circulaire reste saine si les API ont une sémantique de redémarrage testée et si la santé des points de contrôle (checkpoints) est garantie indépendamment. Pour les outils de reprise après sinistre, le plus sûr est de les concevoir hors ligne : calculer un état de point de contrôle équivalent à un arrêt propre, le rendre chargeable par les outils de validation existants, puis déclencher une procédure de démarrage propre — chaque phase devient alors facile à tester avec une excellente couverture. Enfin, des techniques statistiques — Lemon pour le fuzzing, Chaos Monkey et Jepsen pour l'état distribué — ne sont pas des tests reproductibles : rejouer un test après correction ne prouve pas que le défaut est réglé, mais le journal des actions aléatoires (parfois la simple graine du générateur) aide à cerner les zones suspectes du code.

Le besoin de vitesse, et le passage en production

Pour chaque version du dépôt, chaque test rend un verdict — qui peut varier d'une exécution à l'autre, identique en apparence. Estimer la vraie probabilité de succès de chaque test à chaque version est impossible à calculer en pratique ; on forme donc des hypothèses sur les scénarios intéressants et on répète juste ce qu'il faut pour une inférence raisonnable. L'enjeu d'échelle est vertigineux : l'auteur prend l'exemple d'un service à plus de 21 000 tests simples. Pour valider un correctif, on compare le vecteur des verdicts avant et après. À quel taux peut-on rejeter à tort un correctif parfait par simple instabilité (flakiness) des tests ? Si rejeter 1 correctif sur 10 ferait hurler les ingénieurs, en rejeter 1 sur 100 passerait inaperçu. Or, comme le verdict dépend de l'ensemble des tests avant et après, cela revient à exiger que chaque test individuel soit correct plus de 99,9999 % du temps.

   On tolère de rejeter à tort 1 correctif sur 100, soit 0,99 de correctifs acceptés.
   Chaque correctif est jugé sur 2 × 21 000 = 42 000 verdicts
   (un par test avant le correctif, un par test après).

   fiabilité requise par test = (0,99) ^ (1 / 42 000)  ≈  99,9999 %

La séparation entre infrastructure de test et configuration de production est, dans le modèle SRE, particulièrement néfaste : elle empêche de relier le modèle décrivant la production à celui décrivant le comportement applicatif, et donc d'éliminer le risque de migration. On vise au contraire un versionnage et un test unifiés. Les fichiers de configuration méritent une vigilance graduée : celui qui n'existe que pour garder un MTTR bas, modifié seulement lors d'une panne, a une cadence plus lente que le MTBF ; mais celui qui change plus souvent qu'une release applicative (parce qu'il porte de l'état de release) dominera négativement la fiabilité s'il n'est pas testé et supervisé aussi rigoureusement que l'application elle-même.

Enfin, les sondes de production comblent un dernier angle mort. En scindant les requêtes connues en « mauvaises requêtes » (qui doivent échouer), « bonnes requêtes rejouables en production » et « bonnes requêtes non rejouables », on obtient un jeu utilisable à la fois en intégration, en release et en supervision. Or la sonde tourne dans une configuration jamais testée auparavant : le test de release enveloppait le serveur d'un frontal réel et d'un dorsal factice, tandis que la sonde l'enveloppe d'un répartiteur de charge et d'un stockage persistant réels, frontal et dorsal ayant des cycles de release indépendants. Une sonde ne devrait jamais échouer ; si elle échoue, c'est que les API du frontal ou du dorsal ne sont plus équivalentes entre production et release — le site est probablement cassé. Le système de mise à jour qui remplace progressivement l'application remplace aussi les sondes, génère en continu les quatre combinaisons ancien/nouveau, détecte celle qui produit des erreurs et revient à l'état sain : aucun trafic utilisateur n'est jamais routé vers la version défaillante.

Le SRE bâtit du logiciel

Demandez un projet d'ingénierie de Google et l'on citera Gmail, Maps, voire Bigtable ou Colossus. Pourtant, une masse de logiciel invisible soutient la production — l'une des machines les plus complexes jamais bâties par l'humanité — et une bonne part naît au sein du SRE : mécanismes de déploiement de binaires, supervision, environnements de développement à composition dynamique. Ce ne sont pas des bricolages ponctuels mais des projets d'ingénierie à part entière, portés par un état d'esprit produit qui tient compte des clients internes et d'une feuille de route.

Pourquoi le SRE est-il si bien placé pour ce travail ? D'abord parce que l'échelle de Google a souvent rendu le développement interne inévitable, peu d'outils tiers étant pensés pour de tels volumes. Ensuite parce que les SRE conjuguent une connaissance intime de la production — d'où une attention native à la scalabilité, à la dégradation gracieuse et à l'interfaçage — avec une relation directe au public visé : leurs pairs SRE. Ces utilisateurs internes donnent un retour franc et à fort signal, et tolèrent les premières versions rugueuses, ce qui permet de lancer et d'itérer vite. Enfin, un principe directeur du SRE le commande : « la taille de l'équipe ne doit pas croître proportionnellement à celle du service ». Soutenir une croissance exponentielle des services avec une équipe à croissance linéaire impose un travail perpétuel d'automatisation et de rationalisation des outils. Au passage, ces projets offrent aux ingénieurs un équilibre salutaire face aux interruptions et à l'astreinte (on-call), entretiennent leurs compétences de code et attirent une diversité de profils qui prévient les angles morts.

Étude de cas : Auxon et la planification de capacité fondée sur l'intention

La planification de capacité (capacity planning) traditionnelle tourne en un cycle sans fin : collecter des prévisions de demande, élaborer des plans d'achat et d'allocation, faire valider, déployer et configurer. Ce cycle est fragile — la moindre variation (baisse d'efficacité d'un service, hausse d'adoption, retard de livraison d'un cluster, changement d'objectif de performance) oblige à revérifier tout le plan, voire à le refaire entièrement, chaque trimestre s'appuyant sur le résultat attendu des précédents. Il est aussi laborieux et imprécis : le rangement optimal (bin packing) est un problème NP-difficile que l'humain calcule mal à la main, dans des tableurs qui ne passent pas à l'échelle. Et la demande arrive sous une forme rigide — « X cœurs dans le cluster Y » — dont les raisons et les degrés de liberté ont été perdus en chemin.

La réponse de Google : la planification de capacité fondée sur l'intention (intent-based capacity planning), résumée par la formule « spécifie les exigences, pas l'implémentation ». On encode programmatiquement les dépendances et paramètres — l'intention (intent) — du service, et l'on en autogénère un plan d'allocation. Si la demande, l'offre ou les exigences changent, on régénère simplement le plan optimal. L'intention se décline en niveaux d'abstraction croissants.

Niveau 1  « Je veux 50 cœurs dans les clusters X, Y, Z pour Foo. »
            → demande explicite, rigide. Mais pourquoi ces clusters ?
Niveau 2  « Je veux 50 cœurs dans 3 clusters quelconques de la région YYY. »
            → plus de liberté, mais le raisonnement reste opaque.
Niveau 3  « Je veux couvrir la demande de Foo par région, avec redondance N+2. »
            → souplesse réelle ; on comprend l'enjeu en termes « humains ».   ◄── meilleur ratio
Niveau 4  « Je veux faire tourner Foo à 5 nines de fiabilité. »
            → exigence abstraite ; la conséquence d'un échec est limpide.

D'après l'expérience de Google, c'est en franchissant le niveau 3 que les services tirent le meilleur parti : la souplesse est suffisante et les conséquences s'expriment en termes compréhensibles. Trois ingrédients sont nécessaires pour capter l'intention : les dépendances (Foo exige que Bar soit à moins de 30 ms de latence réseau, et ces dépendances sont imbriquées), les métriques de performance (combien de ressources pour servir N requêtes ? combien de Mbps vers Bar pour N requêtes de Foo ? — c'est la « colle » qui convertit un type de ressource de haut niveau en types de plus bas niveau), et la priorisation, qui force des arbitrages transparents lorsque la capacité est insuffisante (N+2 pour Foo vaut-il mieux que N+1 pour Bar ?).

Auxon est l'implémentation Google de cette approche : un produit conçu et développé en SRE par une petite équipe d'ingénieurs et un chef de programme technique en deux ans, qui planifie aujourd'hui des millions de dollars de ressources machine. Il collecte les descriptions d'intention via un langage de configuration ou une API, les traduit en contraintes, et les résout comme un vaste programme linéaire (ou en nombres entiers mixtes) pour produire un plan d'allocation.

   Données de    Prévisions de    Offre de        Tarifs des
   performance   demande/service  ressources      ressources
       └──────────────┬──────────────┴──────────────┘
                      ▼
              Config d'intention  ──►  Moteur de langage de config
              (lisible par l'humain)        (produit une requête
                                             machine = protobuf)
                                                   │
                                                   ▼
                                          ┌──────────────────┐
                                          │  Solveur Auxon    │  ← le « cerveau »,
                                          │ (prog. linéaire,  │    massivement parallèle
                                          │  parallélisable)  │
                                          └────────┬──────────┘
                                                   ▼
                                          Plan d'allocation
                                  (quelles ressources, quels services,
                                   quels lieux — + exigences non satisfaites)

La délégation du bin packing aux machines réduit drastiquement la peine (toil) : les propriétaires de services se concentrent sur les priorités de haut niveau — SLO, dépendances de production, infrastructure — au lieu de gratter des ressources à bas niveau. Et l'optimisation computationnelle atteint une précision bien supérieure, génératrice d'économies réelles.

Les leçons d'Auxon, et comment cultiver l'ingénierie en SRE

Tout au long du développement, l'équipe Auxon est restée immergée dans la production : elle a conservé son rôle dans les rotations d'astreinte de plusieurs services Google. Elle était ainsi à la fois consommatrice et conceptrice de son propre produit — quand il échouait, elle en subissait directement les conséquences, ce qui ancrait les demandes de fonctionnalités dans le vécu et conférait au produit crédibilité et légitimité au sein du SRE. Plusieurs enseignements se dégagent.

• Approximer pour avancer. Le monde de la programmation linéaire étant inconnu de l'équipe, elle a d'abord bâti un « solveur stupide » (Stupid Solver) à base d'heuristiques simples, jamais optimal mais suffisant pour prouver la faisabilité de la vision. L'interface du solveur étant abstraite, il fut ensuite trivial de le remplacer par un solveur plus intelligent. Le mot d'ordre : lancer et itérer (launch and iterate), sans attendre la perfection.
• Concevoir générique et modulaire face aux exigences floues. Plutôt que de s'intégrer à chaque outil d'automatisation, Auxon a façonné un plan d'allocation universellement utilisable — une approche « agnostique » résumée par « viens comme tu es, on travaillera avec ce que tu as », qui a abaissé la barrière d'entrée et élargi l'adoption.
• Susciter l'adoption demande un effort soutenu. Une simple présentation ne suffit pas : il faut une approche cohérente, le plaidoyer des utilisateurs et le parrainage de l'encadrement, de la documentation, et un service client en gants blancs pour les premiers adoptants — y compris pour apaiser la crainte « qu'un script remplace mon poste ».
• Ajuster les attentes. Distinguer les buts aspirationnels du produit minimum viable (minimum viable product) ; un projet meurt en promettant trop, trop tôt. Auxon a marié une feuille de route à long terme et des gains immédiats, et a délibérément ciblé d'abord les équipes sans aucun processus existant de planification de capacité, transformant leurs premiers succès en plaidoyers.

Pour instaurer durablement cette culture, deux conditions priment. La dotation : constituer une équipe-germe mêlant généralistes capables de monter vite en compétence et spécialistes (statistiques, optimisation, recherche opérationnelle), tout en s'associant à des chefs de produit familiers du développement orienté utilisateur — un ingénieur SRE résumait l'écart culturel par : « J'ai un document de conception ; pourquoi faut-il des exigences ? ». Le temps dédié : un temps de projet ininterrompu, défendu avec vigueur, car on n'écrit pas de code utile en alternant entre tâches toutes les heures. Le point crucial, répété par le livre : les SRE engagés dans le développement doivent continuer à exercer comme SRE plutôt que devenir des développeurs à plein temps — leur immersion dans la production est une perspective irremplaçable, puisqu'ils sont à la fois créateurs et clients de leur produit. Et, surtout, ne baissez pas vos standards : revue de code, tests d'intégration et bout en bout, revue de production-readiness par une autre équipe — la crédibilité est longue à bâtir, courte à perdre. Le succès n'est pas l'adoption à 100 % : la dernière ligne droite offre souvent des rendements décroissants. La preuve par l'exemple : un répartiteur de charge de niveau 3 développé par des SRE a si bien réussi qu'il est devenu un produit grand public, Google Cloud Load Balancer.

À retenir

• Le test sert à quantifier la confiance : chaque test qui passe avant et après un changement réduit l'incertitude ; un test à MTTR nul (qui bloque la mise en production) augmente le MTBF vécu par les utilisateurs.
• Les tests traditionnels forment une hiérarchie — unitaires (rapides, nombreux, peu chers), d'intégration, puis système (smoke, performance, régression : larges, lents, coûteux) — et l'on arbitre toujours le compromis confiance / coût.
• Les tests de production sortent du bocal hermétique : tests de configuration (écarts binaire/fichier versionné), de stress (limites avant rupture catastrophique), sondes de production, et le canari (0,1 % du trafic puis montée par ordres de grandeur) qui est une acceptation utilisateur structurée, non un test parfait.
• Les outils du SRE sont du logiciel et doivent être testés ; les outils d'automatisation, dont la finalité est un effet de bord, exigent des barrières de protection et un soin particulier (hors ligne, points de contrôle, sémantique de redémarrage).
• À l'échelle de 21 000 tests, garantir un faible taux de faux rejets impose une fiabilité par test > 99,9999 % ; on délivre les verdicts avant le changement de contexte, et le bris de glace doit rester bruyant et faire l'objet d'une annotation rétroactive.
• Le SRE construit du logiciel, pas seulement de l'ops : sa connaissance de la production et son lien direct avec ses pairs en font un développeur d'outils légitime — condition pour que l'équipe ne croisse pas linéairement avec les services.
• Auxon illustre la planification de capacité fondée sur l'intention : on spécifie l'intention (dépendances, métriques, priorisation), un solveur de programmation linéaire résout le bin packing, et l'on récolte un plan d'allocation — guidé par « approximer, lancer et itérer », en restant immergé dans la production et sans jamais baisser les standards.