C'est quoi un SLO ? Définition, calcul et exemple concret

C'est quoi un SLO ? C'est un chiffre que vous vous fixez sur la fréquence à laquelle votre service doit fonctionner, mesuré sur une période fixe. « 99.9% des requêtes réussissent sur 30 jours » est un SLO. Il transforme « le site a l'air correct » en quelque chose de vérifiable, et il vous dit quand arrêter de livrer des fonctionnalités pour corriger ce qui casse.

Vous n'avez pas besoin d'une équipe plateforme pour ça. Un dev solo avec une API et une base Postgres peut écrire un SLO utilisable en un après-midi. Voici ce que le terme veut dire, comment choisir le chiffre, et où ça dérape.

Il était 2 h du matin et personne ne savait si l'app était cassée

Imaginez un projet annexe avec 400 utilisateurs par semaine. Une nuit, l'endpoint de paiement renvoie des erreurs 500 pendant une vingtaine de minutes. Personne ne tweete, personne n'écrit. Vous l'apprenez trois jours plus tard, grâce à un seul message du support.

Était-ce grave ? Sans objectif, impossible de répondre. Avec un SLO qui autorise environ 43 minutes de panne par mois, et que vous venez de consommer 20 minutes, vous savez que cette seule mauvaise nuit a englouti près de la moitié de votre allocation. C'est tout l'intérêt d'un SLO : il remplace une impression par un budget.

SLI, SLO, SLA : trois sigles qu'on confond tout le temps

On mélange sans arrêt SLI, SLO et SLA, donc voici la version courte.

Un SLI (indicateur de niveau de service) est une mesure. « Part des requêtes HTTP qui ne renvoient pas un statut 5xx sur les 30 derniers jours » est un SLI. C'est un ratio entre les événements réussis et le total des événements.

Un SLO (objectif de niveau de service) est la cible fixée sur cette mesure. « Ce ratio doit rester au-dessus de 99.9% » est le SLO. Il est interne : vous le fixez, vous pouvez le modifier, et personne ne vous poursuit s'il n'est pas atteint.

Un SLA (accord de niveau de service) est un contrat assorti de conséquences, en général des remboursements ou des avoirs. La plupart des projets annexes n'ont pas de SLA, et c'est très bien. Vous pouvez faire des SLO sans. Le chapitre du workbook SRE de Google consacré à la mise en œuvre des SLO reste la référence si vous voulez la version longue.

L'ordre compte : choisissez d'abord le SLI, puis le SLO, et ne pensez au SLA que si un client payant le réclame par écrit.

Le budget d'erreur, la partie qui change votre façon de travailler

Un SLO à 99.9% signifie aussi que 0.1% des événements ont le droit d'échouer. Cette marge est votre budget d'erreur, et c'est la moitié utile de l'idée.

Sur un mois de 30 jours, 99.9% de disponibilité laisse environ 43 minutes de panne. Le calcul : 30 jours × 24 heures × 60 minutes = 43 200 minutes, multiplié par 0.001. Une cible de 99% donne environ 7.2 heures. Une cible de 99.99% donne environ 4.3 minutes.

Ces deux dernières valeurs expliquent pourquoi la plupart des petits projets ne devraient pas viser haut. Quatre minutes par mois : un mauvais déploiement suivi d'un rollback suffit à casser la cible. Le piège, en pratique : plus vous visez haut, plus votre temps part à défendre le chiffre au lieu de construire le produit.

Le budget donne aussi une règle pour décider de la suite. Budget presque intact : vous livrez la fonctionnalité risquée. Budget consommé : vous corrigez d'abord le point instable. Pas besoin de réunion, juste un chiffre sur un tableau de bord.

Prenons un exemple chiffré. Un SLO de 99.5% de disponibilité sur 30 jours, pour environ 600 000 requêtes par mois, autorise 0.5% d'échecs, soit 3 000 requêtes en échec avant que le budget soit vide.

Le jour 9, une mauvaise migration renvoie des 500 pendant 25 minutes et coûte 1 100 requêtes en échec. Vous avez consommé environ 37% du budget en une seule soirée. Le jour 17, une API tierce expire et brûle 900 requêtes de plus. Vous voilà à environ 67% dépensé, avec 13 jours devant vous.

C'est le moment où le budget mérite sa place. Inutile de paniquer, mais ne livrez pas le refactoring risqué prévu pour le jour 20. Vous ajoutez un timeout et un fallback sur cet appel tiers, vous écrivez le contrôle de migration que vous aviez sauté, et vous repoussez le refactoring au mois suivant.

La leçon n'est pas que les échecs sont mauvais. Ils sont attendus et déjà intégrés au calcul. Ce que le chiffre vous donne, c'est une réponse calme et partagée à la question « pouvons-nous nous permettre ce risque maintenant ? », même quand la seule personne dans la pièce, c'est vous.

Choisir un SLI mesurable, puis un chiffre plus bas que prévu

Partez de ce qu'un utilisateur appellerait « cassé ». Pour une appli web, cela se résume en général à deux questions : la requête a-t-elle réussi, et a-t-elle été assez rapide ?

Pour la plupart des projets annexes, deux SLI couvrent 90% de la valeur :

• Disponibilité : requêtes réussies divisées par requêtes totales, où réussie signifie une réponse non 5xx.

• Latence : la part des requêtes servies sous un seuil, par exemple 95% des requêtes en moins de 500 ms.

Remarquez que la latence s'écrit comme une part de requêtes sous un seuil, et non comme une moyenne. La moyenne masque la queue lente, et c'est là que les utilisateurs abandonnent. Une moyenne de 300 ms peut cacher un p99 à 4 secondes.

Mesurez à la frontière de votre système, le plus près possible de l'utilisateur. Un health check sur /healthz, pingé depuis le même VPC, vous dit que le processus est vivant, pas que les utilisateurs peuvent se connecter. Si vous ne pouvez mesurer qu'un seul parcours, prenez un chemin réel, comme la connexion ou le paiement, depuis l'extérieur.

Pour le chiffre, la réponse honnête pour un nouveau projet est 99% ou 99.5%. Regardez vos 30 derniers jours de données, calculez ce que vous avez réellement livré, fixez le SLO légèrement en dessous, et resserrez plus tard si les utilisateurs se plaignent.

Quelques repères pour un projet solo :

• Outil perso, sans revenu : 99% suffit. Environ 7 heures de panne par mois passent inaperçues pour la plupart des utilisateurs.

• SaaS payant avec quelques dizaines de clients : entre 99.5% et 99.9%, selon le degré d'urgence du produit.

• Tout ce dont les clients dépendent en heures ouvrées : 99.9%, et testez votre chemin de rollback avant de le promettre.

Un SLO que vous atteignez 100% du temps est un chiffre trop bas. Un SLO que vous ratez chaque mois est un chiffre auquel personne ne croit. Visez à le rater de temps en temps : c'est à ce moment-là que le budget fait son travail.

Quand revoir le chiffre ? Chaque trimestre, ou après un mois où vous l'avez largement raté ou jamais entamé. Le rater deux fois de suite signifie soit que le système a besoin d'un vrai travail, soit que la cible était ambitieuse pour votre stade. Dans les deux cas, c'est une information utile.

Si vous gagnez des clients payants, demandez-leur ce que « cassé » veut dire pour eux. Un client qui lance un rapport chaque lundi se soucie du lundi matin, pas d'un bug du samedi soir, et votre SLO peut le refléter avec une cible plus stricte pendant ses heures.

Un SLO qui tient dans un fichier, et ce que le monitoring classique ne voit pas

Pas besoin d'un prestataire pour commencer. Écrivez ceci dans votre repo, dans un fichier SLO.md :

service: checkout-api
window: 30d
slis:
  availability:
    good: http_status < 500
    total: toutes les requêtes sauf /healthz
  latency:
    good: response_time < 500ms
    total: toutes les requêtes sauf /healthz
objectives:
  availability: 99.5%
  latency: 95%
if_budget_burned:
  - geler les fonctionnalités non urgentes
  - corriger d'abord la principale source d'erreurs

Si votre stack exporte déjà le nombre de requêtes, le SLI de disponibilité tient en une ligne, en syntaxe Prometheus :

sum(rate(http_requests_total{status!~"5.."}[30d]))
  / sum(rate(http_requests_total[30d]))

Ce ratio, comparé à votre cible, est tout votre tableau de bord SLO. Le reste est du détail. Trois panneaux suffisent : le SLI actuel, le budget restant et une courbe de burn rate.

Un ping monitor reste utile. Il vous dit que le site répondait à telle minute. Un SLO vous dit quelle part des vraies requêtes a fonctionné sur un mois, et ce que cela change pour votre prochaine décision. Imaginez deux semaines où le ping affiche du vert chaque minute, pendant qu'une requête lente en base fait expirer la page pour 3% des utilisateurs connectés. Le monitor dit que tout va bien. Le SLI vous dit que vous avez raté votre cible de latence. Un seul des deux change ce que vous faites le lundi.

Gardez le ping monitor quand même. Il coûte peu et détecte vite les pannes totales. Considérez-le simplement comme une entrée parmi d'autres, pas comme la définition de « fonctionne ».

Alerter sur le burn rate, pas sur chaque à-coup

L'erreur que presque tout le monde commet : alerter dès que le taux d'erreur dépasse un seuil. Vous êtes réveillé à 3 h du matin pour un pic de 90 secondes qui a coûté 0.2% du budget du mois.

Le burn rate règle ce problème. Il mesure la vitesse à laquelle vous consommez le budget, par rapport au rythme qui l'épuiserait exactement à la fin de la fenêtre. Un burn rate de 1 signifie que vous finirez le mois avec un budget vide et sans surprise. Un burn rate de 10 signifie que vous serez à sec en trois jours.

Pour une personne seule, deux alertes suffisent. Une rapide, par exemple un burn rate au-dessus de 10 sur une heure, qui vous réveille. Une lente, un burn rate d'environ 2 sur une journée, qui devient un ticket pour le lendemain matin. Le chapitre du livre SRE de Google sur les objectifs de niveau de service explique le raisonnement, et la version multi-fenêtres se trouve dans le workbook cité plus haut.

Quel outil choisir quand vous êtes toute l'équipe ops

Vous pouvez faire tourner des SLO avec un tableur et une tâche cron pendant un mois, le temps de savoir ce qui compte pour vous. Une fois les chiffres importants, un outil se justifie. Trois options valent le coup d'œil, à condition que votre stack pèse davantage que la liste des fonctionnalités.

Grafana est le choix par défaut pour qui exporte déjà des métriques Prometheus. L'offre gratuite est généreuse pour un projet annexe, et la fonctionnalité SLO se pose sur des données que vous avez probablement déjà. Passez votre chemin si vous n'avez pas encore de pipeline de métriques ni l'envie de le construire.

New Relic propose une offre gratuite avec 100 GB de données ingérées par mois, et des outils SLO intégrés à la plateforme. Il convient si vous voulez une installation par agent avec peu de configuration. Le compromis : les coûts deviennent moins prévisibles une fois le forfait gratuit dépassé.

Datadog est l'option la plus complète et la plus chère, avec infrastructure, APM et logs facturés séparément. Ça vaut le coup si une équipe grandit autour de vous. Passez votre chemin pour un projet solo, sauf si quelqu'un d'autre paie.

Quel que soit votre choix, résistez à l'envie de définir quinze SLO le premier jour. Un SLO de disponibilité et un SLO de latence par service exposé aux utilisateurs suffisent pour apprendre.

Trois erreurs qui rendent un SLO inutile

Mesurer ce qui est facile au lieu de ce que ressentent les utilisateurs. L'usage CPU n'est pas un SLI. Les utilisateurs se moquent que votre CPU soit à 40%. Ils veulent que la page charge.

Fixer la cible à partir de l'ambition. « On veut cinq neuf » sonne sérieux et ne veut rien dire si votre base tourne sur une seule instance, sur une petite VM. Fixez le SLO à partir de la réalité observée, améliorez le système, puis resserrez le chiffre.

Ne jamais consommer le budget. Si vous finissez chaque mois avec 98% du budget intact, vous livrez trop lentement ou la cible est trop lâche. Un budget inutilisé représente une capacité de prise de risque gaspillée.

Et vous, quel service placeriez-vous en premier sous un SLO ? Choisissez un endpoint que vos utilisateurs remarqueraient s'il tombait, écrivez le SLI en clair, fixez la cible 0.5 point sous ce que vous avez livré le mois dernier, et revérifiez dans 30 jours. Quel service de votre parc feriez-vous confiance en dernier aujourd'hui ?