Chaos Engineering

Injecter délibérément des défaillances dans un système EDI pour vérifier qu'il résiste. La discipline qui transforme la résilience d'un espoir en propriété mesurée — pratique née chez Netflix avec Chaos Monkey.

Problème

Un hub EDI moderne intègre des dizaines de patterns de résilience : circuit breaker, retry, bulkhead, dead letter channel, idempotency. Mais la résilience d'un système distribué n'est pas la somme des résiliences de ses composants — elle émerge des interactions, et ces émergences sont souvent surprenantes en panne réelle. La résilience « sur le papier » est différente de la résilience « en production » — c'est le célèbre Bruit, et la fureur de toute production distribuée. La seule façon d'avoir confiance, c'est de tester.

Forces

• Les pannes sont inéluctables : réseau, partenaire, AS2 down, certificate expiré, queue saturée — tout arrivera tôt ou tard.
• Tester en non-prod n'est pas suffisant : la charge, la topologie, les dépendances diffèrent en prod.
• Le coût d'une découverte en incident réel est élevé : MTTR, pénalités SLA, atteinte à la réputation.
• L'expérimentation doit être contrôlée : périmètre limité, rollback automatique, plan blast radius.
• L'apprentissage est l'objectif principal : chaque expérimentation produit des post-mortems et améliore le système.

Solution

Formaliser des chaos experiments : hypothèse vérifiable, population délimitée, perturbation injectée, mesure du steady state, conclusion. Le cycle suit les Principles of Chaos Engineering publiés par l'équipe Netflix : (1) définir un état stable mesurable, (2) hypothétiser que cet état persiste en présence d'une perturbation, (3) varier des événements réels (kill instance, latency injection, network partition), (4) confirmer ou infirmer l'hypothèse en production contrôlée. Les outils : Chaos Monkey, Chaos Kong, Gremlin, AWS Fault Injection Simulator, Chaos Mesh (Kubernetes), Litmus (Kubernetes).

Cycle d'expérimentation chaos :

   1. Hypothèse : "Si le partenaire AS2 ne répond pas pendant 60s,
                   les retries respectent backoff exponentiel et
                   aucun message n'est perdu."
              │
              ▼
   2. Population : 1 partenaire pilote (non critique)
              │
              ▼
   3. Variable : kill TCP entre hub et partenaire pendant 60s
              │
              ▼
   4. Mesure (steady state) :
      • Latence p95 (avant, pendant, après)
      • Taux de messages perdus
      • Comportement du circuit breaker
      • Retries effectués
              │
              ▼
   5. Validation :
      • Si hypothèse vérifiée → on relâche en élargissant le périmètre
      • Sinon → bug détecté, fix + nouveau test

Implémentation EDI

Cas concret : valider la résilience du flux AS2 entrant Walmart. Hypothèse : « si le pipeline de validation interne tombe en panne, les messages sont mis en file de retry, puis acheminés une fois le pipeline rétabli, sans perte ni duplication ». Expérimentation contrôlée : tous les vendredis 14h-15h en pre-prod, le validator est tué via Chaos Mesh pendant 5 min. Mesure : taux de messages reçus / acquittés / routés vers ERP. Résultat attendu : 100% reçus, 0% perdus, routage repris après réplique sur Kubernetes. En production réelle : programmes hebdomadaires sur le périmètre étendu progressivement : certificat expiré simulé, partenaire AS2 qui timeout, Kafka broker tué, retry storms. Chaque expérimentation documente un game day, un post-mortem, des amendements au système. L'approche moderne Continuous Verification intègre ces tests à la CI/CD. Outils EDI courants : Chaos Mesh sur Kubernetes, Toxiproxy pour latency injection sur sockets AS2.

Anti-patterns

• Chaos sans hypothèse : « on casse pour voir » = vandalisme contrôlé, pas expérimentation.
• Pas de blast radius limité : première expérimentation à pleine échelle = incident garanti.
• Pas de mesure steady state : sans baseline, impossible de dire si l'expérience a validé ou non.
• Pas de rollback automatique : si l'expérience dérape, il faut un kill switch instantané.
• Chaos en prod pour un système sans résilience de base : commencer par les fondamentaux (circuit breaker, retry, idempotency) avant d'injecter du chaos, sinon tout casse.
• Game days isolés sans suivi : si les apprentissages ne sont pas tracés et corrigés, le bénéfice s'évapore.

Patterns liés

• Circuit Breaker — pattern testé classiquement par chaos.
• Bulkhead — pattern dont l'isolation est validée par chaos.
• Retry with backoff — pattern dont le comportement est validé par chaos.
• Health Check — pattern dont la fiabilité est vérifiée par chaos.
• Canary Release — l'étape qui suit la validation par chaos d'une nouvelle version.

Sources

• Rosenthal C., Hochstein L., Blohowiak A., Jones N., Basiri A. — Chaos Engineering: System Resiliency in Practice, O'Reilly 2017 (2e éd. 2020). L'ouvrage de référence par l'équipe Netflix fondatrice de la discipline.
• Principles of Chaos Engineering : les cinq principes formalisés par l'équipe Netflix qui définissent la discipline. principlesofchaos.org
• Netflix Tech Blog — Chaos Monkey. La publication originale (2010) de l'outil qui a inauguré le mouvement. netflix.github.io — chaosmonkey
• Chaos Mesh (CNCF Sandbox) — Documentation de la plateforme de chaos engineering open-source pour Kubernetes. chaos-mesh.org
• AWS Fault Injection Simulator (FIS). Service managé AWS pour orchestrer des expérimentations chaos. aws.amazon.com — fis
• Nygard M. — Release It! Design and Deploy Production-Ready Software, Pragmatic Bookshelf, 2e éd. 2018. Discussion du stress testing et de la résilience.