« L’ingénierie du chaos est la discipline qui consiste à expérimenter sur un système distribué afin de renforcer la confiance dans la capacité du système à résister aux conditions turbulentes de la production. » Principes de l'ingénierie du chaos

Netflix , Dropbox , et Twilio Ce sont là autant d'exemples d'entreprises qui réalisent ce type de travaux d'ingénierie. Il est essentiel d'avoir confiance dans les systèmes distribués, vastes et robustes. Chez PagerDuty, nous… effectuer une injection de panne contrôlée dans notre infrastructure de production Depuis plusieurs années, nos pratiques d'ingénierie du chaos ont évolué au fil du temps et de la croissance de notre infrastructure. Parmi les ajouts récents, citons un injecteur de pannes automatisé, que nous appelons ChaosCat.

Arrière-plan

Au départ, l'équipe SRE de PagerDuty a délibérément choisi d'injecter manuellement des défaillances dans notre infrastructure, via SSH et l'exécution de commandes sur chaque hôte. Cette méthode nous a permis de contrôler précisément la défaillance, d'identifier et d'analyser rapidement les problèmes rencontrés, et d'éviter un investissement initial important dans des outils. Cette approche a bien fonctionné pendant un certain temps et nous a permis de constituer une bibliothèque d'attaques chaotiques bien comprises et reproductibles, telles que des latences réseau élevées, une utilisation CPU importante, des redémarrages d'hôtes, etc.

Nous savions que les tâches manuelles ne permettraient pas de les gérer à grande échelle, alors au fil du temps, nous avons commencé à automatiser certaines parties du processus. Dans un premier temps, les commandes individuelles ont été transformées en scripts, puis leur envoi aux hôtes a été automatisé au lieu d'utiliser SSH, et ainsi de suite. Une fois que les différentes équipes ont commencé à… ils possèdent leurs propres services chez PagerDuty Cet outil leur a permis de réaliser leur propre injection de pannes sans avoir besoin d'une équipe SRE centrale.

Cependant, dès le départ, nous avions choisi de communiquer à l'avance aux responsables de chaque service le processus d'injection des défauts. Ainsi, chaque vendredi, ces responsables étaient au moins partiellement informés des problèmes à surveiller, ce qui leur permettait d'anticiper leur résolution.

Dans la réalité, les pannes sont rarement annoncées à l'avance. Nous souhaitions donc introduire une part d'aléatoire dans l'infrastructure, en autorisant l'exécution aléatoire d'un sous-ensemble d'attaques sur n'importe quel hôte. Nous avons donc commencé à ajouter des outils pour sélectionner des hôtes aléatoires et y mener des attaques chaotiques. La dernière étape consistait à automatiser le tout. C'est ainsi qu'est né ChaosCat.

Mise en œuvre

ChaosCat est un chatbot Slack basé sur Scala. Il s'appuie sur plusieurs autres composants de notre infrastructure, tels que notre moteur d'exécution de tâches distribuées Il est fortement inspiré par Singe du Chaos mais plus indépendant de l'implémentation des services, car notre infrastructure comprend une variété de types de services.

Premièrement, il fonctionne comme un service toujours actif. Cela signifie qu'il peut être utilisé pour des exécutions ponctuelles ( @chaoscat exécuter une seule fois ) à tout moment par n'importe quelle équipe autorisée. Entre-temps, pendant les périodes d'inactivité, une planification est vérifiée chaque minute ; nous souhaitons que les pannes aléatoires ne soient injectées que pendant une partie des heures ouvrables où il est certain qu'il y a des ingénieurs d'astreinte disponibles et prêts à intervenir.

Deuxièmement, pendant les heures ouvrables, le système vérifie que son état est optimal. Nous ne voulons pas provoquer de panne si l'état général de notre service n'est pas parfait.

Troisièmement, il déclenche une attaque chaotique choisie aléatoirement (chaque attaque ayant une probabilité de sélection différente) contre un hôte aléatoire de notre infrastructure (aucune exception n'est permise, car tous les hôtes sont également vulnérables à ces problèmes en conditions réelles). Il envoie une tâche pour exécuter l'attaque chaotique via le framework d'exécution Blender mentionné ci-dessus, à l'aide de notre système d'exécution de tâches interne.

Quatrièmement, le système attend 10 minutes, puis exécute à nouveau les étapes deux et trois, et ce, de manière répétée pendant une partie des heures ouvrables prévues. En cas de problème, les attaques peuvent être stoppées par n'importe qui en envoyant @chaoscat arrête .

Leçons apprises

Certaines équipes ont rapidement compris qu'il y a un monde de différence entre être prêt à intervenir, tous tableaux de bord et journaux d'activité à portée de main, et subir un incident pendant qu'on prend son café du matin. Ces équipes ont identifié les lacunes de leurs procédures et de leurs rotations d'astreinte et les ont corrigées. Pari réussi !

Autre constat intéressant : nous avons observé qu’une fois leur appréhension initiale surmontée, les équipes automatisaient les correctifs auparavant manuels et priorisaient correctement les éléments de dette technique dans leur backlog, car les défaillances à l’origine de ces éléments étaient auparavant très rares. De ce fait, ces équipes ont acquis une plus grande confiance dans la fiabilité de leurs services.

Malheureusement, ChaosCat est fortement intégré à nos outils d'infrastructure internes. Pour le moment, cela signifie que nous ne le rendrons pas open source. Cependant, nous serions ravis de recevoir vos commentaires et questions à ce sujet, alors n'hésitez pas à les poser dans le forum. Communauté PagerDuty forums ou dans les commentaires ci-dessous !

Nous espérons que davantage d'entreprises commenceront à pratiquer ce type d'ingénierie de la fiabilité — ou, comme certains aiment à le dire, l'ingénierie du chaos — car c'est un excellent moyen de vérifier la robustesse et le comportement d'infrastructures de plus en plus complexes et diversifiées.