Suivi des SLA et SLO

1) Termes et rôles

SLA (Service Level Agreement) est une obligation contractuelle externe envers le client (clauses de pénalité, crédits).
SLO (Service Level Objective) est un niveau de service interne cible qui prend en charge l'exécution de SLA.
SLI (Service Level Indicator) est un indicateur mesurable sur la base duquel les SLO/SLA sont évalués.
Error Budget est la proportion admissible de « non disponibilité/erreur » pour la période : 'Budget = 1 − SLO'.
Scope : mesuré par les yeux de l'utilisateur (end-to-end). Dans les microservices - au niveau du composant et du chemin de passage.

2) Sélection SLI : exactement ce qu'il faut mesurer

Le critère est la corrélation avec l'expérience utilisateur et la valeur commerciale.

• Disponibilité : proportion de demandes réussies. 'SLI = réussies/tous'.
• Latence : la proportion de requêtes est plus rapide que le seuil T. 'SLI = P (latence ≤ T) ".
• Qualité : proportion de réponses correctes (sans 5xx/fonction. erreurs).
• Pertinence des données : délai de réplication/ETL ≤ X minutes.
• Rendement du processus opérationnel : proportion de paiements/inscriptions réussis.

Anti-schémas : ne compter que 200 ki comme un « succès » en ignorant les erreurs commerciales ; mesurer dans le réseau de test au lieu de l'utilisateur.

3) Formules et fenêtres d'observation

• `Availability = (OK_requests / All_requests) × 100%`.

• 'P95 ≤ T '→ mieux être formulé en proportion :' SLI = % des requêtes ≤ T '.
• Exemple : « 99 % des requêtes de recherche ≤ 300 ms en 28 jours ».
• Fenêtre coulissante : 28 ou 30 jours (équilibre de sensibilité et de stabilité). Pour les incidents - fenêtres : 1 h, 6 h, 24 h

4) Error Budget et gestion de la vitesse du changement

Calcul : à 'SLO = 99. 9 % 'budget =' 0. 1 % 'erreurs/indisponibilité par période.

• Budget> 50 %: sorties et expériences selon le plan.
• Budget de 10 à 50 %: seulement les sorties à bas risque, le resserrement des canaries.
• Budget <10 %: gel des versions, cause racine, amélioration de la fiabilité.
• Lien avec les versions progressives : canary/feature-flags « mangent » le budget dosé, avec un retour automatique en cas de dégradation.

5) Alert-politics : des seuils au taux de burn

Pourquoi n'a-t-il pas « douché SLO - levez l'alert » : trop tard. Il faut être proactif.

• « BR = (erreur observée dans une fenêtre courte/erreur valide dans cette fenêtre) ».
• Si « BR> 1 », le budget est dépensé plus vite que la normale.

• Alert rapide (le bruit est sensible, attrape les catastrophes) : fenêtre 5-10 min, seuil BR 14-20 ×.
• Alert lent (attrape les dégradations rampantes) : fenêtre 1-6 h, seuil BR 2-4 ×.
• Conditions à combiner : rapide ou lent - paging on-call.
• Niveaux : pager pour SLO personnalisé, tickets/notifications pour les dégradations grises des SLI internes.

6) Observabilité et sources de vérité

Logs - diagnostic des causes.
Les métriques sont des SLI numériques (succès/erreur, latence, parts, compteurs).
Les tracés sont des chemins de passage, la localisation des segments « chauds ».
Synthétique - échantillons actifs de la périphérie (région-aware).
Événements réels - RUM/télémétrie des clients, métriques d'affaires (conversion, paiements réussis).

Exigences : une seule image en dashboards de sorties et d'incidents, annotations « version/canari/drapeau ».

7) Conception SLO : modèle étape par étape

1. Décrivez le chemin critique (p. ex., « dépôt par carte »).
2. Identifiez SLI : succès/erreur, seuil de latence, exhaustivité.
3. Accord SLO : objectif pour 28 jours + exceptions (fenêtres programmées).
4. Relier avec SLA : obligation légale ≦ SLO réel.
5. Attribuez un propriétaire (service owner), un RACI et un canal d'alertes.
6. Définissez les politiques d'alerte (BR à deux fenêtres) et les restaurations automatiques.
7. Mettre en place des rapports : examens hebdomadaires du budget, revues post-incidents.
8. Révisez le SLO tous les trimestres (changement de charge/architecture).

8) Exemples de SLO (modèles)

• Disponibilité : '≥ 99. 95 % '(28d, à l'exclusion des fenêtres annoncées ≤ 30 min/mois).
• Latence : '≥ 99 %' des réponses '≤ 400 ms'.
• Succès des opérations commerciales : '≥ 98. 5 % d'autorisations réussies (filtres fraud pris en compte).

• Latence : '≥ 99 %' des requêtes '≤ 300 ms'.
• Pertinence du cache : '≤ 5 min' retard dans 99 % des cas.

• Livraison : '≥ 99. 9 % "pendant" ≤ 60 s "(fin à fin, avec retraits).
• Perte : '≤ 0. 01 % 'des messages (idempotence/déduplication incluse).

9) Multi-région et multi-tenant

SLO « par cohorte » : pays, fournisseur de paiement, segment VIP, appareil.
SLO local sur le bord : métriques des points les plus proches de l'utilisateur (edge/PoP).
Agrégation : le SLO général ne doit pas cacher les échecs dans les cohortes importantes.
Changement de fournisseur : itinéraires de chute automatiques au niveau des gates SLO.

10) Dashboards et rapports

Sortie dashboard : version, canari (% de trafic), SLI (succès/latence), BR, annotations de drapeaux.
Dashboard opérationnel : budget de burn-down par jour, incidents de haut niveau, MTTR, cohortes problématiques.
Rapports hebdomadaires : bilan budgétaire, tendances BR, dette technique (goulets d'étranglement), plan d'amélioration.

11) Processus : Incidents, ACR et améliorations

Gestion de l'incident : alert → évaluation BR → l'échelle des canaries/drapeaux → le retour/fix.
RCA (racine cause) : faits/temporisation/hypothèses/corrections/vérification de l'effet par SLI.
Leçons apprises : post-mortem non-punitif, éléments d'action obligatoires avec les propriétaires et les délais.
Boucle de fermeture : changements dans les tests, les drapeaux de ficha, les limites, les caches, les retraits, les quotas.

12) Conformité et audit

SLO/SLI en tant qu'artefacts de contrôle (policy-as-code, logs immuables).
Liaison aux exigences (par exemple, disponibilité des opérations de paiement).
Preuves : procès-verbaux d'alerte, rapports budgétaires, journaux de sortie/de retrait.

13) Erreurs fréquentes et comment les éviter

“99. 99 % ou la mort" : objectifs inaccessibles → bruit d'alerte constant. Choisissez des SLO réalistes.
Les moyennes mondiales cachent les échecs locaux → injecter des cohortes.
Les métriques ne sont pas e2e : les SLO élevés lors de la dégradation réelle sur le client → ajouter RUM/synthétique.
Les alertes d'un seuil → passer à un taux de burn à deux fenêtres.
Il n'y a pas de lien avec les modifications → les versions ne sont pas annotées, il n'y a pas de retour automatique.

14) Mini-chèque de mise en œuvre

• Les voies critiques et leurs SLI/SLO sont décrites.
• La fenêtre d'observation et d'exclusion est définie.
• Les alerts BR à deux fenêtres (rapides et lents) sont personnalisés.
• Mises à jour et opérations avec annotations de version/drapeaux.
• La politique error budget affecte les versions.
• Examens budgétaires réguliers et ACR post-incidents.
• Documentation et propriétaires d'indicateurs.

15) Exemple de calcul (concret)

API de disponibilité SLO : 99. 9 % en 28 jours → budget = 0. 1%.
En 7 jours, 0 s'est accumulé. 06 % des erreurs ont → dépensées 60 % du budget hebdomadaire.
On observe 2 % d'erreurs sur une fenêtre courte de 15 min. Valide sur cette fenêtre : '0. 1 % de × (15 min/40320 min) ≈ 0. 000037%`.
Burn Rate ≫ 1 (des dizaines de ×) → un pager rapide est déclenché, le canari est ramené à 1%, le drapeau ficha « degrade-payments-UX » est activé, RCA est lancé.

16) Résultat

Le suivi des SLA/SLO n'est pas seulement un chiffre dans le rapport, mais un mécanisme de gestion du risque de changement et de la qualité du service. Les bons SLI, les SLO réalistes, la gestion error du budget, les alertes à burn-rate à deux fenêtres et l'observation e2e transforment les métriques en solutions de travail : libérer plus rapidement la valeur et maintenir l'expérience utilisateur prévisible.