Chaos Engineering ou la correction en production

D'importantes ressources sont investies dans les tests de produits logiciels lorsque les entreprises s'efforcent de créer un produit très stable et résilient. Cependant, cela ne donne pas toujours les résultats escomptés.

Réparer le produit logiciel en production vous semble-t-il préférable à le casser ? Eh bien, cela dépend peut-être à qui nous posons la question.

Nous devrions donc peut-être choisir les termes à employer lorsque nous présentons cela aux parties prenantes ou aux managers. Certains n'apprécient guère les termes « destructifs » et, parfois, nous pouvons avoir besoin d'utiliser des termes « créatifs ». Mais casser le logiciel pour identifier ses faiblesses et le rendre plus robuste, fiable et stable nous amène à penser qu'il faut d'abord le casser, puis le réparer.

Comment appelle-t-on le fait d'expérimenter un logiciel pour voir combien de temps il résistera sous une pression donnée et combien de temps il parviendra à maintenir son intégrité avant de dysfonctionner ? Cela a-t-il un nom ?

Laissez-moi vous présenter le Chaos Engineering (ci-après CE).

Qu'est-ce que le Chaos Engineering ?

Certaines définitions du CE disent qu'il s'agit de la discipline consistant à expérimenter sur un système afin de renforcer la confiance dans la capacité du système à résister à des conditions turbulentes en production.

Supposons que vous développiez un logiciel qui assure certaines fonctionnalités. Ce logiciel fonctionne bien et offre de bonnes performances dans tous les tests entrepris. Mais que se passerait-il si, dans l'environnement de production, ce logiciel était poussé à ses limites et finissait par dysfonctionner ? La perte de revenus pourrait être énorme. Plus le système est important, plus la perte pourrait être significative. Pour éviter cela, nous devrions minimiser le risque mentionné précédemment.

L'ingénierie de la fiabilité (CE) doit être mise en œuvre dans les systèmes de grande envergure accessibles aux utilisateurs presque en permanence. Plus le nombre d'utilisateurs est élevé, plus l'impact est important.

Plongeons encore plus profondément dans le sujet donné.

Chaos Engineering en pratique

Lorsque nous parlons de développement logiciel, nous devons penser à la résilience d'un système logiciel, qui est généralement spécifiée comme une exigence logicielle. Il s'agit de la capacité d'un système logiciel donné à tolérer des défaillances tout en garantissant une qualité de service (QoS) adéquate. Cette exigence peut souvent être difficile à satisfaire pour les équipes de développement en raison d'un faible savoir-faire ou d'un calendrier de projet serré. C'est là qu'intervient le Chaos Engineering.

CE est une technique qui aide à satisfaire l'exigence de résilience et pourrait être utilisée contre les défaillances applicatives, les défaillances d'infrastructure et les défaillances réseau.

Cela se fait en injectant des défaillances dans le système spécifique de manière contrôlée et surveillée afin d'obtenir un aperçu de la résilience d'un système donné. Si des failles massives apparaissent, nous devons traiter la situation pour trouver une solution permettant de les atténuer. Avec le CE, nous pouvons découvrir les faiblesses d'un système spécifique, trouver une solution pour y faire face et construire un système plus résilient pour un risque minimal de perte de revenus ou de la « honte sur le marché » que nos utilisateurs peuvent créer en évaluant un logiciel spécifique.

Les expériences CE suivent certaines directives ou étapes.

Étape n°1

Nous devons définir un état normal du système observé qui doit représenter le comportement normal et avoir une sortie mesurable. À cette fin, nous devons mesurer la sortie du système sur une courte période et définir ces données comme un état normal ou stable.

Étape n°2

Nous devrions formuler l'hypothèse que cet état normal sera présent à la fois dans le groupe de contrôle et dans le groupe expérimental. Elle devrait être fondée sur des données mesurables que nous avons déjà collectées.

Étape n°3

Nous devrions introduire les situations qui représentent des événements du monde réel et qui simuleront des problèmes de serveur (arrêt du serveur, réponses malformées, pics de trafic, épuisement des ressources), des problèmes de réseau (faible bande passante, latence, perte de paquets ou défaillance complète de la liaison), des problèmes de disque dur (épuisement des ressources, données corrompues), etc.

De préférence, nous devrions réaliser ces expérimentations directement dans l'environnement de production afin de garantir l'authenticité et la pertinence du système actuellement déployé. Mais veillez à ne pas impacter les utilisateurs pendant le processus. Si l'expérience utilisateur est affectée, arrêtez immédiatement les tests. Tirez les enseignements de cette expérience et adaptez votre stratégie de test. Réessayez.

Étape n°4

Nous devrions réfuter l'hypothèse avec les différents états dans le groupe de contrôle et le groupe expérimental.

Étape n°5

Automatisez le processus pour exécuter ces expériences en continu. Manuellement, cela pourrait être intenable.

Le système doit fonctionner malgré ses défaillances, et c'est là que le Chaos Engineering devient pertinent.

Avantages du Chaos Engineering

CE peut être un peu difficile à configurer au début, mais à long terme, cela devrait être rentable. Nous constatons ses bénéfices d'un point de vue commercial, client et technique.

D'un point de vue commercial, les défaillances système peuvent conduire l'entreprise à un état indésirable sur le marché, ce qui peut entraîner une perte de revenus, une mauvaise réputation, des coûts de maintenance élevés, des difficultés à recruter de nouveaux employés et à conclure de nouveaux contrats commerciaux, etc.

Du point de vue du client, CE pourrait maintenir de bons avis sur le produit, une disponibilité élevée du produit, une bonne réputation auprès des utilisateurs actuels et un flux stable de nouveaux utilisateurs.

D'un point de vue technique, cette technique peut aider à réduire les problèmes ou incidents système, à mieux comprendre les faiblesses du système, à améliorer le système et à accélérer la résolution des incidents.

Les exemples concrets de ce qui peut se produire sont nombreux.

Nous utilisons tous les médias sociaux pour communiquer. La plupart d'entre nous font partie de certains groupes. Supposons que vous manquiez une notification qui devrait arriver juste à temps pour que vous puissiez entreprendre une certaine action. Elle arrive trop tard. Autre scénario : imaginez que vous disposiez sur votre smartphone d'une solution capable de suivre votre géolocalisation et qui vous fournit des informations incorrectes.

Voici quelques exemples supplémentaires. Imaginez combien de choses pourraient mal tourner dans le cas d'une technologie utilisée pour la conduite autonome. Un autre cas pourrait être une solution logicielle interne qui crée des fichiers PDF dont les employés ont souvent besoin pour conclure de nouveaux contrats. Si cette solution logicielle cessait de fonctionner alors que certaines choses doivent être livrées dans les délais, l'impact sur le profit de l'entreprise pourrait être notable.

Enfin, imaginez que votre entreprise soit une grande banque avec de nombreuses agences et qu'elle détienne une bonne part du marché d'un certain pays. Une nouvelle version de l'application bancaire est publiée. L'application a été testée superficiellement en raison d'un manque de ressources, mais il a été décidé de la mettre en production. Lors du passage en production, certains problèmes environnementaux surviennent et l'application devient indisponible pour tous ses utilisateurs. La note de l'application dans le store chute. La réputation de l'entreprise en pâtit également. Ce genre de situation doit être évité grâce à la flexibilité et à la formation des ingénieurs.

Peut-être qu'avec le CE en place, ces choses ne se seraient pas produites.

Mettons les choses au clair

Si vous n'avez pas encore rencontré le terme Chaos Engineering, vous vous posez peut-être quelques questions, alors laissez-moi vous les expliquer.

• Le CE n'est pas destiné à produire du chaos mais à être une solution en cas de survenance des problèmes mentionnés.
• Tout est réalisé dans un environnement contrôlé (du moins cela devrait être le cas si vous ne voulez pas tout gâcher).
• Tout est également surveillé car nous avons besoin de ces données par la suite
• Outre l'ajout de nouvelles fonctionnalités, les développeurs se soucient de la fiabilité, écrivent et exécutent des tests unitaires.
• Les solutions logicielles doivent être rigoureusement testées avant la mise en production, et l'ingénierie de fiabilité (CE) va au-delà de cette étape. Les tests fournissent les données attendues. L'ingénierie de fiabilité fournit des données inattendues qui peuvent être exploitées pour concevoir des solutions résilientes.
• Le CE est principalement destiné aux grands systèmes, comme mentionné précédemment, mais il est également utile pour les plus petits.
• Aucun outillage spécifique n'est requis.
• Le CE gagne à être automatisé.
• Grâce aux expérimentations en CE, nous découvrons de nouvelles propriétés du système et acquérons de nouvelles connaissances ou renforçons notre confiance dans la solution logicielle.

Utilisation du Chaos Engineering

En 2011, Netflix a publié un article intitulé « The Netflix Simian Army », marquant la première introduction du Chaos Engineering. C'est de ce récit qu'est également né « Chaos Monkey » (développé en 2010 par l'équipe d'ingénierie de Netflix), un outil logiciel qui simule aléatoirement des défaillances d'instances de production. Certains d'entre nous ont peut-être vu des soldats ouest-africains remettre un AK-47 à un singe (YouTube : « Ape With AK-47 »), ce qui illustre bien le caractère imprévisible des résultats. Par ailleurs, Chaos Monkey ne fonctionne pas comme un service, mais plutôt comme une tâche cron planifiée qui appelle Chaos Monkey une fois par semaine pour générer un calendrier de terminaisons.

Nous avons mentionné la « Simian Army » il y a un instant – alors, de quoi s'agit-il ? C'est une suite complète d'outils générateurs de pannes qui va au-delà du Chaos Monkey lui-même. Elle comprend Latency Monkey, Conformity Monkey, Doctor Monkey, Janitor Monkey, Security Monkey, 10-18 Monkey, Chaos Gorilla et Chaos Kong. Nous nous arrêterons là pour l'instant, car préciser ce que fait exactement chaque outil serait peut-être trop long. Cette suite a été créée en 2011. En 2012, Chaos Monkey a été rendu accessible au public.

En 2016, le « Gremlin » a été introduit par Kolton Andrus et Matthew Fornaciari et, fin 2017, il a été rendu public en tant que première solution CE d'entreprise managée au monde.

En 2019, CE est passé à de sérieuses considérations en matière d'adoption, principalement par le e-commerce et les grandes entreprises technologiques. Cela se comprend en raison de l'impact direct sur les revenus dû aux temps d'arrêt susceptibles de survenir.

En 2020, « Amazon Web Services » (AWS) a ajouté le CE au « Well-Architected Framework » (WAF) et le « Fault Injection Simulator » (FIS) a été introduit en tant que service permettant d'exécuter nativement des expériences de chaos sur AWS. Peu de temps après, certaines grandes entreprises ont commencé à adopter le Chaos Engineering.

En 2021, pour la toute première fois, Gremlin a publié le rapport State of Chaos Engineering démontrant l'importance du CE.

La réduction du temps moyen de résolution (MTTR) et du temps moyen de détection (MTTD), moins de bugs et une meilleure résilience du système sont les avantages identifiés dans une étude sur l'impact de l'ingénierie continue (CE) dans les entreprises ayant adopté cette approche.

Les outils que nous pouvons mentionner sont Chaos Mesh, Litmus, ChaosBlade, parmi les déjà mentionnés Gremlin, Simian Army et Chaos Monkey. D'autres outils sont également disponibles, mais je vous laisse le soin de les découvrir.

Le recours au Chaos Engineering peut indiquer que certaines entreprises utilisent une stratégie de test « shift left » placée aux tout premiers stades du cycle de vie du développement logiciel (SDLC).

Et enfin, voici comment mettre en place le CE selon les meilleures pratiques :

• Concevez la résilience du système aux niveaux de l'infrastructure, du réseau, des données, des applications, des personnes et de la culture.
• Utilisez des délais d'attente, des tentatives de reprise et des solutions de repli – des techniques adoptées par Netflix.
• Lorsque vous commencez à formuler une hypothèse, essayez la technique de la pensée computationnelle.
• Faites appel à l'équipe Chaos Engineering pour mettre en place tout ce qui est nécessaire au CE.
• Formez-vous et formez vos employés.
• Utilisez la stratégie de déploiement Canary et de tests Canary, car c'est la méthode la plus sûre pour injecter des défaillances et surveiller les résultats.

Adopter le Chaos Engineering peut générer un retour sur investissement (ROI) en matière de disponibilité et de fiabilité des services d'une entreprise.

J'espère que le développement logiciel futur utilisera les meilleures stratégies et pratiques disponibles et expliquées.

Résumé

Le Chaos Engineering est une approche disciplinée de test de la résilience logicielle consistant à introduire intentionnellement des défaillances contrôlées dans un système. Au lieu de s'appuyer uniquement sur les tests traditionnels, il aide les organisations à comprendre comment les applications se comportent sous la pression du monde réel, y compris les problèmes d'infrastructure, les perturbations réseau ou les pics de trafic inattendus. En exécutant des expériences dans des environnements surveillés, les équipes peuvent identifier les faiblesses précocement, améliorer la fiabilité du système et réduire le risque d'indisponibilité coûteuse en production.

Cette méthode est particulièrement précieuse pour les systèmes à grande échelle et à haute disponibilité, où les défaillances peuvent impacter le chiffre d'affaires, la réputation et la confiance des clients. Le Chaos Engineering favorise une meilleure réponse aux incidents, réduit le temps moyen de détection et de résolution, et renforce la stabilité globale du système. Adopté par des entreprises reconnues comme Netflix et AWS, il est devenu une pratique essentielle pour construire des systèmes logiciels modernes et résilients.