SLA, SLO et KPI Fiabilité

1) Termes et différences

L'indicateur de niveau de service est un indicateur de qualité mesurable (par exemple, la proportion de demandes réussies, la latence p95).
SLO (Service Level Objective) est la valeur cible SLI par fenêtre temporelle (par exemple, "succès ≥ 99. 9 % en 28 jours").
Erreur budgétaire (Error Budget) : Part de non-exécution autorisée de SLO : '1 − SLO'.
SLA (Service Level Agreement) - obligations contractuelles avec pénalités/crédits (externes).
KPI de fiabilité - métriques opérationnelles du processus (MTTD/MTTA/MTTR/MTBF, % des mitygates automatiques, couverture d'alertes, etc.).

2) Comment choisir SLI (basé sur les signaux Golden)

1. Latency - p95/p99 pour les endpoints clés.
2. Traffic - RPS/RPM/flux de messages.
3. Errors est la proportion d'erreurs commerciales 5xx (par exemple, le paiement « decline par faute de PSP » à exclure).
4. Saturation - Saturation des ressources (CPU/RAM/IO/lag).

• Corrélation avec l'expérience utilisateur (user-perceived).
• Techniquement disponible et stable dans la mesure.
• Nous contrôlons (des actions d'amélioration sont possibles).
• Faible coût de la collecte.

3) Formules et exemples

3. 1 Disponibilité (disponibilité)

Availability = Успешные запросы / Все запросы
Error Budget (за период) = 1 − SLO

Exemple : SLO 99. 9 % en 30 jours → budget des erreurs = 0. 1 %, ce qui équivaut à 43 min 12 secondes d'indisponibilité.

3. 2 Latence

Latency SLI = доля запросов с duration ≤ T
SLO пример: 99% запросов ≤ 300 мс (rolling 28d)

3. 3 Paiements (au niveau de l'entreprise)

Payment Success SLI = (успешные проводки — внешние отказы PSP) / все попытки

4) Budget erroné et burn-rate

L'erreur budgétaire est votre « réservoir de carburant » pour innover (sorties, expériences).

• canal rapide (détecteur en ~ de 1 h),
• canal lent (tendance en ~ 6-12 h/24 h).

• Si burn-rate> 14. 4 en 1 heure - SEV-1 (mangeons le budget journalier pour ~ 100 min).
• Si burn-rate> 6 en 6 heures - SEV-2 (dégradation rapide).

5) Alerting par SLO (multi-window, multi-burn)

Indicateur d'erreur : proportion de 5xx ou d'irrégularités de latence.

promql
Доля ошибок за 5 минут sum(rate(http_requests_total{status=~"5.."}[5m]))
/
sum(rate(http_requests_total[5m]))

Быстрый burn (1m окно)
(
sum(rate(http_requests_total{status=~"5.."}[1m])) /
sum(rate(http_requests_total[1m]))
) / (1 - SLO) > 14.4

Медленный burn (30m окно)
(
sum(rate(http_requests_total{status=~"5.."}[30m])) /
sum(rate(http_requests_total[30m]))
) / (1 - SLO) > 2

promql p95 latency histogram_quantile(0.95, sum by (le) (rate(http_request_duration_seconds_bucket[5m])))

6) Exemples de SLI/SLO par domaine

6. 1 passerelle API/Edge

SLI-Errors : taux de réponse 5xx <0. 1% (28d).
SLI-Latency : p95 ≤ 250 ms (jour).
SLO: Availability ≥ 99. 95 % (trimestre).

6. 2 Paiements

SLI-Success : paiement du succès (à l'exclusion des échecs clients) ≥ 99. 8% (28d).
SLI-Latency : autorisation ≤ 2 secondes pour 99 % (jour).
SLO: Time-to-Wallet p95 ≤ 3 мин (24h).

6. 3 Bases de données (PostgreSQL)

SLI-Lag : réplication lag p95 ≤ 1 sec (jour).
SLI-Errors : proportion d'erreurs de requête ≤ 0. 05% (28d).
SLO : disponibilité du cluster ≥ 99. 95%.

6. 4 Files d'attente/streaming (Kafka)

SLI-Lag : lag des consommateurs p95 ≤ N messages (heure).
SLI-Durability : confirmation d'enregistrement ≥ 99. 99% (28d).
SLO : disponibilité des courtiers ≥ 99. 9%.

7) Processus de fiabilité KPI

MTTD (Mean Time To Detect)

MTTA (… To Acknowledge)

MTTR (… To Restore)

MTBF (… Between Failures)

% d'incidents de mitigation automatique

Couverture SLO/alertes des meilleurs chemins de trafic (cible ≥ 95 %)

Part des sorties avec la phase Canaries

Consommation de budget erroné par équipe/fiche

8) Comment mettre SLO réaliste

1. Mesurer la fiabilité de base actuelle (3-4 semaines).
2. Identifiez les chemins d'accès utilisateur « sensibles » (login, dépôt, jeu).
3. Tenez compte du coût de chaque déviation (temps, argent, réputation).
4. Choisissez un objectif ambitieux mais réalisable (une amélioration de 10 à 30 % par rapport à la base).
5. Examiner tous les trimestres.

• Cinq neuf sans justification.
• SLO par métriques non visibles par l'utilisateur (par exemple, CPU sans lien avec UX).
• Trop de SLO → spray focus.

9) Rapports sur les OSL et les budgets

• Exécution pour chaque SLO : réalité vs objectif, tendances, confiance.
• Résumé de la consommation d'erreurs : combien de budget est « brûlé » que, par qui (sortie/incident).
• Les cinq principales causes de dégradation, le plan CAPA et l'état des tâches.
• Impact sur les entreprises : conversion, ND, rétention, LTV.

10) Lien avec la politique de libération

Budget d'erreur <50 % → versions libres.
50 à 80 % → « mode de précaution » : seulement low-risk/canaris.

11) SLA (contractuel) - modèles de clauses

Obligation d'accessibilité : par exemple 99. 9 %/mois.
Exceptions (Force Majeure) : DDoS hors de contrôle raisonnable, fournisseurs tiers.
Fenêtre de mesure et zone de responsabilité : sources de métriques, méthode de calcul.
Crédits/pénalités : tableau des niveaux (p. ex. indisponibilité 60-120 min → crédit X %).
Procédures d'escalade et de notification : délais, canaux.
Données et vie privée : masquage, stockage, Legal Hold.
Plan de travail pour la prévention des répétitions (CAPA) en cas de violation.

12) Outils de mesure

Métriques passives : Prometheus/Mimir/Thanos, exportateurs.
Logs : Loki/ELK pour compter les succès/erreurs au niveau de l'entreprise.
Synthétique : échantillons actifs (login/dépôt/jeu) par cron.
Trace : Tempo/Jaeger pour « goulots d'étranglement » p99.
Paiement/Finance : sources de truth ground pour le SLI de paiement.

13) Exemples de demandes (modèles)

promql
1 - (
sum(rate(http_requests_total{status=~"5.."}[5m]))
/ sum(rate(http_requests_total[5m]))
)

yaml slo:
name: "API Availability"
window: "28d"
target: 0.999 sli: "1 - 5xx%"
owner: "Platform SRE"
alerting:
fast_burn: {window: "1h", factor: 14.4}
slow_burn: {window: "6h", factor: 6}

success_rate = (count_over_time({app="payments"}     = "status=success"[5m]))
/ (count_over_time({app="payments"}     ~ "status=(success    fail)"[5m]))

14) FinOps et fiabilité

Cost per 9 : le coût de l'ajout d'un « neuf » augmente exponentiellement.
Courbe des avantages : optimum lorsque les gains de revenus/réduction des pertes ≥ le coût des « 9 » supplémentaires.
Portefeuille SLO : différents niveaux pour différents chemins (paiements critiques « plus chers », rapports « moins chers »).

15) Qualité SLO/alerts - chèque

• SLI est corrélé avec l'UX et les métriques d'entreprise.
• Fenêtre et agrégation harmonisées (rolling 28d/trimestre).
• Alert multi-window, sans flapping, avec routage de rôle.
• Documentation : propriétaire, formule, sources, runbook.
• Panneau de démonstration SLO avec budget défectueux et indicateurs burn.
• Révision régulière des objectifs (trimestrielle).
• Tests de synthèse sur des scénarios clés.

16) Plan de mise en oeuvre (4 itérations)

1. Semaine 1 : inventaire des chemins utilisateur, brouillons SLI, dashboards de base.
2. Semaine 2 : formalisation du SLO, calcul des budgets, alertes (fast/slow burn).
3. Semaine 3 : intégration avec le processus d'incident/release, règles freeze.
4. Semaine 4 + : SLA contractuels, revues trimestrielles, modèle « cost per 9 ».

17) Mini-FAQ

Dois-je avoir un SLO par service ?
Mieux que 2 ou 3 clés (succès + latence) au lieu de dizaines de mineures.

Et si le budget était épuisé ?
Gel des rejets, accent mis sur la stabilisation et le CAPA, retrait des fiches expérimentales.

Comment éviter un conflit entre la vitesse de sortie et la fiabilité ?
Planifiez les versions « selon le budget », mettez en œuvre les canaries et les fonctionnalités.

Total

La fiabilité n'est pas gérée par un ensemble de métriques disparates, mais par le système : SLI → SLO → erreur de budget → burn-alerting → processus d'incident → CAPA → SLA. Normalisez les définitions, les sources de données et les rapports, liez les objectifs à l'expérience utilisateur et à l'économie, et révisez régulièrement le niveau de 9 % en fonction du ROI réel.