SLO, SLA, SLI : definir des objectifs de service qui ont du sens

Beaucoup d’equipes operent sans objectifs de fiabilite clairs. Sans reponse aux questions de base, la gestion des incidents est reactive et emotionnelle.

Les definitions

SLI : la metrique mesuree. “Taux de requetes avec code HTTP < 500 sur les 5 dernieres minutes.”

SLO : l’objectif interne. “Le SLI de disponibilite doit etre >= 99.9% sur 30 jours glissants.”

SLA : l’engagement contractuel avec les clients. “Disponibilite garantie a 99.5%.”

Definir de bons SLIs

# SLI de disponibilite
sum(rate(http_requests_total{status!~"5.."}[5m]))
/
sum(rate(http_requests_total[5m]))

# SLI de latence (requetes sous 300ms)
sum(rate(http_request_duration_seconds_bucket{le="0.3"}[5m]))
/
sum(rate(http_request_duration_seconds_count[5m]))

Le budget d’erreur

SLO : 99.9% de disponibilite sur 30 jours
Budget d'erreur : 0.1% x 30 jours x 24h x 60min = 43.2 minutes/mois

Le budget d’erreur transforme le SLO en decision : si vous avez consomme 80% de votre budget en 15 jours, vous ralentissez les deploiements.

Alerte sur burn rate

alert: ErrorBudgetBurnRateHigh
expr: |
  (1 - sum(rate(http_requests_total{status!~"5.."}[1h]))
       / sum(rate(http_requests_total[1h])))
  / (1 - 0.999) > 14.4
for: 5m
annotations:
  summary: "Budget d'erreur epuise en 2 jours si ce taux continue"

Notre formation Observabilite couvre la mise en place de SLOs complets.