Comment « l'ingénierie du chaos » vous aide à éviter les temps d'arrêt imprévus

Ingénierie du chaos est une approche des tests de tolérance aux pannes logicielles qui provoque intentionnellement des erreurs dans les déploiements en direct. Il intègre un élément aléatoire pour imiter l'imprévisibilité de la plupart des pannes du monde réel.

L'idée d'ajouter du chaos à un système est généralement attribuée à Netflix. En 2011, la société a publié Chaos Monkey, un outil qu'elle a conçu pour désactiver certaines parties de son infrastructure de production. En provoquant des défaillances aléatoires dans des environnements surveillés, Netflix a découvert qu'il pouvait découvrir des problèmes cachés qui passaient inaperçus lors de tests réguliers.

L'ingénierie du chaos fournit un effet de réponse immunitaire. C'est similaire à la façon dont nous vaccinons les personnes en bonne santé. Vous introduisez délibérément une menace, causant potentiellement des problèmes brefs mais observables, afin de développer une résistance plus forte à long terme.

Construire la résilience

Il’ Il est prudent de supposer que tout système suffisamment volumineux contient des bogues que vous ne connaissez pas. Malgré tous vos tests automatisés et votre utilisation quotidienne dans le monde réel, vous ne pouvez pas tout saisir. Certains problèmes n'apparaissent que dans des scénarios très spécifiques, tels que la perte de connectivité à un service tiers.

L'ingénierie du chaos accepte que les problèmes d'exploitation imprévus seront toujours une réalité, même dans des environnements de production prétendument étanches. Considérant que de nombreuses organisations finissent par prendre un “attendre et voir” approche, en jouant à Whack-a-mole alors que de vrais rapports arrivent, l'ingénierie du chaos fonctionne sur le principe qu'une brève panne que vous invoquez est toujours meilleure qu'une que le client voit en premier.

Casser des objets volontairement vous permet de déterminer la résilience globale de votre système. Que se passe-t-il si la base de données tombe en panne ? Que diriez-vous d'une panne de votre service d'envoi d'e-mails tiers ? La plus grande force de l'ingénierie du chaos est sa capacité à reproduire des événements que les tests unitaires et l'utilisation du monde réel seuls ne couvrent généralement pas.

Les outils de test de chaos sont souvent exécutés sur des déploiements réels pour éliminer les écarts entre les environnements de développement et de production. Cependant, vous n'avez pas besoin d'appliquer autant de risques : tant que vous êtes sûr de pouvoir répliquer avec précision votre infrastructure, vous pouvez utiliser la technique dans un environnement de transfert en bac à sable.

Ajouter du chaos à vos systèmes

Vous avez plusieurs options si vous souhaitez ajouter un peu de chaos à votre infrastructure. Les outils automatisés conçus à cet effet constituent un point de départ mais peuvent être difficiles à intégrer dans votre propre infrastructure. Vous devez normalement vous intégrer à des plates-formes de gestion de VM ou de conteneurs afin que l'outil puisse interagir avec vos propres instances.

Dans le cas de Chaos Monkey, vous devez utiliser Spinnaker, la plate-forme de diffusion continue de Netflix. Bien qu'il soit largement compatible avec les fournisseurs de cloud public populaires, il s'agit également d'une autre dépendance que vous ajoutez à votre pile.

Si vous utilisez Kubernetes, kube-monkey reprend les principes d'origine de Netflix et les emballe pour une utilisation dans votre cluster. Cela fonctionne sur une base opt-in, donc les ressources Kubernetes avec l'étiquette kube-monkey/enabled seront éligibles pour une résiliation aléatoire.

Pumba fournit des fonctionnalités similaires pour les conteneurs Docker classiques. Cela peut provoquer des plantages de conteneurs, stresser les allocations de ressources telles que le processeur et la mémoire, et provoquer des pannes de réseau.

Un outil qui cible spécifiquement les erreurs de mise en réseau est Toxiproxy de Shopify. Cela fournit un proxy TCP qui simule un large éventail de conditions de réseau. Vous pouvez filtrer le trafic de votre application via Toxiproxy pour voir comment le système fonctionne avec une latence importante ou une bande passante réduite.

Pour un contrôle avancé, VMWare's Mangle est une ingénierie de chaos orchestrateur” qui cible plusieurs mécanismes de déploiement différents. Il fonctionne avec Kubernetes, Docker, VMware vCenter et les connexions SSH génériques. Mangle vous permet de définir des défauts personnalisés pour les composants d'application et d'infrastructure. Les défauts d'application doivent affecter un seul service. Les pannes d'infrastructure ciblent des composants partagés qui pourraient arrêter plusieurs services.

Alors que l'ingénierie du chaos est le plus souvent associée au développement back-end et au DevOps, les ingénieurs front-end s'y intéressent également de plus en plus. React Chaos est une bibliothèque qui lancera des erreurs aléatoires à partir des composants React, vous permettant d'identifier les sections d'interface utilisateur floconneuses qui pourraient faire planter toute votre application.

Concevoir votre propre Expériences de chaos

Si vous ne pouvez pas utiliser avec succès un outil de chaos open source, concevez plutôt vos propres expériences. Faites une liste des hypothèses dans l'environnement de votre application. Identifiez les liens entre les services et réfléchissez à ce qui se passerait si l'un d'eux abandonnait.

Vous devez ensuite tester votre hypothèse. Brisez le système et observez les conséquences. Ensuite, déterminez si l'effet était acceptable. L'application a-t-elle planté et affiché une trace de pile pour l'utilisateur ? Ou a-t-il affiché une page d'état de panne et envoyé la trace de la pile par e-mail à votre personnel de garde ?

Il est important de garder chaque test petit et concentré. Cela limite l'impact en cas d'arrêt de production et vous permet de vous assurer que le problème provient de l'hypothèse testée, et non d'une autre partie du système.

Assurez-vous toujours d'avoir une procédure de récupération claire avant de mener manuellement une expérience de chaos. Transformer une panne provoquée en panne réelle et imprévue est la dernière chose que vous souhaitiez. Si vous mettez fin à un service, n'oubliez pas le temps dont vous aurez besoin pour le redémarrer. Il pourrait y avoir des répercussions sur votre application lors de pannes plus longues : si vous abandonnez un service de distribution d'e-mails, il pourrait y avoir un arriéré à traiter lorsqu'il revient en ligne. Ces aspects doivent être intégrés dans votre plan d'action avant de commencer à travailler.

Une fois votre test terminé, vous devrez peut-être mettre à jour votre système avant de réexécuter le test. Tester votre correctif améliore réellement la situation et vous permet d'être sûr que votre système est désormais résilient à ce scénario spécifique.

Voici un résumé du processus d'expérimentation du chaos :

Développez une hypothèse : “Le système est résilient à une latence réseau accrue.”
Concevez une expérience ciblée : “Nous augmenterons artificiellement la latence à 500 ms sur 70 % des requêtes.” Assurez-vous d'avoir une stratégie de restauration et de récupération claire.
Exécutez le test :Observez l'impact sur votre application. Annulez dès que possible les modifications néfastes apportées aux environnements de production.
Analysez les résultats : si vous décidez que votre système n'était pas suffisamment résistant, mettez en œuvre des améliorations et répétez le processus.

Le côté non technique de l'ingénierie du chaos

L'ingénierie du chaos est normalement considérée comme une tâche technique pour les équipes de développement et d'exploitation & après tout, l' & “ingénierie” est dans le nom. Outre les rouages des réseaux et des services, il est également important de considérer le côté humain. Il est facile de penser que votre système ne dépend que d'une base de données, de quelques serveurs d'applications et d'un réseau stable. Ce n'est généralement pas le cas.

Pensez à la façon dont votre système réagirait si les membres de l'équipe n'étaient pas disponibles. Les connaissances sont-elles facilement accessibles si un administrateur doit prendre du recul de manière inattendue ? Surtout dans les petites organisations, il est courant pour une “équipe” être une personne seule. Que se passe-t-il si votre responsable réseau tombe malade lors d'une panne de courant ?

De la même manière que vous testez les aspects techniques en abandonnant les services, vous pouvez également anticiper des scénarios humains. Essayez d'exclure délibérément les personnes clés pendant que vous répétez une panne. Le reste de l'équipe a-t-il été en mesure de rétablir le service dans un état acceptable ? Si ce n'était pas le cas, il serait peut-être utile de documenter davantage le système et ses dépendances.

Résumé

Le terme “ingénierie du chaos” fait référence à la pratique consistant à casser délibérément des éléments en production pour découvrir des problèmes précédemment cachés. Bien que l'approche puisse sembler intimidante au départ, des outils dédiés comme Chaos Monkey peuvent vous aider à démarrer avec un risque minimal.

L'ajout de chaos est une technique utile, car elle permet de découvrir à la fois des problèmes transitoires et systémiques. Vous constaterez peut-être qu'une utilisation maximale de la mémoire a des répercussions sur votre infrastructure, mais que l'augmentation de la latence du réseau a un effet sporadique sur des parties spécifiques de votre pile.

L'utilisation efficace de l'ingénierie du chaos peut vous aider à trouver les bogues plus rapidement , avant que vos clients ne les remarquent. Il vous aide à renforcer la résilience de votre système en encourageant l'anticipation des problèmes. La plupart des équipes traitent toujours les problèmes de manière réactive, ce qui entraîne une augmentation du temps de cycle qui nuit à l'efficacité.

L'ingénierie du chaos est mieux traitée comme un état d'esprit plutôt que comme une procédure ou un produit logiciel spécifique. Si vous reconnaissez que les systèmes tendent vers le chaos, vous commencerez naturellement à prendre en charge la cuisson pour plus de “what-if” scénarios dans votre code.

Cela vaut toujours la peine de penser à l'“impossible” événements, comme une panne de centre de données ou une grave congestion du réseau. En réalité, ils ne sont pas impossibles, juste extrêmement rares. Lorsqu'ils surviennent, il s'agit probablement des événements les plus destructeurs rencontrés par votre système, à moins que votre infrastructure ne soit prête à les gérer avec des routines de secours.