Chaos Engineering – Der Mythos entzaubert! Und wie du davon profitierst

Chaos Engineering nervt! Und ist dennoch eines der wichtigsten Werkzeuge für professionellen Produktivbetrieb.

Warum?

Das erfährst du in diesem Artikel. Und ich zeige dir, wie du sofort mit Chaos Engineering durchstarten kannst. Ohne komplexe Spezialtools, ohne große Planungsrunden. Dafür radikal agil und zielführend.

Warum nervt Chaos Engineering?

Hast du schon einmal vom Chaos Monkey gehört?

Vor etwa zehn Jahren wurde von Beratern in deutschen Unternehmen folgende Geschichte erzählt:

Netflix will eine ultraresiliente Plattform aufbauen. Deshalb lassen sie in der Produktion einige Chaos Monkeys (früher hießen die mal Simian Army) wahlfrei Chaos stiften. Von Latenzen zwischen den Komponenten, automatisiertem Abschießen oder absichtlichem überlasten der Services war die Rede. Sie nennen es Chaos Engineering.

Der Geschichte des Chaos Engineerings – erzählt von Beratern

Befeuert wurde diese Geschichte durch den Artikel “The Netflix Simian Army”.

Typisch für unsere Beratungsbranche wurde dieses Vorgehen sofort als die einzige Methode dargestellt, wie man heutzutage Infrastrukturen betreibt.

Der Mythos war geboren. Wie fest er verankert ist, merke ich immer, wenn ich bei meinen Kunden Chaos Engineering einführe. Der Mythos ist fest verankert.

Man liebt es, oder man hasst es. Aber man denkt anscheinend nicht darüber nach!

Möchtest du auf diese Zombie-Berater hereinfallen, die diesen Mythos immer und immer wieder erzählen? Oder möchtest du ein teures und zum Scheitern verurteiltes Experiment wagen?

Ja? Dann hör jetzt auf zu lesen.

Wenn du den restlichen Artikel gelesen hast, wirst du Klarheit über Chaos Engineering haben. Du wirst die echten Experten in der Horde der Schwätzer identifizieren. Du wirst in der Lage sein, mit einfachen Mitteln effizientes und effektives Chaos Engineering in deinem Team einzuführen. Und du wirst dafür sorgen, dass dein Team nie wieder von Problemen der produktiven Anwendungen überrascht wird.

Was dich in diesem Artikel erwartet?

Richtig eingesetzt ist Chaos Engineering das mit Abstand wirkungsvollste Werkzeuge für den resilienten Betrieb deiner Anwendung und den gemeinsamen Erfahrungsaufbau und Lernen im Team.

In diesem Artikel erfährst du:

• Was Chaos Engineering eigentlich ist und was es dir bringt?
• Wie du mit 5 einfachen Schritten direkt mit Chaos Engineering starten kannst?
• Welche 5 Tipps dir helfen, die typischen Fallstricke zu meiden?

So viel Zeit brauche ich von dir: 13 Minuten

Du wirst sehen, wie falsch die meisten Zombie-Berater liegen.

Du wirst verstehen, warum mir das Thema so am Herzen liegt.

Und du wirst es sofort umsetzen.

Der Mythos: Chaos Monkey in Produktion

Ich kann nicht mit Sicherheit sagen, ob sich wirklich Unternehmen daran gemacht haben, ihre Produktion mit einem automatisierten, unkontrollierten Chaos zu überlasten. Man findet leider nur weichgespülte Marketing-Berichte und Success Stories. Hier findest du zum Beispiel eine Darstellung, unter anderem von Unternehmen, die dies angeblich tun. Ob diese Aufstellung der Wirklichkeit entspricht oder ein Traumbild der Selbstdarstellung der Unternehmen ist, lässt sich leider nicht nachvollziehen. Eine fundierte wissenschaftliche Studie ist es auf jeden Fall nicht. größere Problem ist: Die Misserfolge und die Folgen werden ganz selten veröffentlicht, sodass sich ein verzerrtes Bild darstellt.

Falls Unternehmen unkontrolliertes Chaos in ihrer Produktion ausgelöst haben, haben sie vermutlich eine harte Zeit durchgemacht. Zumindest die normalen Unternehmen, die keine High-Tech-Silicon-Valley-Unternehmen mit hoher Fremdfinanzierung sind.

Downtimes, kaputte Infrastruktur, überlastete und überforderte Mitarbeiter, hohe Verluste sind die Folge.

Ich war in einigen Unternehmen, in denen IT-Leiter die Zombie-Berater zum Glück von davon abgehalten haben, Chaos in der Produktion anzurichten. Stattdessen haben wir erfolgreich das gemacht, was ich dir hier im Artikel vermitteln möchte. Das Chaos im verteilten System mit Engineering-Methoden zu reduzieren und weitestgehend unter Kontrolle zu bringen.

Was du von Netflix lernen kannst?

Was kannst du, der IT-Leiter eines KMU in Deutschland, eigentlich von Netflix lernen? Sind das nicht Äpfel und Birnen?

Es stimmt, die normalen KMU in Deutschland, die solide und langfristig wirtschaften lassen sich in der Regel nicht mit den von Milliarden Fremdkapital überhäuften Silicon-Valley Unternehmen vergleichen.

Aber…

Dieser Blickwinkel ist sowohl nachvollziehbar wie auch gefährlich. Denn, nur weil es Teile gibt, die einfach nicht vergleichbar sind, lohnt sich dennoch der Blick über den Tellerrand. Und was du da findest, sollte dich neugierig machen. Es ist gar nicht so weit weg vom KMU-Denken.

1. Netflix hat ein Software-System geschaffen, dass sie nicht mehr kontrollieren konnten. Im Sinne des Cynefin-Frameworks war es ein chaotisches System,
2. Netflix hat mit dem Chaos Engineering ein geeignetes Verfahren entwickelt, mit dem sie das chaotische System “Netflix” unter Kontrolle zu bringen und kontinuierlich dazuzulernen.
3. Netflix hat verstanden, dass ein stabiles bzw. resilientes System nur dann stabil und resilient ist, wenn kontinuierlich das Gleichgewicht gestört und dieses durch Automatismen oder standardisierte Verfahren wiederhergestellt wird. Damit bildet das Team die Fähigkeiten aus, auch ungewöhnliche Situationen souverän zu meistern und die Teilkomponenten so resilient wie möglich zu bauen.

Stell dir das wie das das Training einer Mannschaft vor, die sich auf das nächste große Spiel vorbereitet:

Fast alle Aktionen im Spiel einer hochkarätigen Mannschaft sind einstudierte und perfektionierte Spielzüge, also Standardverfahren. Nur selten gibt es mal einen Geniestreich.

Wie eine hochkarätige Mannschaft sollten sich auch Produktteams durch kontinuierliches Training ständig weiterentwickeln, um damit die Resilienz und Stabilität ihres Produktes weiter zu erhöhen.

Dafür ist Chaos Engineering das perfekte Werkzeug.

Die ernüchternde Wahrheit über Chaos Engineering – Der einfache 5-Phasen-Prozess

Aber was ist Chaos Engineering jetzt eigentlich? Chaos Engineering ist ein vom wissenschaftlichen Vorgehen beeinflusster, kontinuierlicher Prozess. Es basiert auf klaren Prinzipien und besteht aus 5 Phasen:

Phase #1: Stabilen Zustand herstellen (Steady State)

Steady State beschreibt den stabilen Zustand, in dem sich das System zu Beginn des Prozesses befinden muss. Das ist wichtig, damit du dir sicher sein kannst, dass es sich bei dem beobachteten Verhalten um einen kausalen Zusammenhang handelt. Außerdem stellst du damit die Idempotenz sicher. Was bedeutet Idempotenz? Jeder Durchlauf des Experiments liefert immer das gleiche Ergebnis.

Phase #2: Hypothese aufstellen (Hypothesis)

Es ist wichtig, sich vor dem eigentlichen Experiment klar darüber zu werden, was man eigentlich testen möchte. Typische Fragestellungen sind zum Beispiel:

• Wie verhält sich die Queue, wenn der Konsument seine Events nicht abholt?
• Welche Auswirkung hat es auf das Gesamtsystem, wenn ich den Parameter für die Heap-Size drastisch reduziere?
• Was passiert, wenn zwischen dem Service und seiner Datenbank eine Latenz von größer 1 Sekunde ist?

Allerdings eignen sich diese Fragen noch nicht für gute Experimente. Deshalb muss eine konkrete Hypothese entwickelt werden. Beispiele zu den drei Fragen:

• Wenn ein Konsument für 24 Stunden seine Events nicht vom Broker abholt, soll der Speicher des Brokers auch unter einer Last von 50.000 Events pro Minute weiterhin stabil laufen.
• Wenn ich den Heap-Size des Services halbiere, bleibt die Antwortzeit bei normalerer Last von 10 Requests pro Sekunde konstant.
• Wenn ich ich eine Latenz von einer Sekunde zwischen der Datenbank und dem Service einbaue, dann können dennoch alle Daten gespeichert werden.

Es handelt sich also immer um eine Wenn-Dann-Beziehung mit konkreten Messwerten. Natürlich lassen sich auch weitaus komplexere Beziehungen mithilfe des Chaos Engineerings darstellen. Meist lässt sich die zu testende Annahme allerdings so weit isolieren, dass es gar nicht nötig ist, komplexe Tests aufzubauen.

Phase #3: Experiment aufbauen und durchführen (Experiment)

Jetzt folgt der spannende Teil. Das Experiment wird aufgebaut und durchgeführt. Das Experiment beinhaltet immer

• das notwendige Teilsystem (Komponenten/Services) in einem stabilen Zustand,
• Werkzeuge, mit denen das System im Sinne der Hypothese beeinflusst werden kann (Latenz, Netzwerkabbrüche, Speichermangel auf Infrastruktur, …) und
• Werkzeuge, um das Verhalten zu beobachten.

Geeignete Tools zum “Chaos stiften” sind zum Beispiel:

• https://github.com/chaos-mesh/chaos-mesh
• https://github.com/netflix/chaosmonkey
• https://github.com/Shopify/toxiproxy

Um das Verhalten zu beobachten, eignen sich die klassischen Observability Tools:

• Metriken z.B. durch Prometheus und Grafana
• Logs durch Loki, Graylog, Splunk oder den Opensearch-/ELK-Stack
• Tracing durch Jaeger, Kiali oder ähnliches

Phase #4: Überprüfung und Lernen (Verify & Learn)

Ist der Test erfolgreich durchgeführt, geht es an die Analyse. In dieser Phase steht im Vordergrund, das Ergebnis des Tests zu sichern, die Messwerte und Logs zu interpretieren und damit das Verständnis zu erhöhen. Das Ergebnis wird neben die Hypothese gelegt. Hat sich die Annahme bzw. die Hypothese bestätigt?

Ziel dieser Phase ist es, am Ende ein sicheres Gefühl für das Verhalten des Systems in dieser speziellen Situation zu erlangen.

Phase #5: Erkenntnisse zurückspielen

Wenn du regelmäßig dein System mit Chaos Engineering überprüfst, wirst du früher oder später über diverse Konfigurationsprobleme, schlecht gewählte Architekturpatterns und ungünstige Implementierungen stolpern. Das ist normal! Chaos Engineering erhält erst dann einen Wert, wenn die Erkenntnisse im Backlog erscheinen, priorisiert und zeitnah umgesetzt werden.

Erst durch diesen letzten Schritt wird Chaos Engineering von einer brotlosen Kunst zu einem wertvollen Werkzeug.

Die 5 wichtigsten Tipps zum Chaos Engineering

Nachdem du nun die Chaos Engineering Methode kennengelernt hast und weißt, worauf du achten musst, gebe ich dir noch 5 Tipps, die ich mir leidvoll erarbeiten musste.

Tipp #1: KISS-Prinzip einhalten

Beim Chaos Engineering kann man sich wunderbar in den Details verlieren. Es gibt Unmengen an Tools und viele interessante Artikel, die alle zeigen, was man alles tun kann. Allerdings verzetteln sich die Teams meist damit, wenn sie Chaos Engineering einführen wollen.

Deshalb mein Tipp gegen das Verzetteln: Nutze ganz einfache Tools und führe die Chaos-Tests lokal durch.

Der Toxiproxy ist ein solches Werkzeug. Wenn du beispielsweise auf Containern basierende Microservices betreibst, rate ich dir, die notwendigen Container mithilfe von docker-compose zu starten, eventuell Mocks hinzuzufügen und mit dem Toxiproxy Verbindungsabbrüche, Latenzen und ähnliches zu überprüfen. Damit kannst du das Verfahren erlernen, ohne dich in den Untiefen deiner Kubernetes-Distribution und den eingesetzten Profi-Tools zu verirren.

Tipp #2: Blast Radius reduzieren

Chaos Engineering hat den “Charme”, dass man versehentlich sehr viel zerstören kann.

Es ist ein mächtiges Werkzeug, dass es zu kontrollieren gilt.

Deshalb sind zwei Punkte für den Erfolg essenziell:

1. Eine gute Kommunikation an alle betroffenen Stakeholder.
2. Ein Versuchsaufbau, der möglichst wenige Menschen betrifft.

Die meisten Tests können in einer Staging-Umgebung oder (noch besser) auf einem lokalen Entwicklungsrechner durchgeführt werden, ohne dass sie an Aussagewert verlieren. Es gibt allerdings Fälle, die sich nur in einer bestimmten Konstellation überprüfen lassen. Hier ist eine geeignete Kommunikation maßgeblich: Alle Schnittstellenpartner müssen informiert sein, alle notwendigen Kollegen “Gewehr bei Fuß” stehen, damit im Notfall alle koordiniert eingreifen und die auftretenden Probleme lösen können.

Ein mahnendes Beispiel für einen schief gelaufenen Chaos Test ist die Nuklearkatastrophe am 26.04.1986 im Atomkraftwerk in Tschernobyl. Auch wenn die meisten von uns keine solch kritische Infrastruktur betreiben, zeigt es dennoch, wie durch schlechte Planung, unzureichend ausgebildete Fachkräfte und eine starre Führung eine Katastrophe zu einem Super-GAU werden kann.

Gut geplante und durchgeführte Chaos-Tests beschützen euch vor solchen Szenarien.

Tipp #3: Chaos Days durchführen

Ein gutes Beispiel, bei dem Schwarmintelligenz und soziale Interaktionen zu noch besseren Ergebnissen führen können sind die sogenannten Chaos Days.

Einfach zusammengefasst sind Chaos Days ein Workshopformat, in dem dein Team und andere Stakeholder gemeinsam die Chaos Tests durchführen.

Dafür werden zu Beginn mithilfe eines Brainstormings die möglichen Hypothesen identifiziert, die überprüft werden sollen. Danach werden diese gemeinsam ausformuliert und der gesamte Prozess gemeinsam durchlaufen.

Dadurch

• stärkt sich der Wissens- und Erfahrungsaustausch,
• die Kollegen lernen miteinander das System und seine Schwächen kennen und
• die Zusammenarbeit im Alltag wird durch das neu gewonnene Vertrauen gestärkt.

Alles in allem ist es eine gut investierte Zeit, wenn es zielgerichtet abläuft, gut vorbereitet ist und das gemeinsame Erarbeiten im Vordergrund steht.

Tipp #4: Einplanen und regelmäßig durchführen

Wir alle arbeiten nach einem bestimmten Vorgehensmodell. Unabhängig davon, ob es nun Wasserfall, Scrum oder Kanban ist: Chaos Engineering entfaltet erst dann seine volle Wirkung, wenn es regelmäßig durchgeführt und die Ergebnisse zeitnah umgesetzt werden.

Ob ihr nun vierteljährlich Chaos Days durchführt oder im Sprint immer wieder Hypothesen in Form von User Stories überprüft, ist zweitrangig.

Wichtig ist, dass es gegenüber neuen Features nicht ins Hintertreffen gerät.

Tipp #5: Reproduzierbarkeit und Nachvollziehbarkeit sicherstellen

Chaos Tests sind nur dann etwas Wert, wenn sie reproduzierbar und nachvollziehbar sind.

Wenn ein Test durchgeführt wurde und ein paar Wochen später nicht mehr klar ist, wie der Versuchsaufbau aussah und welche Ergebnisse der Test hatte: Wie willst du dann die Verbesserung überprüfen, wenn du dein System entsprechend angepasst hast?

Hier hilft das strukturierte Dokumentieren des Versuchsaufbaus und der Ergebnisse sowie das Sichern des Versuchsaufbaus in git.

Damit habt ihr gleichzeitig eine Referenz für zukünftige Chaos Tests und könnt die bestehenden jederzeit wiederholen.

Bonustipp: Don’t call it Chaos Engineering

Wenn du bei deinen Kunden bei der Einführung von Chaos Engineering auf Widerstand stößt, habe ich einen Bonustipp, der immer hilft: Nenn es einfach anders. Chaos Engineering hieß nicht immer Chaos Engineering. Hier ein paar Vorschläge:

• Failure Injection Tests: Das ist der ursprüngliche Name, den Netflix der Methode gegeben hat. Er beschreibt meiner Ansicht nach noch besser, was hier passiert.
• Desaster Recovery Tests: Beschreibt zwar nur eine Teilmenge der Testarten des Chaos Engineerings, zeigt dabei aber aus Betriebssicht besser den Mehrwert, den es liefert.
• Resilienz-Tests: Das ist der Teil von Chaos Engineering, der eher die Entwicklerbrille aufsetzt.
• Operativer Systemtests: Für alle, die es in deutschen Unternehmen mit eher klassischen Betriebsdenken.

Fazit

Richtig angewendet ist Chaos Engineering ein mächtiges Werkzeug, mit dem du und dein Team das Chaos und die modernen, verworrenen Architekturen analysieren und meistern kannst. Es gibt kaum eine Methode, mit der du schneller das Wissen teilen, Erfahrung aufbauen und die Betriebsstabilität erhöhen kannst. Gleichzeitig ist Vorsicht geboten. Mit ein paar schlecht geplanten Handgriffen kann man sich die Stage, ggf. auch die Produktion zerschießen.

Ob Netflix nun den Chaos Monkey in Produktion einsetzt oder nicht ist eigentlich irrelevant. Wichtig ist: Der Weg dahin, kontrolliertes Chaos in einer produktionsnahen Umgebung anzurichten und damit dein Team fit zu halten, ist lang. Dafür benötigst du

1. ein sehr genaues Wissen darüber, was du und dein Team leisten können und
2. bereits eingespielte Verfahren, das angerichtete Chaos im Griff zu behalten.

Ich wünsche dir viel Spaß dabei, dieses mächtige Werkzeug auszuprobieren,