Chaos Engineering

Bild: Public Domain Pictures - CC0 1.0

Unter den verschiedenen agilen Frameworks gehört das Chaos Engineering zu den weniger bekannten, was vermutlich auch so bleiben dürfte. Es gibt keine bekannten Gründer-Figuren wie im Fall von Scrum, keine dahinterstehende kommerzielle Organisation wie im Fall von SAFe und (leider ein wesentlicher Punkt) keine Zertifikate, durch die der agil-industrielle Komplex zu seiner Verbreitung beitragen würde. Dafür hat Chaos Engineering etwas ganz Anderes: praktische Relevanz.

Entwickelt wurde der Ansatz ca. 2010 bei Netflix, dem amerikanischen Video-Streamingdienst. Den Entwicklern dort wurde über die Zeit schmerzhaft klar, dass sie auf ihren Test-Umgebungen weder das Systemverhalten noch das Anwenderverhalten genau so simulieren konnten wie es in der unberechenbaren Realität auftrat. Wiederholt kam es dort daher zu Fehlern. Ihre Lösung: die Verlagerung einer Grossteils der Qualitätssicherung in den Live-Betrieb.

Die dahinterstehende Logik: wenn Störungen der Live-Umgebungen schon nicht zu vermeiden sind, dann sollten sie zumindest schnell entdeckt werden können und sofort behebbar sein. Und wenn möglich sollten Fehler während der Arbeitszeit auftreten, wenn jemand da ist der sie schnell beheben kann und nicht irgendwann in der Nacht. Um das zu erreichen sollten die Systeme tagsüber ständigen Stresstests ausgesetzt werden, um diese Fehler so auslösen und beheben zu können.

Since we knew that server failures are guaranteed to happen, we wanted those failures to happen during business hours when we were on hand to fix any fallout. We knew that we could rely on engineers to build resilient solutions if we gave them the context to expect servers to fail. If we could align our engineers to build services that survive a server failure as a matter of course, then when it accidentally happened it wouldn’t be a big deal. In fact, our members wouldn’t even notice. This proved to be the case.

Netflix Tech Blog, 2015

Der technische Kern des Chaos Engineering ist die so genannte Affen-Armee, eine Gruppe von Programmen die diese Tests durchführen. Die bekanntesten unter ihnen sind der Chaos Monkey, der nach Zufallsprinzip Live-Server kurzzeitig abschaltet und der Chaos Gorilla, der das Gleiche mit ganzen Rechenzentren macht. Darüber hinaus existieren u.a. der Latency Monkey, der Conformity Monkey und der Security Monkey, die meisten von ihnen als Open Source veröffentlicht.

Den methodischen Rahmen um die Technik bilden die Principles of Chaos Engineering, die ein grober Leitfaden für die Anwendung des Frameworks sind. Im Kern stehen dabei die vier Grund-Prinzipien:

1. Start by defining ‘steady state’ as some measurable output of a system that indicates normal behavior.
2. Hypothesize that this steady state will continue in both the control group and the experimental group.
3. Introduce variables that reflect real world events like servers that crash, hard drives that malfunction, network connections that are severed, etc.
4. Try to disprove the hypothesis by looking for a difference in steady state between the control group and the experimental group.

Mit anderen Worten: definiere einen messbaren, stabilen Ausgangszustand, lass die Affen-Armee auf ihn los und wenn etwas kaputtgeht finde heraus warum. Wichtig ist an dieser Stelle, dass in diesen Prinzipien von dem bei Netflix im Mittelpunkt stehenden Testen auf der Live-Umgebung noch nicht die Rede ist. Dadurch wird Chaos Engineering auch für kritische Anwendungen nutzbar, etwa den Betrieb von Stromnetzen, die man nicht testweise abschalten sollte.

Für andere Anwendungen, bei denen eine Ausfallzeit von wenigen Sekunden oder Minuten unkritisch ist gibt es die "Advanced Principles", deren Umsetzung schwieriger ist, dafür aber auch einen deutlich  höheren Mehrwert bringt:

1. Build a Hypothesis around Steady State Behavior.
2. Vary Real-world Events.
3. Run Experiments in Production.
4. Automate Experiments to Run Continuously.
5. Minimize Blast Radius.

Auch das in vereinfachten Worten: definiere in der Live-Umgebung einen messbaren, stabilen Ausgangszustand, lass die Affen-Armee in immer neuen Variationen auf ihn los und arbeite daran, dass die Auswirkungen immer geringer werden. Der letzte Punkt ist dabei das grosse Ziel - durch immer bessere Ausweichmechanismen und immer grösser werdende Unabhängigkeit von Komponenten und Regionen wird die Auswirkung von Fehlern und Ausfällen immer kleiner (hier ein Beispiel).

Wie zu Beginn gesagt, der grosse Hype wird Chaos Engineering nicht werden, dafür ist es für die HR-Ressorts, Unternehmensberatungen und Trainings-Provider zu technisch und zu wenig profitabel. In den meisten Entwicklungseinheiten wird man dagegen auf Interesse oder sogar auf Begeisterung stossen, da dort sofort klar ist welcher Beitrag zu Agilität und Resilienz von diesem Framework geleistet werden kann.