Il y a plus de dix ans, Netflix a pris une décision qui, vue de l’extérieur, semblait totalement irrationnelle : commencer à détruire volontairement sa propre infrastructure de production.
Ce n’était pas parce qu’ils subissaient des pannes constantes ni pour défier leurs ingénieurs. C’était parce qu’ils avaient compris une réalité que partagent aujourd’hui presque toutes les grandes plateformes cloud : les pannes sont inévitables.
La véritable question n’a jamais été si un serveur tomberait en panne, mais plutôt ce qu’il se passerait lorsque cela arriverait.
De cette idée est née Chaos Monkey, sans doute le projet d’ingénierie de la fiabilité le plus influent de l’informatique moderne. Quinze années plus tard, ses principes restent plus vivants que jamais et ont même fini par influencer les services gérés d’AWS, Azure, Google Cloud, ainsi que la conception des applications distribuées.
Les clés du Chaos Engineering en 20 secondes
- Netflix a créé Chaos Monkey pour éteindre aléatoirement des serveurs en production.
- Le but était de découvrir les faiblesses avant que les utilisateurs ne rencontrent des problèmes.
- L’initiative a évolué vers des plateformes capables de simuler des chutes de régions entières, la latence ou des problèmes réseau.
- Aujourd’hui, AWS, Kubernetes et de nombreuses entreprises intègrent ces techniques dans leur gestion de la fiabilité.
- L’arrivée de l’IA et des systèmes autonomes rendra encore plus cruciale la mise à l’épreuve en simulant des défaillances contrôlées.
Pendant des années, l’accessibilité maximale était comprise comme la création d’infrastructures « qui ne tomberaient jamais ».
Aujourd’hui, nous savons que cette prémisse est irréalisable.
Les disques échouent.
Les commutateurs cessent de répondre.
Les bases de données rencontrent des blocages.
Les régions cloud peuvent connaître des incidents.
Même le logiciel parfaitement développé contient des bogues qui n’apparaissent que dans des conditions spécifiques.
La différence entre une architecture robuste et une architecture fragile ne réside pas dans l’évitement de tous ces problèmes.
Elle est dans la manière dont elle réagit quand ces problèmes surviennent.
Qu’est-ce que réellement le Chaos Engineering ?
Le Chaos Engineering est une discipline qui consiste à introduire délibérément des défaillances contrôlées dans un système pour vérifier qu’il continue à fonctionner correctement.
Il ne s’agit pas de casser des serveurs pour le plaisir.
Chaque expérience commence par une hypothèse.
Par exemple :
« Si nous perdons un nœud Kubernetes, les utilisateurs ne devraient pas remarquer d’interruption. »
Ou encore :
« Si la latence augmente entre deux microservices, l’application doit continuer à répondre grâce aux mécanismes de timeout et de retry. »
Ensuite, la défaillance souhaitée est provoquée intentionnellement.
Si le système continue de fonctionner, l’hypothèse est correcte.
Sinon, cela révèle un problème… avant que les clients ne le rencontrent.
C’est précisément là toute la valeur du Chaos Engineering.
Tout a commencé après la migration de Netflix de son infrastructure traditionnelle vers Amazon Web Services (AWS).
L’architecture est passée de quelques serveurs à des milliers d’instances réparties.
Dans ce nouveau contexte, un problème totalement différent est apparu.
Il n’était plus réaliste de supposer que tous les serveurs seraient toujours disponibles.
Chaque jour, certains échoueraient.
La solution a été extraordinairement simple.
Créer un programme qui choisit aléatoirement des machines virtuelles et les éteint pendant la journée de travail.
Pourquoi pendant la journée précisément ?
Parce que tous les ingénieurs étaient en train de travailler.
Si quelque chose échouait, cela pouvait être vu immédiatement.
Si l’application ne répondait plus, le problème n’était pas Chaos Monkey, mais l’architecture elle-même.
Très vite, Netflix a découvert que l’interruption de serveurs n’était qu’un des nombreux types de défaillances possibles.
C’est ainsi qu’est née la Sécurité Simienne (Simian Army).
Chaque outil simulait un problème différent.
Chaos Monkey
Le plus connu.
Il arrêtait aléatoirement des instances EC2 pour vérifier que l’application pouvait continuer à fonctionner sans elles.
Latency Monkey
Il introduisait des retards artificiels entre services.
Particulièrement utile dans les architectures de microservices, où quelques dizaines de millisecondes supplémentaires peuvent rapidement s’accumuler.
Chaos Gorilla
Il simulait la perte totale d’une zone de disponibilité AWS.
Autrement dit, une zone physique entière du centre de données disparaissait, et l’application devait continuer de fonctionner depuis une autre zone.
Chaos Kong
Il poussait le test à l’extrême.
Il simulait la disparition totale d’une région cloud.
Une étape essentielle pour tester les stratégies multi-régions.
Autres « monkeys »
Netflix a ensuite développé des outils visant à détecter :
- les ressources sous-utilisées ;
- les configurations incorrectes ;
- les problèmes de sécurité ;
- les dépendances inattendues ;
- les services orphelins.
Avec le temps, ils ont même cessé d’utiliser le terme « monkey ».
L’objectif n’était plus de provoquer des défaillances, mais de réaliser des expériences scientifiques sur le comportement du système.
Netflix a progressivement remplacé la Simian Army par des plateformes bien plus sophistiquées, notamment :
- ChAP (Chaos Automation Platform)
- FIT (Failure Injection Testing)
Plutôt que de lancer des attaques aléatoires, ces outils permettent de définir des expériences précises.
Par exemple :
« Que se passe-t-il si le service d’authentification répond deux secondes plus tard ? »
Ou encore :
« Comment la perte de 25 % du trafic d’une base de données affecte-t-elle le système ? »
Chaque expérience comporte :
- une hypothèse ;
- des métriques ;
- des critères de succès ;
- des mécanismes automatiques pour arrêter l’expérience en cas d’effets inattendus.
C’est le même principe scientifique appliqué à l’infrastructure.
Les idées de Netflix ont eu une influence directe sur l’industrie du cloud.
Aujourd’hui, Amazon propose AWS Fault Injection Service (AWS FIS), un service managé permettant de réaliser ce type d’expériences sans développer ses propres outils.
Avec AWS FIS, il est possible de simuler des scénarios comme :
- l’arrêt d’instances EC2 ;
- la perte de connectivité ;
- l’augmentation de latence ;
- la surcharge du CPU ;
- les erreurs de stockage ;
- les interruptions sur Amazon ECS ;
- les incidents sur Amazon EKS ;
- les dégradations de bases de données.
L’écart avec 2011 est considérable.
Netflix a dû bâtir toute sa plateforme de zéro.
Aujourd’hui, toute organisation peut commencer en quelques heures.
Dans un environnement basé sur des machines virtuelles, les composants évoluaient relativement peu.
Avec Kubernetes, c’est exactement le contraire.
Les pods apparaissent et disparaissent sans cesse.
Les conteneurs se recréent.
Les nœuds entrent et sortent du cluster.
Les équilibreurs de charge modifient en permanence le trafic.
L’infrastructure est par définition dynamique.
Cela rend le Chaos Engineering encore plus précieux.
Il ne suffit plus de vérifier qu’une application fonctionne, il faut s’assurer qu’elle continue à fonctionner dans un environnement qui change constamment.
La prochaine grande étape viendra avec l’intégration de l’intelligence artificielle.
De plus en plus de plateformes délégueront des décisions à des systèmes autonomes.
Balance de charge.
Autoscalade.
Attribution des ressources.
Résolution des incidents.
Optimisation énergétique.
Dans ce contexte, il ne s’agira plus seulement de valider le logiciel.
Il faudra aussi vérifier comment l’IA réagit face à des données incomplètes, contradictoires ou erronées.
Probablement, au cours des prochaines années, apparaîtront de nouveaux outils de Chaos Engineering spécialement conçus pour valider les agents intelligents.
Il n’est pas nécessaire d’être Netflix pour commencer.
Un bon programme de Chaos Engineering débute souvent par des expérimentations très simples.
Voici quelques exemples :
| Hypothèse | Expérience |
|---|---|
| Le service supporte la perte d’un nœud | Éteindre une machine virtuelle |
| Kubernetes répartit correctement les pods | Drainer un nœud du cluster |
| La application supporte une latence élevée | Introduire des retards artificiels |
| La base de données reproduit correctement | Déconnecter temporairement un nœud secondaire |
| Les sauvegardes permettent de restaurer le service | Restaurer périodiquement un environnement complet |
L’essentiel est de progresser étape par étape.
Jamais commencer par des scénarios extrêmes.
Et mesurer absolument tout.
Il existe une idée qui résume parfaitement toute cette discipline :
La résilience ne se prouve pas dans les diagrammes d’architecture.
Elle se démontre lorsque l’infrastructure commence à se briser.
Le Chaos Engineering a complètement changé la façon de concevoir la haute disponibilité.
Au lieu de se demander :
« Est-ce que ça va fonctionner ? »
la question est devenue :
« Que se passera-t-il lorsque cela cessera de fonctionner ? »
Et c’est probablement la meilleure question que tout équipe d’infrastructure puisse se poser à l’ère du cloud, de Kubernetes et de l’intelligence artificielle.
Questions fréquentes
Le Chaos Engineering consiste-t-il à casser des serveurs ?
Non. Il s’agit d’expériences contrôlées pour vérifier comment un système répond à des défaillances prédéfinies.
Est-ce uniquement réservé aux grandes entreprises ?
Pas du tout. Aujourd’hui, des outils comme AWS Fault Injection Service, LitmusChaos ou Chaos Mesh permettent de commencer même dans des petites infrastructures.
Faut-il réaliser ces expériences en production ?
Oui, mais toujours de manière contrôlée, limitée, avec des mécanismes automatiques pour arrêter l’expérience en cas de risques inattendus.
Pourquoi cela deviendra encore plus crucial avec l’IA ?
Parce que les systèmes autonomes prendront des décisions sur des infrastructures complexes. Il sera essentiel de vérifier non seulement que le logiciel fonctionne, mais aussi que ces agents réagissent correctement face à des défaillances réelles.