SLO et budget d’erreur : par où commencer en SaaS?

Pour commencer avec les SLO, choisissez un ou deux indicateurs que vos clients ressentent (la disponibilité et la latence d’une action clé), fixez une cible un peu plus souple que ce que vous visez vraiment (une marge de sécurité), et traitez l’écart comme un budget d’erreur qui guide vos décisions de livraison. Pas besoin d’une équipe SRE pour cela. Il faut surtout choisir peu de choses et s’y tenir.

C’est quoi, un SLI, un SLO et un SLA?

Le chapitre sur les objectifs de niveau de service du livre Site Reliability Engineering de Google donne des définitions utiles :

• SLI (indicateur de niveau de service) : une mesure quantitative bien définie d’un aspect du service, par exemple la latence, le taux d’erreurs ou la disponibilité.
• SLO (objectif de niveau de service) : une valeur cible, ou une plage de valeurs, pour un SLI.
• SLA (entente de niveau de service) : un contrat avec vos utilisateurs qui prévoit des conséquences si les SLO ne sont pas atteints. Sans conséquence, c’est probablement un SLO.

Une erreur fréquente est de promettre un SLA aux clients avant d’avoir mesuré le moindre SLI. Mesurez d’abord. Promettez ensuite, et avec une marge.

1. 1Indicateur (SLI)
2. 2Objectif (SLO)
3. 3Budget d’erreur
4. 4Décision de livraison

Le budget d’erreur est l’écart permis entre 100 % et la cible.

Quels indicateurs choisir en premier?

Le même chapitre conseille de retenir quelques indicateurs qui reflètent ce qui compte pour les utilisateurs : trop d’indicateurs dispersent l’attention, trop peu laissent des comportements importants sans surveillance. Il cite comme catégories courantes la latence, la disponibilité, le débit, la durabilité et la justesse.

Pour une application SaaS, un bon départ tient en deux indicateurs :

1. Disponibilité : la part des requêtes valides qui réussissent (par exemple, qui ne retournent pas une erreur 5xx).
2. Latence : la part des requêtes de l’action la plus importante (connexion, enregistrement, export) qui répondent sous le seuil que vous jugez acceptable (500 ms, par exemple).

Mesurez la latence avec des percentiles plutôt qu’une moyenne. Selon le même ouvrage, la moyenne peut cacher la longue traîne qui touche de vrais utilisateurs, alors que les percentiles élevés (99e, 99,9e) montrent le pire cas plausible.

Comment fixer la cible sans se piéger?

Parmi les conseils du livre, quatre nous semblent particulièrement solides :

• Ne partez pas de vos performances actuelles. Adopter les chiffres d’aujourd’hui sans réfléchir peut vous enfermer dans un système qui exige des efforts héroïques pour tenir ses cibles et qu’on ne peut pas améliorer sans refonte importante.
• Restez simple. Les agrégations compliquées cachent les changements et sont plus difficiles à raisonner.
• Ayez le moins de SLO possible. Abandonnez ceux qui ne vous aident jamais à défendre une priorité.
• Commencez souple. Il vaut mieux resserrer une cible que la relâcher après avoir découvert qu’elle était inatteignable.

Pour mesurer ce que chaque cible signifie en pratique, calculez le temps d’indisponibilité permis. Le calcul est simple : un mois de 30 jours compte 43 200 minutes, multipliées par (1 moins la cible).

99 %432 minutes

99.5 %216 minutes

99.9 %43 minutes

99.99 %4 minutes

Calcul simple, pas un benchmark : 43200 minutes × (1 − cible), arrondi.

Passer de 99,9 % à 99,99 % divise le budget par dix. Chaque neuf supplémentaire demande en général plus de redondance, de garde et de complexité (c’est notre expérience du métier, pas un chiffre du livre). Demandez-vous si vos clients paieraient pour ce neuf.

Que fait-on du budget d’erreur?

Le livre explique que la conformité parfaite n’est ni réaliste ni souhaitable. On autorise plutôt un budget d’erreur, soit le taux auquel le SLO peut être manqué, qu’on suit chaque jour ou chaque semaine. L’écart entre les violations réelles et le budget peut éclairer les décisions de mise en production.

Voici le point de départ que nous proposerions à une petite équipe (c’est notre approche, pas une règle tirée du livre) :

• Budget en santé : on livre normalement.
• Budget presque épuisé : on ralentit les changements risqués et on corrige d’abord les causes des pannes récentes.
• Budget épuisé : on suspend les nouveautés risquées jusqu’au retour à l’équilibre, et la direction produit et la direction technique le décident ensemble.

Ce qui compte, c’est que la règle soit écrite et acceptée avant la prochaine panne, pas pendant.

Comment alerter sans réveiller l’équipe pour rien?

Alerter chaque fois qu’une erreur survient fatigue tout le monde. Le chapitre sur l’alerte basée sur les SLO du Site Reliability Workbook recommande une approche à fenêtres multiples et à taux de consommation multiples. Chaque alerte combine une longue fenêtre, qui confirme qu’une part importante du budget est consommée, et une courte, qui confirme que le problème est encore en cours et permet à l’alerte de se résorber vite.

Pour un SLO de 99,9 %, le tableau recommandé est :

Les deux premières lignes réveillent quelqu’un. La troisième crée simplement un billet pour la semaine. Cette séparation est ce qui rend la garde supportable.

Que vérifierions-nous en premier?

Nous commençons par des questions, pas par des outils :

• Quelle est l’action qu’un client remarque tout de suite quand elle casse?
• Avons-nous déjà des métriques de requêtes (taux d’erreurs, latence) par route, ou faut-il d’abord les instrumenter?
• Qui décide quand le budget est épuisé, et ce choix est-il écrit?
• Les alertes actuelles correspondent-elles à un effet sur les clients, ou à un seuil technique arbitraire (processeur à 80 %, par exemple)?

Si vous voulez de l’aide pour cadrer cela avec un regard senior, la page CTO fractionnel explique comment nous travaillons.

Cet article est de l’information générale et ne constitue pas un avis professionnel. Adaptez les cibles et les seuils à votre contexte et à vos engagements contractuels.