„Chaos Engineering ist die Disziplin, die an einem verteilten System experimentiert, um Vertrauen in die Fähigkeit des Systems zu gewinnen, turbulenten Produktionsbedingungen standzuhalten.“ Prinzipien des Chaos Engineering

Netflix , Dropbox , Und Twilio sind alles Beispiele für Unternehmen, die diese Art von Entwicklung durchführen. Es ist unerlässlich, Vertrauen in große, robuste, verteilte Systeme zu haben. Wir bei PagerDuty haben... Durchführung kontrollierter Fehlereinspeisung in unsere Produktionsinfrastruktur Seit mehreren Jahren. Mit der Zeit und dem Wachstum unserer Infrastruktur haben sich auch unsere Chaos-Engineering-Praktiken weiterentwickelt. Eine relativ neue Ergänzung ist ein automatisierter Fehlerinjektor namens ChaosCat.

Hintergrund

Anfangs entschied sich das SRE-Team von PagerDuty bewusst dafür, Fehler manuell in unsere Infrastruktur einzuschleusen, indem wir uns per SSH verbanden und Befehle pro Host ausführten. Dadurch hatten wir die Fehler präzise unter Kontrolle, konnten auftretende Probleme schnell erkennen und untersuchen und hohe Vorabinvestitionen in Tools vermeiden. Diese Methode funktionierte eine Zeit lang gut und ermöglichte es uns, eine Bibliothek gut verstandener und reproduzierbarer Chaos-Angriffe aufzubauen, wie z. B. hohe Netzwerklatenz, hohe CPU-Auslastung, Host-Neustarts usw.

Uns war klar, dass manuelle Prozesse nicht skalierbar sein würden, daher begannen wir im Laufe der Zeit, Teile des Prozesses zu automatisieren. Zuerst wurden die einzelnen Befehle in Skripte umgewandelt, dann wurde deren Ausführung an die Hosts automatisiert, anstatt SSH-Verbindungen herzustellen, und so weiter. Sobald die einzelnen Teams damit begannen, PagerDuty besitzt seine eigenen Dienste Mithilfe dieser Tools konnten sie ihre eigenen Fehlereinspeisungen durchführen, ohne ein zentrales SRE-Team zu benötigen.

Wir hatten uns jedoch frühzeitig dafür entschieden, den Prozess der Fehlersimulation den einzelnen Serviceverantwortlichen im Voraus mitzuteilen. Dadurch wussten diese jeden Freitag zumindest ansatzweise, worauf sie achten mussten, und konnten so eventuelle Probleme frühzeitig beheben.

Da Ausfälle in der realen Welt selten angekündigt werden, wollten wir den Zufall in die Infrastruktur einbeziehen, indem wir eine Auswahl von Angriffen zufällig auf beliebigen Hosts ermöglichten. Daher begannen wir, zusätzliche Tools zu entwickeln, um zufällig Hosts auszuwählen und Chaos-Angriffe darauf durchzuführen. Das letzte Puzzleteil war die Automatisierung des gesamten Prozesses. Hier kommt ChaosCat ins Spiel.

Durchführung

ChaosCat ist ein Scala-basierter Slack-Chatbot. Er baut auf mehreren anderen Komponenten unserer Infrastruktur auf, wie zum Beispiel unserem verteilte Aufgabenausführungs-Engine Es ist stark inspiriert von Chaosaffe , aber eher serviceimplementierungsagnostisch, da wir in unserer Infrastruktur eine Vielzahl von Servicetypen haben.

Erstens läuft es als permanent aktiver Dienst. Das bedeutet, dass es für einmalige Ausführungen verwendet werden kann ( @chaoscat run-once ) jederzeit von jedem autorisierten Team. Während der Leerlaufzeiten wird der Zeitplan minütlich überprüft – wir möchten, dass zufällige Fehler nur während eines Teils der Geschäftszeiten auftreten, wenn mit Sicherheit diensthabende Techniker verfügbar sind.

Zweitens wird während der Geschäftszeiten geprüft, ob der Systemstatus einwandfrei ist. Wir wollen keinen Fehler auslösen, wenn die allgemeine Funktionsfähigkeit unseres Dienstes nicht hundertprozentig gegeben ist.

Drittens wird ein zufällig ausgewählter Chaosangriff (mit unterschiedlichen Auswahlwahrscheinlichkeiten für verschiedene Angriffe) auf einen zufällig ausgewählten Host innerhalb unserer Infrastruktur gestartet (Ausnahmen sind nicht zulässig, da alle Hosts in der realen Welt gleichermaßen anfällig für diese Probleme sind). Der Chaosangriff wird über das oben verlinkte Blender-Ausführungsframework mithilfe unseres internen Job-Runners ausgeführt.

Viertens wartet es 10 Minuten und führt dann die Schritte zwei und drei während eines Teils der geplanten Geschäftszeiten wiederholt aus. Sollten Probleme auftreten, können Angriffe jederzeit von jedem durch Senden einer Nachricht gestoppt werden. @chaoscat Stopp Die

Erkenntnisse

Manche Teams erkannten schnell, dass es einen himmelweiten Unterschied macht, ob man mit allen Dashboards und Protokollen bestens vorbereitet ist oder ob beim morgendlichen Kaffee etwas schiefgeht. Diese Teams identifizierten Lücken in ihren Betriebshandbüchern und Bereitschaftsplänen und behoben sie. Erfolg!

Eine weitere interessante Beobachtung: Nachdem die Teams ihre anfängliche Unsicherheit überwunden hatten, automatisierten sie zuvor manuell durchgeführte Fehlerbehebungen und priorisierten die technischen Schulden in ihrem Backlog korrekt, da die dafür verantwortlichen Fehler zuvor nur selten aufgetreten waren. Dies wiederum stärkte das Vertrauen der Teams in die Zuverlässigkeit ihrer Dienste.

Leider ist ChaosCat stark in unsere internen Infrastruktur-Tools eingebunden. Daher werden wir es vorerst nicht als Open Source veröffentlichen. Wir freuen uns aber über Ihr Feedback und Ihre Fragen dazu. Stellen Sie diese also gerne im entsprechenden Forum. PagerDuty Community In Foren oder in den Kommentaren unten!

Wir hoffen, dass mehr Unternehmen damit beginnen, diese Art von Zuverlässigkeitstechnik – oder wie manche sagen, Chaos-Engineering – anzuwenden. Es ist eine fantastische Methode, um die Robustheit und das Verhalten zunehmend komplexer und vielfältiger Infrastrukturen zu überprüfen.