Site reliability engineering définition : le guide SRE

Si vous cherchez la site reliability engineering définition, la réponse tient en une phrase : c'est la pratique qui consiste à exploiter des systèmes de production avec du génie logiciel, au lieu d'opérations manuelles. Une équipe SRE fixe un objectif de fiabilité chiffré, mesure le service par rapport à cet objectif et automatise le travail répétitif qui maintient les services en ligne. Si votre astreinte vous réveille à 3 heures du matin pour la même alerte disque chaque mois, c'est précisément le problème que le SRE existe pour supprimer.

Google a popularisé le terme vers 2003. Aujourd'hui, l'idée dépasse largement Google, des startups de 20 personnes aux banques. Ce qui change d'une entreprise à l'autre, c'est l'échelle, pas la mécanique de fond.

Que fait concrètement un site reliability engineer ?

Ben Treynor Sloss, qui a lancé l'équipe SRE de Google, la résume simplement dans le chapitre d'introduction du livre SRE de Google : le SRE, c'est ce qui se passe quand on demande à un ingénieur logiciel de concevoir une équipe d'exploitation. Le travail reste de l'exploitation, mais fait avec du code.

Dans une semaine normale, cela veut dire quatre choses. Vous définissez ce que « fonctionner correctement » signifie pour un service. Vous construisez la supervision qui vous dit quand ce n'est plus le cas. Vous réagissez quand ça casse. Et vous écrivez le correctif pour que la personne suivante ne soit pas réveillée pour la même raison.

Deux exemples rendent cela concret. Une équipe qui déploie à la main chaque jeudi construit un pipeline avec rollback automatique. Une équipe qui redémarre chaque nuit un service qui fuit finit par trouver la fuite. Dans les deux cas, une corvée récurrente devient un projet ponctuel, et c'est tout l'intérêt.

La quatrième partie, celle que les équipes oublient, est pourtant la plus importante. Un SRE qui ne fait que réagir aux incidents n'est qu'un ingénieur d'exploitation avec un nouveau titre. La dimension ingénierie est ce qui fait la différence.

En quoi le SRE diffère-t-il du DevOps ?

Le DevOps est une culture : développeurs et opérationnels partagent la responsabilité de ce qui est livré et de la façon dont cela tourne en production. Il vous dit que le mur entre les équipes est un problème. Il ne vous dit pas quelle indisponibilité est acceptable, ni quand arrêter de livrer.

Le SRE apporte les chiffres. Il fournit des objectifs de niveau de service (SLO), des budgets d'erreur et une limite au travail manuel. Selon la formulation de Google, le SRE est une manière concrète de mettre en œuvre les idées du DevOps.

Inutile de débattre de celui qui est « meilleur ». Si vous dirigez une équipe de 8 personnes, vous emprunterez aux deux. La vraie question est de savoir si votre équipe peut répondre, en une phrase, au niveau de fiabilité exigé pour un service donné.

Que sont les SLI, les SLO et les SLA, et pourquoi comptent-ils ?

Trois sigles portent l'essentiel du SRE, et on les confond en permanence.

• SLI (indicateur de niveau de service) : une mesure. Par exemple, la part des requêtes HTTP qui renvoient une réponse non 5xx en moins de 300 ms.

• SLO (objectif de niveau de service) : la cible fixée pour cette mesure. Par exemple, 99.9% des requêtes sur une fenêtre glissante de 28 jours.

• SLA (accord de niveau de service) : le contrat assorti de conséquences, en général des remboursements, en cas de manquement. Votre SLA doit être moins exigeant que votre SLO.

La raison d'en parler : « le site doit être rapide et fiable » ne se teste pas. Une cible comme « 99.9% des paiements réussissent en moins de 500 ms » se teste, et elle permet de trancher les discussions.

Commencez avec deux ou trois SLI par service. Au-delà, plus personne ne s'en souvient.

Choisissez des SLI que les utilisateurs ressentent. L'usage CPU est une cause, pas un symptôme. Les paiements échoués, les pages lentes et les données périmées sont ce que le client remarque.

Comment fonctionnent les budgets d'erreur ?

Un budget d'erreur correspond à l'indisponibilité que votre SLO autorise. C'est simplement 1 moins le SLO. Une cible de disponibilité de 99.9% laisse 0.1%, soit environ 43 minutes d'indisponibilité sur un mois de 30 jours.

Voici une version minimale en code, parce que l'arithmétique est toute l'idée :

slo = 0.999
fenetre_minutes = 30 * 24 * 60          # 43 200
budget = (1 - slo) * fenetre_minutes    # 43.2 minutes
consomme = 31                           # minutes de mauvais service jusqu'ici
print(f"{budget - consomme:.1f} minutes restantes")  # 12.2 minutes restantes

Tant qu'il reste du budget, l'équipe livre vite. Quand il est épuisé, les mises en production de fonctionnalités s'arrêtent et le travail bascule vers la fiabilité. L'exemple de politique de budget d'erreur du SRE Workbook montre comment une équipe écrit cette règle noir sur blanc.

Il ne s'agit pas de punir. Le budget remplace l'ancien conflit, où les développeurs veulent livrer et les opérationnels veulent de la stabilité, par un chiffre partagé que les deux camps peuvent lire. Mais cela ne fonctionne que si la direction accepte à l'avance de respecter la pause. Une politique de budget que l'on contourne chaque trimestre n'est qu'une décoration.

Pourquoi existe la règle des 50 % de toil ?

Le toil désigne le travail manuel et répétitif qui croît avec le service et ne laisse rien derrière lui. Redémarrer un worker bloqué à la main est du toil. Écrire le health check qui le redémarre automatiquement relève de l'ingénierie.

L'organisation SRE de Google vise à garder le toil sous 50 % du temps de chaque ingénieur, comme le décrit le chapitre sur l'élimination du toil. Le reste va à des projets qui réduisent le toil futur ou ajoutent des fonctionnalités. Le raisonnement est brutal : le toil finit par occuper 100% du temps de tout le monde si personne ne l'arrête.

Considérez les 50 % comme un plafond, pas comme un objectif. Une équipe saine sur un service mature reste bien en dessous. Si vous dépassez ce seuil pendant un trimestre, vous ne faites pas du SRE : vous gérez une file d'attente d'opérations.

Pour commencer simplement : pendant deux semaines, étiquetez chaque ticket et chaque alerte comme toil ou projet. Classez ensuite le toil par heures. Les trois premiers éléments constituent votre backlog d'automatisation.

Qu'est-ce que les post-mortems sans blâme changent ?

Quand quelque chose casse, le post-mortem demande comment le système a permis à une personne de commettre cette erreur, et non qui l'a commise. Le blâme apprend aux gens à cacher l'information. Une revue sans blâme leur apprend à l'écrire.

Un post-mortem utile est court et comporte quatre parties : une chronologie, les causes contributives, ce qui a bien fonctionné, et les actions à mener avec des responsables et des dates. Une action sans responsable reste un vœu pieux.

L'essentiel de la valeur vient du suivi. Revoyez les actions ouvertes chaque mois. Si la même cause réapparaît deux fois en six mois, le premier post-mortem a échoué, quoi qu'en dise le document.

Quels outils une équipe SRE doit-elle adopter en premier ?

Pas beaucoup. Commencez par les signaux, puis ajoutez l'astreinte et l'automatisation.

1. Métriques et tableaux de bord. Suffisants pour calculer vos SLI. Grafana et Prometheus forment un duo open source courant ; Datadog et New Relic constituent la voie hébergée.

2. Alertes liées aux SLO. Alertez quand le budget se consume vite, pas quand un serveur isolé dépasse un seuil. Moins de pages, et de meilleures pages.

3. Feature flags et déploiement progressif. Grosso modo, la plupart des pannes suivent un changement : le gain de fiabilité le moins coûteux consiste à rendre les changements réversibles. LaunchDarkly et Statsig couvrent ce besoin.

4. Un runbook écrit pour chaque page. Si une alerte n'a pas de runbook, rédigez-le ou supprimez l'alerte.

Acheter ou construire, dans cet ordre. Les équipes qui commencent par acheter un outil sans SLO se retrouvent avec de superbes tableaux de bord qui ne mesurent rien en particulier.

Où se situe la lecture de code inconnu dans le SRE ?

C'est le point que personne ne met dans la fiche de poste. Pendant un incident, un SRE doit souvent comprendre un service qu'il n'a pas écrit, dans un dépôt qu'il n'a pas ouvert depuis des mois. La question est rarement abstraite. Elle ressemble à : « où vit cette boucle de retry, et que fait-elle sur un timeout ? »

Vous avez déjà fait cela : grep, blame, puis un message à la personne qui a touché le fichier en dernier. Sur un dépôt de 80K lignes, ça marche. Sur douze services détenus par six équipes, ça mange les 20 premières minutes d'un incident, et ces minutes sont décomptées du budget.

C'est là qu'un outil de recherche de code capable de répondre à des questions sur votre propre dépôt prend tout son sens, par exemple pour demander où un service définit ses timeouts et quels appelants en dépendent. Il ne résoudra pas la panne. Il réduit le temps passé à lire avant de pouvoir agir, et ce temps se mesure.

Le SRE est-il excessif pour votre équipe, et par où commencer ?

Inutile de créer une équipe SRE dédiée si vous avez un seul service, une poignée d'ingénieurs et des utilisateurs qui tolèrent une mauvaise heure de temps en temps. Il vous faut un SLO, une alerte correcte et quelqu'un qui possède l'astreinte.

Envisagez-le dès qu'une de ces conditions est vraie : les pannes coûtent du chiffre d'affaires, l'astreinte épuise les personnes, ou les développeurs sont ralentis par des demandes opérationnelles ponctuelles. Beaucoup d'entreprises commencent par désigner un ou deux ingénieurs à temps partiel comme SRE, puis observent la suite.

Erreur fréquente : renommer l'équipe d'exploitation « SRE » sans changer son fonctionnement. Si elle gère toujours des tickets, des déploiements manuels et aucun budget d'erreur, c'est le titre qui a changé, rien d'autre.

Comment commencer la semaine prochaine

Inutile de réorganiser quoi que ce soit. Choisissez le service visible par les utilisateurs qui vous fait le plus mal, et faites cinq choses.

1. Définissez un SLI et un SLO pour ce service. Gardez-les simples.

2. Calculez le budget d'erreur et affichez-le sur un tableau de bord que toute l'équipe voit.

3. Suivez le toil pendant deux semaines et automatisez l'élément le plus lourd.

4. Organisez un post-mortem sans blâme pour votre prochain incident, avec des actions assignées.

5. Actez par écrit ce qui se passe quand le budget atteint zéro.

Si, dans un mois, l'équipe discute moins de savoir s'il faut livrer et davantage de ce que disent les chiffres, la démarche fonctionne. Si le budget ne bouge jamais parce que le SLO est trop laxiste, resserrez-le.