Incident Management et Chaos Engineering

Pourquoi les incidents sont inévitables — et pourquoi c’est normal

En production, la question n’est jamais si un incident va arriver, mais quand. Un déploiement qui casse un connection pool, un certificat TLS oublié, un nœud Kubernetes qui disparaît à 3h du matin — chaque équipe DevOps a vécu ce genre de scénario. La différence entre une équipe mature et une équipe qui improvise ne se joue pas sur la prévention absolue des pannes. Elle se joue sur la capacité à détecter, réagir, corriger et apprendre.

L’Incident Management structuré, les postmortems blameless et le Chaos Engineering forment un triptyque essentiel du SRE. Ensemble, ils transforment chaque incident en opportunité d’amélioration et chaque hypothèse de résilience en preuve vérifiable. Ce cours te donne les méthodes, les outils et les templates concrets pour mettre tout ça en place.

🔥 Cas réel : En 2017, GitLab a perdu 300 Go de données de production suite à une erreur humaine lors d’une maintenance de base de données. Leur postmortem, publié publiquement avec une transparence totale, est devenu une référence du blameless postmortem. Résultat : des dizaines d’améliorations systémiques et une confiance renforcée de la communauté.

Incident Management : un processus, pas une improvisation

Un incident non structuré, c’est 5 personnes dans un call qui parlent en même temps, personne ne sait qui fait quoi, et le fix arrive par chance plutôt que par méthode. Un incident structuré suit un flow clair avec des rôles définis.

Le processus se décompose en quatre phases : Detection (une alerte Prometheus, un rapport utilisateur), Triage (quelle sévérité ? quel impact ? qui est affecté ?), Response (coordination, debug, mitigation) et Resolution (fix définitif déployé et vérifié).

Chaque incident est classé par sévérité, ce qui détermine la vitesse de réponse et le niveau de mobilisation :

## Niveaux de sévérité

SEV1 — CRITICAL
  Impact : Service complètement down pour tous les utilisateurs
  Response : Immédiate, 24/7, IC + toute l'équipe mobilisée
  Communication : Update aux stakeholders toutes les 15 min
  Exemple : Base de données production corrompue, perte de données

SEV2 — MAJOR
  Impact : Service dégradé, un subset d'utilisateurs affecté
  Response : < 30 min, heures de bureau (extensible si dégradation)
  Communication : Update toutes les 30 min
  Exemple : Latence ×10, 20% de requêtes en erreur

SEV3 — MINOR
  Impact : Fonctionnalité secondaire indisponible
  Response : Prochaines heures de bureau
  Communication : Ticket créé, pas de mobilisation urgente
  Exemple : Dashboard interne HS, export CSV cassé

💡 Tip DevOps : La classification de sévérité doit être définie avant le premier incident, pas pendant. Documente-la dans un runbook accessible à toute l’équipe et revois-la chaque trimestre.

Pendant un incident, trois rôles clés structurent la réponse. L’Incident Commander (IC) coordonne, prend les décisions et délègue — il ne debug jamais lui-même. L’Operations Lead investigue, propose des solutions et exécute les changements. Le Communications Lead rédige les status updates, informe les stakeholders et maintient la status page. Cette séparation évite le chaos où tout le monde debug la même chose pendant que personne ne communique.

⚠️ Attention : L’erreur la plus fréquente est que l’IC se met à debugger. Dès qu’il plonge dans les logs, plus personne ne coordonne. Un IC qui debug, c’est un avion sans pilote.

Postmortem blameless : apprendre sans punir

Un postmortem blameless repose sur un principe fondamental : les personnes ont fait de leur mieux avec les informations dont elles disposaient à ce moment-là. On ne cherche pas un coupable, on cherche les failles systémiques qui ont rendu l’erreur possible.

La différence est radicale. Au lieu de “Jean a cassé la prod”, on écrit “Le système permettait de déployer sans tests d’intégration”. Au lieu de “Tu aurais dû vérifier”, on écrit “Le processus de vérification n’était pas documenté”. Ce changement de perspective transforme la culture d’équipe : les gens partagent leurs erreurs au lieu de les cacher, et le système s’améliore réellement.

Voici un template de postmortem éprouvé que tu peux adopter directement :

# Postmortem — [Titre de l'incident]

**Date:** 2026-03-20
**Auteur:** [Nom]
**Sévérité:** SEV2
**Durée:** 45 minutes (14:22 — 15:07 UTC)
**Impact:** 15% des requêtes en erreur 503 sur l'API orders

## Résumé
Déploiement de la v2.3.1 du service orders avec une régression
dans la gestion du connection pool PostgreSQL.
Le pool s'épuisait en ~10 min sous charge normale.

## Timeline
| Heure (UTC) | Événement |
|-------------|-----------|
| 14:15 | Déploiement v2.3.1 via ArgoCD |
| 14:22 | Alerte: error_rate > 5% (PagerDuty) |
| 14:24 | IC assigné: Alice |
| 14:35 | Corrélation avec le déploiement |
| 14:38 | Décision: rollback vers v2.3.0 |
| 14:48 | Pods healthy, error rate en baisse |
| 15:07 | Incident résolu, monitoring stable |

## Root Cause
Mise à jour de la lib pgx (v4 → v5). Pool par défaut passé
de 25 à 4 connections. Config non explicite dans notre code.

## Action Items
| Action | Owner | Priorité | Status |
|--------|-------|----------|--------|
| Config pool explicite | Bob | P0 | Done |
| Tests de charge en CI | Alice | P1 | Todo |
| Canary deploys | Team | P1 | Todo |
| Alerte pool exhaustion | Bob | P0 | Done |

🧠 À retenir : Un postmortem sans action items suivis est une perte de temps. Chaque action item doit avoir un owner, une priorité et une deadline. Revois-les en weekly jusqu’à complétion.

Chaos Engineering : prouver la résilience, pas la supposer

Le Chaos Engineering consiste à injecter des pannes volontairement dans un système pour vérifier qu’il les gère correctement. L’idée, popularisée par Netflix avec Chaos Monkey, est simple : si tu ne testes pas tes failure modes, tu les découvriras en production à 3h du matin.

La méthode suit quatre étapes. D’abord, tu formules une hypothèse : “Si le service auth tombe, les pages publiques restent accessibles”. Ensuite, tu définis le steady state — les métriques normales (error rate < 1%, latence p99 < 300ms). Puis tu injectes la panne de manière contrôlée. Enfin, tu observes : le système a-t-il tenu l’hypothèse, ou as-tu découvert une faiblesse ?

Les outils principaux dans l’écosystème Kubernetes sont Litmus Chaos (CNCF, CRDs natifs), Chaos Mesh (focus réseau et I/O) et Gremlin (SaaS commercial multi-plateforme). Voici un exemple concret avec Litmus qui supprime 50% des pods d’un service pendant 60 secondes tout en vérifiant que le healthcheck reste vert :

# pod-delete-experiment.yaml
apiVersion: litmuschaos.io/v1alpha1
kind: ChaosEngine
metadata:
  name: order-service-chaos
  namespace: production
spec:
  appinfo:
    appns: production
    applabel: "app=order-service"
    appkind: deployment
  engineState: active
  chaosServiceAccount: litmus-admin
  experiments:
    - name: pod-delete
      spec:
        components:
          env:
            - name: TOTAL_CHAOS_DURATION
              value: "60"
            - name: CHAOS_INTERVAL
              value: "10"
            - name: FORCE
              value: "false"
            - name: PODS_AFFECTED_PERC
              value: "50"
        probe:
          - name: "check-availability"
            type: httpProbe
            httpProbe/inputs:
              url: "http://order-service.production/healthz"
              method:
                get:
                  criteria: ==
                  responseCode: "200"
            mode: Continuous
            runProperties:
              probeTimeout: 5
              interval: 5
              retry: 2

Pour tester la résilience réseau, tu peux injecter de la latence entre un service et sa base de données. Cet exemple ajoute 500ms de latence sur l’interface réseau vers l’IP de la DB :

# network-latency-experiment.yaml
apiVersion: litmuschaos.io/v1alpha1
kind: ChaosEngine
metadata:
  name: network-delay-chaos
spec:
  appinfo:
    appns: production
    applabel: "app=order-service"
    appkind: deployment
  experiments:
    - name: pod-network-latency
      spec:
        components:
          env:
            - name: NETWORK_INTERFACE
              value: "eth0"
            - name: NETWORK_LATENCY
              value: "500"
            - name: TOTAL_CHAOS_DURATION
              value: "120"
            - name: DESTINATION_IPS
              value: "10.0.0.50"

🔥 Cas réel : Amazon organise des Game Days internes où des équipes entières injectent des pannes sur leurs services en production. Un de ces Game Days a révélé qu’un service critique n’avait pas de circuit breaker vers une dépendance — un single point of failure invisible dans l’architecture. Corrigé avant qu’un incident réel ne le révèle.

Game Days : la pratique en équipe

Les Game Days sont des sessions planifiées de Chaos Engineering en équipe. Avant le Game Day : choisis 3 à 5 scénarios maximum, préviens les stakeholders, prépare les rollbacks, vérifie que le monitoring fonctionne et assure-toi de ne pas être en période critique (Black Friday, fin de trimestre).

Pendant le Game Day : un facilitateur coordonne, un scribe note la timeline en temps réel, les scénarios s’exécutent un par un, et on observe sans intervenir immédiatement — sauf si l’impact utilisateur dépasse ce qui était prévu.

# Script de Game Day — vérification pré-chaos
#!/bin/bash
echo "=== Pre-Chaos Checklist ==="

# Vérifier que le monitoring fonctionne
echo "Checking Prometheus..."
curl -s http://prometheus:9090/-/healthy | grep -q "OK" && echo "✅ Prometheus OK" || echo "❌ Prometheus DOWN"

# Vérifier les replicas actuels
echo "Current replicas:"
kubectl get deploy -n production -o custom-columns=NAME:.metadata.name,REPLICAS:.spec.replicas,READY:.status.readyReplicas

# Snapshot des métriques avant chaos
echo "Baseline error rate:"
curl -s "http://prometheus:9090/api/v1/query?query=rate(http_requests_total{code=~'5..'}[5m])"

echo "=== Ready to inject chaos ==="

💡 Tip DevOps : Commence toujours le Chaos Engineering en staging avec des expériences simples (kill un pod). Ne passe en production qu’une fois que tu as un circuit breaker, du monitoring solide et un kill switch pour arrêter l’expérience instantanément.

On-Call : des astreintes qui ne brûlent pas l’équipe

L’on-call mal géré est la première cause de burnout en SRE. Voici les règles qui fonctionnent. Pour la structure : rotation hebdomadaire minimum, toujours un primary et un secondary, maximum 25% du temps d’une personne en astreinte, et une compensation réelle (temps libre ou rémunération).

Pour les alertes : chaque alerte qui page doit être actionnable. Si tu reçois une alerte et qu’il n’y a rien à faire, cette alerte doit être supprimée ou corrigée. La cible est moins de 2 pages par shift de 12h. Chaque page non-actionnable est de la dette technique.

Pour le support : chaque alerte doit avoir un runbook associé qui explique quoi vérifier, quoi faire et quand escalader. Un on-call sans runbook, c’est envoyer quelqu’un au front sans carte ni boussole.

# Exemple de runbook structuré pour PagerDuty/Opsgenie
alert: HighErrorRate
description: "Error rate > 5% sur le service orders"
severity: SEV2
runbook:
  diagnosis:
    - "Vérifier le dashboard Grafana: /d/orders-overview"
    - "kubectl logs -n production -l app=order-service --tail=100"
    - "Vérifier la connectivité DB: kubectl exec -it <pod> -- pg_isready"
  decision_tree:
    network: "Si timeout vers la DB → vérifier les Network Policies et le DNS"
    application: "Si panic/OOM → vérifier les limits et les derniers déploiements"
    database: "Si connection refused → vérifier le PG cluster et le pool"
  remediation:
    rollback: "argocd app rollback orders --to <revision>"
    restart: "kubectl rollout restart deploy/order-service -n production"
    scale: "kubectl scale deploy/order-service --replicas=5 -n production"
  escalation:
    - condition: "Impact > 30% des requêtes ou durée > 30 min"
      action: "Escalader à SEV1, appeler le secondary on-call"

⚠️ Attention : Un SLO sans error budget policy est inutile — c’est la policy qui drive les décisions. Et ne fixe pas des SLOs trop ambitieux : 99.999% coûte 100× plus que 99.9% et laisse 5 secondes de downtime par an. Sois réaliste.

Résumé — Les fondamentaux à retenir

🧠 À retenir :

• L’Incident Management structuré transforme le chaos en processus reproductible — rôles clairs (IC, Ops Lead, Comm Lead), sévérités définies à l’avance, communication régulière
• Le postmortem blameless est le moteur d’amélioration continue — pas de coupable, des failles systémiques, des action items trackés jusqu’à complétion
• Le Chaos Engineering prouve ta résilience au lieu de la supposer — hypothèse, steady state, injection, observation
• Les Game Days transforment la théorie en pratique collective — des pannes simulées en équipe, dans un cadre contrôlé
• L’on-call sain repose sur des alertes actionnables, des runbooks à jour et une rotation équitable — sinon c’est du burnout garanti
• La boucle vertueuse : Chaos Engineering révèle des faiblesses → les incidents sont mieux gérés → les postmortems produisent des améliorations → le système devient plus résilient