SLO : Service Level Objective
Infrastructure
SLO : Service Level Objective. « Objectif de niveau de service », par analogie avec la promesse qu'on se fait de courir trois fois par semaine, un peu plus exigeante que l'abonnement signé avec la salle de sport.
Indicateur, objectif, contrat : On mesure un indicateur (latence, taux de succès), on lui fixe un objectif interne, le SLO, et on s'engage contractuellement sur un seuil plus prudent, le SLA. L'écart entre les deux est l'espace où se loge la dignité de l'équipe d'exploitation.
Le budget d'erreur : Un objectif inférieur à cent pour cent autorise une quantité d'échecs sur une période. Tant que le budget n'est pas consommé, on livre ; quand il fond, on stabilise.
Alertes : Alerter sur la vitesse de consommation du budget plutôt que sur chaque pic évite de réveiller quelqu'un pour une anomalie que les utilisateurs n'ont pas vue.
Côté sécurité : Les services de sécurité méritent aussi leurs objectifs : disponibilité d'un service de signature, délai de révocation, fraîcheur des listes de révocation. Un contrôle indisponible finit toujours par être contourné « temporairement ».
Ce qui arrive si on s'en passe
Sans objectif de niveau de service, aucun seuil ne dit à partir de quand une dégradation devient un problème. Les incidents lents passent inaperçus jusqu'aux plaintes des utilisateurs, et les alertes sont réglées au jugé, soit trop bavardes pour être lues, soit trop discrètes pour servir. Pour les services de sécurité, cela signifie qu'une autorité de signature, un répondeur de révocation ou un fournisseur d'identité peut se dégrader sans que personne ne le voie ; les équipes applicatives finissent alors par ajouter des contournements, désactiver des vérifications ou allonger des délais, et ces exceptions provisoires ont une longévité remarquable.
Explication de la marmotte
Un service en ligne ne fonctionne jamais parfaitement tout le temps. Plutôt que de promettre l'impossible, l'équipe qui s'en occupe se fixe un but chiffré, par exemple : la page doit répondre correctement dans presque tous les cas sur un mois. Elle mesure en permanence si ce but est tenu. Tant qu'il l'est, elle peut ajouter des nouveautés ; si les pannes s'accumulent, elle se concentre sur la réparation. C'est un peu comme un élève qui se fixe une moyenne à atteindre : ça l'aide à savoir quand réviser davantage.
Où ce terme est utilisé
- Gestion réseau, supervision et référentiels d’exploitation (5 occurrences)
- Saturation d'une équipe de sécurité : une panne d'architecture (3 occurrences)
- Comment observer un LLM en production (2 occurrences)
- Gérer une crise cloud multi-tenant (2 occurrences)
- Observabilité en architecture cyber : logs, métriques, traces (2 occurrences)
- Réduire l’alert fatigue sans perdre la détection (2 occurrences)
- Relier FinOps et MLOps pour piloter le coût de l'IA en production (2 occurrences)