Chaos testing réseau sous Windows
Le chaos testing consiste à casser quelque chose exprès, sous vos yeux, pour découvrir ce que fait votre logiciel. Au niveau du réseau, c’est exactement ce qu’est cet outil : un moyen d’injecter une panne dans une application et de voir si elle y survit.
Les pannes que vous pouvez injecter
| Panne | Ce qu’elle modélise |
|---|---|
| Perte, corruption, duplication | Un chemin dégradé. Des paquets disparaissent, arrivent abîmés ou arrivent deux fois. |
| Latence, gigue, pics | Un chemin lent ou instable, y compris le blocage de plusieurs secondes qui fait sauter les délais d’attente. |
| Réinitialisations de connexion | Un pare-feu ou un répartiteur de charge qui coupe des connexions en plein transfert. |
| Coupures de liaison | Le chemin qui disparaît puis revient, selon un cycle. |
| Adresse ou port bloqué | Une dépendance injoignable alors que tout le reste fonctionne. |
| Internet coupé, réseau local vivant | La forme du portail captif : le local fonctionne, le monde extérieur non. |
Ce qui distingue le chaos du bruit : la répétabilité
Une panne aléatoire qu’on ne peut pas rejouer produit une anecdote, pas un rapport de bug. Chaque décision aléatoire ici vient d’une graine, si bien que la même commande reproduit la même exécution : les mêmes paquets perdus, la même gigue, dans le même ordre :
BeanNetworkTester.exe --loss 15 --rst-prob 5 --seed 42 --target myapp.exe --duration 120C’est la différence entre « ça a planté une fois mardi dernier » et un test en échec qu’une autre personne peut lancer.
Dans un pipeline
La ligne de commande rend compte par des codes de sortie, si bien qu’une build peut distinguer « l’application a échoué » de « l’outil n’a pas pu démarrer », et la session se termine d’elle-même : il n’y a aucune étape de nettoyage à oublier :
BeanNetworkTester.exe --loss 10 --rst-prob 5 --target myapp.exe --duration 90 --format json > chaos.ndjsonUne suite de pannes plutôt qu’une seule est un fichier de scénario, et ceux-ci sont eux aussi répétables. Voir scénarios temporels et tests réseau en CI pour les codes de sortie et le runner nécessaire.
Où s’arrête le rayon d’action
Deux limites, toutes deux voulues. La dégradation atteint un seul processus, PID, adresse ou port quand vous la dirigez, si bien que la machine sur laquelle vous travaillez continue de fonctionner. Et c’est une seule machine : il s’agit d’injection de pannes pour un client et sa connexion, pas pour un cluster. Si vous cherchez du chaos entre services et nœuds, c’est un autre type d’outil, et celui-ci est la pièce qui casse le réseau sous une seule application Windows.
Tout est réversible sur-le-champ. STOP rétablit le réseau, une limite de durée fait de même, et un chien de garde dans l’outil arrête la capture si l’outil lui-même meurt : une panne que vous avez injectée ne doit jamais survivre à l’exécution qui l’a injectée.