Error Budgets et gestion SLO

1) Pourquoi SLO et budget des erreurs

SLO (Service Level Objective) est le niveau de qualité cible perçu par l'utilisateur ; SLI est une métrique mesurable ; Error Budget - tolérance pour les écarts par fenêtre (habituellement 30/90 jours).
Le budget des erreurs transforme la fiabilité d'une « abstraction » en une ressource gérable : quand le budget brûle rapidement - geler les fiches et le chinim ; lorsque le budget est en bonne santé, il est possible d'accélérer les sorties.

2) Le choix de SLI : Que considérer comme « bon »

Critère : « avec succès du point de vue de l'utilisateur ».

2. 1 SLI classique

Disponibilité : proportion de demandes réussies (sauf celles annulées par le client).
« success = http_status ∈ {2xx, 3xx, 404} et sans délai » (404 peut être considéré comme un succès pour l'API de lecture si c'est la sémantique attendue).
Latitude : la proportion de requêtes est plus rapide que le seuil (par exemple, p95 ≤ 300 ms).
`good_latency = duration_ms ≤ 300`.
Freshness/Staleness : « données ne dépassant pas X minutes » (cache, répertoires, coefficients).
Qualité : exactitude du résultat (passage des validateurs d'entreprise/invariants backend).

2. 2 Frontières et segments

SLI doit être compté par tranches importantes : 'route', 'tenant/brand', 'region/jurisdiction', 'payment _ provider'. Ainsi, vous ne « briserez » pas la défaillance d'un stylo critique dans tout le système.

3) Formules et budget

3. 1 Request-based (de préférence pour l'API)

SLO_availability = good_requests / total_requests
Error_budget = 1 - SLO_target
Burn = 1 - SLO_actual

3. 2 Time-based (pour les services d'arrière-plan/streaming)

SLO_uptime = good_minutes / total_minutes

3. 3 Exemple d'objectifs

API général : 99. 9 % de disponibilité en 30 jours → budget = 0. 1%.
Stylos de paiement critiques : 99. 95%; catalogues/recherche : 99. 5%.
Latence : p95 ≤ 300ms par '/v1/payments ', p99 ≤ 800ms.

4) Outil SLI

4. 1 Principes

Logs/tracks → métriques RED (Rate/Errors/Durée) avec des buckets explicites.
Assurez-vous de mettre « tenant », « région », « route _ classe » (sans PII).
Comptez deux métriques : « succès » et « total », et pour latinité, « rapide » et « total ».

4. 2 Exemple de Prometheus (taux par 5m)

promql
Availability (successes/total)
sli:success:rate5m = sum by(region, route)(
rate(http_requests_total{code=~"2..    3.."}[5m])
)
sli:total:rate5m = sum by(region, route)(
rate(http_requests_total[5m])
)
sli:availability:ratio5m = sli:success:rate5m / sli:total:rate5m

Latency (fraction faster than 300 ms)
sli:fast:rate5m = sum by(region, route)(
rate(http_request_duration_seconds_bucket{le="0. 3"}[5m])
)
sli:latency_ok:ratio5m = sli:fast:rate5m / sli:total:rate5m

5) Alert par taux de burn (multi-window, multi-burn)

5. 1 Idée

Nous voyons à quelle vitesse le budget brûle par rapport à l'objectif. Si la vitesse est élevée sur une fenêtre courte et longue - signal.

5. 2 Profils de seuil (pour SLO 99. 9%)

Paging : burn rate ≥ 14. 4 × (10 % du budget en 1 heure et 5 % en 6 heures).
Tiquet : taux de burn ≥ 6 × (2 % pour 6 heures et 1 % pour 24 heures).

5. 3 Exemple de règles (Prometheus, pseudo)

promql
Let's calculate the error_ratio on two windows short = 1 - (sum (rate (http_requests_total{code=~"2..    3.."}[5m])) /
sum(rate(http_requests_total[5m])))
long = 1 - (sum(rate(http_requests_total{code=~"2..    3.."}[1h])) /
sum(rate(http_requests_total[1h])))

For SLO = 99. 9%, error_budget=0. 001. BurnRate = error_ratio / 0. 001 burn_short = short / 0. 001 burn_long = long / 0. 001

Paging: Both windows exceed 14. 4× alert: SLOErrorBudgetBurnRateHigh expr: burn_short > 14. 4 and burn_long > 14. 4 for: 5m labels: { severity="page" }
annotations:
summary: "SLO burn rate high (short & long windows)"
runbook: "slo/runbooks/payments. md"

De même pour 6h/24h pour un tiquet.

6) Bureau du budget : processus

6. 1 Gates de sortie

Si le solde du budget est <25 % et que la tendance est négative - « code-gel » sur les fiches, priorité SRE/durabilité.
Les versions canaries doivent avoir une section SLO distincte ('deployment. environment="canary"`).

6. 2 Priorité au béclog

Répartissez la capacité de l'équipe en proportion de la vitesse de combustion et de l'impact sur les recettes.
Justifiez la dette technique avec des métriques : « fix X réduira le taux de burn de Y % ».

6. 3 Post-incident

Chaque incident est RCA et « fix qui ne peut pas être annulé » (actif), le contrôle « est-il retourné à SLO ».

7) SLO comme code

7. 1 Exemple de manifeste SLO (YAML)

yaml service: payments-api owner: team-payments slis:
- name: availability type: request_based success_query: sum(rate(http_requests_total{svc="pay",code=~"2..    3.."}[5m]))
total_query:  sum(rate(http_requests_total{svc="pay"}[5m]))
objective: 99. 95 window: 30d segments: ["region", "tenant", "route"]
- name: latency_p95_300ms type: latency_threshold good_query: sum(rate(http_request_duration_seconds_bucket{svc="pay",le="0. 3"}[5m]))
total_query: sum(rate(http_request_duration_seconds_count{svc="pay"}[5m]))
objective: 99. 0 window: 30d alerts:
- name: burn_high_page windows: ["5m", "1h"]
threshold_burn: 14. 4 severity: page

7. 2 Génération de règles

Utilisez les générateurs (slo-generator, pyrra, sloth) pour créer automatiquement des règles, des dashboards et des rapports.

8) Dégradation et protection des SLO

Load shedder : donnez des réponses rapides sans dépendances « chères » au pic.
Cache & stale: `stale-while-revalidate` для read.
Limites de taux/de concurrence : protège les backends ; les itinéraires importants sont une priorité.
Circuit/Timeout : Les temporisations rapides et les branches « fallback ».
Feature flags : éteignez les fiches lourdes avec un bouton.

9) Observabilité pour SLO

Dashboards : SLO actual vs target, solde du budget, taux de croissance, contribution par itinéraire/fournisseurs.
Corrélation : à partir du « trou » SLO → dans examplar → trace spécifique → logi/profiles.
Rapports : hebdomadaires - tendances, consommation budgétaire, principales causes de dégradation.

10) Anti-modèles

Un SLO « global » pour tout le → masque les problèmes. Segmentez.
«99. 99 % pour tout" sans tenir compte du coût et de la réalité. Choisissez des cibles à partir de l'expérience utilisateur.
Alert par CPU/heap au lieu de burn rate/SLO.
Ignorer les 4xx/longs radis qui gâchent l'UX.
La fenêtre opaque (rolling vs calendrier) est une comparaison entre « pommes et oranges ».

11) Spécificités d'iGaming/Finance

Chemins d'argent (dépôts/conclusions) : Les SLO individuels sont au-dessus du niveau général (par exemple, 99. 95 % de disponibilité ; p95 ≤ 250 ms).
Fournisseurs PSP/KYC : SLO pour chaque fournisseur + alertes sur leur contribution au burn ; commutation automatique des itinéraires (routage intelligent).
Juridictions/tenants : SLO et budgets par 'région/jurisdiction/marque' afin que le problème local ne « inonde » pas la métrique globale.
Jeu responsable : SLO pour la durée d'application des limites/auto-exclusion (formule de conformité).
Vérification/réglementation : conservez les rapports des OSL et des incidents ; transparence pour les audits internes.

12) Chèque-liste prod-prêt

• Les SLI (availability/latency/quality/freshness) et les segments (route/tenant/region) ont été définis.
• Les objectifs (SLO) sont réalistes, cohérents avec les entreprises ; il y a des fenêtres rolling 30/90 jours.
• Alert par burn rate avec multi-fenêtres (paging/ticket).
• SLO en tant que code (générateur de règles/dashboards) ; rapports budgétaires.
• Les gates de sortie sont attachés au reste du budget ; les tranches canaries.
• Les mécanismes de dégradation (shedder, cache stale, circuit, limites) ont été mis en œuvre et testés.
• Corrélation des métriques de ↔ des tracés, runbooks clairs.
• Voies financières/juridictionnelles - SLO/alerts distincts ; Les PSP/KYC sont dégroupés.
• Rétro régulier sur les incidents et investissement dans la fiabilité basée sur le burn.

13) TL; DR

Définissez SLI en fonction de la valeur de l'utilisateur, définissez des SLO réalistes et gérez via Error Budget et burn rate avec des fenêtres multiples. Incluez le code SLO, les gates de sortie et la dégradation planifiée. Segmentez par itinéraires/tenants/régions ; pour les voies d'argent, garder des cibles plus dures et des alertes séparées.