Culture SRE : budgets d'erreur, toil et postmortems sans fautes

En 2003, Benjamin Treynor Sloss reçoit la mission de diriger une équipe d'ingénieurs logiciels chargée de maintenir les sites de Google en ligne. L'équipe avait des gens qui écrivaient du code, pas des gens d'exploitation, donc une partie de leur temps est passée à toucher la production en plus du développement, précisément pour comprendre comment leur code tournait dans le monde réel. De ce départ est née l'ingénierie de fiabilité du site et avec elle une culture complète. « Developing a Google SRE Culture », le cours de Google Skills pour les leaders TI et métier, la démonte de bout en bout. Ce post la parcourt.

DevOps pose le cadre, SRE le concrétise

DevOps existe pour abattre le mur entre les développeurs, qui veulent vitesse et innovation, et les opérateurs, qui veulent stabilité et constance ; le modèle de jeter le code par-dessus le mur a cessé d'être viable. Google catégorise la philosophie en cinq domaines : réduire les silos organisationnels, accepter que la panne est normale (les ordinateurs sont inheremment peu fiables), implémenter un changement progressif, tirer parti des outils et de l'automatisation, et mesurer tout.

DevOps est une philosophie et n'offre pas de guides explicites d'implémentation. C'est là qu'intervient SRE, la manière concrète de résoudre les problèmes que DevOps aborde. Et une nuance qui libère d'une chasse à l'organigramme : SRE est à la fois une pratique et un rôle. Toute organisation qui suit ses principes n'a pas besoin d'ingénieurs au titre SRE ; les titres et les structures d'équipe sont des détails d'implémentation.

flowchart LR
    subgraph A[Cinq domaines DevOps]
      direction TB
      D1[Réduire les silos] --- D2[Accepter la panne] --- D3[Changement progressif] --- D4[Outils et automatisation] --- D5[Mesurer tout]
    end
    A --> V1[1. SLO avec conséquences]
    V1 --> V2[2. Demain mieux qu'aujourd'hui]
    V2 --> V3[3. Réguler la charge de travail]

Le budget qui rend possible le lancement

La fiabilité simple, le bon temps sur le temps total, ne convient pas aux systèmes distribués complexes ; l'approximation correcte est de définir la disponibilité comme les interactions bonnes sur les interactions totales, la fraction d'utilisateurs réels qui vivent le service en fonctionnement. De là sortent trois pièces avec des noms différents.

Le SLI est une mesure quantifiable de fiabilité du point de vue de l'utilisateur, exprimée en bons événements sur événements valides fois cent, et il doit correspondre à des attentes réelles : latence de réponse, qualité, traitement des données, correction et fraîcheur. Le SLO est l'objectif numérique pour ce SLI agrégé dans le temps, convenu entre parties prenantes et normalement juste en dessous de cent pour cent, disons 99,9 % : il trace la ligne entre clients satisfaits et insatisfaits. La SLA est la promesse au client de ce que fera l'affaire si le SLO n'est pas tenu, par exemple rembourser.

flowchart TD
    SLI[SLI : bons événements / valides × 100] --> SLO[SLO : objectif numérique<br/>juste sous 100 %]
    SLO --> EB[Budget d'erreur : l'indisponibilité<br/>qu'on tolère]
    SLO --> SLA[SLA : ce que promet l'affaire<br/>si ce n'est pas tenu]
    EB -->|Budget restant| F[Lancer des fonctionnalités]
    EB -->|Budget épuisé| R[Arrêter et rétablir la fiabilité]

Et le concept qui clôt l'argument : le error budget, la quantité d'indisponibilité qu'on est prêt à tolérer, la différence entre la perfection et le SLO. Viser 100 % de fiabilité est le mauvais objectif, parce qu'il freine les livraisons de fonctionnalités qui font avancer l'affaire. Tant qu'il y a budget, on peut livrer ; le budget peut aussi se dépenser en changements attendus, pannes matériel et réseau inévitables, temps d'arrêt planifié ou expériences risquées. Quand il est épuisé, il faut travailler sur la fiabilité. C'est l'incitation commune qui met développeurs et SRE à regarder le même chiffre.

Postmortems sans fautes, et pourquoi ça coûte

Après un incident, le livrable est un postmortem, aussi appelé rétrospective : un registre écrit avec les détails de l'incident et sa chronologie, les actions prises pour mitiger ou résoudre, l'impact, le déclencheur ou la cause racine, et les actions de suivi pour prévenir la récidive. Presque toutes les interruptions ont plusieurs causes racines, chacune isolée peut-être insuffisante, d'où l'usage de tactiques comme les cinq pourquoi. Le focus reste sur les causes, sans pointer des personnes ni des équipes.

Que cela coûte n'est pas une métaphore. La sécurité psychologique, la croyance qu'une personne ne sera ni punie ni humiliée pour exposer des idées ou des erreurs, fait défaut là où la culture de la faute considère identifier le responsable comme la solution. La recherche identifie deux moteurs de la faute : le biais rétrospectif, surestimer la capacité d'avoir prédit un résultat qui ne pouvait pas l'être (« c'était évident », toujours après coup), et la décharge d'inconfort, qui, selon la sociologue Pardis Brown, dit que la faute existe pour décharger l'inconfort et la douleur au niveau neurobiologique. Accuser les personnes génère de la réticence à partager l'information et à déclarer les incidents, et inhibe l'innovation parce que personne ne propose d'améliorations s'il sera blâmé en cas d'échec. La recherche DORA, à l'inverse, associe une forte sécurité psychologique à un meilleur lead time, une fréquence de déploiement et un temps de restauration.

En tant que leader, cela se construit en trois étapes : cadrer le problème comme un problème d'apprentissage et non d'exécution, admettre sa propre faillibilité et encourager à poser des questions ; modéliser la curiosité ; et accuser les systèmes et les processus, pas les personnes, en supposant la bonne foi et en améliorant le système pour que les personnes prennent de meilleures décisions.

Changement progressif, prototypage et toil

Les développeurs penchent vers la pensée moonshot, des changements massifs qui peuvent échouer, tandis que les SRE préfèrent l'intégration continue construit, intègre et teste le code en développement pour que les ingénieurs testent plus souvent ; la livraison continue permet de déployer en production fréquemment, même si on choisit de ne pas le faire. CI/CD réduit les douleurs d'intégration et les erreurs humaines et accélère le time to market.

Le canarying porte cette logique au déploiement : le changement est relâché auprès d'un groupe d'utilisateurs qui ignorent le recevoir, l'impact est évalué et la suite est décidée. La métaphore est le canari dans la mine de charbon, quelque chose de grand qu'on ne veut pas blesser et quelque chose de petit qu'on peut perdre, qui détecte le danger. Les exigences se heurtent un peu : la population canary doit être représentative face au contrôle et, en même temps, assez petite pour ne pas mettre en risque la qualité de service globale, la seule différence pratique étant le changement testé et facilement annulable.

Réduire le coût de la panne ouvre de la place à l'innovation, et là apparaît le design thinking avec ses cinq phases : empathiser, définir le problème du point de vue de l'utilisateur, idéer, prototyper et tester avec de vrais utilisateurs. Être prototype driven compte : sans prototypage, moins d'idées sont testées avec des échecs lents ; avec une culture du prototypage, plus d'idées sont testées avec des échecs rapides et plus de réussites. Un détaillant néerlandais a prototypé son processus de production avec des gobelets en papier, marquant avec des gobelets de couleur les étapes à améliorer ou à jeter.

Le toil, de son côté, est un travail directement lié à un service qui est manuel, répétitif, automatisable, tactique, sans valeur durable ou qui croît linéairement avec la croissance du service. Si un opérateur humain doit toucher le système en fonctionnement normal, c'est un bug. Tout ce qui est administratif n'est pas du toil, ni ce que quelqu'un n'aime pas. Le seuil recommandé est que les SRE passent moins de 50 % de leur temps dans le toil ; l'excès provoque un stagnant professionnel, une baisse de moral, une confusion de rôle, des fonctionnalités lentes et de l'attrition, et un peu de toil donne une sensation de réussite rapide, mais ça ne doit jamais être le travail principal.

Mesurer tout, avec les biais sur la table

Trois objectifs soutiennent la mesure : comprendre l'état actuel du service de manière objective, analyser les données pour identifier des actions d'amélioration et collaborer avec l'affaire pour de meilleures décisions. Un bon SLI corrèle avec l'expérience utilisateur et a une plage étroite en fonctionnement normal, distincte de la plage d'une interruption ; un SLI à forte variance et chevauchement oblige à choisir entre faux positifs et faux négatifs. L'utilisateur ne distingue pas si la base de données est tombée ou si l'équilibrateur échoue : il ne vit que la page lente.

D'où la règle d'alerte : par symptômes et non par causes, idéalement fondée sur la consommation du budget d'erreur, une heure de budget dépensée en une heure mérite une page, une consommation sur trois jours ne génère qu'un ticket, avec les alertes de capacité en exception. Et les quatre signaux dorés de Google : latence, trafic, erreurs et saturation.

La culture de la mesure a son contrepoids dans les OKR, notés de 0,0 à 1,0 avec un point optimal entre 60 % et 70 %, conçus ambitieux et qui ne sont pas l'évaluation de performance ; ceux de l'organisation se notent publiquement et s'accompagnent de check-ins fréquents. S'y ajoute la transparence, avec des outils de monitoring partagés et des feedback loops (produire, mesurer en production, utiliser l'information pour améliorer), et le nettoyage des biais inconscients dans les décisions : affinité, confirmation, étiquetage et attention sélective. Les remèdes : questionner les premières impressions, justifier les décisions par écrit et décider collectivement en répétant ce qui a été entendu.

Gérer le changement, c'est là qu'on échoue

Les gens réagissent au changement en quatre groupes : les navigateurs, qui rendent les équipes réussies et qu'il faut célébrer ; les critiques, avec passion, énergie et peurs valides, avec qui ça vaut la peine de passer du temps parce qu'ils peuvent devenir de puissants défenseurs ; les victimes, qui le prennent personnellement et demandent écoute et empathie ; et les spectateurs, avec qui il vaut mieux communiquer pour savoir comment ils le vivent. Se connecter se fait à trois niveaux : tête (pourquoi le changement), cœur (pourquoi c'est important pour chacun) et pieds (connaissances, ressources et soutien).

La résistance est la principale raison d'échec des changements et c'est généralement la peur de la perte : sécurité ou contrôle, compétence, relations ou sens de la direction. La réaction à la perte pèse plus que la réaction au gain. Le cas d'une banque commerciale espagnole l'illustre : son VP d'ingénierie voulait investir dans l'automatisation pour montrer des bénéfices à l'affaire, mais les équipes sur le terrain percevaient cela comme une menace directe pour leurs emplois parce que personne ne leur avait expliqué ce que les changements impliquaient ni comment les affecteraient.

Maturité, équipes et par où commencer

Une organisation de haute maturité a des SLO bien documentés et centrés utilisateur, des budgets d'erreur avec des actions définies si le service échoue, une culture de postmortems sans fautes et une faible tolérance au toil. Aucun de ces principes n'exige une équipe SRE nommée : n'importe quelle équipe responsable de systèmes de production peut les adopter. Les quatre étapes recommandées par Google sont de définir SLO, budgets d'erreur et culture de postmortems ; puis de définir et organiser les équipes SRE ; et ensuite d'implémenter l'automatisation et la régulation de la charge de travail. Pour une auto-évaluation initiale, il y a le DORA DevOps Quick Check, cinq questions.

Quant à la façon de bâtir l'équipe, il y a six implémentations recommandées, chacune avec son avantage et son ombre : kitchen sink, une seule équipe dédiée sans trous de couverture mais sans charter pour la contenir ; infrastructure, sur des services partagés, avec le risque de s'éloigner du client ; tools, qui construit du logiciel de fiabilité et risque de résoudre les mauvais problèmes ; product, axé sur une application critique ; embedded, avec des SRE incrustés dans une équipe de développement, idéal pour démarrer ou échelonner une fonction ; et consulting, comme embedded mais moins hands-on, avec un ou deux consultants à temps partiel quand l'organisation est déjà grande.

Dans le recrutement, les concepts de SRE sont rarement enseignés à l'université : chez Google, on recrute aussi des administrateurs système avec expérience opérationnelle et un peu de scripting, et on les forme en ingénierie logicielle. Les compétences essentielles sont l'exploitation et l'ingénierie logicielle, le monitoring, l'automatisation de production, l'architecture, le troubleshooting analytique, la culture de la confiance (communication, accord et confiance) et la gestion des incidents, avec la résilience et la flexibilité comme traits.

Ce qui est resté sans vérification

Ce parcours montre que la culture SRE est une chaîne où chaque maillon oblige le suivant : sans SLO pas de budget d'erreur à prioriser, sans budget pas de conséquence à attaché au manquement, sans postmortems sans fautes pas de données honnêtes sur ce qu'il faut améliorer, et sans mesure la discussion reste aux opinions. Ce qu'un post comme celui-ci ne peut pas faire, c'est remplacer l'auto-évaluation.

Ce qui n'a pas été vérifié : les sept quiz intermédiaires et l'évaluation finale (80 % pour passer) ne se sont pas ouverts, donc aucune affirmation sur leurs réponses ; la vidéo d'introduction de la section finale n'a pas de transcription et son contenu n'est pas documenté ; et l'auto-évaluation DORA DevOps Quick Check n'a été ni visitée ni exécutée.

*Source : « Developing a Google SRE Culture », de Google Skills.*