SLO/SLA et métriques

SLO/SLA et métriques

1) Termes et hiérarchie

SLI (Service Level Indicator) est un indicateur mesurable « tel que l'utilisateur nous voit » : proportion de demandes réussies, p95 latence, fraîcheur des données, proportion de trampolines traitées avec succès, etc.
SLO (Service Level Objective) est la valeur cible de SLI sur l'intervalle d'observation (28/30/90 jours). Exemple : "99. 9 % des demandes/paiements sont terminés ≤ 400 ms'.
Error budget — 1 − SLO. Sous SLO 99. 9 % d'erreurs de budget = 0. 1 % du temps/des demandes.
Le SLA (Accord) est un niveau de service juridiquement significatif : comprend le SLO, la mesure, les exceptions, les compensations/amendes.

2) Principes de conception

Symptômes> métriques internes. SLI doit refléter l'expérience utilisateur réelle.
Un petit nombre de SLI clés. Pour le service - 2-5 principales : succès, latence, bande passante/fraîcheur, exactitude.
Couvrir les voies critiques. Pour chaque scénario d'entreprise (checkout, login, webhook, ETL-téléchargement) - son propre jeu de SLI/SLO.
Sémantique rigoureuse du « succès ». Pas « code 200 », mais « l'utilisateur a reçu une réponse dans le délai et le résultat est validé ».
Séparation des SLO externes et internes. Intérieur - plus strict ; le SLA externe est ≤ 1-2 neuf plus bas.

3) Catalogue SLI (référence)

3. 1 API/services en ligne

Taux de réussite : 'SLI _ success = 1 − (5xx + timeout + business_error )/ all_requests'

Latence : p95/p99 'http _ server _ durée _ secondes' par itinéraire/méthodes/locataires

Bande passante : 'RPS '/limites/quotas

Exactitude : proportion de réponses valides (signatures, schémas, invariants)

3. 2 Webhooks/livraisons asynchrones

Livraison : proportion d'événements confirmés en T secondes et ≤ N rétroactifs

Clients : part d'abonnés sans retard prolongé (per-tenant)

3. 3 Données/ETL/DWH

Fraîcheur (freshness) : 'now − last_successful_ingest_ts'

Exhaustivité : 'ingested _ rows/ expected_rows'

Exactitude : proportion d'enregistrements ayant subi des contrôles de qualité

Piplines : proportion de job remplis jusqu'à la date limite

3. 4 SDK mobile/client

Succès client : proportion de séances sans erreurs fatales

Latence round-trip : p95 de la demande au rendu

Cash hits : proportion de personnes servies à partir du cache (comme symptôme de performance)

4) Formules et exemples d'objectifs

• `SLI_req_avail = 1 − (failed_requests / total_requests)`
• `SLO_req_avail = 99. 95 % 'pendant 30 jours → error budget = 0. 05 % des demandes.

• `uptime = (obs_window − downtime) / obs_window`

• 'SLO _ latency = p95 (route = »/pay ») ≤ 400 ms'sur 7 jours, à l'exclusion des échauffements de cache (1 %)

• 'SLO _ freshness (dataset = » orders ») ≤ 10 min' p99 en 24 heures.

5) Error budget et gestion du changement

Budget (B) : « B = 1 − SLO ».
Dépense budgétaire (burn) : rapport des erreurs réelles aux erreurs admissibles.

• Dépassement (burn> 1) → fichfriz, accent mis sur la fiabilité.
• Avec burn rate> X dans une fenêtre courte - incident et cap. mesures.
• Planification : la part du sprint sur la fiabilité est corrélée avec le burn de la période précédente.

6) Alerting : taux de burn et règles multi-fenêtres

L'idée : capturer les fuites rapides et la dérive lente.

• Critique : « 2 % du budget en 1 heure » (incendie rapide).
• Attention : « 5 % du budget en 6 heures » (dégradation rampante).

• Fenêtre courte (minute-heure) pour les incidents rapides.
• Fenêtre longue (6-24 heures) pour les tendances.
• Latence : alert par p99> seuil de ≥5 min, avec suppression de flapping et communication avec les exemplaires des pistes.

error_ratio_5m = errors[5m] / requests[5m]
error_ratio_1h = errors[1h] / requests[1h]
burn_5m     = error_ratio_5m / error_budget_fraction burn_1h     = error_ratio_1h / error_budget_fraction alert_critical if burn_1h > 14 and burn_5m > 14 alert_warning  if burn_6h > 6 and burn_30m > 6

7) Polyvalence (multi-tenant) et segmentation

Les SLI/SLO sont comptés par locataire/plan/région, sinon la médiane « bloquera » les échecs.
Nombre minimum d'événements pour la signification statistique (guard-rails).
Les SLA peuvent varier selon les tarifs (par exemple, "Pro 99. 9%, Free 99. 5%»).

8) Lien avec l'observation et les traces

Métriques SLI - à partir des histogrammes/compteurs avec les implars → passer aux trajets « mauvais ».
Les logs sont la source des causes : délais, codes d'erreur commerciale, limites.
Pour les données, un lien avec lineage : « Quel joba a retardé la mesure de fraîcheur ».

9) Contrats et SLA

• Définitions de SLI/méthode de mesure/fenêtre.
• Exceptions (travaux planifiés, force majeure).
• Procédure d'incident et de communication (page d'état, DP/DP).
• Compensation (crédits de service) et procédure de demande.
• Compétence, durée de validité, conditions du réexamen.

• Ne jamais promettre publiquement un SLO plus strict que l'architecture et les pratiques opérationnelles le permettent.
• Séparez les SLO internes et les SLA externes.

10) Coût et priorité

Le prix du neuvième n'augmente pas linéairement. «99. 9% → 99. 99 %" = une autre classe d'architecture (N + 1, multisone, actif-actif).
Mettez SLO sur les actions utilisateur les plus précieuses.
Contrôler le coût de la télémétrie : downsampling, quotas, réplique et stockage par classe.

11) Procédures et rapports

Rapports hebdomadaires : exécution de SLO sur les services/locataires, dépenses budgétaires, raisons principales, plans d'amélioration.
RCA postincidents : nous associons avec des morceaux de budget ; Nous mettons l'accent sur les causes profondes.
Fichfriz : critères d'inclusion/retrait.

12) Modèles (pour un démarrage rapide)

12. 1 Carte SLO (exemple)

Service: Checkout API
SLI:
success: 1 - (5xx+timeouts+biz_failures)/all latency_p95: p95(http_server_duration_seconds{route="/pay"})
SLO:
success: 99. 95% / 30d latency_p95: ≤ 400ms / 7d
Windows:
primary: 30d rolling secondary: 7d rolling
Burn Alerts:
critical: use 1h/5m > 14 warning: use 6h/30m > 6
Owner: Team Checkout
Tenancy: per-tenant (≥ 1k req/day threshold)
Dashboards: RED + trace exemplars

12. 2 Table « SLO maturité »

13) Exemples de règles (fragments)

promql
Error rate (5xx + timeout) for the sum (rate (http_requests_total{route="/pay",code=~"5. route.    599"}[5m]))
/ sum(rate(http_requests_total{route="/pay"}[5m]))

p99 histogram_quantile latency (0. 99, sum(rate(http_server_duration_seconds_bucket{route="/pay"}[5m])) by (le))

promql error_budget_fraction = 0. 001 for 99. 9%
(err_rate_5m / 0. 001 > 14) and (err_rate_1h / 0. 001 > 14) # critical
(err_rate_30m / 0. 001 > 6) and (err_rate_6h / 0. 001 > 6)  # warning

promql
Data order lag (minutes)
(max(time()) - max(last_ingest_ts_seconds{dataset="orders"})) / 60

14) SLO pour les données et ML (caractéristiques)

Données SLO de bout en bout : fraîcheur p99, exhaustivité p99, temps de « refonte » après panne.
Contrats de données : schémas attendus, volumes, doublons ; violation → des données.
ML : SLO sur la latence de l'inference, SLA sur la disponibilité du fich store, surveillance de la dérive (la qualité du modèle est un sujet distinct, en dehors de SLA).

15) Intégration avec la sécurité et la vie privée

Logs SLI sans PII/secrets ; Tokenisation/masquage.
Audit des modifications apportées aux SLO/SLA et des publications de rapports dans des revues immuables.
Pour les voies réglementaires (paiements/IPI) - SLO séparés et plus stricts.

16) Chèques-feuilles

Avant de lancer le service/fiches

• Défini par le SLI « succès/latence/bande passante/fraîcheur ».
• Spécifiés par SLO et fenêtres ; le budget des erreurs a été calculé.
• Les alertes burn-rate (court + long) sont configurées.
• Dashboards RED + exemples de pistes → ; runibooks des incidents.
• Coupes et seuils de signification multi-arènes.
• Procédure de fichfrise et de déclaration.

Exploitation

• Rapport hebdomadaire sur SLO/burn, plans hardening.
• Réévaluation du SLO lorsque l'architecture/la charge change.
• « Incidents-exercices » périodiques et mise à jour des runibooks.
• Contrôle du coût de la télémétrie et de la quantité de SLI.

17) Runbook’и

Runbook : Croissance rapide de p99/pay

1. Alert p99> le seuil → ouvrir le dashboard → passer par examplar à la piste.
2. Trouvez un CLIENT/SERVER-span étroit, comparez les régions/versions.
3. Activer la dégradation (cache/limite/follback), avertir la commande de dépendance.
4. Après stabilisation - RCA, tâche d'optimisation, mise à jour des mesures SLO.

Runbook : dépenses budgétaires> 50 % par semaine

1. Geler les fiches, augmenter la priorité de fiabilité.
2. Clustering d'erreurs : par itinéraire/locataires/dépendances.
3. Faire des corrections → confirmer le rétablissement de la tendance.
4. Rétrospective et ajustement des alertes/seuils.

18) FAQ

Q : Combien de SLO faut-il ?
R : Minimum sur les scénarios critiques personnalisés : succès + latence. Tout le reste, par nécessité.

Q : Quelle est la meilleure chose - disponibilité dans le temps ou sur demande ?
R : Selon les demandes, une métrique plus personnalisée. Temps utile pour les composants réseau/infra.

Q : Pourquoi p95 et pas la moyenne ?
O : Le milieu cache la queue ; l'utilisateur sent p95/p99.

Q : Comment ne pas « tourner les écrous » trop fort ?
R : Commencez par des objectifs réalistes (données historiques), puis resserrez-les à mesure que vous arrivez à maturité.

• « Observabilité : logs, métriques, tracés »
• Traces distribuées
• Audit et journaux invariables
• « Garantie de livraison des webhooks »
• « Cryptage In Transit/At Rest »
• Origine des données (Lineage)