Le chaos engineering consiste à tester un logiciel en simulant des incidents. Découvrez tout ce que vous devez savoir sur cette pratique très utilisée en DevOps !
Quelle meilleure façon de tester la résilience d’un système que de le mettre à l’épreuve ? Au début des années 2000, l’ingénieur informatique Jesse Robbins d’Amazon créa le concept de « GameDay ».
Le but était de simuler des pannes dans les environnements de production pour tester la résilience des systèmes, le temps d’une journée.
Cette pratique a permis à Amazon d’améliorer considérablement la disponibilité de ses systèmes et de mieux préparer les équipes de développement et d’opération aux pannes éventuelles.
Quelques années plus tard, en 2009, alors que Netflix migrait vers le cloud AWS pour faire face à l’explosion de son nombre d’utilisateurs, la firme fut confrontée à de nouveaux défis liés à l’informatique en nuage.
Elle devait notamment faire face à l’augmentation des connexions et dépendances, et à d’autres problématiques bien plus complexes que l’équilibrage de charge dans ses data centers sur site.
Le moindre faux pas sur le cloud risquait de ruiner l’expérience pour les utilisateurs du service de streaming. Elle a donc développé un outil permettant d’éteindre aléatoirement des instances de logiciel en production pour tester comment l’infrastructure réagissait.
Cet outil fut nommé Chaos Monkey, inspiré par l’idée d’un singe sauvage relâché dans une salle de serveurs. En 2010, ce logiciel permettant de simuler des pannes sur les instances AWS fut lancé en open source.
C’est ainsi qu’une nouvelle méthode de test s’est popularisée dans toute l’industrie informatique et le monde du DevOps : le chaos engineering.
Qu’est-ce que le chaos engineering ?
Pour faire simple, l’ingénierie du chaos est une méthode de test de logiciel distribué. Elle consiste à introduire des perturbations ou des erreurs pour vérifier la résistance face aux imprévus.
De tels événements peuvent causer des réactions imprédictibles de la part des applications, et les pousser à rompre sous la pression. Le rôle des ingénieurs du chaos est de se demander pourquoi.
Ces spécialistes consacrent tout leur temps à perturber les systèmes on-prem et les logiciels cloud pour renforcer leurs résistances.
Ils soumettent le logiciel à une crise contrôlée, simulée pour tester les comportements instables. Le rôle de chaos engineer est devenu un métier hautement reconnu.
La crise mise en scène peut être un incident technique, naturel ou malveillant, par exemple une cyberattaque infectant une application ou un séisme impactant un Data Center.
Lorsque les performances du logiciel se dégradent, les découvertes des chaos engineers permettent aux développeurs d’ajouter de la résilience au code pour que l’application soit parée en cas d’urgence en conditions réelles.
À mesure que les ingénieurs effectuent leurs tests, ils peuvent changer des variables et accroître l’ampleur de la perturbation simulée. Ceci les aide à mieux modéliser les réactions des applications et microservices, et ces informations précieuses peuvent être partagées avec les développeurs pour perfectionner le logiciel ou l’infrastructure cloud-native.
Après la démocratisation du chaos engineering initiée par Netflix et son Chaos Monkey, d’autres outils ont vu le jour.
En 2016, la plateforme Gremlin a été fondée pour aider les entreprises à tester la résilience de leurs applications et infrastructure avec une large gamme d’outils de test. Il permet notamment la simulation de pannes de réseau et de bases de données.
De même, Pumba développé par Kontena permet de simuler des pannes dans des conteneurs Docker.
Aujourd’hui, de nombreuses entreprises adoptent cette pratique DevOps pour s’assurer que leurs systèmes soient capables de résister aux pannes et aux conditions de stress et réduire les temps d’arrêt.
Comment fonctionne le chaos engineering ?
L’ingénierie du chaos repose sur plusieurs étapes.
Dans un premier temps, les ingénieurs formulent une hypothèse en se demandant ce qui arriverait s’ils modifiaient une variable spécifique.
Par la suite, afin de tester cette hypothèse, ils orchestrent une simulation d’incidents combinée avec un test de charge et surveillent les signes de perturbation dans les services, réseaux, appareils et l’infrastructure délivrant l’application. Tout échec ou panne dans le stack prouve que l’hypothèse est fausse. Les ingénieurs l’isolent alors afin de comprendre ce qui l’a provoquée. Tout dommage ou autre effet causé par le test est appelé « blast radius » ou rayon de l’explosion. Le contrôle des tests permet de gérer cette zone d’impact.
Enfin, les découvertes réalisées à travers ces tests sont exploitées dans le processus de développement et de livraison. Ceci permet aux nouveaux logiciels et microservices de mieux résister aux événements imprévisibles.
Afin de limiter les dégâts sur les environnements de production, les ingénieurs du chaos commencent dans un environnement de test et s’étendent progressivement vers la production.
Cette pratique permet de configurer finement les indicateurs et objectifs de niveau de service, d’améliorer les alertes, et de construire des tableaux de bord plus efficaces collectant les données pertinentes pour observer et analyser l’environnement.
Avantages et inconvénients
Une fois bien implanté dans une organisation, le chaos engineering apporte de nombreux bienfaits. Il permet tout d’abord d’accroître la résilience et la fiabilité, en fournissant des informations exploitables sur la façon dont le logiciel se comporte en condition de stress.
Cette approche permet aussi d’accélérer l’innovation en permettant aux développeurs de modifier le design du logiciel pour le rendre plus durable et améliorer la qualité en production.
Outre les développeurs, les équipes techniques peuvent également tirer profit des informations glanées par les chaos engineers à partir de leurs expériences. C’est donc un précieux atout pour la collaboration.
Le temps de réponse aux incidents est également amélioré, puisque les équipes appréhendent beaucoup mieux les différentes perturbations qu'ils peuvent rencontrer.
In fine, la satisfaction des clients s’en trouve accrue puisque les temps d’interruption sont réduits. Ainsi, l’ingénierie du chaos fournit un avantage compétitif aux entreprises.
Néanmoins, cette pratique a aussi des inconvénients. Le risque principal est de causer des dommages lors d’un test en environnement de production. Il est donc essentiel de bien contrôler le rayon d’explosion.
Or, un manque d’observabilité de tous les systèmes impactés peut poser problème. Ceci peut empêcher de fixer les priorités en termes de correctifs, ou de déterminer la racine exacte d’un problème.
Conclusion : le chaos engineering, une méthode de test idéale pour DevOps
Le chaos engineering est utilisé par de nombreuses équipes DevOps, sur des applications exécutées à la fois en pré-production et production.
En permettant de tester la résilience des systèmes et d’identifier les problèmes avant qu’ils ne posent problème en production, cette approche favorise l’intégration et la livraison continue (CI/CD).
Cette méthode de test permet d’améliorer continuellement la qualité des logiciels, et les informations obtenues à partir des tests peuvent être exploitées aussi bien par les développeurs que par les opérateurs.
Afin d’apprendre à maîtriser toutes les meilleures pratiques DevOps, vous pouvez choisir DevUniversity. Notre formation à distance éligible au CPF vous permet d’acquérir toutes les compétences d’ingénieur DevOps. Découvrez DevUniversity !
Vous savez tout sur le chaos engineering. Pour plus d’informations sur le même sujet, découvrez notre dossier complet sur le SRE et notre dossier sur le CI/CD.
.jpg)
