« 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 à des conditions turbulentes en production. » — Principes de l'ingénierie du chaos

Netflix , Dropbox , et Twilio sont autant d'exemples d'entreprises qui effectuent ce type d'ingénierie. Il est essentiel d'avoir confiance dans des systèmes distribués de grande taille et robustes. Chez PagerDuty, nous sommes effectuer une injection de fautes contrôlée dans notre infrastructure de production Depuis plusieurs années, le temps a passé et notre infrastructure s'est développée, tout comme nos pratiques d'ingénierie du chaos. Un ajout récent est un injecteur de défauts automatisé, que nous appelons ChaosCat.

Arrière-plan

Au début, l'équipe SRE de PagerDuty a spécifiquement choisi d'injecter les pannes dans notre infrastructure manuellement, via SSH et en exécutant des commandes par hôte. Cela nous a permis d'avoir un contrôle précis sur la panne, d'apprendre et d'enquêter rapidement sur les problèmes qui survenaient et d'éviter de lourds investissements initiaux dans les outils. Cela a bien fonctionné pendant un certain temps et nous a permis de constituer une bibliothèque d'attaques du chaos bien comprises et répétables telles qu'une latence réseau élevée, une utilisation élevée du processeur, des redémarrages d'hôte, etc.

Nous savions que faire les choses manuellement ne serait pas efficace, donc au fil du temps, nous avons commencé à automatiser certaines parties du processus. Tout d'abord, les commandes individuelles ont été transformées en scripts, puis leur envoi automatisé aux hôtes au lieu de SSH, et ainsi de suite. Une fois que les équipes individuelles ont commencé à possèdent leurs propres services sur PagerDuty , cet outillage leur a permis de réaliser leur propre injection de fautes sans avoir besoin d'une équipe SRE centrale.

Cependant, nous avions choisi dès le début de faire connaître à l'avance le processus d'injection des défauts aux propriétaires de services individuels. Cela signifiait que chaque vendredi, ces propriétaires seraient au moins quelque peu conscients de ce qu'ils devaient rechercher. Ce qui signifiait qu'ils auraient une longueur d'avance pour résoudre les problèmes éventuels.

Le monde réel prévient rarement à l'avance des échecs, c'est pourquoi nous avons voulu introduire l'élément de hasard dans l'infrastructure, en permettant à un sous-ensemble d'attaques d'être exécutées de manière aléatoire sur n'importe quel hôte. Nous avons donc commencé à ajouter des outils supplémentaires pour sélectionner des hôtes aléatoires et exécuter des attaques de chaos sur eux. La dernière pièce du puzzle consistait à mettre tout cela ensemble selon un calendrier automatisé. C'est là qu'est entré 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 la mise en œuvre du service, car nous avons une variété de types de services dans notre infrastructure.

Tout d'abord, il fonctionne comme un service toujours actif. Cela signifie qu'il peut être utilisé pour des exécutions ponctuelles ( @chaoscat exécuté une fois ) à tout moment par n'importe quelle équipe autorisée. En attendant, pendant les périodes d'inactivité, un planning est vérifié toutes les minutes — nous voulons seulement que des pannes aléatoires soient injectées pendant un sous-ensemble d'heures ouvrables où il est certain qu'il y aura des ingénieurs de garde éveillés et prêts.

Deuxièmement, une fois les heures ouvrables écoulées, il vérifie si l'état du système est correct. Nous ne voulons pas provoquer une panne si l'état général de notre service n'est pas à 100 %.

Troisièmement, il déclenche une attaque de chaos choisie au hasard (les différentes attaques ayant des probabilités de sélection différentes) sur un hôte aléatoire au sein de notre infrastructure (aucune exemption n'est autorisée, car tous les hôtes sont également vulnérables à ces problèmes dans le monde réel). Il envoie une tâche pour exécuter l'attaque de chaos via le framework d'exécution Blender lié ci-dessus, en utilisant notre exécuteur de tâches interne.

Quatrièmement, il attend 10 minutes, puis exécute à nouveau les étapes deux et trois, encore et encore, pendant un sous-ensemble d'heures ouvrables programmées. Si des problèmes surviennent, les attaques peuvent toujours être arrêtées par n'importe qui en envoyant @chaoscat arrête .

Apprentissages

Certaines équipes ont rapidement compris qu'il y avait une différence énorme entre rester assis à table avec tous ses tableaux de bord et journaux ouverts et avoir un problème pendant que vous prenez votre café du matin. Ces équipes ont identifié des lacunes dans leurs carnets d'exécution et leurs rotations d'astreinte et les ont corrigées. Succès !

Autre chose intéressante : nous avons constaté qu'une fois que les équipes ont surmonté leur malaise initial, elles ont automatisé les correctifs qui étaient auparavant effectués manuellement et ont hiérarchisé correctement les éléments de dette technique dans leur backlog, car les pannes qui les causaient étaient auparavant si rares. Cela a permis à ces équipes d'avoir davantage confiance dans la fiabilité de leurs services.

Malheureusement, ChaosCat est étroitement lié à notre infrastructure interne. Pour le moment, cela signifie que nous ne le publierons pas en open source. Cependant, nous aimerions connaître votre avis et vos questions à ce sujet, alors n'hésitez pas à nous le demander dans le Communauté PagerDuty forums ou dans les commentaires ci-dessous !

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