Qu’est-ce que l’ingénierie du chaos et pourquoi est-elle importante ?
Pourquoi l’ingénierie du chaos est-elle importante ? Regardons pourquoi l’Assurance Qualité (QA) existe tout d’abord.
Tout simplement, la QA existe parce que, peu importe à quel point nous nous efforçons de créer des logiciels parfaits, qui font toujours ce pour quoi ils sont conçus et censés faire, le monde réel ne semble pas le permettre.
Des erreurs s’infiltrent. Les machines interprètent notre code différemment de ce que nous avions prévu. Des imprévus se produisent. L’ingénierie de la qualité existe pour essayer de détecter ces problèmes non intentionnels avant que nos clients ne les rencontrent.
Envie d'en avoir plus avec The CTO Club ?
Créez un compte gratuit pour terminer cet article et rejoindre une communauté de CTO et de leaders en ingénierie partageant des cadres pratiques, des outils et des conseils pour concevoir, déployer et faire évoluer des technologies alimentées par l'IA.
Have an account? Log In
Qu’est-ce que l’ingénierie du chaos ?
L’ingénierie du chaos est une approche méthodique visant à identifier les défaillances potentielles avant qu’elles ne deviennent des pannes réelles. Avec l’ingénierie du chaos, vous concevez des expériences d’injection d’échecs et vous comparez ce que vous pensez qui va se passer avec ce qui se passe réellement dans vos systèmes. Vous « cassez littéralement des choses exprès » afin d’apprendre comment construire des systèmes plus résilients.
Pourquoi l’ingénierie du chaos est-elle importante ?
Parce que les systèmes évoluent. Traditionnellement, la QA exécute une variété de tests et de types de tests pour rechercher de façon proactive ces problèmes, bien avant que le code n’atteigne la production. Ces tests sont réalisés à la fin d’une version logicielle, avant que ce code ne soit déployé publiquement, en général dans des environnements de pré-production ou de test, par opposition au test en production.
Jusqu’ici tout va bien, si nous évoluons dans un modèle traditionnel de développement et de déploiement logiciel. Les conceptions monolithiques et les déploiements sur des machines appartenant à l’entreprise offrent un grand contrôle. Il y a une stabilité inhérente à ce contrôle. Cela rend ces environnements de pré-production et de test similaires aux environnements de production et permet d’y effectuer des tests avec succès.
Les systèmes distribués, c’est différent. Le cloud, c’est différent. Nous ne contrôlons pas l’infrastructure. Elle change constamment. L’infrastructure évolue selon notre conception, avec des services et microservices individuels et la répartition de charge qui lance ou retire des nœuds de calcul en fonction des besoins. Les systèmes de basculement s’ajustent automatiquement pour assurer la gestion des risques. Ce changement permanent provoque des comportements inattendus, émergents. Ce sont des comportements que nous ne pouvons pas toujours prévoir, mais que nous pouvons reproduire ou provoquer via une forme de test appelée ingénierie du chaos.
Les tests doivent s’adapter lorsque les systèmes changent
Nous ne pouvons pas tester efficacement tout ce que notre code de production et l’environnement vont rencontrer en testant dans un autre environnement. Nous pouvons tester énormément de choses, celles que la QA traditionnelle effectue déjà très bien et qu’elle doit continuer à faire, même si certaines peuvent maintenant être automatisées dans la chaîne de construction. Mais la manière dont nous faisions la QA ne permet pas de tester comment notre système distribué va réagir, par exemple, lorsque le réseau entre une base de données et plusieurs nœuds de calcul est saturé et que la latence augmente.
Nos tests automatisés et menés par l’humain ne tiennent pas compte de cet environnement de production qui évolue rapidement, où les services apparaissent ou s’arrêtent en fonction de la demande. La seule façon de tester si un système distribué restera fiable face à des comportements émergents causés par les conditions changeantes de la production est de faire comme dans tous les paradigmes de test : essayer et constater.
Comment fonctionne l’ingénierie du chaos : tester et apprendre par l’échec
Nous avons tous des objectifs de disponibilité. Nous voulons tous améliorer nos performances. Pour cela, nous devons utiliser toutes les ressources à notre disposition pour en apprendre un maximum sur la façon dont nos systèmes gèrent les défaillances, qu’il s’agisse d’une erreur saisie par un utilisateur dans un champ de formulaire ou bien d’un composant du cloud qui ne fonctionne pas comme prévu.
« Que se passe-t-il si ? » est une question que nous adorons tous poser. Ensuite, nous essayons et nous constatons.
Puisque nos systèmes et nos conceptions de systèmes ont évolué d’une manière sans précédent, nous devons également faire évoluer nos méthodes de tests pour mieux comprendre comment nos systèmes distribués géreront les défaillances, et comment les échecs de composants ou de dépendances impactent l’ensemble du système. Ce type de test global est précisément la raison d’être de l’ingénierie du chaos, car elle permet de tester notre système dans son intégralité tel qu’il existe en production.
Un programme d’ingénierie du chaos commence petit, en testant ce que nous savons déjà ou pensons savoir :
- Notre système de surveillance détectera-t-il activement une latence réseau dépassant un certain seuil ?
- Cela entraînera-t-il l’alerte de l’ingénieur d’astreinte ou peut-être le déclenchement d’une atténuation automatique ?
- Notre configuration a-t-elle évolué avec le temps, ou lançons-nous toujours des nœuds de calcul selon les spécifications ?
Comment chaque instance de service se comporte-t-elle sous un test léger ? Moyen ? Lourd ? Elles devraient toutes fonctionner de façon similaire et notre répartition de charge devrait distribuer la charge entre elles de façon appropriée. Que se passe-t-il si une instance commence à recevoir une charge sensiblement plus lourde que les autres parce que notre service d'équilibrage de charge rencontre des problèmes ?
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 de manière réfléchie. Nous concevons les premières expériences pour minimiser le rayon d'impact, c'est-à-dire l'ensemble des services et des composants susceptibles d'être affectés, et pour minimiser l'ampleur des paramètres de l'expérience.
Une fois que nous avons réussi à ce stade, nous pouvons choisir de construire pas à pas, en augmentant notre confiance dans notre système ou en enrichissant notre liste priorisée d'améliorations à apporter. Lorsque nous procédons à ces améliorations et que nous retestons avec 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 la seule façon d'apprendre comment nos systèmes gèrent réellement les échecs en production, là où nos clients verront inévitablement les résultats. Si nous pouvons détecter maintenant les petits problèmes, avant qu'ils ne deviennent de gros problèmes, nous pouvons garantir que de moins en moins de défaillances systémiques se produiront.
Cela fait du Chaos Engineering un outil de fiabilité remarquable. C'est une discipline qui nous aide à faire, dans le cloud et à grande échelle, ce que nous étions autrefois capables d'accomplir dans des environnements plus petits et contrôlés via le test traditionnel QA.
Cela signifie finalement moins de défaillances et de pannes de production à grande échelle. En fait, lorsque le Chaos Engineering est mis en œuvre et utilisé de manière régulière, les incidents de service et de composant qui devraient survenir dans le chaos du cloud n'auront aucun impact sur nos clients. Ils ne se rendront même jamais compte qu'il y a eu une panne, et c'est bien là le véritable objectif.
Et maintenant ?
J'ai approfondi le sujet du chaos engineering 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 pourrez partager les meilleures pratiques avec d'autres QA et ingénieurs qualité. Au plaisir de vous y retrouver !
À lire également : LES 10 MEILLEURS OUTILS DE LOGICIELS D’INGÉNIERIE QUALITÉ : GUIDE COMPLET
