Die Idee von Chaos Engineering

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 (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.

Die Logik von Chaos Engineering

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 genauso simulieren konnten, wie es in der unberechenbaren Realität auftrat. Wiederholt kam es daher zu Fehlern. Ihre Lösung: die Verlagerung eines Großteils 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.

“Da wir wussten, dass es garantiert zu Serverausfällen kommen würde, wollten wir, dass diese Ausfälle während der Geschäftszeiten auftreten, wenn wir vor Ort sind, um eventuelle Schäden zu beheben. Wir wussten, dass wir uns darauf verlassen konnten, dass unsere Techniker belastbare Lösungen entwickeln würden, wenn wir ihnen den Kontext gaben, in dem sie mit Serverausfällen rechnen mussten. Wenn wir unsere Techniker darauf ausrichten könnten, Dienste zu entwickeln, die einen Serverausfall ganz selbstverständlich überstehen, dann wäre es keine große Sache, wenn er versehentlich auftritt. Tatsächlich würden unsere Mitglieder es nicht einmal bemerken. Dies war der Fall.”³

Der Kern und die Prinzipien von Chaos Engineering

Der technische Kern des Chaos Engineering ist die sogenannte 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. Definieren Sie zunächst den Begriff “stabiler Zustand” als eine messbare Leistung eines Systems, die ein normales Verhalten anzeigt.
2. Stellen Sie die Hypothese auf, dass dieser stabile Zustand sowohl in der Kontrollgruppe als auch in der Versuchsgruppe bestehen bleibt.
3. Führen Sie Variablen ein, die reale Ereignisse widerspiegeln, z. B. Server, die abstürzen, Festplatten, die nicht funktionieren, Netzwerkverbindungen, die unterbrochen werden, usw.
4. Versuchen Sie, die Hypothese zu widerlegen, indem Sie nach einem Unterschied zwischen der Kontrollgruppe und der Versuchsgruppe suchen.

Mit anderen Worten: definieren Sie einen messbaren, stabilen Ausgangszustand, lassen Sie die Affen-Armee auf ihn los und wenn etwas kaputtgeht, finden Sie die Ursache dafür heraus. 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. Erstellen Sie eine Hypothese über das Verhalten im eingeschwungenen Zustand.
2. Variieren Sie Ereignisse der realen Welt.
3. Experimentieren Sie in der Produktion.
4. Automatisieren Sie Experimente zur kontinuierlichen Ausführung.
5. Minimieren Sie den Explosionsradius.

Auch das in vereinfachten Worten: definieren Sie in der Live-Umgebung einen messbaren, stabilen Ausgangszustand, lassen Sie die Affen-Armee in immer neuen Variationen auf ihn los und arbeiten Sie daran, dass die Auswirkungen immer geringer werden. Der letzte Punkt ist dabei das große Ziel – durch immer bessere Ausweichmechanismen und immer größer werdende Unabhängigkeit von Komponenten und Regionen wird die Auswirkung von Fehlern und Ausfällen immer kleiner.⁶

Was hat Chaos Engineering mit Agilität zu tun?

Wäre es nicht langsam Zeit für den Abschnitt über Rollen, Meetings, Verantwortlichkeiten und Lieferzyklen? Nicht wirklich. Derartige Elemente existieren zwar in einigen Frameworks (vor allem Scrum und SAFe), Agilität ist aber etwas viel Grundlegenderes: Die Fähigkeit in kurzen Abständen lieferfähig und reaktionsfähig zu sein – und dazu trägt Chaos Engineering mit seinem Fokus auf schnelle Fehler-Entdeckung und System-Resilienz definitiv bei.

Darüber hinaus ergibt sich aber noch ein zweiter “agiler Aspekt”, denn es wird normalerweise nicht versucht, diese System-Resilienz auf einmal, also in einem Big Bang⁷ herbeizuführen. Stattdessen soll sie nach und nach wachsen und ausgebaut werden, was ziemlich genau dem iterativ-inkrementellen Ansatz praktisch aller agilen Frameworks entspricht. In gewisser Weise ist dabei die System-Resilienz selbst das Produkt, das basierend auf echten Anwendungserfahrungen ständig weiterentwickelt wird.

In der Umsetzung kann diese “inkrementelle Resilienz” so aussehen, dass das System zuerst kleineren, noch beherrschbaren Störungen ausgesetzt wird. Sobald es für diese einen funktionierenden Kompensations-Mechanismus gibt, können etwas größere folgen, sobald auch diese kompensierbar sind, nochmal größere, etc. Beispiele für solche kleineren Störungen wären zu Beginn noch moderate Nutzungs-Anstiege oder eine zunächst nur geringe Reduzierung des verfügbaren Speicherplatzes.

An diesen Beispielen lässt sich gut absehen, wie die immer anspruchsvolleren Experimente (so nennt man in Chaos Engineering die Stresstests) aussehen könnten. Das Ausmaß der Störfaktoren (in diesen Fällen steigende Nutzungsintensität und schrumpfender Speicherplatz) kann mit jedem Experiment hochgeschraubt werden, bis zu dem Punkt, an dem der komplette Ausfall einer ganzen AWS-Region⁸ simuliert wird.

Darüber hinaus ist es in späteren “Resilienz-Inkrementen” auch sinnvoll, verschiedene Experimente gleichzeitig auf demselben System laufen zu lassen, um auch mögliche Interdependenzen erkennen zu können. Um bei den Beispielen zu bleiben: gleichzeitig steigende Nutzungsintensität und schrumpfender Speicherplatz, in einem nächsten Experiment dann zusätzlich dazu noch die Simulation von Übertragungsstörungen oder ausfallender Leitungen.

Scrum und “soziales Chaos Engineering”

Rein theoretisch ließe sich Chaos Engineering sogar nach Scrum umsetzen, mit jeweils einem Experiment als Sprintziel⁹ und den damit verbundenen Umsetzungs-, Monitoring- und Stabilisierungsmaßnahmen als Backlog Items. Gegenstand der Sprint Reviews wären die erfolgreich verhinderten (oder doch stattgefundenen) Systemausfälle, die eingeladenen Stakeholder wären die Verantwortlichen der dort betriebenen Anwendungen, die dann sagen können, wie viel mehr Ausfallsicherheit sie benötigen.

In derartigen Kontexten könnte man sogar noch einen Schritt weiter gehen und Chaos Engineering auf das umsetzende Team selbst anwenden. Auch hier lassen sich einzelne Personen temporär aus den Arbeitsabläufen herausnehmen, um festzustellen, ob die anderen diesen Ausfall kompensieren können. Ist das nicht der Fall, ist ein Problem identifiziert, das beim nächsten Urlaub oder Krankheitsfall für Störungen oder Stillstand sorgen würde.

Die Problembehebung ist dann relativ einfach, denn in fast allen Fällen liegt einer von zwei Root Causes vor: entweder fehlen den anderen Mitarbeitern die Kenntnisse, um die Tätigkeiten des ausfallenden Kollegen zu übernehmen. Das kann kompensiert werden, indem sie sich in Richtung T-Shape oder Full Stack entwickeln. Oder ihnen fehlen Zugriffsberechtigungen auf die vom ausfallenden Kollegen verantworteten Systeme, was sich lösen lässt, in dem diese erteilt werden.

Ein zum Glück seltener werdender dritter Root Cause liegt vor, wenn der ausfallende Kollege Code Ownership in Teilen der Anwendung hat, also vereinbart wurde, dass er als Einziger dort Änderungen vornehmen darf. Eine andere Variante dieses Problems ist es, wenn nur eine Person für bestimmte Bereiche Pull Requests annehmen, also Änderungen genehmigen darf. Die Lösung ist in beiden Fällen einfach – man muss nur diese limitierenden Regeln abschaffen.

Die Ergebnisse von “sozialem Chaos Engineering” sind häufig überraschend, da Wissensmonopole, Berechtigungsengpässe und Code Ownership nicht immer explizit gemacht werden. Oft sind sie eher unbemerkt entstanden und werden selbst von den Beteiligten in ihrer Tragweite unterschätzt. Um so wichtiger ist es, herauszufinden, ob sie vorliegen. Und einen netten Nebeneffekt gibt es auch noch: die temporär abwesenden Kollegen haben Zeit für Weiterbildung oder Überstundenabbau.

Fazit

Chaos Engineering ist ein agiles Framework, das deshalb so interessant ist, weil es sich erkennbar von den anderen unterscheidet. Man muss sich nur davon trennen, “Agile” lediglich als eine Sammlung von Rollen, Meetings und Prozessen zu sehen, wenn man den Sinn in ihm erkennen will. Der große Hype wird es wie zu Beginn gesagt nicht werden, dafür ist es für die HR-Ressorts, Unternehmensberatungen und Trainings-Provider zu technisch und zu wenig profitabel (da ohne Zertifizierungen). In den meisten Entwicklungseinheiten wird die Idee dagegen auf Interesse oder sogar auf Begeisterung stoßen, da dort sofort klar ist, welcher Beitrag zu Agilität und Resilienz von diesem Framework geleistet werden kann. Und mit dem sozialen Chaos Engineering kann es sogar zur Teamentwicklung eingesetzt werden.

Hinweise:

Wenn Ihnen der Beitrag gefällt oder Sie darüber diskutieren wollen, teilen Sie ihn gerne in Ihrem Netzwerk. Und falls Sie sich für weitere Tipps aus der Praxis interessieren, dann testen Sie gerne unseren wöchentlichen Newsletter mit neuen Beiträgen, Downloads und Empfehlungen.

[1] Was ist der agil-industrielle Komplex?
[2] [4] The Netflix Simian Army
[3] Netflix Technology Blog: Chaos Engineering Upgraded
[5] Principles of Chaos Engineering
[6] Hier ein Beispiel: From Chaos to Control — Testing the resiliency of Netflix’s Content Discovery Platform
[7] Bing Bang-Releases
[8] AWS suffers another outage as East Coast datacenter loses power
[9] Sprinziele

Felix Stein veröffentlicht regelmäßig Beiträge in dem zurecht sehr bekannten und beliebten Blog On Lean and Agility. Definitiv mehr als einen Besuch wert!

Felix Stein hat einen weiteren Beitrag im t2informatik Blog veröffentlicht:

Was macht eigentlich t2informatik? Ein Klick hier und Sie wissen es.