SRE à quarante : ce qu'une petite organisation peut prendre
À quarante ingénieurs, l'essentiel du SRE tient en un budget d'erreur minimal : deux ou trois SLO, une règle de décision écrite d'avance, un plafond de travail répétitif. Ce qu'il faut prendre, ce qu'il faut laisser, et comment savoir si le dispositif décide quelque chose.
Par Elias Varen6 min de lectureMembres
Le SRE a été conçu pour des organisations qui comptent leurs ingénieurs en milliers et leurs requêtes en millions par seconde. À quarante, on n'a ni l'un ni l'autre, et copier le dispositif complet donne un résultat connu : deux personnes rebaptisées « SRE » qui héritent de l'astreinte de tout le monde, une quinzaine de SLO affichés sur un écran que personne ne regarde, et la même dispute qu'avant entre livrer et stabiliser.
Une seule idée du SRE supporte le changement d'échelle sans perte, le budget d'erreur, parce qu'il relève moins de l'outil d'exploitation que du contrat de décision entre le produit et la technique. Un contrat de décision n'a pas besoin de mille ingénieurs.
Un contrat entre livrer et stabiliser
Un objectif de 99,9 % de réussite sur trente jours autorise 0,1 % d'échec. Sur une fenêtre de trente jours, soit 43 200 minutes, cela fait 43 minutes d'indisponibilité totale, ou l'équivalent réparti. Ce reste constitue le budget.
Son intérêt tient à ce qu'il remplace. Sans lui, la question « peut-on livrer cette semaine ou faut-il stabiliser ? » se règle au rapport de force ; la technique dit que c'est fragile, le produit que c'est urgent, et le plus haut placé tranche à l'humeur. Avec lui, la réponse se lit sur un chiffre que les deux parties ont accepté à froid.
- Tant qu'il reste du budget, la fiabilité est suffisante par définition, et l'équipe peut livrer, prendre des risques, faire sa migration.
- Quand le budget est consommé, la fiabilité passe devant, par définition aussi, jusqu'à ce qu'il se reconstitue.
Le budget protège donc dans les deux sens. Il empêche le produit d'ignorer une dégradation, et la technique de réclamer une perfection que personne n'a demandée. Un objectif de 99,9 % dit explicitement que 99,99 % serait du gaspillage.
À lire ensuite
Toute la rubrique InfraInfra
Alerter sur le burn rate : fenêtres multiples et réglage
D'où viennent les seuils d'une alerte sur la vitesse de consommation du budget d'erreur, comment les recalculer pour votre fenêtre, et pourquoi ils échouent à faible trafic.
7 minMembres
Infra
SLO : pourquoi les vôtres ne servent à rien
Comment reconnaître un SLO de vanité, en construire un sur un parcours utilisateur, et vérifier qu'il change réellement une décision.
8 minMembres
Infra
Anatomie d'une facture cloud
L'ordre dans lequel lire une facture cloud, ce que cache chaque famille de lignes, et comment la ramener à un coût par tenant pour décider quoi optimiser, et quoi laisser tranquille.
7 minMembres