Chaos engineering¶

Provoquer les pannes avant qu'elles ne vous trouvent — méthode, game days et modèle de maturité.

Pourquoi provoquer des pannes¶

Le chaos engineering consiste à injecter délibérément des perturbations dans un système pour vérifier qu'il résisté. L'objectif n'est pas de tout casser — c'est de découvrir les faiblesses avant qu'elles se manifestent en production sous forme de panne non planifiee.

Mieux vaut découvrir qu'un circuit breaker est mal configuré lors d'un test maîtrise que lors d'une panne réelle a 3h du matin un jour de forte charge. Le chaos engineering transforme les pannes en événements attendus et planifies plutôt qu'en crises.

La confiance dans un système ne vient pas de l'absence de pannes en production — elle vient de la preuve que le système survit quand on lui en inflige une délibérément.

Les 4 étapes de la méthode¶

1. Définir l'état stable¶

Identifier les métriques qui caracterisent un fonctionnement normal : latence p99, taux d'erreur, throughput, saturation. C'est la "steady state hypothesis". Sans référence établie, impossible de déterminer si le système a résisté ou non à la perturbation.

Critères pour un bon état stable :

• Mesurable en temps réel (pas un rapport hebdomadaire)
• Representatif de l'expérience utilisateur (pas du CPU serveur)
• Stable en conditions normales (faible variance)
• Automatisable (pas de vérification manuelle)

2. Formuler une hypothèse¶

Être précis et mesurable : "Si je tue un pod du service de catalogue, le service reste disponible a 99.9% et la latence p99 reste sous 300ms pendant les 5 minutes suivantes."

L'hypothèse doit être falsifiable. "Le système devrait aller bien" n'est pas une hypothèse — c'est un vœu. "Le taux d'erreur reste sous 0.1% et la latence p99 reste sous 500ms pendant 10 minutes après l'injection" est une hypothèse.

3. Injecter la perturbation¶

Exécuter l'expérience avec un blast radius maîtrise :

• Avoir un plan de rollback immédiat (un bouton, pas une procédure)
• Prévenir l'équipe (pas de surprises)
• Exécuter de préférence en heures ouvrables, avec des personnes disponibles pour intervenir
• Monitorer en temps réel pendant l'injection

4. Observer et comparer¶

Les métriques restent-elles dans l'enveloppe définie ? Si oui, l'hypothèse est validee et la confiance dans le système augmente. Si non, la faiblesse est identifiée, documentee et corrigee avant la prochaine panne réelle.

graph TD
    D["1. Definir l'etat stable\nmetriques de reference"]
    H["2. Formuler l'hypothese\nprecise et falsifiable"]
    I["3. Injecter la perturbation\nblast radius controle"]
    O["4. Observer et comparer\nmetriques vs hypothese"]

    D --> H
    H --> I
    I --> O
    O -->|hypothese validee| Conf["Confiance accrue"]
    O -->|hypothese invalidee| Fix["Corriger la faiblesse"]
    Fix --> D

    style Conf fill:#2a9d8f,color:#fff
    style Fix fill:#e76f51,color:#fff

Catalogue d'expériences¶

Priorité des expériences¶

Commencer par les expériences les plus courantes et les moins risquees :

1. Pod kill — la perturbation la plus fréquente en production (déploiements, scaling, OOM). Si le système ne survit pas a ca, rien d'autre ne sert.
2. Latency injection — révélé les timeouts mal configures et les cascades de lenteur.
3. Dependency failure — valide les fallbacks et circuit breakers.
4. Network partition — teste la résilience aux pannes réseau entre zones.

Blast radius : elargir progressivement¶

Chaque palier doit être valide avant de passer au suivant :

graph LR
    S1["1. Un pod\nen staging"]
    S2["2. Un service\nprod heures creuses"]
    S3["3. Un service\nprod heures de pointe"]
    S4["4. Une zone\nde disponibilite"]

    S1 -->|valide| S2
    S2 -->|valide| S3
    S3 -->|valide| S4

    style S1 fill:#2a9d8f,color:#fff
    style S2 fill:#e9c46a,color:#000
    style S3 fill:#e76f51,color:#fff
    style S4 fill:#c44,color:#fff

Palier 1 — Un pod en staging — valider que l'expérience est sans danger, que les métriques sont lisibles, que le rollback fonctionne. Zero risque utilisateur.

Palier 2 — Un service en production aux heures creuses — confirmer que la résilience observee en staging tient en conditions réelles. Impact minimal.

Palier 3 — Un service en production aux heures de pointe — tester sous charge representative, quand les ressources sont plus sollicitees. Révélé les problèmes de concurrence et de saturation.

Palier 4 — Une zone de disponibilité entière — tester la résilience regionale, le failover inter-zone, les TTL DNS. Réservé aux organisations matures.

Game days¶

Un game day est une session planifiee ou l'équipe pratique le chaos engineering et la réponse aux incidents en conditions controlees. C'est l'équivalent d'un exercice incendie pour les systèmes informatiques.

Structure d'un game day¶

Règles d'un game day réussi¶

Toute l'équipe est présenté. Le game day n'est pas réservé aux SRE. Les développeurs, les product owners et les managers doivent comprendre comment le système se comporte sous stress. La diversite des points de vue révélé des angles morts.

Le rollback est toujours pret. Avant chaque injection, vérifier qu'on peut annuler en moins de 30 secondes. Si le rollback n'est pas teste, le game day n'est pas pret.

On documente tout. Chaque expérience, chaque observation, chaque surprise. Le game day produit un rapport avec les actions a mener, classees par priorité.

On ne blame personne. Le game day révélé des faiblesses du système, pas des fautes individuelles. Un circuit breaker mal configuré n'est pas la faute du développeur qui l'a écrit — c'est une opportunité d'amélioration.

On celebre les découvertes. Trouver un bug pendant un game day est un succès, pas un échec. C'est une panne evitee.

Game day vs chaos engineering automatise¶

Les game days sont le point d'entree. Le chaos automatise est la destination pour les organisations matures.

Modèle de maturité¶

Toutes les organisations ne sont pas pretes pour le chaos engineering en production. Le modèle de maturité permet de situer l'équipe et de progresser par paliers.

Niveau 0 — Absent¶

Pas de chaos engineering. Les pannes sont découvertes en production par les utilisateurs. Pas de health checks fiables, pas d'alertes configurees, pas de runbooks.

Action : mettre en place les health checks (chapitre 04), les SLI/SLO (chapitre 05) et l'observabilité (chapitre 06) avant de commencer le chaos.

Niveau 1 — Manuel en staging¶

Premières expériences de chaos en staging. L'équipe tue des pods manuellement et observe les métriques. Les expériences sont ad hoc et non reproductibles.

Action : structurer les expériences (hypothèse, métriques, blast radius). Documenter les résultats. Planifier le premier game day.

Niveau 2 — Game days en production¶

Game days réguliers (mensuels ou trimestriels) en production, avec l'équipe présenté. Les expériences sont planifiees, documentees et suivies d'actions correctives.

Action : automatiser les expériences les plus courantes. Intégrer les résultats dans les rétrospectives.

Niveau 3 — Automatise et cible¶

Les expériences de chaos sont automatisees et exécutées quotidiennement sur des services spécifiques. Les résultats alimentent des dashboards. L'équipe est alertee uniquement quand une hypothèse est invalidee.

Action : elargir le scope. Tester les scenarios multi-service. Intégrer dans le pipeline CI/CD.

Niveau 4 — Continu et large¶

Le chaos engineering fait partie de la culture. Des expériences non supervisées tournent en continu en production. Le blast radius inclut des zones de disponibilité entières. L'équipe a une confiance élevée dans la résilience du système.

graph LR
    N0["Niveau 0\nAbsent"]
    N1["Niveau 1\nManuel staging"]
    N2["Niveau 2\nGame days prod"]
    N3["Niveau 3\nAutomatise"]
    N4["Niveau 4\nContinu"]

    N0 --> N1
    N1 --> N2
    N2 --> N3
    N3 --> N4

    style N0 fill:#c44,color:#fff
    style N1 fill:#e76f51,color:#fff
    style N2 fill:#e9c46a,color:#000
    style N3 fill:#2a9d8f,color:#fff
    style N4 fill:#264653,color:#fff

Aspects organisationnels¶

Convaincre le management¶

Le chaos engineering est contre-intuitif : on propose de casser des choses en production. Pour convaincre :

• Chiffrer le coût des pannes passees — combien ont coute les 3 dernières pannes non planifiees (heures d'intervention, impact client, revenus perdus) ?
• Commencer petit — un game day en staging ne présente aucun risque. Les résultats parlent d'eux-mêmes.
• Montrer les découvertes — "nous avons decouvert que le circuit breaker du service paiement n'etait pas configuré" est plus convaincant que "nous devrions faire du chaos engineering".

Culture blameless¶

Le chaos engineering ne fonctionne que dans une culture ou les erreurs sont des opportunités d'apprentissage. Si l'équipe a peur de révéler des faiblesses, elle ne pratiquera pas le chaos ou cachera les résultats.

Les principes :

• Documenter les découvertes sans nommer de responsable
• Célébrer les bugs trouves (pannes evitees)
• Partager les résultats largement (transparence)
• Mesurer l'amélioration dans le temps (pas les échecs)

Outils¶

Chaos Monkey (Netflix / Simian Army)¶

Tue des instances aléatoires en production. Principe fondateur du chaos engineering moderne. Conçu pour AWS EC2. Ne pas déployer sans maturité suffisante sur la résilience de base.

La philosophie Netflix : si le système ne survit pas à la perte d'une instance, il n'est pas pret pour la production.

Litmus¶

Framework open source pour Kubernetes. Catalogue riche d'expériences prédéfinies :

• Pod chaos (kill, CPU stress, memory stress)
• Network chaos (partition, latence, perte de paquets)
• I/O chaos (latence disque, erreurs I/O)
• Node chaos (drain, taint, reboot)

S'intégré avec Argo Workflows pour l'automatisation et le scheduling des expériences.

Gremlin¶

Plateforme SaaS avec catalogue d'attaques prédéfinies, contrôles de blast radius fins, reporting et templates de game day. Solution la plus accessible pour débuter sans expertise DevOps avancee.

Chapitre suivant : Securiser — analyse de risques et protection architecturale.