Ce que résout SRE
Bienvenue dans l'Ingénierie de la fiabilité des sites
L'Ingénierie de la fiabilité des sites (SRE) a débuté chez Google en 2003. Ben Treynor Sloss a repris une petite équipe d'opérations et l'a reconstruite comme si des ingénieurs, et non des humains pagers, géraient la production. Le résultat est devenu le modèle standard pour exploiter de grands services Internet.
Les équipes d'opérations traditionnelles maintenaient les services en fonctionnement grâce à un travail manuel : redémarrer ce serveur, pager cet ingénieur, écrire un runbook, espérer que cela tienne. Ce modèle ne tient plus à grande échelle. Une équipe de cinquante opérateurs ne peut pas redémarrer manuellement cinq mille serveurs. Au-delà d'une certaine taille, les opérations manuelles deviennent une taxe qui consomme chaque heure productive.
SRE inverse le modèle. Au lieu d'embaucher davantage d'opérateurs lorsque les systèmes grandissent, SRE recrute des ingénieurs logiciels et leur dit : écrivez du code qui effectue le travail opérationnel à votre place. Votre travail s'apparente à de l'ingénierie logicielle appliquée aux problèmes d'opérations. Votre production : automatisation, surveillance et fiabilité conçue, et non des interventions manuelles.
Trois idées fondamentales guident la pratique SRE :
- Objectifs de niveau de service (SLO) : cibles numériques de fiabilité, définies à l’avance
- Budgets d’erreur : l’inverse d’un SLO, dépensé pour prendre des risques
- Élimination de la corvée : tout travail opérationnel qui augmente linéairement avec la taille du système doit disparaître
Ces trois idées se répercutent sur toutes les pratiques SRE : post-mortems, rotations d’astreinte, planification de capacité, surveillance et ingénierie des releases.
Ops traditionnel versus SRE
Pourquoi l’Ops traditionnel échoue à grande échelle
Une équipe ops classique grandit de façon linéaire avec les systèmes qu’elle gère. Doublez le nombre de serveurs, doublez le nombre d’opérateurs. Cela a un sens financier pour les petits déploiements, mais devient désastreux à grande échelle : on ne peut pas recruter pour sortir d’un problème quadratique.
SRE limite le travail opérationnel à cinquante pour cent du temps d’un ingénieur. L’autre moitié doit être consacrée à l’ingénierie : construire des outils, automatiser les processus, éliminer la corvée qui les a conduits à cinquante pour cent en premier lieu. Si la corvée dépasse cinquante pour cent trop longtemps, l’équipe doit renvoyer du travail à une équipe de développement ou recruter davantage de SRE. La règle des cinquante pour cent empêche une équipe SRE de se transformer en équipe ops traditionnelle sous une pression soutenue.
Comparez les modes d’échec :
- Ops traditionnel : plus d’incidents entraînent plus de réponses manuelles, ce qui laisse moins de temps pour la prévention, ce qui crée encore plus d’incidents. Une boucle infernale.
- SRE : plus d’incidents déclenchent des postmortems, qui font émerger des opportunités d’automatisation, qui réduisent le temps de réponse du prochain incident. Une boucle vertueuse, quand elle fonctionne.
SLI, SLO, SLA
Trois lettres qui font tourner la production
La fiabilité sans mesure n'est que du théâtre. Le SRE transforme la fiabilité en un chiffre, convenu à l'avance, que tout le monde peut vérifier.
Indicateur de Niveau de Service (SLI) : une mesure du comportement d’un service. Exemples : latence des requêtes, taux d’erreur, débit, profondeur de file d’attente. Un SLI est une chose que vous pouvez représenter graphiquement.
Objectif de Niveau de Service (SLO) : une valeur cible ou une plage pour un SLI. Exemple : « 99,9 % des requêtes HTTP réussissent sur une fenêtre glissante de 28 jours. » Un SLO est une promesse que vous vous faites à vous-même et à vos utilisateurs concernant la qualité de service acceptable.
Accord de Niveau de Service (SLA) : un engagement contractuel, généralement assorti de pénalités financières en cas de violation. Exemple : « Nous remboursons 10 % si la disponibilité mensuelle tombe en dessous de 99,9 %. » Un SLA est une promesse appliquée par des avocats.
Distinction essentielle : votre SLA doit toujours être plus souple que votre SLO. Si vous visez 99,9 % en interne et contractez 99,9 % en externe, vous n’avez aucune marge. Les SREs exécutent généralement des SLOs avec un neuf de plus que le SLA : cible 99,95 %, contrat 99,9 %. L’écart absorbe la mauvaise semaine inévitable.
Error Budgets : l'inverse du SLO
Des objectifs de fiabilité aux décisions d'ingénierie
Un SLO définit un objectif de fiabilité. Le budget d'erreur est ce qui reste : la quantité d'échecs que vous pouvez dépenser avant de manquer l'objectif.
Si votre SLO promet 99,9 % de succès sur 28 jours, votre budget d'erreur est de 0,1 % des requêtes, soit environ 40 minutes d'indisponibilité totale par mois. Ce budget est à votre disposition : pour des déploiements planifiés, des fonctionnalités expérimentales, du chaos engineering ou pour tolérer une dépendance défaillante.
Les budgets d'erreur transforment le conflit dev versus ops. Sans budget, chaque incident déclenche une discussion sur qui a livré le mauvais changement et comment éviter le suivant. Avec un budget :
- Budget restant : livrez plus vite, prenez plus de risques, lancez des expériences. Le budget le finance.
- Budget épuisé : arrêtez les nouvelles fonctionnalités, gel des changements risqués, concentrez-vous sur le travail de fiabilité jusqu'à reconstitution du budget.
Cela transforme la fiabilité d'un débat émotionnel en une ressource mesurable. Les ingénieurs peuvent dépenser le budget de manière délibérée, comme toute autre ressource de production.
Définir la corvée
Ce qui compte comme corvée
Toutes les tâches opérationnelles ne sont pas des corvées. La SRE définit précisément la corvée : un travail manuel, répétitif, automatisable, tactique, dépourvu de valeur durable et qui augmente linéairement avec la croissance du service.
Les six propriétés doivent être réunies. Une migration de données unique est manuelle mais pas répétitive : cela ne compte pas comme corvée. Un ingénieur senior concevant une nouvelle architecture de service prend une décision tactique mais apporte une valeur durable : cela ne compte pas comme corvée.
Exemples qui comptent comme corvée :
- Redémarrer manuellement un service après un plantage dû à une fuite mémoire
- Coller des extraits de logs dans un canal de discussion pendant le triage d’un incident
- Remplir un formulaire de ticket pour provisionner une nouvelle base de données
- Exécution manuelle d'un rapport de capacité trimestriel
- Approbation individuelle des demandes de déploiement de routine
La règle des cinquante pour cent limite le toil à la moitié du temps d'un SRE. Au-delà de 50 %, l'équipe doit soit restituer la responsabilité à une équipe produit, soit recruter davantage d'ingénieurs, mais l'objectif reste clair : réduire le toil à zéro en le remplaçant par des systèmes automatisés qui effectuent le même travail sans intervention humaine.
L'automatisation ne se contente pas de gagner du temps. Elle élimine entièrement une catégorie d'erreurs humaines. Un script qui provisionne une base de données n'oublie aucune étape après une longue journée.
Raisonnement de l'audit du toil
Votre équipe suit la répartition de son temps. Au dernier trimestre, la ventilation était la suivante : 30 % de déploiements, 25 % de réponse aux incidents, 20 % de travail sur la capacité, 15 % d'ingénierie de fonctionnalités, 10 % de demandes ponctuelles des équipes produit.
Hygiène d’astreinte
Ingénieurs, pas des pagers
L'astreinte a un coût réel. Le sommeil est perturbé, les week-ends sont interrompus et le stress lié aux problèmes inconnus s'accumule. Les SRE considèrent l'astreinte comme une ressource finie qui doit rester durable, et non comme un fardeau héroïque supporté par ceux qui s'en soucient le plus.
Les rotations d'astreinte saines suivent plusieurs principes :
- Temps compensé : les heures d'astreinte donnent droit à du temps compensatoire, une rémunération supplémentaire ou un avantage comparable. L'astreinte gratuite épuise l'équipe.
- Profondeur de rotation raisonnable : une équipe de six personnes assurant une astreinte primaire et secondaire signifie que chaque ingénieur prend un service toutes les trois semaines. Les rotations à deux personnes détruisent les carrières.
- Budget de volume de pages : le livre SRE de Google suggère un maximum de deux événements de paging par période de douze heures. Au-delà, l'équipe doit investir du temps d'ingénierie pour réduire le volume d'alertes, et non simplement le supporter.
- Alertes actionnables uniquement : chaque page doit nécessiter une action humaine. Si une page risque d'être ignorée, automatisée ou déclenchée de façon répétée pendant le fonctionnement normal, elle ne devrait pas exister. La fatigue des alertes est un défaut de fiabilité.
- Passages de relais « follow-the-sun » : les équipes réparties mondialement se relaient aux frontières des fuseaux horaires afin que personne ne soit appelé à 3 h du matin, sauf si le système ne peut vraiment pas attendre le matin.
Postmortems sans blâme
Comment les pannes deviennent des améliorations
Chaque incident significatif fait l’objet d’un postmortem : une analyse écrite de ce qui s’est passé, pourquoi, ce qui l’a résolu et les changements qui empêcheront sa récurrence. Le postmortem est l’équivalent SRE des intérêts composés : chacun ajoute une fiabilité permanente au système.
Sans blâme signifie que le document attribue les défaillances aux systèmes et aux processus, jamais aux individus. Si un ingénieur a exécuté la mauvaise commande, le postmortem demande : pourquoi le système a-t-il permis cette commande ? Pourquoi aucun garde-fou ne l’a-t-il interceptée ? Quel changement du système, de la documentation ou des outils empêcherait le prochain ingénieur de commettre la même erreur ?
Le principe du blâme zéro existe pour une seule raison : les gens cachent leurs erreurs quand ils craignent une sanction. Les erreurs cachées deviennent l’incident suivant. Le coût d’une culture sans blâme est faible comparé au coût de l’accumulation de défauts non divulgués.
Les postmortems couvrent généralement :
- Résumé : description en un paragraphe de l’incident et de son impact
- Chronologie : reconstitution minute par minute avec horodatages
- Analyse des causes profondes : facteurs techniques et processus qui ont permis l’incident
- Détection : comment l’équipe a pris connaissance de l’incident et combien de temps cela a pris
- Résolution : les actions entreprises pour rétablir le service
- Leçons apprises : ce qui a fonctionné, ce qui n’a pas fonctionné
- Éléments d’action : tâches d’ingénierie concrètes, attribuées et limitées dans le temps
Les éléments d’action vivent dans un outil de suivi. Ils sont priorisés comme tout autre travail d’ingénierie. Les postmortems sans éléments d’action se réduisent à un simple récit. Le travail ne change rien.
Les quatre signaux d’or
Ce que chaque service doit mesurer
Le livre SRE de Google propose quatre signaux que tout service orienté utilisateur doit exposer : latence, trafic, erreurs et saturation. Ensemble, ils décrivent la santé du service du point de vue de l'utilisateur. Surveiller avec moins de signaux laisse des angles morts ; surveiller avec des centaines de métriques noie l'équipe dans la fatigue des alertes.
Latence : durée des requêtes. Suivre les distributions, pas les moyennes. p50 (médiane) décrit l'expérience typique. p99 décrit le pire 1 % des utilisateurs. La moyenne seule cache les longues traînes : un service avec une médiane de 50 ms et un p99 de 5 000 ms semble correct en moyenne, mais ruine un utilisateur sur cent.
Trafic : la demande sur le service. Pour un service web, cela signifie les requêtes par seconde. Pour un service de streaming, les connexions simultanées. Pour un traitement par lots, les éléments traités par minute. Le trafic est corrélé aux décisions de capacité et révèle les anomalies de charge.
Erreurs : le taux de requêtes échouées. Les échecs explicites (HTTP 500), les échecs implicites (HTTP 200 avec données corrompues) et les échecs de politique (temps de réponse trop long pour respecter le SLO) comptent tous. Il est important de les distinguer : une réponse 200 avec une charge utile incorrecte nuit souvent plus aux utilisateurs qu'un 500 honnête.
Saturation : à quel point le système est saturé. Utilisation CPU, profondeur de file d’attente, pression mémoire, occupation du pool de connexions. La saturation permet de prédire la latence future : un système à 95 % de CPU dispose de très peu de marge avant que la latence perçue par les utilisateurs n’augmente fortement.
La plupart des alertes SRE sont dérivées de ces quatre signaux. L’alerte basée sur les symptômes (alerte lorsque les utilisateurs le remarqueraient) est plus efficace que l’alerte basée sur les causes (alerte lorsque le CPU dépasse 80 %). Les quatre signaux d’or décrivent des symptômes.
Parcours de carrière SRE
Où les compétences SRE sont valorisées
Les carrières SRE divergent selon la partie de la discipline que l’ingénieur préfère :
Infrastructure SRE : construit les plateformes sur lesquelles les autres équipes s’appuient. Kubernetes, service meshes, cloud interne. Ingénierie systèmes avancée, théorie des systèmes distribués et conception de plateformes. Rémunération très élevée dans les grandes entreprises car le travail est scalable : un seul Infrastructure SRE soutient des centaines d’ingénieurs produit.
Embedded SRE : travaille en binôme avec une équipe d’ingénierie produit pour améliorer la fiabilité d’un service spécifique. Mi-ingénieur, mi-coach. Les compétences en communication et en revue de code comptent autant que la profondeur technique. Souvent le meilleur chemin pour les ingénieurs qui aiment transmettre.
Reliability tooling : construit la stack d’observabilité : monitoring, alerting, tableaux de bord, outils de post-mortem, plateformes de gestion d’incidents. Travail important en frontend et en data engineering. Les livrables sont utilisés par toutes les autres équipes.
Production engineering : terme utilisé chez Facebook/Meta pour désigner les SRE centrés sur la capacité, le déploiement et la gestion du trafic. Travail important en réseau et en systèmes.
Certifications techniques à posséder : le Google Cloud Professional Cloud Architect, l’AWS Solutions Architect Professional et les certifications CNCF (Kubernetes Administrator, Kubernetes Application Developer) attestent d’une maîtrise du cloud-native. Les certifications de la Linux Foundation signalent une expertise système. Aucune de ces certifications ne remplace un portfolio concret, mais elles aident à franchir les filtres des recruteurs.
Conclusion
Ce que vous savez maintenant
L’ingénierie de la fiabilité des sites est née de la réponse de Google à un problème de passage à l’échelle et s’est transformée en une discipline désormais pratiquée dans toute l’industrie. Vous avez abordé :
- Le passage des opérations manuelles à une fiabilité conçue par l’ingénierie
- Les SLI, SLO, SLA et le concept d’inverse-SLO que sont les budgets d’erreurs
- La définition du toil, la règle des 50 % et sa réduction par l’ingénierie
- Des rotations d’astreinte durables et la pratique des post-mortems sans blâme
- Les quatre signaux d’or comme point de départ pour la surveillance des services
- Les parcours de carrière SRE et les certifications qui ouvrent des portes
Deux idées comptent le plus. La fiabilité est un nombre, convenu à l’avance. Et le toil est un défaut, pas une description de poste. Gardez ces deux idées en tête et le reste de la SRE s’ensuit naturellement.
Lecture recommandée : le livre SRE de Google (gratuit en ligne : sre.google/books/), le SRE Workbook pour des exercices pratiques, et les écrits de Charity Majors sur l’observabilité. La leçon « geometry-of » complémentaire approfondit la structure visuelle qui sous-tend la pratique SRE : distributions de latence, cônes de budget d’erreur, graphes de dépendances et mises en page de tableaux de bord.