Chaos Engineering Guide

Chaos Engineering Guide

Workflow

1. Définir l'état stable (baseline)

Avant toute expérience, établir les métriques qui définissent le "normal" :

Documenter la baseline avec des captures Grafana datées avant l'expérience.

2. Formuler une hypothèse testable

Format : "Si [condition de chaos], alors [comportement attendu] en [délai max], sans [impact inacceptable]."

Exemples :

• "Si un pod API tombe, Kubernetes le remplace en < 30 s sans erreur 5xx côté client."
• "Si la base de données principale devient indisponible, le failover vers le réplica se fait en < 60 s."
• "Si la latence réseau dépasse 500 ms sur le service de paiement, le circuit breaker s'ouvre et renvoie une réponse dégradée (cache)."

3. Choisir l'outil adapté

Critère de choix : Kubernetes → Litmus ; AWS managed → FIS ; test réseau isolé → Toxiproxy ; budget SaaS → Gremlin.

4. Concevoir l'expérience

Composants d'une expérience :

• Cible : pod, nœud, service, dépendance externe
• Type de fault : kill, latency, CPU stress, network loss, disk fill
• Durée : commencer à 30–60 s, jamais > 10 min en première itération
• Blast radius : 1 instance → 25 % des instances → 50 % (montée progressive)
• Kill switch : rollback identifié et testé avant l'expérience

Exemple Litmus (pod kill) :

apiVersion: litmuschaos.io/v1alpha1
kind: ChaosEngine
metadata:
  name: pod-kill-test
  namespace: default
spec:
  appinfo:
    appns: production
    applabel: "app=payment-service"
    appkind: deployment
  chaosServiceAccount: litmus-admin
  experiments:
    - name: pod-delete
      spec:
        components:
          env:
            - name: TOTAL_CHAOS_DURATION
              value: "30"
            - name: CHAOS_INTERVAL
              value: "10"
            - name: FORCE
              value: "false"

Exemple Toxiproxy (latence réseau) :

# Créer un proxy vers la DB
toxiproxy-cli create --listen 0.0.0.0:5433 --upstream db:5432 db-proxy

# Ajouter 300 ms de latence
toxiproxy-cli toxic add db-proxy -t latency -a latency=300 -a jitter=50

# Supprimer après le test
toxiproxy-cli toxic remove db-proxy -n latency_downstream

Exemple Istio (fault injection HTTP) :

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: payment-fault
spec:
  hosts:
    - payment-service
  http:
    - fault:
        delay:
          percentage:
            value: 20
          fixedDelay: 2s
      route:
        - destination:
            host: payment-service

5. Exécuter en environnement contrôlé

Ordre d'exécution :

1. Staging d'abord — valider que l'expérience est reproductible
2. Production hors heures de pointe — avec monitoring actif
3. Jamais pendant une release ou un incident actif

Checklist pré-lancement :

• Monitoring ouvert (Grafana, Datadog)
• Kill switch testé (kubectl delete chaosengine pod-kill-test -n default)
• On-call alerté et disponible
• Périmètre communiqué à l'équipe Slack/Teams

6. Organiser des Game Days

Structure d'un game day efficace (3 h) :

Rôles : Chaos Master (pilote les injections), Observer (note les métriques), On-call (répond comme en production).

7. Analyser les résultats

Comparer hypothèse vs réalité :

Hypothèse : failover DB < 60 s
Observé    : 142 s + 23 erreurs 500 pendant la transition
Delta      : FAIL — circuit breaker non configuré sur le service Orders
Action     : Ajouter Resilience4j circuit breaker + retry avec backoff exponentiel
Owner      : @sre-team | Sprint N+1

Métriques à capturer impérativement :

• MTTR (Mean Time To Recovery)
• MTTD (Mean Time To Detect) — si > 5 min, réviser les alertes
• Nombre d'erreurs utilisateur pendant la panne
• Comportement du circuit breaker / retry

8. Automatiser dans le pipeline CI/CD

Intégrer les expériences validées en CI (ex. GitHub Actions) :

jobs:
  chaos-tests:
    runs-on: ubuntu-latest
    needs: deploy-staging
    steps:
      - name: Run Litmus chaos experiment
        run: |
          kubectl apply -f chaos/pod-kill-test.yaml
          sleep 60
          kubectl get chaosresult pod-kill-test-pod-delete \
            -o jsonpath='{.status.experimentStatus.verdict}'
      - name: Assert SLO not breached
        run: |
          ERROR_RATE=$(curl -s "http://prometheus/api/v1/query" \
            --data 'query=rate(http_requests_total{status=~"5.."}[1m])' \
            | jq '.data.result[0].value[1]')
          [ $(echo "$ERROR_RATE < 0.01" | bc) -eq 1 ]

Garde-fous et anti-patterns

Ne jamais faire

• Lancer sans kill switch testé — le rollback doit prendre < 30 s.
• Cibler 100 % des instances pour la première expérience — blast radius 1 instance max.
• Chaos en production pendant une release — risque de confusion cause/effet.
• Injecter sans baseline documentée — impossible de savoir si le système a régressé.
• Utiliser le chaos comme punition ou exercice surprise — blameless culture obligatoire.

Pièges courants

• Circuit breaker mal calibré : timeout trop long → cascade d'erreurs avant ouverture.
• Healthcheck trop optimiste : le pod répond 200 mais la DB interne est KO.
• Retry sans backoff : amplifie la charge sur un service déjà dégradé (retry storm).
• Monitoring manquant sur les dépendances externes : la panne est invisible jusqu'au SLA.
• Expérience non reproductible : toujours versionner les manifestes de chaos dans Git.

Bonnes pratiques 2026

• Adopter eBPF (Tetragon, Cilium) pour observer l'impact réseau sans modifier le code.
• Intégrer les résultats de chaos dans le DORA scorecard de l'équipe (MTTR notamment).
• Utiliser OpenTelemetry pour corréler les traces pendant l'expérience.
• Maintenir un catalogue d'expériences (YAML versionnés) avec résultats historiques.
• Préférer les Steady-State Hypotheses du standard Chaos Toolkit pour la portabilité entre outils.