Kapitel 4. Slacks Katastrophentheater

Diese Arbeit wurde mithilfe von KI übersetzt. Wir freuen uns über dein Feedback und deine Kommentare: translation-feedback@oreilly.com

Richard Crowley

Wie kommst du ins Chaos Engineering, wenn dein Team und deine Werkzeuge nicht damit geboren wurden? Es kann wie eine überwältigende und unüberwindbare Aufgabe erscheinen, Chaos in Systeme einzubauen, die mit der Denkweise entwickelt wurden, dass Computer eine lange Lebensdauer haben können und sollten. Komplexe Systeme, die mit dieser Denkweise entwickelt wurden, sind in der Regel weniger anpassungsfähig an die extreme Vergänglichkeit der zugrunde liegenden Computer als ihre cloudbasierten Nachfolger. Solche Systeme sind unter optimalen Bedingungen wahrscheinlich sehr leistungsfähig, aber im Falle eines Ausfalls lassen sie schnell nach und sind manchmal katastrophal.

Vielleicht bist du der stolze Besitzer eines solchen Systems. Es wurde nicht für das Chaos entwickelt, aber ob es dir gefällt oder nicht, das Chaos wird kommen, denn es wird immer größer und muss immer mehr, schneller und zuverlässiger werden. Es ist keine Zeit für eine Neufassung - das System steht bereits unter Druck. Die Anwendung neuer Chaos-Engineering-Praktiken auf alte Systeme wird die Situation nur noch verschlimmern. Du brauchst eine andere Strategie.

In diesem Kapitel wird eine Strategie beschrieben, mit der du komplexe Systeme, die nicht unbedingt mit Chaos Engineering im Hinterkopf entworfen wurden, sicher und systematisch testen kannst, indem du Fehler und Netzwerkabtrennungen auf durchdachte und kontrollierte Weise einführst. Es handelt sich dabei um einen Prozess, der nicht automatisiert ist, sondern deinem Team hilft, die Anfälligkeit deiner Software zu verstehen, Verbesserungen zu motivieren und zu überprüfen, ob die Systeme die vorhersehbaren Fehler verkraften. Dieser Prozess wird bei Slack seit Anfang 2018 aktiv genutzt. In mehr als zwanzig Übungen hat er Schwachstellen aufgedeckt, die Sicherheit von neuen und alten Systemen bewiesen und die Roadmaps vieler Entwicklungsteams beeinflusst.

Der erste Schritt besteht jedoch darin, sicherzustellen, dass die fraglichen Systeme auch theoretisch bereit sind, die Art von Fehlern zu tolerieren, die du erwartest.

Chaos nachrüsten

Die Werkzeuge und Techniken, die du einsetzen kannst, um ein System fehlertoleranter zu machen, sind die gleichen, die du auch einsetzen kannst, um es zu modernisieren, es Cloud-nativ zu machen, es zuverlässiger zu machen oder es hochverfügbar zu machen. Schauen wir uns das mal an.

Gemeinsame Entwurfsmuster in älteren Systemen

Bestehende Systeme, vor allem ältere, gehen eher davon aus, dass einzelne Computer eine lange Lebensdauer haben als neue Systeme, die heute gebaut werden. Diese einfache Annahme ist der Kern vieler Systeme, die fehlerintolerant sind. Wir haben diese Annahme in einer Zeit gemacht, in der Ersatzcomputer vermieden werden sollten - das war Verschwendung - und sie hat sich seither in unserem Systemdesign gehalten.

Als Computer noch rar waren, wurden sie wahrscheinlich kurz nach dem Kauf mit einem Betriebssystem und allem Drum und Dran ausgestattet und während ihrer gesamten Nutzungsdauer aktualisiert. Der Bereitstellungsprozess konnte stark automatisiert sein, vor allem wenn viele Computer auf einmal auf der Laderampe auftauchten, aber der Start dieses Prozesses erfolgte wahrscheinlich manuell. Bei kleineren Installationen war es nicht ungewöhnlich, dass ein Großteil des Bereitstellungsprozesses manuell durchgeführt wurde.

Auch der Failover war in der Regel eine manuelle Aktion, die von einem Menschen durchgeführt wurde, der dies als angemessene Reaktion auf einen Fehler oder eine Abweichung vom Normalbetrieb erachtete. In besonders alten Systemen war der Zeitraum zwischen dem Fehler und dem Failover ein Ausfall, der den Kunden zugemutet wurde. Man ging davon aus, dass ein Failover selten vorkommt, sodass sich Automatisierung und in manchen Fällen sogar Dokumentation und Schulung nicht lohnen.

Sicherung und Wiederherstellung ist ein weiterer Bereich, in dem die bestehenden Systeme hinter dem Stand der Technik zurückbleiben können. Positiv zu vermerken ist, dass mit ziemlicher Sicherheit Backups erstellt werden. Es ist jedoch nicht so sicher, dass diese Sicherungen wiederhergestellt werden können oder dass sie schnell wiederhergestellt werden können. Wie bei der Ausfallsicherung war auch die Wiederherstellung von Backups früher ein seltenes Ereignis, für das sich eine Automatisierung offensichtlich nicht lohnte.

Wir akzeptieren eher die potenziellen Auswirkungen unwahrscheinlicher Ereignisse - vielleicht werden sie ja gar nicht eintreten! Bestehende Systeme, die für diese Risiken ausgelegt sind, haben es schwer, wenn die Fehlerquote mit dem Umfang zunimmt oder wenn die Auswirkungen für das Unternehmen weniger akzeptabel werden.

Der Vollständigkeit halber ( ) möchte ich kurz auf Monolithen eingehen. Es gibt keinen genauen Schwellenwert, ab dem ein System ein Monolith ist - das ist relativ. Monolithische Systeme sind nicht per se mehr oder weniger fehlertolerant als serviceorientierte Architekturen. Sie sind jedoch schwieriger umzurüsten, weil sie eine größere Oberfläche haben, sich nur schwer schrittweise ändern lassen und der Radius von Fehlern schwer zu begrenzen ist. Vielleicht entscheidest du dich, deinen Monolithen aufzubrechen, vielleicht auch nicht. Die Fehlertoleranz ist auf beiden Wegen erreichbar.

Gemeinsame Entwurfsmuster in neueren Systemen

Im Gegensatz dazu gehen die Systeme, die heute entwickelt werden, davon aus, dass einzelne Computer häufig kommen und gehen. Diese neue Denkweise hat viele Konsequenzen, aber die vielleicht wichtigste ist, dass Systeme so entwickelt werden, dass sie auf n Computern gleichzeitig laufen und auch dann noch funktionieren, wenn einer fehlschlägt und nur noch n - 1 übrig ist.

Gesundheitsprüfungen, die tief genug sind, um Probleme zu erkennen, aber flach genug, um kaskadenartige Ausfälle durch die Abhängigkeiten eines Dienstes zu vermeiden, spielen eine entscheidende Rolle. Sie nehmen fehlschlagende Computer aus dem Betrieb und leiten in vielen Fällen automatisch einen Ersatz ein.

Instanz Ersatz - einzelne Computer werden von Cloud-Service-Providern als Instanzen bezeichnet - ist eine leistungsstarke Strategie, die von modernen Systemen eingesetzt wird. Sie ermöglicht die gerade beschriebene Fehlertoleranz sowie gleichmäßige Betriebsmuster wie die blau-grüne Bereitstellung. Und in Systemen, die Daten speichern, bietet die Instanzersetzung die Möglichkeit und Motivation, automatisch und häufig zu testen, ob Backups wiederhergestellt werden können.

Ich möchte noch einmal betonen, dass ein eher monolithisches System nicht ausschließt, dass es die Vorteile dieser Entwurfsmuster nutzt. Es ist jedoch eine bewährte architektonische Entscheidung, neue Funktionen als Dienst bereitzustellen, der mit einem bestehenden Monolithen zusammenarbeitet.

Einstieg in die grundlegende Fehlertoleranz

Chaos Experimente sollten in der Produktion durchgeführt werden (zusätzlich zu den Entwicklungs- und Staging-Umgebungen) und du solltest sicher sein können, dass die Auswirkungen auf die Kunden vernachlässigbar sind, wenn es überhaupt welche gibt. Dies sind einige der wichtigsten Änderungen, die du vornehmen kannst, wenn eines der Systeme, die du betreibst, den Designmustern entspricht, die in älteren Systemen üblich sind.

Erstens und vor allem: Halte Ersatzkapazitäten online. Mindestens ein zusätzlicher Computer während des normalen Betriebs ist der Anfang von Fehlertoleranz (und deckt mehr Arten von Hardwareausfällen ab als RAID, das nur Festplatten abdeckt, oder Graceful Degradation auf Anwendungsebene, was in deiner speziellen Anwendung vielleicht nicht möglich ist). Nutze diese freie Kapazität, um Anfragen zu bearbeiten, die eintreffen, während ein oder mehrere Computer nicht funktionieren.

Sobald du über freie Kapazitäten verfügst, solltest du dir überlegen, wie du nicht funktionierende Computer automatisch aus dem Verkehr ziehen kannst (bevor du dich ins Chaos Engineering stürzt). Bleib aber nicht bei der automatischen Entfernung stehen. Fahre mit dem automatischen Ersatz fort. Hier bietet die Cloud einige deutliche Vorteile. Es ist leicht (und macht Spaß), die Bereitstellung von Instanzen zu optimieren, aber eine grundlegende Implementierung der automatischen Skalierung, die Instanzen ersetzt, wenn sie beendet werden, um die Gesamtzahl konstant zu halten, ist für die meisten Systeme geeignet. Die automatische Instanzersetzung muss zuverlässig sein. Die Ersatzinstanzen müssen in weniger als der mittleren Zeit zwischen zwei Ausfällen in Betrieb gehen.

Einige Systeme, vor allem solche, die Daten speichern, unterscheiden vielleicht zwischen einem Anführer und vielen Mitläufern. Es ist einfach (und macht Spaß), sich mit der Wahl des Anführers und dem Konsens zu beschäftigen, aber auch hier ist eine Implementierung, die menschliche Handlungen vom kritischen Pfad fernhält, wahrscheinlich ausreichend. Die Einführung der automatischen Ausfallsicherung ist der perfekte Zeitpunkt, um die Zeitüberschreitungs- und Wiederholungsrichtlinien in abhängigen Diensten zu überprüfen. Du solltest auf kurze, aber vernünftige Timeouts achten, die lang genug sind, um den automatischen Failover abzuschließen, und auf Wiederholungsversuche, die exponentiell mit ein wenig Jitter ablaufen.

Tabletop-Übungen, bei denen dein Team die Details des erwarteten Verhaltens eines Systems im Falle eines Fehlers durchspricht, sind nützlich, um dich davon zu überzeugen, dass ein System fertig ist. Diese akademische Zuversicht reicht jedoch bei einem komplexen System bei weitem nicht aus. Der einzige Weg, echtes Vertrauen zu gewinnen, ist, einen Fehler in der Produktion zu provozieren. Der Rest dieses Kapitels stellt das Verfahren von Slack vor, mit dem dies auf sichere Weise möglich ist.

Katastrophenstück Theater

Ich nenne diesen Prozess "Desasterpiece Theater". Wenn du mit anderen wertvollen Anliegen um die Zeit deiner Kolleginnen und Kollegen konkurrierst und sie aufforderst, die Art und Weise, wie sie Softwaresysteme entwickeln und betreiben, zu ändern, ist eine einprägsame Marke wirklich hilfreich. Das Disasterpiece Theater wurde zunächst als Forum zum Thema Systemausfall eingeführt. Es ist eine fortlaufende Reihe von Übungen, bei denen wir zusammenkommen und absichtlich einen Teil von Slack fehlschlagen lassen.

Ziele

Jede Übung des Katastrophen-Theaters ist ein bisschen anders. Wir graben verschiedene Hacks aus unserer Vergangenheit aus, wecken verschiedene Ängste und gehen verschiedene Risiken ein. Alle Übungen lassen sich jedoch auf die gleichen grundlegenden Ziele zurückführen.

Abgesehen von den extremsten Anhängern einer reinen Crash-Software werden die meisten Systeme häufiger eingesetzt, als ihre zugrunde liegende Netzwerk- und Serverinfrastruktur fehlschlägt. Wenn wir eine Disasterpiece Theater Übung entwerfen, achten wir sehr genau darauf, wie genau die Entwicklungsumgebung mit der Produktionsumgebung übereinstimmt. Es ist wichtig, dass alle Softwareänderungen in der Entwicklungsumgebung getestet werden können, aber es ist auch wichtig, dass Ausfälle dort geübt werden können. Die Vorteile von Disasterpiece Theater, das die Behebung von Abweichungen erzwingt, zahlen sich bei jedem Durchlauf der Testsuite und jedem Bereitstellungszyklus aus.

Wenn wir kontrollierte Ausfälle herbeiführen, ist ein Hauptziel, Schwachstellen in unseren Produktionssystemen zu entdecken. Die Planung dieser Übungen trägt dazu bei, das Risiko, dass eine unbekannte Schwachstelle sich auf den Kunden auswirkt, zu minimieren (wenn auch nie vollständig). Wir suchen nach Schwachstellen in Bezug auf Verfügbarkeit, Korrektheit, Kontrollierbarkeit, Beobachtbarkeit und Sicherheit.

Disasterpiece Theater ist eine fortlaufende Reihe von Übungen. Wenn bei einer Übung eine Schwachstelle entdeckt wird, planen wir, die Übung zu wiederholen, um zu überprüfen, ob die Maßnahmen zur Behebung der Schwachstelle wirksam waren, so wie man die Testsuite eines Programms wiederholt, um zu bestätigen, dass man einen Fehler behoben hat, der einen Test fehlschlagen ließ. Allgemeiner ausgedrückt: Die Übungen validieren die Systementwürfe und die darin enthaltenen Annahmen. Im Laufe der Zeit entwickelt sich ein komplexes System weiter und es kann passieren, dass eine Annahme, die vor langer Zeit in einem abhängigen Teil des Systems getroffen wurde, versehentlich ungültig wird. Zum Beispiel kann die Zeitüberschreitung, die ein Dienst für Anfragen an eine Abhängigkeit vorsieht, nicht mehr ausreichen, wenn diese Abhängigkeit in mehreren Cloud-Regionen eingesetzt wird. Das Wachstum der Organisation und des Systems verringert die Genauigkeit des Modells eines einzelnen Mitarbeiters (laut STELLA-Bericht); es ist immer unwahrscheinlicher, dass dieser Mitarbeiter alle Annahmen, die bei der Entwicklung des Systems getroffen wurden, kennt. Die regelmäßige Überprüfung der Fehlertoleranz hilft der Organisation, die Richtigkeit ihrer Annahmen sicherzustellen.

Anti-Goals

Disasterpiece Theater soll also die Gleichheit zwischen Entwicklungs- und Produktionsumgebungen fördern, zur Verbesserung der Zuverlässigkeit motivieren und die Fehlertoleranz eines Systems demonstrieren. Ich finde es auch hilfreich, klar zu sagen, was ein Prozess oder ein Werkzeug nicht sein soll.

Eine Größe passt nicht für alle, aber für Slack habe ich beschlossen, dass Katastrophenschutzübungen geplant und durchgeführt werden sollten, um die Wahrscheinlichkeit eines Produktionsausfalls zu minimieren. Slack ist ein Dienst, der von kleinen und großen Unternehmen genutzt wird, um ihre Geschäfte abzuwickeln; es ist wichtig, dass der Dienst jederzeit für sie da ist. Einfacher ausgedrückt: Slack verfügt nicht über ein ausreichendes Fehlerbudget, um schwerwiegende oder langwierige Auswirkungen auf die Kunden als Ergebnis einer dieser geplanten Übungen zu akzeptieren. Du hast vielleicht ein größeres Fehlerbudget oder eine größere Risikotoleranz und wenn du sie effektiv einsetzt, lernst du dank der Übungen, die du damit planen kannst, mehr und schneller.

Die Dauerhaftigkeit der Daten ist sogar noch wichtiger. Das bedeutet nicht, dass Speichersysteme nicht von diesem Prozess betroffen sind. Vielmehr bedeutet es, dass die Pläne und Eventualitäten für diese Pläne sicherstellen müssen, dass die Daten niemals unwiederbringlich verloren gehen. Das kann sich auf die Techniken auswirken, mit denen ein Ausfall herbeigeführt wird, oder dazu führen, dass während der Übung ein zusätzliches Replikat in Reserve gehalten oder manuell ein Backup erstellt wird. Welchen Vorteil das Disasterpiece Theater auch haben mag, es ist es nicht wert, die Daten eines Kunden zu verlieren.

Katastrophen-Theater ist kein Erkundungstheater. Wenn du ein kleines Missgeschick einführst, das es vorher noch nicht oder nur sehr selten gegeben hat, ist Planung der Schlüssel. Du solltest eine detaillierte, glaubwürdige Hypothese darüber haben, was passieren wird , bevor du das Scheitern auslöst. Alle Experten und interessierten Menschen in einem Raum oder auf einer Videokonferenz zu versammeln, hilft, das Chaos einzudämmen, mehr Ingenieure über die Details der zu übenden Systeme aufzuklären und das Katastrophen-Theaterprogramm selbst bekannt zu machen. Im nächsten Abschnitt wird der Prozess von der Idee bis zum Ergebnis im Detail beschrieben.

Der Prozess

Jede Katastrophenstück-Theaterübung beginnt mit einer Idee. Oder vielleicht besser gesagt, mit einer Sorge. Sie kann vom Autor und langjährigen Besitzer eines Systems kommen, von einer Entdeckung, die bei einer nicht verwandten Arbeit gemacht wurde, als Folge eines Postmortem - ganz egal, wo. Mit dieser Sorge und der Hilfe eines oder mehrerer Experten für das betreffende System führt ein erfahrener Moderator uns alle durch den Prozess.

Vorbereitung

Du und deine Co-Moderatoren sollten sich in einem Raum oder auf einer Videokonferenz treffen, um die Übung vorzubereiten. Meine Original-Checkliste für das Disasterpiece-Theater schlägt folgende Punkte vor, die ich im Einzelnen beschreiben werde:

  1. Entscheide dich für einen Server oder einen Dienst, der fehlschlagen soll, für den Fehlermodus und für die Strategie zur Simulation dieses Fehlermodus.

  2. Überprüfe den Server oder Dienst in Dev und Prod; notiere dein Vertrauen in unsere Fähigkeit, den Ausfall in Dev zu simulieren.

  3. Identifiziere Alarme, Dashboards, Protokolle und Metriken, von denen du annimmst, dass sie den Fehler aufdecken werden; wenn es keine gibt, erwäge, den Fehler trotzdem auszulösen und dich rückwärts bis zur Entdeckung vorzuarbeiten.

  4. Identifiziere Redundanzen und automatisierte Abhilfemaßnahmen, die die Auswirkungen des Ausfalls abmildern sollen, sowie Runbooks, die zur Reaktion erforderlich sein könnten.

  5. Lade alle relevanten Personen ein, vor allem diejenigen, die zu dem Zeitpunkt Bereitschaft haben, und kündige die Übung in #disasterpiece-theater (einem Kanal im Slack-eigenen Slack) an.

Ich habe festgestellt, dass meistens eine gemeinsame Stunde ausreicht, um loszulegen und die letzten Vorbereitungen asynchron erledigt werden können. (Ja, wir benutzen Slack dafür.)

Manchmal ist die Sorge, die zu der ganzen Übung geführt hat, so konkret, dass du schon genau weißt, welchen Fehler du auslösen willst, z. B. wenn du dafür sorgst, dass ein Prozess seine Gesundheitsprüfungen besteht, aber trotzdem nicht auf Anfragen reagiert. In anderen Fällen gibt es viele Möglichkeiten, den gewünschten Fehler zu erreichen, und sie unterscheiden sich alle auf subtile Weise. In der Regel ist es am einfachsten, einen Prozess zu stoppen, zu reparieren und zu tolerieren. Dann gibt es noch das Beenden von Instanzen (vor allem in der Cloud), was sinnvoll sein kann, wenn sie automatisch ersetzt werden. Die Verwendung von iptables(8), um das Abziehen des Netzwerkkabels eines Computers zu simulieren, ist ein ziemlich sicherer Fehlermodus, der sich vom Anhalten eines Prozesses und (manchmal) der Beendigung einer Instanz unterscheidet, weil die Fehler als Timeouts und nicht als ECONNREFUSED auftreten. Und dann kannst du dich in die endlose und manchmal erschreckende Welt der partiellen und sogar asymmetrischen Netzwerkpartitionen begeben, die normalerweise mit iptables(8) simuliert werden können.

Außerdem stellt sich die Frage, wo im System eine dieser Techniken angewendet wird. Einzelne Computer sind ein guter Anfang, aber du kannst dich auch zu ganzen Racks, Reihen, Rechenzentren, Verfügbarkeitszonen oder sogar Regionen hocharbeiten. Größere Ausfälle können uns helfen, Kapazitätsbeschränkungen und enge Kopplungen zwischen Systemen aufzudecken. Erwäge, den Ausfall zwischen Load Balancern und Anwendungsservern, zwischen einigen Anwendungsservern (aber nicht allen) und ihren Backup-Datenbanken usw. einzuführen. Du solltest diesen Schritt mit ganz konkreten Schritten oder besser noch mit Befehlen verlassen, die du ausführen kannst.

Als Nächstes solltest du dich vergewissern, was wirklich möglich ist, um sicher zu trainieren. Sieh dir deine Entwicklungsumgebung genau an, um festzustellen, ob der Fehler, den du einführen willst, dort auch tatsächlich auftreten kann. Überlege auch, ob es in deiner Entwicklungsumgebung genügend Datenverkehr gibt (oder geben kann), um den Fehler zu erkennen und mögliche negative Auswirkungen wie die Erschöpfung von Ressourcen in einem abhängigen Dienst mit schlecht konfigurierten Timeouts, in den verbleibenden Instanzen des gestörten Dienstes oder in verwandten Systemen wie der Diensterkennung oder der Log-Aggregation zu erfahren.

Stell dir einen Moment lang vor, dass deine Entwicklungsumgebung den Fehler problemlos verkraftet. Traust du dir dann zu, den gleichen Fehler in deiner Produktionsumgebung zu provozieren? Wenn nicht, solltest du die Übung abbrechen und in deine Entwicklungsumgebung investieren. Wenn ja, dann ist es gut, dass du eine Entwicklungsumgebung hast, die dein Vertrauen stärkt! Nimm dir jetzt einen Moment Zeit, um dieses Vertrauen zu formalisieren. Identifiziere alle Alarme, von denen du erwartest, dass sie ausgelöst werden, wenn du diesen Fehler verursachst, sowie alle Dashboards, Protokolle und/oder Kennzahlen, von denen du annimmst, dass sie den Fehler erkennen, und diejenigen, von denen du annimmst, dass sie stabil bleiben. Stell dir das so vor, als würdest du deinen Incident-Response-Prozess "vorbereiten". Du planst nicht, es zu brauchen, aber es ist eine lohnende Vorsichtsmaßnahme, um sicherzustellen, dass die Zeit zum Erkennen und die Zeit zum Aufbauen praktisch gleich Null ist, falls die Übung nicht wie geplant verläuft. Ich hoffe, dass du in den meisten Fällen diese Protokolle und Messwerte eher brauchst, um deine Hypothese zu bestätigen.

Aber wie sieht diese Hypothese aus? Nimm dir etwas Zeit, um genau aufzuschreiben, was du und deine Mitstreiter/innen erwarten. Nimm mehrere Perspektiven ein. Überlege dir, wie Health Checks, Load Balancer und Service Discovery bei einem Ausfall funktionieren. Denke darüber nach, was mit den Anfragen passiert, die durch den Ausfall unterbrochen werden, sowie mit denen, die kurz danach eintreffen. Wie erfährt ein anfragendes Programm von dem Ausfall? Wie lange dauert das? Versuchen einige dieser Programme ihre Anfragen erneut? Wenn ja, wie aggressiv? Führt die Kombination dieser Zeitüberschreitungen und Wiederholungen dazu, dass die Ressourcen erschöpft sind? Erweitere nun dein Modell der Situation auf den Menschen und notiere alle Punkte, an denen ein menschliches Eingreifen notwendig oder wünschenswert wäre. Finde heraus, welche Runbooks oder Dokumentationen notwendig sein könnten. (Auch dies dient dazu, den Reaktionsprozess auf einen Vorfall vorzubereiten.) Versuche schließlich zu quantifizieren, welche Auswirkungen auf die Kunden du erwartest, und bestätige, dass diese so gering sind, dass du fortfahren kannst.

Schließe deine Vorbereitung ab, indem du die Logistik der Übung ausarbeitest. Ich empfehle, mindestens drei Stunden in einem großen Konferenzraum einzuplanen. Meiner Erfahrung nach werden selten alle drei Stunden genutzt, aber es wäre eine Ablenkung, während einer Übung, die nicht nach Plan verläuft, umziehen zu müssen. Wenn es Teilnehmer/innen aus der Ferne gibt, verwende ein Videokonferenzsystem mit einem guten Mikrofon, das den ganzen Raum abdeckt. Versammle die Co-Moderatoren, alle anderen Experten für das zu übende System und seine Kunden, alle, die auf Abruf sind, und alle, die etwas lernen wollen. Diese Übungen sind sehr teuer, was unterstreicht, wie wichtig eine gründliche Vorbereitung ist. Jetzt, wo du vorbereitet bist, ist es Zeit für das Desasterpiece-Theater.

Die Übung

Ich versuche, aus jeder Übung eine Art Spektakel zu machen, um den Bekanntheitsgrad von Disasterpiece Theater im Unternehmen zu erhöhen. Dieses Programm konkurriert um die Zeit der Leute; es ist sehr wichtig, dass jeder versteht, dass die Zeit, die man in Disasterpiece Theater investiert, zu einem zuverlässigeren System mit einer vertrauenserweckenden Entwicklungsumgebung führt.

Du solltest einen Mitschreiber bestimmen. (In der Vergangenheit habe ich diese Rolle bei Slacks Katastrophen-Theaterübungen übernommen, aber es gibt keinen Grund, warum du nicht anders entscheiden kannst). Ich empfehle, die Notizen in einem Chat-Kanal oder einem ähnlichen Medium zu machen, das jede Nachricht automatisch mit einem Zeitstempel versieht. Wir machen Notizen im Kanal #disasterpiece-theater in Slacks eigenem Slack.

Wenn du zu irgendeinem Zeitpunkt während einer Übung feststellst, dass du unangenehm vom Plan abweichst oder unvorhergesehene Auswirkungen auf die Kunden hast, brich ab. Lerne, was du kannst, sammle dich neu und versuche es an einem anderen Tag erneut. Du kannst eine ganze Menge lernen, ohne die Schwelle zum Ernstfall zu überschreiten.

Meine Original-Katastrophen-Theater-Checkliste setzt sich in der Übung selbst fort und wie bei der Vorbereitungs-Checkliste beschreibe ich jeden Schritt im Detail:

  1. Vergewissere dich, dass alle damit einverstanden sind, dass die Videokonferenz aufgezeichnet wird, und beginne, wenn möglich, mit der Aufzeichnung.

  2. Überprüfe die Vorbereitung und ändere sie, wenn nötig.

  3. Kündige die Dev-Übung in #ops an (ein Kanal in Slacks eigenem Slack, in dem wir Produktionsänderungen und Vorfälle besprechen).

  4. Verursache den Ausfall in dev. Notiere die Zeit.

  5. Erhalte Warnmeldungen und prüfe Dashboards, Protokolle und Metriken. Notiere den Zeitpunkt, zu dem sie den endgültigen Beweis für den Fehler liefern.

  6. Falls zutreffend, gib automatischen Abhilfemaßnahmen Zeit, um ausgelöst zu werden. Notiere die Zeit, die sie sind.

  7. Wenn nötig, folge den Runbooks, um den Dienst in dev wiederherzustellen. Notiere die Zeit und alle erforderlichen Abweichungen.

  8. Entscheide, ob du die Aktion fortsetzen willst oder nicht. Wenn es nicht geht, gibst du in #ops Entwarnung, führst eine Nachbesprechung durch und hörst auf. Wenn ja, geh.

  9. Kündige die Prod-Übung in #ops an.

  10. Verursache den Ausfall in prod. Notiere die Zeit.

  11. Erhalte Warnmeldungen und prüfe Dashboards, Protokolle und Metriken. Notiere den Zeitpunkt, zu dem sie den endgültigen Beweis für den Fehler liefern.

  12. Falls zutreffend, gib automatischen Abhilfemaßnahmen Zeit, um ausgelöst zu werden. Notiere die Zeit, die sie sind.

  13. Wenn nötig, befolge die Runbooks, um den Dienst in prod wiederherzustellen. Notiere die Zeit und alle erforderlichen Abweichungen.

  14. Gib die Entwarnung in #ops bekannt.

  15. Nachbesprechung.

  16. Wenn es eine gibt, verteile die Aufzeichnung, sobald sie verfügbar ist.

Ich habe gerne eine Audioaufzeichnung der Übung, auf die ich zurückgreifen kann, für den Fall, dass etwas Wichtiges in den Notizen, die ich in Echtzeit gemacht habe, nicht oder nicht richtig erfasst wurde. Es ist jedoch wichtig, dass alle Teilnehmer/innen mit der Aufzeichnung einverstanden sind. Kläre das zuerst und beginne, wenn möglich, mit der Aufzeichnung.

Beginne mit einer gründlichen Überprüfung des Plans. Einige der Teilnehmer/innen sehen ihn wahrscheinlich zum ersten Mal. Ihre einzigartige Perspektive kann den Plan verbessern. Beziehe ihr Feedback mit ein, besonders wenn es die Übung sicherer oder die Ergebnisse aussagekräftiger macht. Wir veröffentlichen die Pläne im Voraus in gemeinsamen Dokumenten und aktualisieren sie mit diesen Änderungen. Sei jedoch vorsichtig, wenn du aus einer Laune heraus zu weit vom Plan abweichst, denn das kann eine sichere und gut geplante Übung in einen Hindernisparcours verwandeln.

Wenn der Plan genehmigt ist, kündige die Übung an einem sehr öffentlichen Ort an, z. B. in einem Chat-Kanal, in dem Updates über den Systembetrieb erwartet werden, in einer Mailingliste für die gesamte Entwicklungsabteilung oder ähnlichem. In dieser ersten Ankündigung sollte darauf hingewiesen werden, dass die Übung in der Entwicklungsumgebung beginnt, und die Zuschauer sollten aufgefordert werden, dort mitzumachen. In Beispiel 4-1 siehst du, wie eine typische Ankündigung bei Slack aussieht.

Beispiel 4-1. Eine typische erste Disasterpiece Theater-Ankündigung bei Slack

Richard Crowley 9:50 AM #disasterpiece-theater is on again and we are about to unplug the network cables on 1/4 of the Channel Servers in dev. Verfolge das Geschehen im Channel oder warte auf meine Ankündigung hier, wenn wir auf prod umsteigen.

Jetzt ist der Moment der Wahrheit gekommen (zumindest in der Entwicklungsumgebung). Einer deiner Co-Moderatoren sollte den vorbereiteten Befehl ausführen, um den Fehler auszulösen. Dein Mitschreiber sollte die Zeit notieren.

Jetzt ist der Zeitpunkt gekommen, an dem alle Teilnehmer (außer dem Protokollführer) aktiv werden müssen. Sammle Beweise für den Ausfall, die Wiederherstellung und die Auswirkungen auf benachbarte Systeme. Bestätige oder widerlege alle Details deiner Hypothese. Notiere dir genau, wie lange die automatische Wiederherstellung dauert und was deine Kunden in der Zwischenzeit erlebt haben. Und wenn du eingreifen musst, um den Dienst wiederherzustellen, mach dir besonders detaillierte Notizen zu deinen Aktionen und denen deiner Mitstreiter/innen. Achte darauf, dass der Protokollant deine Beobachtungen festhalten und Screenshots der untersuchten Diagramme posten kann.

Zu diesem Zeitpunkt sollte deine Entwicklungsumgebung wieder in einen stabilen Zustand übergegangen sein. Ziehe Bilanz. Wenn deine automatisierten Abhilfemaßnahmen den Fehler nicht erkannt haben oder auf andere Weise fehlerhaft waren, solltest du hier aufhören. Wenn der Ausfall für die Kunden zu auffällig war (wie auch immer du das von deiner Entwicklungsumgebung ableitest) oder zu lange anhielt, solltest du hier aufhören. Wenn du das Risiko abschätzt und dich für einen Abbruch entscheidest, kündige das an, wo du den Beginn der Übung angekündigt hast. In Beispiel 4-2 siehst du, wie ein solcher seltener Rückzug bei Slack aussieht.

Beispiel 4-2. Eine abgebrochene Disasterpiece Theater-Ankündigung bei Slack

Richard Crowley 11:22 AM Das Disasterpiece Theater ist für heute zu Ende, ohne dass wir es bis zum Prod.

Wenn die Übung in deiner Entwicklungsumgebung wie geplant verläuft, kannst du ankündigen, dass die Übung in deine Produktionsumgebung übergeht. In Beispiel 4-3 siehst du, wie eine typische Ankündigung bei Slack aussieht.

Beispiel 4-3. Eine typische Ankündigung, wenn Disasterpiece Theater auf prod

Richard Crowley 10:10 AM #disasterpiece-theater hat zwei Runden in der Entwicklung hinter sich und ist dort fertig. Jetzt gehen wir zu prod über. Erwarte, dass in naher Zukunft eine Reihe von Kanälen im Channel Server Ring neu verteilt werden. Ich werde wieder posten, wenn alles klar ist.

Dies ist der Moment der Wahrheit. Die ganze Vorbereitung und die Übung in der Entwicklungsumgebung haben dich zu diesem Moment geführt, in dem einer deiner Co-Moderatoren den Fehler in der Produktionsumgebung mit Hilfe der vorbereiteten Schritte oder Befehle herbeiführen soll. Bei manchen Übungen wird sich das wie ein Kinderspiel anfühlen, bei anderen wird es richtig beängstigend sein. Achte auf diese Gefühle - sie zeigen dir, wo das Risiko in deinen Systemen liegt.

Jetzt ist es wieder an der Zeit, dass alle Beteiligten (außer dem Protokollführer) in Aktion treten und Beweise für den Ausfall, die Wiederherstellung und die Auswirkungen auf benachbarte Systeme sammeln. Die Beweise sind in der Regel viel interessanter, wenn echter Kundenverkehr auf dem Spiel steht. Bestätige oder widerlege deine Hypothese in der Produktion. Beobachte, wie das System auf den Fehler reagiert und notiere die Zeit, in der du eine automatische Behebung beobachtest. Wenn du eingreifen musst, um den Dienst wiederherzustellen, musst du das natürlich schnell und entschlossen tun - deine Kunden zählen auf dich! Auch hier solltest du darauf achten, dass der Protokollant deine Beobachtungen festhält und Screenshots von den Diagrammen anfertigt, die du untersuchst.

Wenn deine Produktionsumgebung wieder einen stabilen Zustand erreicht hat, gibst du an derselben Stelle Entwarnung, an der du die Übung in deiner Entwicklungsumgebung und den Übergang zu deiner Produktionsumgebung angekündigt hast. Wenn du einen vorläufigen Kommentar zum Erfolg der Übung abgeben kannst, ist das großartig, aber zumindest hält die Ankündigung die Teammitglieder, die Änderungen in der Produktionsumgebung vornehmen, über die Situation auf dem Laufenden.

Bevor sich alle Teilnehmer in alle Winde zerstreuen, nimm dir Zeit für eine unmittelbare Sinnfindung. Das heißt, nimm dir Zeit, um alle Unklarheiten über die Übung zu verstehen oder zumindest zu dokumentieren.

Nachbesprechung

Kurz nach der Übung, wenn die Erinnerungen noch frisch und lebendig sind, fasse ich die Übung gerne zusammen - nur die Fakten - für ein breites Publikum. Es ist hilfreich, die Zusammenfassung mit einer Geschichte zu versehen, die erklärt, warum der geübte Ausfallmodus wichtig ist, wie die Systeme den Ausfall verkraftet haben (oder auch nicht) und was das für die Kunden und das Unternehmen bedeutet. Es dient auch dazu, dem Rest des Unternehmens zu verdeutlichen, warum diese Übungen so wichtig sind. Meine Original-Checkliste für das Katastrophentheater enthält die folgenden Eingabeaufforderungen:

  • Wie lange dauerte es bis zur Entdeckung und wie lange bis zur Erholung?

  • Hat jemand etwas bemerkt? Woher wissen wir das? Wie können wir das mit "Nein" beantworten?

  • Was musste der Mensch tun, was der Computer hätte tun sollen?

  • Wo sind wir blind?

  • Wo sind unsere Dashboards und Dokumente falsch?

  • Was müssen wir noch öfter üben?

  • Was müssten die Techniker/innen im Bereitschaftsdienst tun, wenn dies unerwartet passiert?

Wir halten die Antworten auf diese Fragen in Slack oder in einem zusammenfassenden Dokument fest, das wir in Slack teilen. Seit Kurzem nehmen wir auch Audioaufnahmen von Übungen auf und archivieren sie für die Nachwelt.

Nach der Zusammenfassung gibt der Moderator Schlussfolgerungen und Empfehlungen im Namen der Übung ab. Deine Aufgabe als Übungsleiter/in ist es, diese Schlussfolgerungen und Empfehlungen im Dienste der Zuverlässigkeit des Systems und der Qualität der Entwicklungsumgebung auf der Grundlage der in der Zusammenfassung sachlich dargestellten Beweise zu ziehen. Diese Empfehlungen gewinnen an Bedeutung, wenn die Übung nicht nach Plan verlaufen ist. Wenn selbst die erfahrensten Köpfe das System vor der Übung falsch oder unvollständig verstanden haben, ist es wahrscheinlich, dass alle anderen noch weiter daneben liegen. Das ist deine Chance, das Verständnis aller zu verbessern.

Die Nachbesprechung und ihre Ergebnisse bieten eine weitere Möglichkeit, dein Unternehmen zu beeinflussen, indem du noch mehr Menschen über die Arten von Fehlern, die in der Produktion auftreten können, und die Techniken, die dein Unternehmen einsetzt, um sie zu tolerieren, aufklärst. Dieser Vorteil ist einem der Vorteile der internen Veröffentlichung von detaillierten Nachbesprechungen von Vorfällen bemerkenswert ähnlich.

Wie sich der Prozess entwickelt hat

Das Katastrophentheater war ursprünglich als Ergänzung zum Incident-Response-Prozess und sogar als Forum zum Üben von Incident-Response konzipiert. Frühe Listen mit potenziellen Übungen enthielten eine ganze Reihe von Fehlern, von denen schon damals bekannt war, dass sie menschliches Eingreifen erfordern. Das war zumindest theoretisch akzeptabel, denn diese Fehlermodi beruhten auf Annahmen, die sich im Laufe der Zeit als falsch erwiesen haben könnten.

Mehr als ein Jahr später hat Slack noch nie eine Katastrophenschutzübung durchgeführt, bei der ein menschliches Eingreifen erforderlich war, obwohl es Fälle gab, in denen ein menschliches Eingreifen dennoch notwendig war. Stattdessen haben wir ein anderes Programm entwickelt, um die Reaktion auf Zwischenfälle zu üben: Incident Management Lunch. Dabei handelt es sich um ein Spiel, bei dem eine Gruppe von Leuten versucht, sich selbst zu ernähren, indem sie dem Incident Response Prozess folgt. In regelmäßigen Abständen ziehen sie Karten, die sie vor unvorhergesehene Probleme stellen, wie z.B. plötzliche Restaurantschließungen, Allergien und wählerische Esser. Dank dieser Übung und dem Training, das ihr vorausgeht, muss das Disasterpiece Theater diese Lücke nicht mehr füllen.

Das Disasterpiece Theater hat sich auch in anderer Hinsicht weiterentwickelt. Die ersten Versionen konzentrierten sich ausschließlich auf die Ergebnisse und ließen eine Menge pädagogischer Möglichkeiten auf dem Tisch liegen. Die Nachbesprechungen und vor allem die schriftlichen Zusammenfassungen, Schlussfolgerungen und Empfehlungen wurden speziell wegen ihres pädagogischen Werts eingeführt. Auch die kürzlich eingeführten Aufzeichnungen ermöglichen es zukünftigen Beobachtern, tiefer in die Materie einzutauchen, als dies mit der Zusammenfassung und dem Chatverlauf allein möglich ist.

Für Fernteilnehmer/innen einer Videokonferenz kann es schwierig sein, den Redner/innen zu folgen, vor allem, wenn sie das Video nicht sehen können, weil jemand ihren Bildschirm teilt. Deshalb habe ich mit Disasterpiece Theater begonnen und empfehle, den Bildschirm nicht zu teilen. Andererseits kann es unglaublich wirkungsvoll sein, wenn alle gemeinsam auf dieselbe Grafik schauen. Ich bin immer noch auf der Suche nach dem richtigen Gleichgewicht zwischen Bildschirmfreigabe und Video, das für die Teilnehmer/innen aus der Ferne das beste Erlebnis bietet.

Schließlich forderte meine ursprüngliche Desasterpiece-Theater-Checkliste die Hosts auf, sich synthetische Anfragen auszudenken, die sie in einer engen Schleife stellen konnten, um den Fehler und die Toleranz zu visualisieren. Diese Praxis erwies sich nie als so nützlich wie ein gut kuratiertes Dashboard, das die Anfrage- und Fehlerrate, ein Latenzhistogramm und so weiter enthielt. Ich habe diese Eingabeaufforderung aus der Checkliste bei Slack entfernt, um den Prozess zu straffen.

Das werden sicher nicht die letzten Entwicklungen dieses Prozesses bei Slack sein. Wenn du einen ähnlichen Prozess in deinem Unternehmen einführst, achte darauf, was sich unangenehm anfühlt, um es zu glätten, und wer keinen Nutzen daraus zieht, um den Prozess integrativer zu gestalten.

Management-Buy-In erhalten

Wenn du wieder bist, ist eine Erzählung der Schlüssel. Du könntest mit einem rhetorischen Mittel beginnen: "Hallo, CTO und VP of Engineering. Wollt ihr nicht wissen, wie gut unser System den Ausfall des Datenbankmasters, Netzwerkpartitionen und Stromausfälle verkraftet?" Zeichne ein Bild, das einige Unbekannte enthält.

Und dann bring die unbequeme Wahrheit. Der einzige Weg, um zu verstehen, wie ein System mit einem Fehler in der Produktion umgeht, ist, einen Fehler in der Produktion zu haben. Ich muss an dieser Stelle zugeben, dass es den Führungskräften von Slack unglaublich leicht gefallen ist, dies zu glauben.

Generell muss jedoch jede verantwortliche Führungskraft den Nachweis erbringen, dass du Risiken effektiv und angemessen handhabst. Der Disasterpiece Theater Prozess wurde speziell dafür entwickelt, um diese Anforderung zu erfüllen. Betone, dass diese Übungen sorgfältig geplant und kontrolliert werden, um den Lerneffekt zu maximieren und die Auswirkungen auf die Kunden zu minimieren (oder besser noch zu eliminieren).

Dann plane deine erste Übung und zeige ein paar Ergebnisse wie die im nächsten Abschnitt.

Ergebnisse

Ich habe Dutzende von Disasterpiece Theater Übungen bei Slack durchgeführt. Die meisten von ihnen sind ungefähr nach Plan verlaufen, haben unser Vertrauen in bestehende Systeme gestärkt und die korrekte Funktion neuer Systeme bewiesen. Einige haben jedoch ernsthafte Schwachstellen in der Verfügbarkeit oder Korrektheit von Slack aufgedeckt und uns die Möglichkeit gegeben, diese zu beheben, bevor sie sich auf die Kunden auswirken.

Vermeiden Sie Cache-Inkonsistenzen

Das erste Mal, als sich Disasterpiece Theater mit Memcached beschäftigte, war, um in der Produktion zu demonstrieren, dass die automatische Instanzersetzung richtig funktioniert. Die Übung war einfach: Wir trennten eine Memcached-Instanz vom Netzwerk und beobachteten, wie eine Ersatzinstanz ihren Platz einnahm. Anschließend stellten wir die Netzwerkverbindung wieder her und beendeten die Ersatzinstanz.

Bei der Überprüfung des Plans haben wir eine Schwachstelle im Algorithmus zum Ersetzen von Instanzen entdeckt und sie bald in der Entwicklungsumgebung bestätigt. So wie er ursprünglich implementiert war, löscht eine Instanz ihre Cache-Einträge nicht, wenn sie ihre Lease für einen Bereich von Cache-Schlüsseln verliert und dann dieselbe Lease zurückbekommt. In diesem Fall hatte jedoch in der Zwischenzeit eine andere Instanz diesen Bereich von Cache-Schlüsseln bedient, so dass die Daten in der ursprünglichen Instanz veraltet und möglicherweise falsch waren.

Wir haben dies in der Übung behoben, indem wir den Cache zum richtigen Zeitpunkt manuell geleert haben und dann, direkt nach der Übung, den Algorithmus geändert und erneut getestet haben. Ohne dieses Ergebnis hätten wir möglicherweise eine ganze Weile unwissentlich mit einem kleinen Risiko der Cache-Beschädigung gelebt.

Versuch, Versuch nochmal (zur Sicherheit)

Auf haben wir Anfang 2019 eine Reihe von zehn Übungen geplant, um die Toleranz von Slack gegenüber zonalen Ausfällen und Netzwerkpartitionen in AWS zu demonstrieren. Eine dieser Übungen betraf den Channel Server, ein System, das für die Weiterleitung neu gesendeter Nachrichten und Metadaten an alle angeschlossenen Slack-Client-WebSockets zuständig ist. Ziel war es, 25 % der Channel Server vom Netzwerk zu trennen, um zu beobachten, dass die Ausfälle erkannt und die Instanzen durch Ersatzinstanzen ersetzt werden.

Beim ersten Versuch, diese Netzwerkpartition zu erstellen, fehlte das Overlay-Netzwerk, das für eine transparente Transitverschlüsselung sorgt. Im Endeffekt haben wir die einzelnen Channel Server viel stärker isoliert als erwartet, so dass wir sie eher vom Netzwerk getrennt haben als eine Netzwerkpartition zu erstellen. Wir brachen das Projekt vorzeitig ab, um uns neu zu gruppieren und die Netzwerkpartition genau richtig zu machen.

Der zweite Versuch war vielversprechend, wurde aber ebenfalls beendet, bevor er in Produktion ging. Diese Übung brachte jedoch ein positives Ergebnis. Sie zeigte, dass Consul ziemlich gut in der Lage war, Netzwerkpartitionen zu umgehen. Das stimmte zuversichtlich, aber die Übung war zum Scheitern verurteilt, weil keiner der Channel Server tatsächlich fehlschlug.

Der dritte und letzte Versuch brachte schließlich ein ganzes Arsenal an iptables(8)-Regeln mit sich und schaffte es, 25% der Channel Server vom Netzwerk zu trennen. Consul entdeckte die Ausfälle schnell und die Ersatzserver wurden in Betrieb genommen. Das Wichtigste: Die Belastung der Slack-API durch diese massive automatische Neukonfiguration lag weit unter der Kapazität des Systems. Am Ende eines langen Weges war das Ergebnis rundum positiv!

Unmöglichkeit Ergebnis

Es auch negative Ergebnisse gegeben. Als wir auf einen Vorfall reagierten, waren wir einmal gezwungen, eine Codeänderung vorzunehmen und zu implementieren, um eine Konfigurationsänderung vorzunehmen, weil das System, mit dem diese Konfigurationsänderung vorgenommen werden sollte, ein intern entwickeltes System namens Confabulator, nicht funktionierte. Ich fand, dass dies eine weitere Untersuchung wert war . Die Betreuer und ich planten eine Übung, die die Situation, auf die wir gestoßen waren, direkt nachahmen sollte. Confabulator sollte vom Slack-Dienst abgetrennt werden, aber ansonsten völlig intakt bleiben. Dann würden wir versuchen, eine Konfigurationsänderung vorzunehmen, die nicht funktioniert.

Wir konnten den Fehler problemlos reproduzieren und begannen, unseren Code zu überprüfen. Es dauerte nicht lange, bis wir das Problem gefunden hatten. Die Autoren des Systems hatten die Situation vorausgesehen, dass Slack selbst nicht erreichbar war und daher die vorgeschlagene Konfigurationsänderung nicht validieren konnte; sie boten einen Notfallmodus an, der diese Validierung übersprang. Sowohl der Normal- als auch der Notfallmodus versuchten jedoch, eine Mitteilung über die Konfigurationsänderung in einem Slack-Kanal zu posten. Für diese Aktion gab es keine Zeitüberschreitung, aber für die gesamte Konfigurations-API gab es eine Zeitüberschreitung. Daher konnte die Anfrage selbst im Notfallmodus nie bis zur Konfigurationsänderung durchdringen, wenn Slack selbst nicht erreichbar war. Seitdem haben wir viele Verbesserungen am Code und an der Konfiguration vorgenommen und die Zeitüberschreitungs- und Wiederholungsrichtlinien in diesen kritischen Systemen überprüft.

Fazit

Die Entdeckungen, die wir bei diesen Übungen gemacht haben, und die Verbesserungen an der Zuverlässigkeit von Slack waren nur möglich, weil Disasterpiece Theater uns einen klaren Prozess zum Testen der Fehlertoleranz unserer Produktionssysteme gegeben hat.

Disasterpiece Theater-Übungen sind sorgfältig geplante Ausfälle, die in der Entwicklungsumgebung und dann, wenn es gut läuft, in der Produktionsumgebung von einer Gruppe von Experten durchgeführt werden, die alle zusammenkommen. Das hilft, das Risiko zu minimieren, das mit dem Testen von Fehlertoleranz verbunden ist, vor allem, wenn es auf Annahmen beruht, die vor langer Zeit in älteren Systemen gemacht wurden, die vielleicht ursprünglich nicht für eine solche Fehlertoleranz ausgelegt waren.

Der Prozess soll zu Investitionen in Entwicklungsumgebungen motivieren, die der Produktionsumgebung genau entsprechen und die Zuverlässigkeit komplexer Systeme verbessern.

Deine Organisation und deine Systeme werden durch regelmäßige Disasterpiece-Theater-Übungen besser funktionieren. Deine Zuversicht, dass etwas, das in der Entwicklungsumgebung funktioniert, auch in der Produktionsumgebung funktionieren wird, sollte größer sein. Du solltest in der Lage sein, Annahmen, die du vor langer Zeit getroffen hast, regelmäßig zu validieren, um Bitfäule zu vermeiden. Und dein Unternehmen sollte ein besseres Risikoverständnis haben, vor allem wenn es um Systeme geht, die menschliches Eingreifen zur Wiederherstellung nach einem Ausfall erfordern. Am wichtigsten ist jedoch, dass Disasterpiece Theater ein überzeugender Grund für dein Unternehmen ist, in Fehlertoleranz zu investieren.

Get Chaos Engineering now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.

Start your free trial