Qu’est-ce que l’Ingénierie du Chaos et pourquoi est-elle importante ?
Pourquoi l’ingénierie du chaos est-elle importante ? Voyons pourquoi l’Assurance Qualité (AQ) existe en premier lieu.
Tout simplement, l’AQ existe parce que, peu importe nos efforts pour créer un logiciel parfait qui fait toujours ce pour quoi il a été conçu, le monde réel ne le permet tout simplement pas.
Des erreurs s’introduisent. Les machines interprètent notre code différemment de ce que nous avions prévu. Des imprévus surviennent. L’ingénierie qualité existe pour essayer de déceler ces problèmes involontaires avant que nos clients ne les découvrent.
Qu’est-ce que l’ingénierie du chaos ?
L’ingénierie du chaos est une approche méthodique destinée à identifier les défaillances potentielles avant qu’elles ne deviennent des pannes. Avec l’ingénierie du chaos, vous concevez des expériences d’injection de panne et comparez ce que vous pensez qu’il va se passer à ce qui se passe réellement dans vos systèmes. Vous « cassez volontairement des choses » pour apprendre à concevoir des systèmes plus résilients.
Pourquoi l’ingénierie du chaos est-elle importante ?
Parce que les systèmes évoluent. Traditionnellement, l’AQ exécute une variété de tests et de types de tests afin de détecter de manière proactive ces problèmes, bien avant que le code n’aboutisse en production. Ces tests sont pratiqués à la fin d’une construction et avant que ce code ne soit déployé publiquement, généralement dans un environnement de préproduction ou de test, par opposition aux tests en production.
Jusqu’ici tout va bien, si nous travaillons avec un modèle de développement et de déploiement logiciel traditionnel. Les conceptions monolithiques et les déploiements sur des machines détenues par l’entreprise offrent un contrôle élevé. Il existe une certaine stabilité découlant de ce contrôle. Cela rend ces environnements de préproduction ou de test semblables à ceux de production et permet d’y réaliser des tests efficaces.
Les systèmes distribués sont différents. Le cloud est différent. Nous ne maîtrisons pas l’infrastructure. Elle change en permanence. L’infrastructure évolue selon notre conception avec des services individuels, des microservices et la répartition de charge qui active ou retire des nœuds de calcul en fonction des besoins. Les systèmes de basculement s’ajustent pour garantir la gestion des risques. Ces changements constants provoquent des comportements inattendus et émergents. Ce sont des comportements que nous ne pouvons pas toujours prévoir, mais que nous pouvons reproduire et provoquer à l’aide d’une forme de test appelée ingénierie du chaos.
Les stratégies de test doivent s’adapter à l’évolution des systèmes
Nous ne pouvons pas tester efficacement tout ce que notre code de production et son environnement rencontreront en nous limitant à d’autres environnements. Nous pouvons tester de nombreux éléments : ce que l’AQ traditionnelle fait bien – et doit continuer à faire – même si une partie peut désormais être automatisée au sein du pipeline de compilation. Mais la manière dont nous menions jusque-là l’AQ ne permet pas de tester, par exemple, la réaction de notre système distribué lorsque le réseau entre un magasin de données et plusieurs nœuds de calcul est saturé et que la latence augmente.
Nos tests automatisés et manuels ne prennent pas en compte ce contexte de production en évolution rapide, où les services démarrent et s’arrêtent en fonction de la demande. La seule façon de tester si un système distribué restera fiable lorsque surviennent des comportements émergents dus à des conditions changeantes en production, c’est d’appliquer le principe fondamental de tous les types de tests : essayer et observer.
Comment fonctionne l’ingénierie du chaos : tester et apprendre à travers l’échec
Nous avons tous des objectifs de disponibilité. Nous cherchons tous à améliorer nos performances. Pour cela, nous devons exploiter toutes les ressources à notre disposition afin d’en apprendre un maximum sur la façon dont nos systèmes gèrent les échecs, que ce soit lorsqu’un utilisateur ne saisit pas les données attendues dans un champ de formulaire ou lorsqu’un composant système dans le cloud ne fonctionne pas comme prévu.
« Que se passe-t-il si… » est une question que nous aimons tous poser. Puis, nous essayons et nous observons les résultats.
Parce que nos systèmes et nos conceptions ont évolué de façon sans précédent, nous devons aussi faire évoluer nos méthodes de test afin de mieux comprendre comment nos systèmes distribués gèrent les défaillances et de quelle façon les défaillances de composants et de dépendances affectent l’ensemble du système. Ce type de test global, c’est ce que vise l’ingénierie du chaos, car elle permet de tester notre système complet tel qu’il existe en production.
Un programme d’ingénierie du chaos commence petit, en testant des comportements que l’on connaît déjà ou que l’on pense connaître :
- Notre système de surveillance détectera-t-il activement une latence réseau dépassant un certain seuil ?
- Cela déclenchera-t-il une alerte vers l’ingénieur d’astreinte ou une mitigation automatique ?
- Notre configuration a-t-elle dérivé au fil du temps ou démarrons-nous toujours des nœuds de calcul selon les spécifications ?
Comment chaque instance de service résiste-t-elle à une charge légère ? Moyenne ? Lourde ? Elles devraient toutes se comporter de manière identique et notre répartition de charge devrait distribuer le trafic entre elles de façon optimale. Que se passe-t-il si une instance commence à recevoir une charge beaucoup plus importante que les autres parce que notre service de répartition rencontre un problème ?
Les tests systématiques des systèmes chaotiques apportent des avantages essentiels
Nous testons en utilisant la méthode scientifique, en commençant petit et avec intention. Nous concevons des expériences précoces afin de minimiser le rayon d'impact, c'est-à-dire l’ensemble des services et des composants que nous pensons susceptibles d’être affectés, et de limiter l’ampleur des paramètres expérimentaux.
Une fois que nous avons du succès à cette étape, nous pouvons décider de progresser pas à pas, en renforçant notre confiance dans notre système ou en développant notre backlog priorisé d’améliorations à apporter. Lorsque nous réalisons ces améliorations et que nous refaisons le test en utilisant la même expérience de chaos et les mêmes paramètres, le système réussira et nous saurons qu’il est plus fiable qu’auparavant.
C'est le seul moyen d'apprendre comment nos systèmes réagissent vraiment aux défaillances en production, là où nos clients feront finalement l’expérience des résultats. Si nous identifions maintenant les petits problèmes, avant qu’ils ne deviennent de grands problèmes, nous pouvons nous assurer que les défaillances systémiques se font de plus en plus rares.
Cela fait de l'ingénierie du chaos un outil de fiabilité remarquable. Il s'agit d'une discipline qui nous permet de réaliser dans le cloud et à grande échelle ce que nous pouvions autrefois accomplir dans des environnements plus petits et contrôlés grâce à l’assurance qualité traditionnelle.
Cela signifie, en fin de compte, moins de pannes et d’incidents majeurs en production. En fait, lorsque l'ingénierie du chaos est appliquée et utilisée de manière régulière, les défaillances de services et de composants que l’on peut attendre dans le chaos du cloud n'auront aucun impact sur nos clients. En réalité, ils ne sauront même jamais qu'une panne a eu lieu, et c’est bien là l’objectif.
Quelle est la prochaine étape ?
J’ai discuté plus en détail de l’ingénierie du chaos dans l’épisode du podcast The QA Lead avec Jonathon Wright.
Note de la rédaction :
Vous pouvez rester informé des autres podcasts et articles de The QA Lead en vous inscrivant à la newsletter.
Vous pouvez également devenir membre pour accéder au forum communautaire de The QA Lead où vous pouvez partager les meilleures pratiques avec d’autres spécialistes de l’assurance qualité et ingénieurs qualité. Au plaisir de vous y retrouver !
À lire également : LES 10 MEILLEURS OUTILS LOGICIELS POUR L'INGÉNIERIE QUALITÉ : UN GUIDE COMPLET
