„Chaos Engineering ist die Disziplin des Experimentierens an einem verteilten System, um Vertrauen in die Fähigkeit des Systems aufzubauen, turbulenten Bedingungen in der Produktion standzuhalten.“ — Prinzipien des Chaos Engineering

Netflix , Dropbox , Und Twilio sind alles Beispiele für Unternehmen, die diese Art von Engineering durchführen. Es ist wichtig, Vertrauen in große, robuste, verteilte Systeme zu haben. Bei PagerDuty haben wir Durchführen einer kontrollierten Fehlereinfügung in unsere Produktionsinfrastruktur seit mehreren Jahren. Im Laufe der Zeit und mit dem Wachstum unserer Infrastruktur haben sich auch unsere Chaos Engineering-Praktiken weiterentwickelt. Eine relativ neue Ergänzung ist ein automatisierter Fehlerinjektor, den wir ChaosCat nennen.

Hintergrund

Zu Beginn entschied sich das SRE-Team bei PagerDuty dafür, Fehler manuell in unsere Infrastruktur einzuschleusen, indem es SSH verwendete und Befehle pro Host ausführte. Dadurch konnten wir den Fehler präzise kontrollieren, schnell lernen und auftretende Probleme untersuchen und hohe Vorabinvestitionen in Werkzeuge vermeiden. Das funktionierte eine Zeit lang gut und ermöglichte uns den Aufbau einer Bibliothek gut verstandener und wiederholbarer Chaosangriffe wie hoher Netzwerklatenz, hoher CPU-Auslastung, Hostneustarts usw.

Wir wussten, dass manuelles Arbeiten nicht skalierbar war, also begannen wir mit der Zeit, Teile des Prozesses zu automatisieren. Zuerst wurden die einzelnen Befehle in Skripte umgewandelt, dann wurden sie automatisch an Hosts gesendet, anstatt per SSH zu kommunizieren, und so weiter und so fort. Sobald einzelne Teams begannen, besitzen ihre eigenen Dienste bei PagerDuty Dieses Tool ermöglichte ihnen die eigene Fehlerinjektion, ohne dass ein zentrales SRE-Team erforderlich war.

Wir hatten uns jedoch schon früh dafür entschieden, den Prozess der Fehlereinfügung den einzelnen Servicebesitzern im Voraus mitzuteilen. Das bedeutete, dass diese Besitzer jeden Freitag zumindest einigermaßen wussten, worauf sie achten mussten. Das bedeutete, dass sie einen Vorsprung bei der Behebung etwaiger Probleme hatten.

In der realen Welt gibt es selten Vorwarnungen für Ausfälle. Deshalb wollten wir das Element des Zufalls in die Infrastruktur einführen, indem wir eine Teilmenge von Angriffen nach dem Zufallsprinzip auf jedem Host ausführen lassen. Also begannen wir damit, zusätzliche Tools hinzuzufügen, um zufällig ausgewählte Hosts zu verwenden und Chaosangriffe auf sie auszuführen. Das letzte Puzzleteil war, alles nach einem automatisierten Zeitplan zusammenzufügen. Hier kommt ChaosCat ins Spiel.

Implementierung

ChaosCat ist ein Scala-basierter Slack-Chatbot. Er baut auf mehreren anderen Komponenten unserer Infrastruktur auf, wie zum Beispiel unserem Engine für verteilte Aufgabenausführung Es ist stark inspiriert von Chaos Monkey , aber eher dienstimplementierungsagnostisch, da wir in unserer Infrastruktur eine Vielzahl von Diensttypen haben.

Erstens läuft es als Always-On-Dienst. Das heißt, es kann für einmalige Läufe verwendet werden ( @chaoscat einmal ausführen ) jederzeit von jedem autorisierten Team ausgeführt werden. In der Zwischenzeit wird während Leerlaufzeiten jede Minute ein Zeitplan überprüft – wir möchten nur, dass zufällige Fehler während einer Teilmenge der Geschäftszeiten auftreten, wenn mit Sicherheit wache und einsatzbereite Techniker auf Abruf verfügbar sind.

Zweitens wird während der Geschäftszeiten geprüft, ob der Systemstatus einwandfrei ist. Wir möchten keinen Fehler einschleusen, wenn die allgemeine Integrität unseres Dienstes nicht 100 %ig ist.

Drittens feuert es einen zufällig ausgewählten Chaosangriff (wobei verschiedene Angriffe unterschiedliche Auswahlwahrscheinlichkeiten haben) auf einen zufälligen Host innerhalb unserer Infrastruktur ab (keine Ausnahmen zulässig, da alle Hosts in der realen Welt gleichermaßen anfällig für diese Probleme sind). Es sendet eine Aufgabe zum Ausführen des Chaosangriffs über das oben verlinkte Blender-Ausführungsframework unter Verwendung unseres internen Job-Runners.

Viertens wartet es 10 Minuten und führt dann die Schritte zwei und drei erneut aus, immer und immer wieder während einer Teilmenge der geplanten Geschäftszeiten. Wenn Probleme auftreten, können Angriffe immer von jedem gestoppt werden, indem er sendet @chaoscat, hör auf .

Erkenntnisse

Einige Teams haben schnell gelernt, dass es einen großen Unterschied macht, ob man mit allen Dashboards und Protokollen am Schreibtisch sitzt oder beim morgendlichen Kaffeetrinken plötzlich etwas schiefgeht. Diese Teams haben Lücken in ihren Runbooks und Bereitschaftsrotationen erkannt und behoben. Mit Erfolg!

Eine weitere interessante Sache: Wir haben festgestellt, dass die Teams, nachdem sie ihre anfängliche Unbehaglichkeit überwunden hatten, Korrekturen automatisierten, die zuvor manuell durchgeführt wurden, und technische Schulden in ihrem Backlog richtig priorisierten, da die Fehler, die sie verursachten, zuvor so selten waren. Dies wiederum führte dazu, dass diese Teams mehr Vertrauen in die Zuverlässigkeit ihrer Dienste hatten.

Leider ist ChaosCat stark an unsere internen Infrastrukturtools gebunden. Das bedeutet, dass wir es im Moment nicht als Open Source zur Verfügung stellen werden. Wir freuen uns jedoch über Ihr Feedback und Ihre Fragen dazu. Stellen Sie Ihre Fragen also gerne im PagerDuty Gemeinschaft Foren oder in den Kommentaren unten!

Wir hoffen, dass mehr Unternehmen diese Art des Zuverlässigkeits-Engineerings – oder wie manche es nennen, des Chaos-Engineerings – praktizieren. Es ist eine fantastische Möglichkeit, die Robustheit und das Verhalten zunehmend komplexer und vielfältiger Infrastrukturen zu überprüfen.