Le métier de SRE : labeur, SLO et taux de consommation du budget d'erreur

Objectif

Comprendre ce qu'on attend d'un ingénieur SRE (Site Reliability Engineering) en entreprise, mesurer le labeur (le travail manuel qui ne finit jamais) et piloter les décisions de livraison avec le taux de consommation du budget d'erreur, au-delà du simple calcul du budget vu dans la formation Supervision.

L'essentiel

• Le SRE applique des méthodes d'ingénierie logicielle à l'exploitation : il mesure la fiabilité, l'automatise et la négocie avec les équipes produit.
• Le labeur (toil) est le travail manuel, répétitif, automatisable, sans valeur durable, qui grossit avec le trafic. On le mesure et on le plafonne (souvent à 50 % du temps).
• Le budget d'erreur ne sert à rien s'il n'est relié à une politique écrite : qui décide du gel, à partir de quel seuil, avec quelles exceptions.
• Le taux de consommation (burn rate) dit à quelle vitesse on brûle le budget : 1 = on finira pile à la fin de la fenêtre ; 14,4 = on aura tout brûlé en 50 heures.
• On alerte sur le burn rate avec deux fenêtres (une longue pour la certitude, une courte pour savoir que ça dure encore), pas sur un simple taux d'erreur instantané.

1. Ce que fait un SRE au quotidien

Dans une ESN ou une grande société IT, l'intitulé « SRE » recouvre souvent les mêmes missions :

Le SRE n'est pas « l'administrateur qui fait tout » : il passe une partie importante de son temps à coder (scripts, outils, automatisation) pour que l'exploitation ne grossisse pas au même rythme que le service.

SRE, DevOps, administrateur système

• DevOps est une culture : les équipes de développement et d'exploitation partagent les objectifs et les outils.
• SRE est une façon concrète de la mettre en œuvre, avec des chiffres (SLO, budget, labeur).
• L'administrateur système reste indispensable ; le SRE en garde les compétences (Linux, réseau, stockage) et y ajoute la mesure et le code.

2. Le labeur : le mesurer pour s'en débarrasser

Une tâche est du labeur si elle coche la plupart de ces cases :

• manuelle : quelqu'un tape des commandes ;
• répétitive : on l'a déjà faite la semaine dernière ;
• automatisable : une machine pourrait la faire ;
• réactive : déclenchée par une alerte ou un ticket, pas par un projet ;
• sans valeur durable : après l'avoir faite, le service n'est pas meilleur qu'avant ;
• proportionnelle au trafic : deux fois plus de clients, deux fois plus de travail.

Ne sont pas du labeur : écrire un post-mortem, concevoir une alerte, automatiser une tâche, les réunions de planification (ce sont des frais généraux, à surveiller autrement).

Mesurer

On note pendant une ou deux semaines le temps passé, puis on fait le compte :

# categorie;nature;minutes
awk -F';' 'NR>1 {total+=$3} NR>1 && $2=="toil" {labeur+=$3}
           END {printf "Labeur : %d min sur %d (%.0f %%)\n", labeur, total, 100*labeur/total}' semaine.csv

# Les catégories qui coûtent le plus : les premières à automatiser
awk -F';' '$2=="toil" {m[$1]+=$3} END {for (c in m) print m[c], c}' semaine.csv | sort -rn | head -3

La règle la plus répandue : pas plus de 50 % de labeur par personne. Au-delà, l'équipe n'a plus le temps de construire les outils qui la libéreraient, et le labeur grossit encore. Quand le plafond est dépassé, on le dit à la direction comme on signalerait un disque plein : c'est un risque, pas un mérite.

Choisir quoi automatiser

Le bon candidat combine fréquence, durée et risque :

gain mensuel ≈ fréquence par mois × minutes par exécution
             + coût d'une erreur humaine × probabilité de se tromper

Redémarrer l'API à la main 12 fois par mois (30 minutes chacune, à 3 h du matin) vaut bien deux jours de développement. Copier un certificat une fois par an, beaucoup moins.

3. SLO : aller plus loin que le calcul du budget

La formation Supervision a posé les bases : SLI, SLO, SLA, budget d'erreur en minutes. Le métier de SRE consiste à s'en servir pour décider.

Choisir un bon SLI

Un SLI doit refléter ce que vit l'utilisateur. Quelques choix fréquents :

Mesurer au répartiteur de charge voit les erreurs que l'application ne journalise même pas (processus planté, délai d'attente). Mesurer par une sonde synthétique (un faux client qui passe une commande toutes les minutes) voit aussi les pannes quand personne n'achète.

La politique de budget d'erreur

Un budget sans règle écrite déclenche des disputes à chaque incident. Une politique tient en une page :

Service : API de paiement      SLO : 99,9 % de requêtes non 5xx, 30 jours glissants
Si le budget consommé dépasse 100 % :
  - gel des nouvelles fonctionnalités jusqu'à revenir sous le SLO
  - seules partent en production les corrections de bugs et de fiabilité
  - le prochain sprint comporte au moins un chantier de fiabilité
Si un seul incident consomme plus de 20 % du budget : post-mortem obligatoire
Exception : correctif de sécurité urgent (décision du responsable technique)
Arbitrage en cas de désaccord : direction technique

Cette politique est signée à froid par le produit et la technique, pas négociée au milieu d'une panne.

4. Le taux de consommation (burn rate)

Le budget sur 30 jours dit combien on a consommé. Le burn rate dit à quelle vitesse.

burn rate = taux d'erreur observé / taux d'erreur autorisé par le SLO

SLO 99,9 %  →  taux autorisé = 0,1 % = 0,001
Dernière heure : 1 728 erreurs sur 120 000 requêtes = 1,44 %
burn rate = 0,0144 / 0,001 = 14,4

Temps avant épuisement d'un budget neuf : 720 h / burn rate.

Alerter sur le burn rate, avec deux fenêtres

Alerter sur « taux d'erreur > 0,1 % pendant 5 minutes » réveille l'astreinte pour des pics sans importance. La pratique éprouvée combine une fenêtre longue (la consommation est significative) et une fenêtre courte (elle est toujours en cours, sinon l'alerte se termine vite) :

En PromQL (formation Supervision), la première ligne s'écrit avec deux conditions reliées par and : le ratio d'erreurs sur [1h] et sur [5m] dépassent tous deux 14.4 * 0.001. L'important ici est le raisonnement, pas la syntaxe.

Calculer à la main pendant un incident

Pendant un incident, on n'a pas toujours le tableau de bord : un journal d'accès suffit.

# Journal du répartiteur : le 9e champ est le code HTTP
total=$(wc -l < acces.log)
erreurs=$(awk '$9 ~ /^5/' acces.log | wc -l)
awk -v e="$erreurs" -v t="$total" 'BEGIN {printf "taux=%.4f burn=%.1f\n", e/t, (e/t)/0.001}'

5. Cas réel : la boutique MasterLinux pendant les soldes

Vendredi, 10 h. Le tableau de bord indique un budget mensuel consommé à 60 %. Personne ne s'inquiète : il reste 40 %. À 10 h 30, le burn rate sur une heure passe à 14,4, et sur 5 minutes à 16 : l'alerte part. L'astreinte découvre qu'un nouveau moyen de paiement renvoie des erreurs 503 pour un client sur soixante-dix. À ce rythme, les 40 % restants partent en 20 heures, avant la fin des soldes. Le retour arrière est fait à 10 h 50. Le lundi, la politique s'applique : budget consommé à 104 %, gel des nouveautés, la semaine est consacrée à des tests de charge du moyen de paiement.

Sans burn rate, l'équipe aurait vu « 60 % consommé, tout va bien » jusqu'à la rupture du SLO.

Pièges fréquents

• Compter le labeur « au feeling » : sans relevé du temps, chacun sous-estime ses tâches manuelles. Mesurez deux semaines avant de décider.
• Un SLO à 100 % : impossible à tenir et paralysant (aucun changement n'est plus permis). Visez ce que les utilisateurs remarquent.
• Confondre budget consommé et burn rate : 60 % consommé avec un burn rate de 0,5 est calme ; 10 % consommé avec un burn rate de 50 est une panne en cours.
• Une politique de gel jamais appliquée : si le gel est toujours levé « exceptionnellement », le SLO ne veut plus rien dire.

Lab

Sur Ubuntu 24.04, dans /root/sre, vous allez :

1. calculer la part de labeur de l'équipe sur une semaine ;
2. désigner la catégorie de labeur à automatiser en premier ;
3. calculer le burn rate de la dernière heure ;
4. en déduire le temps avant épuisement d'un budget neuf ;
5. appliquer la politique de budget d'erreur à la fenêtre de 30 jours.

Quiz

1. Citez quatre caractéristiques du labeur.
2. Pourquoi plafonne-t-on le labeur à environ 50 % du temps d'un SRE ?
3. Un SLO de 99,9 % et 0,6 % d'erreurs sur la dernière heure : quel est le burn rate ?
4. Pourquoi une alerte de burn rate utilise-t-elle une fenêtre longue et une fenêtre courte ?
5. Qui doit signer la politique de budget d'erreur, et quand ?