Qu’est-ce que le test de chaos ?

Le test de chaos est une technique utilisée pour tester la résilience des systèmes logiciels en introduisant des défaillances inattendues ou des interruptions. Les tests de chaos sont également appelés ingénierie du chaos. L’objectif des tests de chaos est d’identifier les faiblesses et d’améliorer la résilience de votre application.

Les tests de chaos sont basés sur l’idée que les systèmes échouent de manière inattendue. Les méthodes de test traditionnelles échouent souvent à découvrir ces modes d’échec inattendus. Lorsque vous utilisez des tests de chaos, vous simulez des scénarios réels, tels que les blocages de serveur, la latence réseau ou l’épuisement des ressources. La simulation de ces comportements permet d’exposer des problèmes cachés et des faiblesses qui peuvent ne pas être évidentes dans des conditions de test normales.

Voici quelques points clés à garder à l’esprit sur les tests de chaos :

• Soyez proactif. Au lieu d’attendre que des échecs se produisent, les tests de chaos introduisent de manière proactive des échecs pour voir comment le système répond. Les tests de chaos vous permettent d’identifier et de résoudre les problèmes avant qu’ils ne deviennent des problèmes majeurs.
• Obtenez des perspectives. L’objectif des tests de chaos est d’apprendre des échecs. En les introduisant, vous pouvez obtenir des informations précieuses sur le comportement du système sous contrainte et utiliser ces informations pour l’améliorer.
• Promouvoir un effort d’équipe. Les tests de chaos sont plus efficaces quand vous le faites en collaboration. Vous souhaitez obtenir des commentaires des développeurs, des testeurs, des opérations et d’autres parties prenantes. En travaillant ensemble, vous pouvez identifier les domaines les plus importants à tester et vous assurer que tout le monde est informé.
• Commencez petit et développez progressivement. Lorsque vous commencez par des tests de chaos, il est judicieux de commencer petit et progressivement augmenter la complexité de vos tests. Commencer petit vous aide à renforcer votre confiance et à mieux comprendre comment le système se comporte dans différentes conditions.

En résumé, le test de chaos est une technique puissante qui peut vous aider à améliorer la résilience de vos applications. En introduisant de manière proactive les échecs et en les apprenant, vous pouvez identifier et résoudre les problèmes avant qu’ils ne deviennent des problèmes majeurs.

Test de chaos pour les API que votre application appelle

Les tests de chaos se concentrent souvent sur l’infrastructure : serveurs, réseaux et conteneurs. Si votre application dépend d’API, certaines des défaillances que vos utilisateurs constatent proviennent de ces API : une erreur 500 provenant d’un fournisseur de paiement, une erreur 429 provenant de GitHub ou d’OpenAI, ou une réponse qui prend 8 secondes au lieu de 80 millisecondes. Vous pouvez appliquer les mêmes idées de test de chaos à ces dépendances, au niveau des réponses d’API individuelles :

• Erreurs. Renvoyez des erreurs 5xx de manière aléatoire et vérifiez que votre application relance les opérations pour lesquelles une nouvelle tentative est sûre et affiche un message utile dans les autres cas.
• Limitation. Renvoyez une erreur 429 avec un en-tête Retry-After et vérifiez que votre application attend avant de renouveler l’appel.
• Latence. Retardez les réponses et vérifiez les délais d’expiration, les indicateurs de chargement et le comportement de votre application lorsque les réponses arrivent dans le désordre.

Approach	Ce que vous trouvez	Ce que vous ne pouvez pas vérifier
Attendre qu’un problème survienne en production	Échecs réels	Tout, jusqu’à ce qu’un utilisateur y soit confronté
Simuler l’API dans vos tests ou laisser votre agent de codage écrire la simulation	Si vos branches de gestion des erreurs s’exécutent	Les formats d’échec réels de l’API, la stratégie de nouvelle tentative de votre SDK et le comportement de l’application en cours d’exécution. Votre application a également besoin d’un commutateur réservé aux tests pour accéder au simulateur.
Provoquer des défaillances de l’infrastructure réelle (par exemple, arrêter un service ou bloquer le trafic réseau)	Comment votre système fait face aux pannes	Les défaillances au niveau de l’API, comme un code d’erreur spécifique ou un en-tête Retry-After
Intercepter le trafic réel de votre application et injecter des défaillances d’API	Les erreurs, la limitation de débit et la latence sur les URL réelles, à la fréquence de votre choix	Les défaillances de l’infrastructure. Utilisez des outils de test de chaos dédiés à l’infrastructure pour les détecter.

L'essayer sur votre application

Dev Proxy introduit des défaillances d’API dans votre application tandis que celle-ci continue d’appeler les URL réelles. Il fonctionne avec n’importe quel type d’application, sur n’importe quelle pile technologique, sans modifier votre code. Par exemple, pour faire échouer la moitié des demandes à une API avec des erreurs aléatoires, suivez Testez mon application avec des erreurs aléatoires et pour les ralentir, consultez Simuler des réponses d’API lentes. Pour exécuter les mêmes tests dans votre pipeline CI, consultez Utiliser le proxy de développement dans CI/CD.

Étape suivante

Tester mon application avec des erreurs aléatoires