SLIs, SLOs et SLAs

---

1 - Vue d'ensemble

Terme	Définition	Exemple
SLI	Métrique qui mesure le service	Latence P99
SLO	Objectif cible pour le SLI	P99 < 200ms
SLA	Contrat avec conséquences	99.9% avec pénalités

---

2 - Service Level Indicators (SLIs)

2.1 Caractéristiques d'un bon SLI

good_sli:
  - Mesurable quantitativement
  - Reflète l'expérience utilisateur
  - Comparable dans le temps
  - Simple à comprendre
  - Actionnable

2.2 Types de SLIs

Catégorie	SLI	Formule
Availability	Uptime	Successful requests / Total requests
Latency	Response time	Requests < threshold / Total requests
Throughput	Requests/sec	Successful requests / Time period
Error Rate	Errors	Failed requests / Total requests
Quality	Correctness	Correct responses / Total responses

2.3 SLI Specification

# sli-specification.yaml
slis:
  - name: availability
    description: "Proportion of successful HTTP requests"
    specification:
      type: ratio
      good_events: "HTTP 2xx responses"
      total_events: "All HTTP responses excluding 4xx"
    measurement:
      source: prometheus
      query: |
        sum(rate(http_requests_total{status=~"2.."}[5m]))
        /
        sum(rate(http_requests_total{status!~"4.."}[5m]))

  - name: latency
    description: "Proportion of requests served within 200ms"
    specification:
      type: ratio
      good_events: "Requests with latency < 200ms"
      total_events: "All requests"
    measurement:
      source: prometheus
      query: |
        sum(rate(http_request_duration_seconds_bucket{le="0.2"}[5m]))
        /
        sum(rate(http_request_duration_seconds_count[5m]))

2.4 Request-based vs Window-based

request_based:
  # Chaque requête compte individuellement
  formula: "Good requests / Total requests"
  example: "99.9% des requêtes réussies"
  
window_based:
  # Périodes de temps
  formula: "Good time windows / Total time windows"
  example: "99.9% des minutes avec < 1% erreurs"

---

3 - Service Level Objectives (SLOs)

3.1 Définir un SLO

slo_definition:
  service: api-gateway
  sli: availability
  objective: 99.9%
  window: 30 days (rolling)
  
  # Ce que ça signifie
  allowed_downtime:
    per_day: 1.44 minutes
    per_week: 10.08 minutes
    per_month: 43.8 minutes
    per_year: 8.76 hours

3.2 Niveaux de fiabilité

SLO	Downtime/an	Usage
99%	3.65 jours	Internal tools
99.9%	8.76 heures	Standard services
99.95%	4.38 heures	Business critical
99.99%	52.6 minutes	Mission critical
99.999%	5.26 minutes	Life critical

3.3 Multi-SLO Strategy

# Plusieurs SLOs pour un service
service: payment-api
slos:
  - name: availability
    objective: 99.95%
    window: 30d
    priority: P1
    
  - name: latency-p50
    objective: 95%  # 95% des requêtes < 100ms
    threshold: 100ms
    window: 30d
    priority: P2
    
  - name: latency-p99
    objective: 99%  # 99% des requêtes < 500ms
    threshold: 500ms
    window: 30d
    priority: P1

3.4 SLO Document

# slo-document.yaml
service: checkout-service
team: platform
owner: sre-[email protected]

description: |
  Service de checkout pour les commandes clients.
  Critique pour le business.

slos:
  availability:
    sli: "Ratio of successful checkouts"
    objective: 99.9%
    window: 30 days rolling
    rationale: "Below this, revenue impact is significant"
    
  latency:
    sli: "P99 checkout completion time"
    objective: 99% < 3s
    window: 30 days rolling
    rationale: "User experience degrades above 3s"

error_budget_policy:
  document: link-to-policy
  
escalation:
  - severity: warning
    threshold: 50% budget consumed
    action: "Notify team"
  - severity: critical
    threshold: 75% budget consumed
    action: "Freeze non-critical changes"
  - severity: emergency
    threshold: 100% budget consumed
    action: "All hands on deck"

---

4 - Service Level Agreements (SLAs)

4.1 SLA vs SLO

Règle : SLO doit être plus strict que SLA (buffer de sécurité).

4.2 Composants d'un SLA

sla_components:
  service_description:
    - What is covered
    - What is excluded
    
  availability_commitment:
    target: 99.9%
    measurement_period: Monthly
    
  performance_targets:
    - Response time commitments
    - Throughput guarantees
    
  remedies:
    - Service credits
    - Refunds
    - Termination rights
    
  exclusions:
    - Scheduled maintenance
    - Customer-caused issues
    - Force majeure

4.3 Exemple de calcul de crédit

Availability	Credit
99.9% - 99.0%	10%
99.0% - 95.0%	25%
< 95.0%	50%

---

5 - Implémentation Prometheus

5.1 Recording Rules

# recording-rules.yaml
groups:
  - name: slo_rules
    interval: 30s
    rules:
      # Availability SLI
      - record: sli:availability:ratio
        expr: |
          sum(rate(http_requests_total{status=~"2.."}[5m]))
          /
          sum(rate(http_requests_total{status!~"4.."}[5m]))

      # Latency SLI
      - record: sli:latency:ratio
        expr: |
          sum(rate(http_request_duration_seconds_bucket{le="0.2"}[5m]))
          /
          sum(rate(http_request_duration_seconds_count[5m]))

      # Error budget remaining (30 day window)
      - record: slo:error_budget:remaining
        expr: |
          1 - (
            (1 - sli:availability:ratio)
            /
            (1 - 0.999)  # SLO target
          )

5.2 Alerting Rules

groups:
  - name: slo_alerts
    rules:
      - alert: SLOBudgetBurnRateHigh
        expr: |
          (
            sli:availability:ratio < 0.999  # SLO
            and
            slo:error_budget:remaining < 0.5  # 50% remaining
          )
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "Error budget consumption rate is high"
          
      - alert: SLOBreached
        expr: slo:error_budget:remaining < 0
        for: 1m
        labels:
          severity: critical
        annotations:
          summary: "SLO has been breached"

---

6 - Dashboard SLO

6.1 Métriques essentielles

dashboard_panels:
  - title: "Current SLI"
    type: gauge
    query: sli:availability:ratio
    thresholds: [0.99, 0.999, 0.9999]
    
  - title: "Error Budget Remaining"
    type: stat
    query: slo:error_budget:remaining * 100
    unit: percent
    
  - title: "Error Budget Burn Rate"
    type: timeseries
    query: deriv(slo:error_budget:remaining[1h])
    
  - title: "Time Until Budget Exhaustion"
    type: stat
    query: |
      slo:error_budget:remaining 
      / 
      deriv(slo:error_budget:remaining[1h])

6.2 Burn Rate Windows

# Multi-window burn rate alerting
burn_rates:
  - window: 1h
    burn_rate: 14.4  # Exhaust budget in ~2 days
    severity: page
    
  - window: 6h
    burn_rate: 6  # Exhaust budget in ~5 days
    severity: page
    
  - window: 3d
    burn_rate: 1  # On track to exhaust budget
    severity: ticket

---

Résumé

Dans ce chapitre, nous avons appris :

• Les SLIs : métriques qui comptent
• Les SLOs : objectifs internes
• Les SLAs : engagements clients
• L'implémentation avec Prometheus
• Les dashboards SLO
• Les burn rates pour l'alerting

---

Prochaine étape

Dans le prochain chapitre, nous verrons Error Budget.

→ Chapitre suivant : Error Budget

---

← Retour à la table des matières