SLA, SLO et SLI : comprendre et calculer la disponibilité
SLA, SLO, SLI : définitions, formule de disponibilité, temps d'arrêt autorisé de 99 % à 99,99 %, budget d'erreur et clauses de contrat.
- Publié le
- Temps de lecture
- 7 min de lecture
Sur cette page
- SLA, SLO et SLI : trois notions, trois rôles
- Le SLI, la mesure
- Le SLO, l'objectif interne
- Le SLA, l'engagement contractuel
- La formule et les temps d'arrêt autorisés
- La formule
- Le tableau des objectifs courants
- Exemple chiffré et budget d'erreur
- Un mois avec incidents
- Le budget d'erreur
- Ce qui compte comme une indisponibilité
- Mesurer depuis l'extérieur et depuis plusieurs régions
- La disponibilité composée des services dépendants
- Choisir un objectif réaliste
- Rédiger les clauses d'un SLA
- En résumé
Un client vous demande de garantir 99,9 % de disponibilité. Le chiffre paraît raisonnable, presque modeste. Mais savez-vous combien de minutes d'arrêt il vous laisse chaque mois, ce qui compte comme une panne, et comment vous prouverez que l'engagement a été tenu ?
Ce guide pose les définitions, donne la formule et les temps d'arrêt autorisés, déroule un exemple chiffré, puis aide à choisir un objectif et à rédiger des clauses solides.
SLA, SLO et SLI : trois notions, trois rôles
Le SLI, la mesure
Le SLI (Service Level Indicator) est un indicateur mesuré : le pourcentage de vérifications réussies sur la page d'accueil, la proportion de requêtes API servies sans erreur 5xx, ou celle des pages chargées en moins d'une seconde. C'est un fait, pas un objectif : « en septembre, le site a répondu correctement depuis l'extérieur pendant 99,94 % du temps ».
Le SLO, l'objectif interne
Le SLO (Service Level Objective) est la cible que l'équipe se fixe sur un SLI, sur une période donnée : « 99,9 % de disponibilité sur un mois calendaire ». Il sert à piloter le travail : tant qu'il est respecté, on livre ; s'il est menacé, on ralentit et on consolide.
Le SLA, l'engagement contractuel
Le SLA (Service Level Agreement) est la promesse faite au client, avec des conséquences si elle n'est pas tenue, le plus souvent des avoirs. Il est en général moins ambitieux que le SLO : avec un objectif interne de 99,9 %, vous pouvez vous engager sur 99,5 % et garder une marge entre le moment où l'équipe réagit et celui où vous devez de l'argent.
La formule et les temps d'arrêt autorisés
La formule
Le calcul tient en une ligne :
disponibilité (%) = (temps mesuré − temps d'indisponibilité) / temps mesuré × 100
Le temps mesuré est la période de référence, moins les fenêtres de maintenance si le contrat les exclut. Le temps d'indisponibilité est la somme des pannes retenues. Tout l'enjeu est dans ces deux définitions, pas dans la division.
Le tableau des objectifs courants
Calculé sur un mois moyen de 30,44 jours et une année de 365 jours, arrondi à la seconde :
| Objectif | Arrêt autorisé par mois | Arrêt autorisé par an |
|---|---|---|
| 99 % | 7 h 18 min 20 s | 3 j 15 h 36 min |
| 99,5 % | 3 h 39 min 10 s | 1 j 19 h 48 min |
| 99,9 % | 43 min 50 s | 8 h 45 min 36 s |
| 99,95 % | 21 min 55 s | 4 h 22 min 48 s |
| 99,99 % | 4 min 23 s | 52 min 34 s |
Chaque « 9 » supplémentaire divise le temps d'arrêt par dix. Passer de 99,9 % à 99,99 %, c'est passer de trois quarts d'heure à quatre minutes par mois : à peine le temps de recevoir l'alerte et d'ouvrir son ordinateur. Pour d'autres valeurs, par jour, par semaine ou par trimestre, utilisez notre calculateur de SLA gratuit.
Exemple chiffré et budget d'erreur
Un mois avec incidents
Prenons septembre, 30 jours, soit 43 200 minutes, pour un site e-commerce avec un SLO de 99,9 % :
- le 3, une saturation de la base de données provoque une panne confirmée de 18 minutes ;
- le 17, un déploiement défectueux rend le site indisponible 7 minutes ;
- le 24, une maintenance planifiée et annoncée dure 40 minutes ;
- à plusieurs reprises, le site est lent mais répond, environ 2 heures au total ;
- une nuit, une seule sonde voit le site en erreur pendant que les autres le voient en ligne.
Si le contrat exclut la maintenance et ne retient que les pannes confirmées, le temps mesuré est de 43 200 − 40 = 43 160 minutes, l'indisponibilité de 18 + 7 = 25 minutes :
(43 160 − 25) / 43 160 × 100 = 99,942 %
Le SLO est tenu. Si la maintenance compte comme une panne, on obtient (43 200 − 65) / 43 200 = 99,850 % et l'objectif est manqué. Même mois, même service, deux conclusions opposées : tout doit être écrit à l'avance.
Le budget d'erreur
Le budget d'erreur est la part d'indisponibilité que l'objectif autorise : 43 min 50 s pour 99,9 % sur un mois moyen. Dans notre exemple, sur 43 160 minutes mesurées, il vaut 43,16 minutes, dont 25 consommées, soit 58 %.
Plutôt que de viser zéro panne, l'équipe dispose d'un budget à dépenser. Il en reste beaucoup à mi-mois ? On peut livrer cette migration un peu risquée. Il est presque épuisé ? On gèle les mises en production non urgentes. Le chapitre Embracing Risk du livre SRE de Google détaille cette mécanique.
Ce qui compte comme une indisponibilité
C'est la source de la plupart des litiges, et il n'y a pas de réponse universelle.
Les pannes confirmées comptent toujours, à condition d'être réelles : un échec isolé vu depuis une seule sonde relève souvent d'un problème réseau local. Exiger une confirmation par une majorité de régions évite de gonfler le temps d'arrêt, comme nous l'expliquons dans notre guide pour éviter les faux positifs grâce au multi-régions.
Les dégradations sont une zone grise. Une page qui met 12 secondes à s'afficher est disponible en théorie, pas pour l'utilisateur. Certains contrats ignorent la lenteur, d'autres fixent un seuil de temps de réponse. Choisissez, et écrivez-le.
Les maintenances planifiées sont généralement exclues, si elles ont été annoncées avec un préavis défini (72 heures, par exemple) et restent sous un plafond mensuel. Sans plafond, dix heures de « maintenance » par mois videraient le SLA de son sens.
Les causes externes (faute du client, force majeure, fournisseur tiers explicitement nommé) font l'objet d'exclusions classiques, à négocier.
Mesurer depuis l'extérieur et depuis plusieurs régions
Un SLA ne vaut que s'il est mesuré d'une manière que le client accepte. Les métriques internes ne suffisent pas : une machine injoignable ne remonte rien et une panne DNS passe inaperçue. La mesure doit venir de l'extérieur, comme vos utilisateurs.
Plusieurs régions de mesure rendent le résultat plus juste : une panne vue depuis Paris, Amsterdam et Varsovie est une vraie panne, un échec vu d'un seul point peut venir du réseau entre la sonde et vous. C'est le principe de la surveillance multi-régions de LucidStack : quand une vérification échoue, les autres régions du moniteur revérifient immédiatement, et la panne n'est déclarée que si la majorité échoue.
La fréquence compte aussi. Avec une vérification toutes les 5 minutes, chaque panne est mesurée avec plusieurs minutes d'incertitude, ce qui est incompatible avec les 4 min 23 s mensuelles de 99,99 %. Au-delà de 99,9 %, il faut vérifier à la minute ou toutes les 30 secondes.
La disponibilité composée des services dépendants
Votre site dépend d'un hébergeur, d'une base de données, d'un prestataire de paiement, d'un DNS. Quand des composants sont en série, c'est-à-dire que la panne d'un seul rend le service inutilisable, leurs disponibilités se multiplient :
99,95 % × 99,9 % × 99,9 % = 99,75 %
Trois briques honorables donnent 99,75 %, soit près d'1 h 50 d'arrêt possible par mois : impossible de promettre 99,9 % sur cet ensemble.
La redondance joue en sens inverse : deux composants indépendants à 99,9 % en parallèle donnent en théorie 1 − (0,001 × 0,001) = 99,9999 %. Mais les pannes sont rarement indépendantes : ce chiffre est un plafond optimiste.
Choisir un objectif réaliste
Partez de votre historique : si votre disponibilité mesurée sur six mois tourne autour de 99,93 %, un SLO à 99,9 % est atteignable, un SLA à 99,99 % ne l'est pas. Tenez compte ensuite de l'architecture et de l'organisation :
- un site ou un SaaS hébergé sur une seule infrastructure vise raisonnablement 99,5 % à 99,9 % ;
- 99,95 % suppose de la redondance et des déploiements sans interruption ;
- 99,99 % exige en plus une astreinte réactive à toute heure et une détection en moins d'une minute.
Chaque « 9 » supplémentaire se paie en infrastructure et en nuits blanches : gardez un écart entre SLO interne et SLA contractuel.
Rédiger les clauses d'un SLA
Un SLA solide répond au minimum à ces questions :
- Périmètre : quels services, URL ou points d'API sont couverts.
- Méthode de mesure : outil de surveillance externe, régions, fréquence des vérifications, règle de confirmation d'une panne, fuseau horaire et période de référence.
- Définition de l'indisponibilité : codes de réponse acceptés, délai d'expiration, traitement des dégradations.
- Exclusions : maintenances annoncées et plafonnées, causes imputables au client, force majeure, dépendances tierces nommées.
- Avoirs : paliers (un pourcentage de la mensualité selon l'écart à l'objectif, par exemple), plafond total, caractère libératoire ou non.
- Réclamation : délai pour la demander, justificatifs, source de données qui fait foi.
Un rapport mensuel partagé avec le client, comme les rapports clients de LucidStack avec disponibilité, incidents et temps de réponse, sert de base commune.
En résumé
Le SLI mesure, le SLO guide l'équipe, le SLA engage vis-à-vis du client. Décidez à l'avance ce qui compte comme une panne, comment vous la mesurez et ce que vous excluez. LucidStack mesure la disponibilité depuis trois régions européennes, ne retient que les pannes confirmées, exclut vos fenêtres de maintenance et reprend ces chiffres dans ses rapports mensuels (à partir du plan Solo). Le plan gratuit suffit pour commencer à constituer l'historique qui vous aidera à choisir votre prochain objectif.