Chaos Engineering, Incidents und schuldfreies Lernen

Ausfälle absichtlich üben

Alles in diesem Kapitel war bisher ein Versprechen, wie sich das System verhält, wenn etwas schiefgeht: Timeouts werden auslösen, Circuit Breaker werden öffnen, Last wird abgeworfen, Replikate werden übernehmen, Alerts werden jemanden erreichen, der weiß, was zu tun ist. Kapitel 2 hat gewarnt, dass ein Failover, das nie geübt wurde, oft genau dann versagt, wenn es endlich gebraucht wird (Abschnitt 2.5). In diesem Abschnitt geht es darum, diese Versprechen in Belege zu verwandeln, und darum, wie Organisationen auf die Ausfälle reagieren, die trotzdem passieren, und aus ihnen lernen.

Zwei Praktiken gehören zusammen. Vor Ausfällen verursachen Chaos Engineering und Game Days absichtlich kleine, kontrollierte Ausfälle, um Schwachstellen zu finden und Menschen zu trainieren. Nach Ausfällen begrenzt das Incident-Management den Schaden, und schuldfreie Post-Incident-Reviews machen aus jedem Incident eine dauerhafte Verbesserung. Beide beruhen auf derselben Überzeugung: Komplexe Systeme sind immer teilweise kaputt, und Resilienz entsteht dadurch, früh und gefahrlos herauszufinden, wie.

Chaos Engineering

Chaos Engineering entstand aus der Migration von Netflix aus eigenen Rechenzentren zu Amazon Web Services, die nach einer schweren Datenbankbeschädigung im Jahr 2008 begann. Einzelne Cloud-Instanzen konnten jederzeit verschwinden, also baute Netflix Chaos Monkey, ein Werkzeug, das während der Geschäftszeiten zufällig Produktionsinstanzen beendete, wenn die Engineers an ihren Schreibtischen saßen, um daraus entstehende Probleme zu bemerken und zu beheben. Netflix beschrieb es zusammen mit einer Familie verwandter Werkzeuge namens Simian Army in einem Blogbeitrag im Juli 2011. Spätere Werkzeuge gingen weiter: Chaos Kong simulierte den Verlust einer ganzen AWS-Region, indem der Traffic daraus abgezogen wurde.

Engineers von Netflix und andere hielten die Disziplin später als Principles of Chaos Engineering fest (principlesofchaos.org, zuletzt 2019 überarbeitet), die sie definieren als das Experimentieren mit einem System, um Vertrauen in seine Fähigkeit aufzubauen, turbulenten Bedingungen in der Produktion standzuhalten. Das entscheidende Wort ist Experimentieren: Chaos Engineering heißt nicht, Dinge willkürlich kaputt zu machen, um zu sehen, was passiert, sondern die wissenschaftliche Methode auf Resilienz anzuwenden. Die Prinzipien nennen fünf Praktiken:

Eine Hypothese über das Verhalten im Steady State aufstellen. Wählen Sie eine messbare Ausgabe, die normalen Betrieb anzeigt, etwa aufgegebene Bestellungen pro Minute oder den Checkout-SLI, statt interner Metriken wie CPU. Die Steady-State-Hypothese sagt voraus, dass diese Ausgabe innerhalb ihrer Grenzen bleibt, während der Fehler injiziert wird. Reale Ereignisse variieren. Injizieren Sie die Fehler, die tatsächlich vorkommen: sterbende Instanzen, eine langsamer werdende Abhängigkeit, Paketverlust, eine volle Festplatte, ein abgelaufenes Zertifikat, Uhrenabweichung, eine Traffic-Spitze. Experimente in der Produktion durchführen. Nur die Produktion hat den echten Traffic, die echten Daten und die echte Konfiguration. Experimente automatisieren, damit sie kontinuierlich laufen. Ein einmaliges Experiment beweist Resilienz einmal; Systeme ändern sich täglich. Den Blast Radius minimieren. Beginnen Sie mit dem kleinsten Experiment, aus dem sich etwas lernen lässt (eine Instanz, ein kleiner Prozentsatz des Traffics), und halten Sie einen Abbruchschalter bereit.

Experimente in der Produktion durchzuführen ist das umstrittenste Prinzip. Seine Befürworter argumentieren, dass sich Staging-Umgebungen in Traffic, Daten, Größe und Konfiguration unterscheiden, sodass nur Experimente in der Produktion echte Schwachstellen aufdecken, und dass ein kleines, kontrolliertes Experiment um 15:00 für Benutzer weit schonender ist als derselbe Ausfall, der unkontrolliert um 03:00 eintritt. Kritiker weisen darauf hin, dass vielen Organisationen die Observability, die Automatisierung und das organisatorische Vertrauen fehlen, um das sicher zu tun. Der praktische Konsens ist ein schrittweises Vorgehen: in einer Staging-Umgebung beginnen, dann in der Produktion mit winzigem Blast Radius und automatischen, an SLOs geknüpften Abbruchbedingungen laufen lassen und nur mit wachsendem Vertrauen erweitern. Beginnen Sie nie mit einem System, von dem Sie bereits wissen, dass es fragil ist; beheben Sie zuerst die bekannten Schwachstellen, denn ein Experiment, dessen Ergebnis Sie vorhersagen können, lehrt nichts.

Werkzeuge sind inzwischen breit verfügbar: Cloud-Anbieter bieten verwaltete Fault Injection an (AWS Fault Injection Service, Azure Chaos Studio), Chaos Mesh und LitmusChaos sind Open-Source-Projekte der CNCF für Kubernetes, und kommerzielle Plattformen wie Gremlin bieten Bibliotheken von Angriffen mit Sicherheitskontrollen. Service Meshes und Proxys können Latenz und Fehler in einen Prozentsatz der Aufrufe injizieren, ohne den Anwendungscode anzufassen. Die Werkzeuge sind der leichte Teil; der schwere Teil ist, aussagekräftige Hypothesen zu wählen und auf die Ergebnisse zu reagieren.

Game Days

Ein Game Day ist eine geplante Übung, bei der ein Team absichtlich einen erheblichen Ausfall verursacht oder simuliert und die Reaktion darauf übt. Jesse Robbins machte die Praxis bei Amazon bekannt, wo seine Berufsbezeichnung Berichten zufolge Master of Disaster lautete. Google führt große Übungen namens Disaster Recovery Testing (DiRT) durch, und sein SRE-Buch beschreibt das Wheel of Misfortune, ein Rollenspiel, in dem Engineers in Rufbereitschaft einen vergangenen Incident durchspielen, während ein Spielleiter enthüllt, was das Monitoring gezeigt hätte.

Game Days testen mehr als Software. Sie testen, ob Alerts die richtigen Personen erreichen, ob die Menschen um 03:00 die nötigen Zugänge haben, ob Runbooks aktuell sind, ob das Failover-Verfahren tatsächlich funktioniert, ob sich Backups wiederherstellen lassen und ob der Kommunikationsplan die Kunden erreicht. Ein typischer Game Day bei der Essenslieferplattform könnte an einem ruhigen Nachmittag die Bestelldatenbank auf ihren Standby umschalten, während die gesamte Rufbereitschaftsrotation zusieht, ein Moderator Überraschungen einstreut (die Person, die das Runbook kennt, ist im Urlaub) und ein Beobachter jede Verzögerung und Verwirrung für das anschließende Review notiert. Vor einem großen Ticket-Vorverkaufsstart könnte dasselbe Team proben, wie der Zahlungsanbieter ausfällt und mitten im Verkauf auf den Ersatzanbieter umgeschaltet wird.

Incident-Management

Ein Incident ist ein ungeplantes Ereignis, das einen Dienst stört oder zu stören droht und eine koordinierte Reaktion erfordert. Incident-Management ist die Praxis, diese Reaktion so zu führen, dass sie schnell, ruhig und gut kommuniziert ist. Die meiste moderne Praxis lehnt sich an das Incident Command System an, das in den 1970er-Jahren in Kalifornien für die Bekämpfung von Waldbränden entwickelt und im Kapitel des Google-SRE-Buchs über das Management von Incidents für Software angepasst wurde.

Der zentrale Gedanke ist die Trennung der Rollen. Der Incident Commander ist für den Incident verantwortlich: Er setzt Prioritäten, vergibt Rollen, trifft Entscheidungen und behält den Überblick, und er debuggt bewusst nicht, denn ein Commander, der in einer Logdatei versunken ist, führt nicht. Die Betriebsleitung und die Responder diagnostizieren und dämmen ein. Die Kommunikationsleitung ist die einzige Stimme gegenüber allen außerhalb der Reaktion: Support-Teams, Führungskräften und Kunden über die Statusseite, mit Updates im zugesagten Rhythmus, auch wenn es nichts Neues gibt. Ein Protokollführer hält Zeitablauf, Entscheidungen und Hypothesen fest. In einem kleinen Unternehmen kann eine Person mehrere Rollen innehaben, aber die Rollen sollten trotzdem benannt werden. Bei Schichtwechseln werden Rollen ausdrücklich übergeben.

Einige Gewohnheiten machen den Unterschied. Rufen Sie Incidents früh und ohne großen Aufwand aus: Es ist besser, einen Fehlalarm abzublasen, als nach einer Stunde festzustellen, dass drei Teams getrennt voneinander dasselbe Problem debuggt haben. Ordnen Sie jedem Incident einen Schweregrad zu, der nach den Auswirkungen auf Benutzer definiert ist, nicht nach der Ursache, damit alle wissen, wen sie rufen und wie breit sie kommunizieren müssen. Dämmen Sie ein, bevor Sie diagnostizieren: Rollen Sie zuerst das letzte Deployment zurück, schalten Sie per Failover um, schalten Sie das Feature-Flag ab oder werfen Sie Last ab, und finden Sie das Warum später heraus. Nutzen Sie einen einzigen Incident-Kanal. Und denken Sie an externe Pflichten: Eine Verletzung des Schutzes personenbezogener Daten muss nach der DSGVO unter Umständen binnen 72 Stunden der Aufsichtsbehörde gemeldet werden, weshalb Sicherheitsvorfälle dem zugehörigen Prozess in Abschnitt 8.8 folgen.

Schuldfreie Post-Incident-Reviews

Nach dem Incident kommt der wertvollste Teil: das Lernen. Ein Post-Incident-Review (oft Postmortem genannt) rekonstruiert, was passiert ist, warum es den Beteiligten damals sinnvoll erschien und was sich ändern wird. Das Kapitel des Google-SRE-Buchs über Postmortem-Kultur legt die Erwartungen fest: eine schriftliche Aufzeichnung für jeden erheblichen Incident, die Auswirkungen, Zeitablauf, beitragende Ursachen und Folgemaßnahmen abdeckt, geprüft und geteilt wird und ohne Schuldzuweisung verfasst ist.

John Allspaws Beitrag Blameless PostMortems and a Just Culture aus dem Jahr 2012, geschrieben, als er bei Etsy den technischen Betrieb leitete, erklärt, warum Blameless Culture (Schuldfreiheit) praktisch und nicht nur freundlich ist. Engineers, die mit Bestrafung rechnen, hören auf, vollständig zu berichten, was sie gesehen und getan haben, sodass die Organisation genau die Informationen verliert, die sie braucht, um den nächsten Incident zu verhindern. Allspaw stützt sich auf die Sicherheitswissenschaft, darunter Sidney Dekkers Arbeiten zur Just Culture, und auf die Idee der zweiten Geschichten: Die erste Geschichte sagt ein Engineer hat den falschen Befehl ausgeführt; die zweite fragt, warum der Befehl so leicht auszuführen war, warum das Werkzeug nicht gewarnt hat, warum das Vorgehen unter Zeitdruck vernünftig erschien, und findet Bedingungen, die auch die nächste Person in die Falle locken werden. Schuldfrei heißt nicht folgenlos: Von den Menschen wird weiterhin erwartet, vollständig Rechenschaft abzulegen, und die Organisation ist dafür verantwortlich, die Bedingungen zu beheben.

Gute Reviews vermeiden den Rückschaufehler (das Ergebnis war damals nicht offensichtlich), kontrafaktische Aussagen (hätte sollen, hat es versäumt) und die Suche nach einer einzigen Grundursache. Richard Cooks kurzer Aufsatz How Complex Systems Fail (1998) argumentiert, dass bei schweren Ausfällen in komplexen Systemen mehrere Mängel zusammenkommen müssen, sodass es keine einzelne Grundursache gibt, nur beitragende Faktoren. Eine Five-Whys-Kette, die bei menschlichem Versagen endet, hat zu früh aufgehört. Halten Sie auch fest, was gut lief: Die Expertise und Improvisation, die den Schaden begrenzt haben, gehören dazu, wie das System wirklich in Betrieb bleibt, und sie bleiben unsichtbar, wenn niemand sie festhält.

Aus Incidents lernen, und die Grenzen von MTTR

Organisationen wollen natürlich eine Zahl, die zeigt, ob sich die Incident Response verbessert, und die Mean Time to Recovery (MTTR) ist der übliche Kandidat. Kapitel 2 verwendete MTTR in A = MTBF / (MTBF + MTTR), wo sie für eine einzelne Komponente mit wiederholbaren Ausfällen aussagekräftig ist. Als organisatorische Kennzahl über viele verschiedene Incidents hinweg ist sie viel schwächer. Die Dauern von Incidents sind stark schief verteilt: Die meisten sind kurz und einige wenige sehr lang, sodass der Mittelwert von einer Handvoll Ausreißern dominiert wird. Courtney Nashs Analysen Tausender öffentlicher Incident-Berichte in der Verica Open Incident Database (VOID-Berichte ab 2021) fanden genau diese Schiefe, und ein Google-Bericht von Štěpán Davidovič aus dem Jahr 2021, Incident Metrics in SRE, zeigte mit Simulationen, dass Veränderungen der MTTR bei realistischen Incident-Zahlen überwiegend Rauschen sind und nicht verlässlich zeigen können, ob eine Verbesserung gewirkt hat.

Bessere Signale sind die Auswirkungen auf SLOs und Error Budgets (die Incidents danach gewichten, was Benutzer gespürt haben), wiederkehrende Themen über Reviews hinweg (dieselbe Art von Konfigurationsänderung, die dreimal Ärger macht), Beinahe-Vorfälle, wie schnell Incidents erkannt werden, wie oft Reviews zu abgeschlossenen Systemänderungen führen, und qualitative Belege, etwa ob Engineers Reviews nützlich finden. Viele Organisationen veröffentlichen Reviews intern in einer durchsuchbaren Bibliothek und halten regelmäßige Incident-Review-Meetings ab, damit die Lehre eines Teams auch andere erreicht.

Maßnahmen, die das System tatsächlich ändern

Ein Review ist nur so viel wert wie die Änderungen, die es bewirkt. Maßnahmen unterscheiden sich stark in ihrer Wirkung. Am stärksten sind solche, die die Gefahr beseitigen (den gefährlichen Befehl löschen, den unsicheren Zustand unmöglich machen), dann Leitplanken, die verhindern, dass sich der Fehler ausbreitet (Validierung der Konfiguration, gestaffelte Rollouts und Canaries, Rate Limits für Änderungen, automatischer Rollback bei SLO-Verbrauch), dann schnellere Erkennung und Eindämmung (ein neuer SLO-Alert, ein getestetes Runbook, ein automatisiertes Failover). Am schwächsten sind Schulungen, Dokumentation und Ermahnungen. Sorgfältiger sein ist keine Maßnahme; es ändert nichts an den Bedingungen, auf die die nächste Person treffen wird.

Jede Maßnahme braucht eine verantwortliche Person, eine Priorität und einen Fälligkeitstermin und muss im normalen Backlog des Teams stehen statt in einem vergessenen Dokument. Die Error-Budget-Policy aus Abschnitt 9.5 liefert den Hebel: Ein Incident, der einen großen Teil des Budgets verbraucht hat, verschafft seinen Korrekturen Vorrang vor Features. Halten Sie die Liste kurz; fünf erledigte Maßnahmen sind besser als zwanzig offene. Wo eine Maßnahme die Architektur ändert, etwa durch ein zusätzliches Bulkhead oder das Entfernen einer synchronen Abhängigkeit, halten Sie sie in einem Architecture Decision Record fest, der den Incident nennt, und verlinken Sie die relevanten Runbooks aus den Alerts, die beim nächsten Mal auslösen.