Vos SLO avant vos SLA

Le SLA arrive toujours par le mauvais bout. Un contrat partenaire se négocie, la direction commerciale demande « on peut mettre 99,9 % ? », quelqu'un répond « la plateforme est solide », et le chiffre entre dans le contrat. Personne n'a regardé une seule mesure avant de signer.

Six mois plus tard, on découvre en incident que l'API concernée passe par un backend qui redémarre chaque nuit, et que le 99,9 % promis était mathématiquement intenable dès la signature.

Les trois lettres dans l'ordre

Le vocabulaire est connu mais l'ordre est presque toujours inversé.

SLI d'abord : l'indicateur. Que mesure-t-on, où, et comment ? « Disponibilité » ne veut rien dire tant qu'on n'a pas répondu à : mesurée depuis où (la gateway, le client, une sonde externe), sur quoi (le taux d'erreurs 5xx, le taux de réponses sous un seuil de latence), sur quelle fenêtre.

SLO ensuite : l'objectif interne. Le niveau que l'équipe se donne, mesuré par le SLI, avec une marge d'erreur explicite. C'est un outil de pilotage, pas un contrat : on a le droit de le rater, et le rater déclenche une conversation, pas une pénalité.

SLA en dernier : le contrat. Un engagement externe, avec pénalités, posé en dessous du SLO démontré. En dessous, pas au niveau : si vous tenez 99,95 % démontré sur douze mois, vous pouvez signer 99,9 %. Si vous ne mesurez rien, vous ne pouvez rien signer, vous pouvez seulement parier.

Ce qu'une API peut promettre

Une API ne peut pas être plus disponible que la chaîne qu'elle traverse. Gateway, réseau, fournisseur d'identité, backend, dépendances du backend : la disponibilité composée se dégrade à chaque maillon.

C'est le calcul qui refroidit les enthousiasmes : une gateway à 99,95 % devant un backend à 99,5 % donne une chaîne à 99,45 % dans le meilleur cas. Promettre 99,9 % sur cette chaîne, c'est promettre la météo.

D'où une conséquence pratique : le SLA d'une API se construit backend par backend, pas au niveau de la plateforme. La plateforme peut afficher un engagement global sur ce qu'elle contrôle. Chaque API hérite du plancher de ses dépendances.

L'outillage minimal

Tenir un SLO demande trois choses, toutes fournies par une plateforme correctement observée :

1. le SLI calculé en continu depuis les journaux de la gateway, par API et par consommateur, pas un chiffre global qui noie les problèmes.
2. un budget d'erreur : la quantité d'indisponibilité que l'objectif autorise sur la fenêtre, et sa consommation en temps réel. C'est le chiffre qui transforme les débats d'opinion en décisions : budget consommé, on gèle les mises en production.
3. la mesure des exclusions : maintenances programmées, pannes de dépendances externes, cas de force majeure du contrat. Si elles ne sont pas mesurées à part, le premier litige partenaire se perdra en reconstitution manuelle.

Le bénéfice caché

L'exercice SLO a un effet secondaire précieux : il force l'inventaire des dépendances réelles de chaque API. Pour poser un objectif, il faut savoir par quoi passe l'appel, et ce travail révèle systématiquement des surprises : le backend critique hébergé sur une machine sans redondance, l'appel synchrone vers un SaaS que personne n'avait noté, le certificat partagé entre huit API.

Autrement dit, on commence l'exercice pour préparer un contrat, et on en ressort avec une carte des fragilités. C'est souvent le premier livrable utile, avant même le premier objectif publié.