Qu'est-ce que la gestion des SLA ?

Qu'est-ce que la gestion des SLA ?

La gestion des SLA consiste à définir, mesurer et rapporter les niveaux de service promis à vos clients. Un accord de niveau de service (SLA) est un contrat qui associe des conséquences, comme des crédits de service, au non-respect d'objectifs convenus tels que la disponibilité ou le temps de réponse. La gérer, c'est fixer des objectifs mesurables, les instrumenter, alerter avant la violation, rapporter le taux d'atteinte et traiter les crédits.

SLI, SLO et SLA : la différence

Le livre SRE de Google définit les trois termes ainsi, et la distinction clarifie qui est responsable de quoi :

• SLI (indicateur de niveau de service) : une mesure quantitative précisément définie d'un aspect du service, par exemple la part des requêtes qui aboutissent.
• SLO (objectif de niveau de service) : une valeur ou une plage cible pour un SLI, par exemple 99,9 % de requêtes réussies sur 28 jours.
• SLA (accord de niveau de service) : un contrat avec les utilisateurs qui prévoit les conséquences du respect ou du non-respect des SLO qu'il contient. Sans conséquence explicite, il s'agit presque sûrement d'un SLO.

Le livre SRE précise aussi que les SLA sont liés à des décisions business et produit, et qu'un SLO interne plus strict que le SLO public laisse de la marge pour corriger les problèmes chroniques avant que les utilisateurs ne les voient. La pratique d'ensemble est décrite dans l'ingénierie de la fiabilité.

Ce que valent les pourcentages de disponibilité en durée

Un objectif de disponibilité ne devient concret qu'une fois converti en indisponibilité autorisée. Les chiffres sont de la simple arithmétique : (1 moins l'objectif) fois la durée de la fenêtre, pour une semaine de 7 jours, un mois de 30 jours et une année de 365 jours.

Vérifiez quelle fenêtre le contrat utilise. Un mois civil de 31 jours autorise plus d'indisponibilité qu'un mois de 28, et 99,99 % laisse environ quatre minutes par mois, qu'un seul déploiement lent peut consommer.

Comment fonctionne la gestion des SLA

1. Rédiger des termes mesurables. Précisez le périmètre (quels endpoints ou fonctions), la fenêtre de mesure, la façon de compter une requête en échec et les exclusions, comme la maintenance planifiée annoncée à l'avance.
2. Mesurer le SLI de l'extérieur. Mesurez ce que vit le client, pas ce que croit votre serveur. Des contrôles externes depuis plusieurs lieux sont plus difficiles à contester que les seuls logs internes.
3. Fixer un SLO interne plus strict. Si le SLA promet 99,5 % par mois, un SLO interne de 99,9 % laisse environ 2 heures 53 minutes de marge mensuelle (172,8 minutes sur un mois de 30 jours) avant que le contrat soit menacé.
4. Alerter sur le SLO, pas sur le SLA. Quand le SLA est violé, le client l'a déjà ressenti.
5. Rapporter le taux d'atteinte. Publiez le chiffre mensuel automatiquement, par exemple sur une page de statut, pour que personne n'ait à le discuter.
6. Traiter les violations. Calculez les crédits selon le barème du contrat, prévenez le client et faites un retour d'expérience. La communication d'incident pendant la panne fait partie de l'expérience du SLA.

Exemple

Une société SaaS promet 99,5 % de disponibilité mensuelle pour son API et tient un SLO interne de 99,9 %. Sur un mois de 30 jours, le SLO autorise 43 minutes d'indisponibilité et le SLA 3 heures 36 minutes. Un mauvais déploiement provoque 52 minutes d'erreurs : le SLO est manqué, l'équipe ouvre une revue d'incident, mais le SLA est respecté et aucun crédit n'est dû. Sans SLO interne, personne n'aurait regardé avant que la ligne du contrat soit franchie.

Erreurs fréquentes

• Promettre un SLA sans SLO ni mesure associés, si bien que le taux d'atteinte se discute de mémoire.
• Choisir un chiffre dans un tableau, comme les cinq neuf, plutôt que ce que l'architecture peut tenir.
• Mesurer la disponibilité depuis un seul lieu, qui ne distingue pas un problème régional d'un problème global.
• Ne compter que les pannes totales et ignorer les réponses lentes que les clients vivent comme des échecs.
• Laisser les exclusions floues, si bien que chaque incident devient un litige.

Gestion des SLA avec tests et surveillance

La surveillance produit le SLI. La surveillance d'API contrôle vos endpoints à intervalles réguliers et enregistre échecs et temps de réponse. La surveillance d'API de LoadFocus lance des contrôles depuis 25 régions cloud, alerte par e-mail, Slack, Microsoft Teams et d'autres canaux, et affiche la disponibilité sur la période choisie. Le plan gratuit contrôle toutes les 5 minutes et inclut une page de statut ; les rapports de SLA par rapport à un objectif sont disponibles sur les plans payants.

Les tests montrent si l'objectif est réaliste. On ne défend pas une promesse de latence en période de pointe sans tests de charge ni tests de capacité. Côté surveillance, lisez l'article en anglais bonnes pratiques de surveillance pour DevOps et développeurs.

Questions fréquentes : gestion des SLA

Quelle différence entre SLA, SLO et SLI ?

Un SLI est une mesure, un SLO est un objectif pour cette mesure et un SLA est un contrat qui associe des conséquences au non-respect de l'objectif. Les équipes exploitent en général des SLO en interne et promettent un SLA plus souple à l'extérieur.

Combien d'indisponibilité autorise 99,9 % ?

Environ 43 minutes sur un mois de 30 jours et environ 8 heures 46 minutes sur une année de 365 jours. Chaque neuf supplémentaire divise la marge par dix.

Que se passe-t-il quand un SLA est violé ?

Cela dépend du contrat. Le recours courant est un crédit de service calculé selon un barème de l'accord. Consultez votre propre contrat pour les conditions exactes, la procédure de réclamation et les exclusions.

Le SLO doit-il être plus strict que le SLA ?

Oui. Un SLO interne plus strict vous prévient avant que le contrat soit menacé et laisse de la marge pour corriger les problèmes avant que les clients ne les voient.

Qui est responsable de la gestion des SLA ?

Plusieurs équipes. L'ingénierie gère la mesure et l'architecture, le produit et le succès client le contrat et sa rédaction, la finance les crédits.