Accepter le risque : error budgets et SLO

On pourrait croire que Google cherche à bâtir des services fiables à 100 %, qui ne tombent jamais. Or, au-delà d'un certain point, accroître la fiabilité dégrade le service plutôt qu'il ne l'améliore — pour l'entreprise comme pour ses utilisateurs. C'est le paradoxe fondateur du SRE, et la matière des chapitres « Accepter le risque » (Embracing Risk) et « Objectifs de niveau de service » (Service Level Objectives) du livre de Google. Là où The DevOps Handbook prônait un flux rapide et Accelerate démontrait par la recherche que vitesse et stabilité vont de pair, le SRE apporte ici l'instrumentation conceptuelle qui rend cet équilibre opérationnel : on mesure le risque, on le budgète, et on s'en sert pour arbitrer — sans politique, sans peur, sans espoir.

100 % est le mauvais objectif

Pourquoi la fiabilité extrême est-elle néfaste ? D'abord parce qu'elle a un coût qui ne croît pas linéairement. L'expérience de Google montre qu'un gain incrémental de fiabilité peut coûter cent fois plus cher que le gain précédent. Ce coût a deux dimensions. Le coût des ressources redondantes (machines, capacité de calcul, blocs de parité) qui permettent de retirer des systèmes du service pour maintenance ou d'assurer une durabilité minimale des données. Et le coût d'opportunité (opportunity cost) : chaque ingénieur affecté à réduire le risque est un ingénieur qui ne construit pas de fonctionnalités visibles par l'utilisateur.

Ensuite, parce que les utilisateurs ne perçoivent pas la différence. L'expérience d'un utilisateur est dominée par les maillons les moins fiables de la chaîne — le réseau cellulaire, le terminal lui-même. Un utilisateur sur un smartphone fiable à 99 % est tout simplement incapable de distinguer un service à 99,99 % d'un service à 99,999 %. Maximiser la disponibilité au-delà de ce que l'utilisateur remarque revient à gaspiller des ressources qui auraient pu financer des fonctionnalités.

Le SRE conçoit donc le risque comme un continuum et accorde une importance égale à deux tâches : améliorer la fiabilité des systèmes, et identifier le niveau de tolérance approprié pour chaque service. C'est ce qui permet une analyse coût/bénéfice : où placer Search, Ads, Gmail ou Photos sur ce continuum non linéaire ? L'objectif est d'aligner explicitement le risque pris par un service avec le risque que l'entreprise est prête à supporter. On vise un service « assez fiable, mais pas plus fiable qu'il n'a besoin de l'être ». Quand on fixe une cible de disponibilité à 99,99 %, on veut la dépasser — mais pas de beaucoup, car ce serait autant d'occasions perdues d'ajouter des fonctionnalités, de rembourser de la dette technique ou de réduire les coûts d'exploitation. La cible de disponibilité est donc à la fois un plancher et un plafond.

Mesurer le risque d'un service

Pour rendre le risque mesurable et comparable entre des systèmes très différents, le SRE se concentre sur l'indisponibilité non planifiée (unplanned downtime). On l'exprime classiquement en « neufs » : 99,9 %, 99,99 %, 99,999 %. Chaque neuf supplémentaire représente un ordre de grandeur de plus vers le 100 %.

Deux manières de calculer cette disponibilité coexistent. La première, traditionnelle, est temporelle : la part de temps où le système fonctionne.

Disponibilité temporelle (time-based availability)

                 uptime
availability = ───────────────────
                uptime + downtime

Sur un an, une cible de 99,99 % autorise au plus
52,56 minutes d'indisponibilité dans l'année.

Mais chez Google, une métrique temporelle est rarement pertinente : les services sont répartis sur la planète, et l'isolation des pannes fait qu'à tout instant on sert au moins une partie du trafic quelque part dans le monde — on est toujours au moins partiellement « up ». Google définit donc plutôt la disponibilité comme un taux de requêtes réussies (request success rate), calculé sur une fenêtre glissante.

Disponibilité agrégée (aggregate availability)

                 successful requests
availability = ─────────────────────
                  total requests

Exemple : un service qui traite 2,5 M de requêtes/jour
avec une cible journalière de 99,99 % peut servir
jusqu'à 250 erreurs et rester dans sa cible ce jour-là.

Toutes les requêtes ne se valent pas : échouer une inscription n'a pas le même poids qu'échouer une requête d'arrière-plan qui sonde la boîte mail. Mais, dans bien des cas, le taux de réussite agrégé sur l'ensemble des requêtes constitue une approximation raisonnable de l'indisponibilité non planifiée telle que l'utilisateur la vit. Avantage majeur : cette définition s'applique aussi aux systèmes qui ne servent pas directement des utilisateurs (traitement par lots (batch), pipelines, stockage, transactions) dès lors qu'ils ont une notion claire d'unité de travail réussie ou échouée. Un pipeline qui extrait, transforme et insère des enregistrements obtient ainsi une métrique de disponibilité utile, même s'il ne tourne pas en continu. En pratique, Google fixe des cibles trimestrielles et suit la performance au jour ou à la semaine, pour traquer et corriger les dérives significatives à mesure qu'elles surgissent.

La tolérance au risque dépend du service

Identifier la tolérance au risque d'un service, c'est traduire des objectifs métier en objectifs techniques explicites. C'est plus facile à dire qu'à faire, et la démarche diffère selon la nature du service.

Pour les services grand public (consumer services), une équipe produit fait office de propriétaire métier (Search, Maps, Docs ont chacun leur product manager). C'est elle la meilleure ressource pour discuter des exigences de fiabilité. Plusieurs facteurs entrent en jeu.

Facteur	Questions à poser
Niveau de disponibilité attendu	Quel niveau les utilisateurs attendent-ils ? Le service est-il lié au chiffre d'affaires ? Payant ou gratuit ? Grand public ou entreprise ? Que font les concurrents ?
Type de pannes	Une panne totale occasionnelle est-elle pire qu'un taux faible et constant d'échecs ? Une fuite de données privées impose-t-elle de couper tout le service ?
Coût	Un neuf de plus rapporterait combien de revenu marginal ? Ce revenu compense-t-il le coût de fiabilité ?
Autres métriques	La latence, le débit, la fraîcheur des données comptent-ils autant que la disponibilité ?

Le contraste Google Apps for Work / YouTube est éclairant. Les Apps for Work servent des entreprises dont les employés en dépendent au quotidien : une panne chez Google est une panne chez tous ses clients. On y fixe une cible externe de 99,9 %, adossée à une cible interne plus stricte et à un contrat assorti de pénalités. YouTube, à son acquisition en 2006, était grand public et en pleine croissance : on lui a fixé une cible plus basse, car le développement rapide de fonctionnalités primait alors.

Le type de panne mérite une attention particulière. Une application de gestion de contacts qui n'affiche plus les photos de profil offre une mauvaise expérience, qu'un SRE corrige vite ; mais une panne qui exposerait les contacts privés d'un utilisateur à un autre détruirait la confiance — au point qu'il serait alors approprié de couper entièrement le service le temps du débogage et du nettoyage. À l'inverse, certains services tolèrent des coupures régulières : l'Ads Frontend, utilisé surtout aux heures ouvrées, comptabilisait jadis ses fenêtres de maintenance comme de l'indisponibilité planifiée, pas non planifiée.

Le coût est souvent le facteur décisif. Ads peut traduire directement les succès et échecs de requêtes en revenu, ce qui rend l'arbitrage très concret.

Cible de disponibilité proposée : 99,9 % → 99,99 %
Gain de disponibilité           : 0,09 %
Revenu du service               : 1 000 000 $
Valeur du gain de disponibilité : 1 M$ × 0,0009 = 900 $

→ Si améliorer d'un neuf coûte moins de 900 $, c'est rentable.
  Si cela coûte plus de 900 $, le coût dépasse le revenu projeté.

Quand aucune fonction de traduction simple fiabilité→revenu n'existe, une stratégie utile consiste à se comparer au taux d'erreur de fond des fournisseurs d'accès (mesuré entre 0,01 % et 1 %) : descendre sous ce seuil ferait disparaître les erreurs dans le bruit de la connexion de l'utilisateur. Au-delà de la disponibilité, d'autres métriques offrent des degrés de liberté. La latence en est l'exemple type : AdWords, qui s'affiche à côté des résultats de recherche, traite la rapidité comme un invariant ; AdSense, qui insère des publicités contextuelles dans des pages tierces, tolère une latence supérieure de plusieurs centaines de millisecondes — ce relâchement permet de consolider le service sur moins de sites géographiques et d'économiser considérablement.

Le budget d'erreur (error budget)

Voici l'innovation centrale du chapitre. Une tension structurelle oppose les équipes de développement produit et les SRE : les premières sont évaluées sur la vélocité (incitation à pousser du code vite), les seconds sur la fiabilité (incitation à freiner le changement). Cette tension est aggravée par une asymétrie d'information — les développeurs voient l'effort de livraison, les SRE voient l'état réel de la production. Sans métrique objective, les arbitrages se règlent par la politique, la peur ou l'habileté à négocier. La devise officieuse du SRE Google tranche : « L'espoir n'est pas une stratégie » (Hope is not a strategy).

Le budget d'erreur (error budget) est cette métrique objective, partagée et incontestable. Il découle directement du SLO :

error budget = 1 − SLO

Exemple : SLO = servir avec succès 99,999 % des requêtes/trimestre
→ budget d'erreur = taux d'échec autorisé de 0,001 % sur le trimestre

Si un incident fait échouer 0,0002 % des requêtes attendues,
il consomme 20 % du budget d'erreur trimestriel.

Le mécanisme est un boucle de contrôle simple et neutre :

1. Le Product Management définit un SLO (uptime attendu / trimestre).
2. L'uptime réel est mesuré par un tiers neutre : le monitoring.
3. Différence (SLO − réel) = budget d'« indisponibilité » restant.
4. Tant qu'il reste du budget → les nouveaux déploiements continuent.
   Budget épuisé → on GÈLE les lancements, on investit dans la
   résilience (tests, perf, robustesse) jusqu'au rétablissement.

Le bénéfice est profond : le budget d'erreur fournit une incitation commune qui pousse développeurs et SRE à trouver ensemble le bon équilibre entre innovation et fiabilité. Quand le budget est large, les développeurs peuvent prendre plus de risques. Quand il est presque épuisé, ce sont les développeurs eux-mêmes qui réclament davantage de tests ou un rythme de déploiement plus lent, car ils ne veulent pas griller leur budget et bloquer leur prochain lancement. L'équipe produit devient auto-régulée (self-policing) — à condition, bien sûr, que les SRE aient réellement l'autorité d'arrêter un lancement si le SLO est rompu.

Le budget redistribue aussi la responsabilité : si une panne réseau ou de datacenter entame le budget, le nombre de déploiements peut être réduit pour le reste du trimestre, et toute l'équipe accepte cette réduction car chacun partage la responsabilité de l'uptime. Plus subtil que le simple commutateur on/off, on peut ralentir ou annuler les déploiements à mesure que le budget approche de l'épuisement. Et si une équipe peine à lancer ses fonctionnalités, elle peut choisir de relâcher le SLO (donc d'élargir le budget) pour gagner en innovation — un arbitrage assumé, fondé sur des données.

SLI, SLO, SLA : démêler les termes

Impossible de gérer correctement un service sans comprendre quels comportements comptent vraiment et comment les mesurer. L'industrie agrège tout sous la bannière confuse du « SLA ». Le SRE distingue rigoureusement trois concepts.

Terme	Définition	Rôle	Exemple
SLI (indicator)	Mesure quantitative soigneusement définie d'un aspect du service	Ce qu'on mesure	Latence, taux d'erreur, débit, disponibilité (yield), durabilité
SLO (objective)	Valeur ou plage cible pour un niveau de service mesuré par un SLI	La valeur visée	« 99 % des appels Get aboutissent en < 100 ms »
SLA (agreement)	Contrat explicite ou implicite, avec conséquences si le SLO est manqué	Ce qui se passe si on échoue	Remise, pénalité financière

La structure naturelle d'un SLO est SLI ≤ cible ou borne basse ≤ SLI ≤ borne haute. Le test infaillible pour distinguer un SLO d'un SLA : « que se passe-t-il si l'objectif n'est pas tenu ? » — s'il n'y a aucune conséquence explicite, c'est un SLO. Le SRE n'intervient guère dans la rédaction des SLA (affaire d'équipes métier et juridiques) mais aide à éviter d'en déclencher les pénalités et à définir des SLI mesurables sans ambiguïté. Google Search, par exemple, n'a pas de SLA public — mais une indisponibilité a tout de même des conséquences : atteinte à la réputation et chute des revenus publicitaires.

Bien choisir et mesurer ses indicateurs

N'utilisez pas comme SLI toute métrique que votre monitoring sait collecter. Une poignée d'indicateurs représentatifs suffit généralement : trop d'indicateurs noie l'attention, trop peu laisse des comportements importants dans l'angle mort. Les services se rangent en grandes familles : les systèmes frontaux se soucient de disponibilité, latence et débit ; les systèmes de stockage de latence, disponibilité et durabilité ; les pipelines de débit et de latence de bout en bout. Tous, enfin, devraient veiller à la correction (correctness) — la bonne réponse a-t-elle été renvoyée ?

La règle d'or de la mesure : préférer les percentiles aux moyennes. Une moyenne masque la longue traîne. Considérons un système où la requête typique est servie en 50 ms, mais où 5 % des requêtes sont vingt fois plus lentes : surveiller la seule moyenne ne montrerait aucun changement, alors que la latence de queue varie fortement.

Latences par percentile (échelle Y logarithmique)

p99   ┤        ▁▁▁▂▂▃▃▃▂▂▁▁▁        ← « pire cas » plausible (1 000 ms)
p95   ┤     ▁▂▂▂▂▂▂▂▂▂▂▂▂▂▁
p85   ┤   ▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁
p50   ┤ ▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁     ← cas typique / médiane (≈ 50 ms)
      └──────────────────────────►  temps
        La moyenne « plate » cacherait la dérive du p99.

Un percentile élevé (p99, p99,9) révèle le pire cas plausible ; la médiane (p50) le cas typique. Comme les utilisateurs préfèrent un système un peu plus lent à un système à forte variance, certaines équipes SRE ne surveillent que les hauts percentiles : si le p99,9 est bon, le cas typique l'est forcément. Méfiez-vous des sophismes statistiques : aucune requête ne répond en moins de 0 ms, un timeout à 1 000 ms tronque la distribution — moyenne et médiane peuvent donc être très éloignées. Pensez distributions, pas moyennes. Enfin, standardisez vos SLI (intervalle d'agrégation, périmètre, fréquence, mode de collecte) avec des modèles réutilisables, pour ne pas les réinventer à chaque fois.

Choisir des cibles et fixer des attentes

Le choix d'un SLO n'est pas une activité purement technique : il porte des implications produit et métier. Quelques leçons apprises par Google.

Principe	Pourquoi
Ne pas se caler sur la performance actuelle	Adopter la valeur du moment vous enferme dans un système qui exige des efforts héroïques pour tenir sa cible et qu'on ne peut améliorer sans refonte.
Garder simple	Les agrégations compliquées masquent les changements de performance et sont plus dures à raisonner.
Éviter les absolus	« Toujours disponible », « latence constante à charge infinie » : irréaliste, ruineux, et souvent meilleur que ce dont l'utilisateur a besoin.
Avoir le moins de SLO possible	Juste assez pour couvrir le système. Un SLO qui ne fait jamais pencher un arbitrage ne mérite pas d'exister.
La perfection peut attendre	Mieux vaut une cible lâche qu'on resserre qu'une cible trop stricte qu'il faut relâcher.

Partez de ce qui intéresse l'utilisateur, pas de ce que vous savez mesurer ; travailler à rebours, des objectifs vers les indicateurs, donne souvent de meilleurs SLO. Surtout, publier des SLO fixe des attentes. Sans SLO explicite, les utilisateurs forgent leurs propres croyances, source de sur-dépendance (ils croient le service plus fiable qu'il ne l'est) ou de sous-dépendance (ils le croient plus fragile). Pour rester réaliste, deux tactiques : conserver une marge de sécurité (un SLO interne plus strict que celui annoncé) et ne pas surperformer — car les utilisateurs construisent sur la réalité de ce que vous offrez, pas sur ce que vous promettez.

À retenir

• 100 % est le mauvais objectif : le coût de la fiabilité croît de façon exponentielle (chaque neuf peut coûter 100× plus cher) et l'utilisateur, limité par son réseau et son terminal, ne distingue pas 99,99 % de 99,999 %. La cible de disponibilité est à la fois un plancher et un plafond.
• Le risque se mesure en indisponibilité non planifiée, exprimée en « neufs » : soit en disponibilité temporelle (uptime / temps total), soit — le plus utile chez Google car les services sont globaux — en taux de requêtes réussies sur une fenêtre glissante.
• La tolérance au risque dépend du service : grand public ou infrastructure, lié au revenu ou non, le type de panne (panne totale vs erreurs diffuses, fuite de données privées) et surtout le coût déterminent où placer le service sur le continuum.
• Le budget d'erreur (error budget = 1 − SLO) aligne les incitations de Dev et SRE : tant qu'il reste du budget, on déploie ; épuisé, on gèle les lancements. L'équipe produit s'auto-régule, car « l'espoir n'est pas une stratégie ».
• SLI ≠ SLO ≠ SLA : l'indicateur est ce qu'on mesure, l'objectif la valeur visée, l'accord le contrat avec conséquences. Test : « que se passe-t-il si l'objectif est manqué ? » — sans conséquence, c'est un SLO.
• Mesurez avec des percentiles, pas des moyennes (la moyenne masque la longue traîne) ; pensez distributions ; standardisez vos SLI ; gardez-en le moins possible.
• Choisissez les cibles sans vous caler sur la performance actuelle, gardez une marge de sécurité et ne surperformez pas — publier des SLO fixe les attentes et évite la sur-dépendance (leçon Chubby).