On teste rarement un système distribué là où il fait le plus mal : au moment où une dépendance lâche, où le réseau se fige, où une instance disparaît sans prévenir. En 2021, une étude estimait qu’une heure de downtime coûtait plus de 100 000 $ pour 98 % des entreprises interrogées. Le problème, c’est que ces pannes ne surviennent presque jamais dans des conditions confortables : elles arrivent en production, sous charge, au pire moment. Plutôt que d’attendre passivement ce scénario, une discipline propose de le provoquer soi-même, dans un cadre maîtrisé : le Chaos Engineering.
Provoquer la panne avant qu’elle ne vous trouve
Popularisé par Netflix dans les années 2010, le Chaos Engineering consiste à injecter volontairement des perturbations dans un système distribué pour découvrir ses faiblesses avant que les utilisateurs ne les rencontrent. L’idée peut sembler contre-intuitive (casser délibérément ce qui fonctionne) mais elle découle directement du principe du Design For Failure : dans une architecture distribuée, la panne n’est pas une exception à éviter, c’est une certitude à anticiper. L’objectif final n’est donc pas de casser pour casser, mais d’augmenter la confiance que l’on peut placer dans la résilience réelle du système.
Ce qui distingue le Chaos Engineering d’un simple sabotage, c’est sa rigueur : il s’agit d’une véritable démarche scientifique, structurée en quatre temps.
- Définir l’état stable : caractériser le comportement normal du système à travers des métriques mesurables (latence, taux d’erreur, débit).
- Formuler une hypothèse : décrire ce que l’on s’attend à observer une fois la perturbation introduite, idéalement « rien ne change pour l’utilisateur ».
- Injecter la perturbation : appliquer la panne ciblée dans des conditions contrôlées.
- Mesurer et apprendre : comparer le comportement observé à l’hypothèse, puis corriger les écarts révélés.
Cette boucle se déploie ensuite à différents niveaux du système, du plus large au plus local.
Au niveau de l’infrastructure
C’est le terrain historique de la discipline. Chaos Monkey, l’un des premiers outils développés par Netflix, agit délibérément sur n’importe quelle instance, quelle que soit la technologie qui tourne dessus : il en tue une au hasard et observe si le système absorbe la disparition. D’autres solutions plus complètes ont depuis émergé, comme Gremlin, Azure Chaos Studio ou Chaos Toolkit.
Ces outils permettent de simuler tout un éventail de perturbations réalistes :
- de la latence injectée dans les couches de communication ;
- des pannes réseau ciblées sur une région ou un cluster précis ;
- la mise hors service d’instances spécifiques ;
- des opérations qui saturent les CPU pour reproduire une surcharge.
L’intérêt est de valider, à l’échelle du système, que les mécanismes de redondance et de bascule tiennent bien la route quand une brique disparaît pour de vrai.
Au niveau applicatif
Tout ne se joue pas au niveau de l’infrastructure. Il est souvent tout aussi pertinent d’introduire le chaos plus localement, au cœur même d’une instance, via des bibliothèques dédiées. L’écosystème C# est ici exemplaire avec le duo Polly et Simmy.
Polly est une bibliothèque qui implémente les patterns de résilience que j’ai déjà détaillés dans ma série dédiée à la résilience : circuit breaker, retries, timeouts. Simmy en est le complément naturel : une intégration directe à Polly qui permet, à l’inverse, d’injecter le chaos pour vérifier que ces protections fonctionnent. Concrètement, Simmy sait introduire :
- des exceptions dans le système (timeout, erreurs HTTP) ;
- de la latence artificielle ;
- des comportements et des résultats altérés.
Quand l’écosystème n’offre pas d’outil mature
Tous les langages ne disposent pas d’une bibliothèque aussi aboutie que Polly. Ce n’est pas une raison pour renoncer : on peut introduire un niveau minimal de perturbations avec quelques briques de base.
- Un proxy de substitution : intercaler une version alternative de vos dépendances qui injecte erreurs et latence. Cela suppose toutefois un système d’injection de dépendances en place, pour pouvoir remplacer facilement une dépendance classique par sa variante perturbatrice.
- Des crashs aléatoires : simuler un process qui sort de manière inopinée, pour vérifier la capacité de redémarrage et de reprise.
- La saturation de l’event loop : dans l’écosystème Node.js, exécuter des tâches CPU-intensive pour provoquer un event loop lag, ou pousser l’Event Loop Utilization (ELU) afin de reproduire des conditions de saturation.
Conclusion
Le Chaos Engineering renverse une logique : au lieu de croiser les doigts en espérant que les pannes n’arriveront jamais, on choisit de les provoquer pendant qu’on est encore en mesure de les observer, de comprendre et de corriger. Qu’il s’agisse de tuer une instance avec Chaos Monkey ou d’injecter une exception avec Simmy, la démarche reste la même : transformer l’incertitude en hypothèse testable.
Et c’est peut-être là le vrai bénéfice : une heure de downtime imprévue coûte cher ; une heure de chaos provoqué, dans un cadre maîtrisé, est l’un des investissements les plus rentables que l’on puisse faire pour la robustesse d’un système.