SLO, SLA et surveillance de la fiabilité

(Section : Technologie et infrastructure)

Résumé succinct

SLO est un objectif de qualité interne, SLA est un engagement externe envers le client, SLI - comment nous mesurons la qualité. Dans iGaming, les principaux SLI sont : disponibilité API et paiement, p95/p99 latence des itinéraires critiques, Time-to-Wallet (TTW), conversion de paiement, lancement de jeux, ainsi que métriques de file d'attente. La gestion de la fiabilité s'articule autour d'un budget d'erreurs, d'alertes multi-burn, de gates de sortie claires et d'annotations visuelles.

1) Termes et différences

SLI (Service Level Indicator) est un indicateur mesurable (par exemple, la proportion de requêtes réussies par fenêtre temporelle).
SLO (Service Level Objective) est la valeur cible SLI (par exemple, "disponibilité 99. 9 % en 30 jours").
SLA (Service Level Agreement) - contrat/engagement avec rémunération ; basé sur des SLO réels, mais incluant des clauses légales et des fenêtres d'exception (maintenance planifiée, force majeure).

Règle : Stabilisez d'abord le SLI/SLO à l'intérieur, puis fixez le SLA à l'extérieur.

2) Cadre SLI pour iGaming

TexSLO

Disponibilité : succès 2xx/3xx/toutes les demandes.
Latitude : p95/p99 par routeurs clés ('/deposit ', '/bet', '/game/init ').
Errors : proportion 5xx/timeout.
Saturation/Queues : retard des files d'attente de paiement/transactions.

Business-SLI

Payment conversion: `success/attempt`.
TTW p95 : temps entre la demande de retrait et l'inscription.
Game start success : sessions de jeux, initialisation du fournisseur.
KYC/AML flow success : réussite du parcours.

3) Budget des erreurs : comment compter

Error Budget = 1 − SLO.
Exemple : SLO disponibilité 99. 9 %/30d ⇒ budget des erreurs = 0. 1 % du temps ≈ 43min 12s dans la fenêtre de 30 jours.

success_ratio = success_requests / all_requests error_ratio  = 1 - success_ratio

Le SLO est compté sur la fenêtre glissante (30/7/1 jour) et visible sur les dashboards.

• La « combustion » rapide du budget → freeze releases, canaris stop, travailler sur la stabilité.
• La marge budgétaire → permet des changements plus fréquents (contrôlables).

4) Exemples de SLO pour les flux clés

• Availability ≥ 99. 9 %/30d
• Latency p95 `/deposit` ≤ 250 ms / 30д
• Payment conversion ≥ baseline − 0. 3 %/24h
• TTW p95 (sortie) ≤ 3 min/24h

• Game init success ≥ 99. 5% / 7д p95 game init ≤ 600 ms / 7д

• Job success ≥ 99 %/7d, lag <5 min (fenêtres de pointe séparées).

5) Mesure : Formules et BouQL (idées)

promql sum(rate(http_requests_total{status=~"2..    3..",service="payments-api"}[5m]))
/
sum(rate(http_requests_total{service="payments-api"}[5m]))

promql histogram_quantile(0. 95,
sum by (le) (rate(http_request_duration_seconds_bucket{service="payments-api",route="/deposit"}[5m])))

promql histogram_quantile(0. 95,
sum by (le) (rate(ttw_seconds_bucket{flow="withdrawal"}[15m])))

promql sum(rate(payments_success_total[15m])) / sum(rate(payments_attempt_total[15m]))

6) Burn-rate alert (multi-window)

Idée : comparer le débit actuel du budget à celui autorisé.

• Fast burn : 14 × de budget en 1 heure → page en 5-15 minutes.
• Slow burn : 6 × de budget en 24 heures → ticket, analyse de la raison.

yaml recording rule: job:http:success_ratio — заранее alert: SLOFastBurn expr: (1 - job:http:success_ratio{job="payments-api"}) > (1 - 0. 999) 14 for: 10m labels: { severity: "page" }

alert: SLOSlowBurn expr: (1 - job:http:success_ratio{job="payments-api"}) > (1 - 0. 999) 6 for: 1h labels: { severity: "ticket" }

7) Dashboards « SLO-map » et opération

• Cartes par service : Availability, p95, Error-rate, Burn-rate, reste Error Budget.
• Filtres : « bou », « région », « tenant », « version ».
• Annotations de sortie : Git SHA, type (canary/blue-green), temps de commutation.

• Comparaison de stable vs canary.
• Coupure par PSP/fournisseurs de jeux.
• Accédez à exemplars (trace_id) et aux logs associés.
• Queue lag et saturation (métriques d'utilisation).

8) Processus SLO : Gates, freeze, escalade

Gates en CD : la promotion canari n'est autorisée que lorsque le proxy SLO est exécuté (availability, p95, bou).
Freeze : Avec un budget fast-burn ou zéro, arrêtez les sorties avant la reprise.
Escalades : matrice SEV (paiements/dépôts SEV1, jeux SEV2, bacoffis SEV3).
RCA : examen sans charges, mise à jour des tests/limites/ficheflags.

9) Data/ML-SLO (pour les recommandeurs/LLM)

Latency : p95 réponses du modèle ≤ 300 ms (ou tokens/s ≥ N).
Qualité proxy : proportion de réponses valides/faible toxicité, partager d'helpful.
Freshness : âge des fiches/données ≤ X heures.
Cost per 1k événements : dépenses dans le budget.
Les gates SLO sont intégrés dans les versions des modèles (A/B/rollout canarien).

10) Conception SLA basée sur SLO

Choisissez les SLO conservateurs comme base de SLA.
Identifiez les exceptions (travaux planifiés, fournisseurs dépendants externes, règles relatives aux incidents).
Inscrivez les indemnités selon le niveau d'infraction (crédit/remise), les mécanismes de déclaration et de vérification.

11) Erreurs fréquentes et anti-modèles

Pas de SLO, seulement « uptime 100 % » - irréaliste, démotivant et cachant les risques.
Les alertes de « chaque métrique » au lieu de burn-rate sont alert-fetig et ignorées.
Le mélange PII dans les métriques/loges pour SLO est un risque de complication.
La cardinalité explose : 'user _ id/session _ id' en tant que labels.
L'absence d'annotations de version est difficile à lier aux dégradations aux changements.
Budget opaque des erreurs - l'équipe ne comprend pas quand « vous pouvez » risquer.
SLO n'est pas lié aux entreprises - les technologies « vertes », les recettes « rouges ».

12) Chèque de mise en œuvre

1. Approuver le SLI de base (Disponibilité, p95/p99, Taux d'erreur, TTW, Conversion).
2. Définissez SLO sur les fenêtres 30/7/1 jour et comptez Error Budget.
3. Ajoutez les règles de recording et les alertes burn-rate (fast/slow).
4. Construisez une carte SLO avec des annotations de version et des comparaisons canary/stable.
5. Incluez les gates dans le CD : sans SLO-ok - sans promotion.
6. Entrez les procédures freeze et la matrice d'escalade SEV.
7. Relier le SLO aux métriques d'affaires (bou, TTW) et aux itinéraires de paiement.
8. Pour Data/ML, définissez latency/quality/freshness-SLO.
9. RCA réguliers et révision des SLO/seuils (trimestriels).
10. Documenter le SLA seulement après la stabilisation du SLO.

13) Exemples de cibles « prêtes » (comme départ)

API générale : Disponibilité 99. 9 %/30д; p95 ≤ 250 ms/30d ; Error-rate ≤ 0. 3 %/30д.
Payments: Conversion ≥ baseline − 0. 3 %/24ч; TTW p95 ≤ 3 min/24h.
Games init: Success ≥ 99. 5 %/7д; p95 ≤ 600 ms/7d.
Backoffice jobs: Success ≥ 99%/7д; lag ≤ 5 min/7d.
LLM/Reco: tokens/s ≥ N, toxicity viol. ≤ 0. 5 %/7d, freshness ≤ 6h.

Résultats

L'approche SLO/SLA transforme la fiabilité de « mieux qu'hier » en une discipline mesurable : SLI transparent, budget d'erreur compréhensible, alertes sur la vitesse de combustion, dashboards compréhensibles et gates de qualité intégrés dans les versions. Ce circuit donne à la plate-forme iGaming un p95/p99 prévisible, des paiements stables et des TTW, ce qui signifie un meilleur chiffre d'affaires et moins d'incidents dans les heures les plus chaudes.