On Lean and Agility

Bild: Pixabay / GlauchauCity - Lizenz

Dem regelmässigen Leser dieser Seite dürfte es aufgefallen sein, dass ich ein Fan von Chaos Engineering bin. Als technische Praktik kann es entscheidend dafür sorgen, dass die in den methodischen Frameworks vorgesehehene kontinuierliche Liefer- und Reaktionsfähigkeit tatsächlich auch stattfinden kann. Darüber hinaus lässt sich Chaos Engineering aber auch von der Technik lösen und selbst als methodischer Ansatz einsetzen.

Noch einmal kurz zur Erinnerung: Chaos Engineering stellt die Resilienz (und damit auch die Liefer- und Reaktionsfähigkeit) eines Systems sicher indem auf Produktion nach Zufallsprinzip wichtige Ressourcen temporär abgeschaltet werden (Server, Übertragungskapazitäten, etc.). Übersteht das System diesen Stresstest ist alles gut, übersteht es ihn nicht, wird klar, an welcher Stelle an Kompensations-Automatismen gearbeitet werden muss.

Auf dieser Abstraktionsebene beschrieben lässt sich die Idee problemlos auf soziele Systeme übertragen, also auf Teams, Abteilungen oder Projekte. Auch hier lassen sich einzelne Ressourcen (→ 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, Berechtigungs-Engpä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 Überstunden-Abbau.

Grafik: Wikimedia Commons / Henrique José Teixeira Matos - CC BY-SA 3.0

Dass Chaos Engineering zu den eher unbekannten und unterschätzten agilen Frameworks gehört, dürfte auch daran liegen, dass nicht sofort ersichtlich ist, was es eigentlich mit Agilität zu tun hat. Sowohl von der formalen Perspektive (Prozesse, Rollen, Meetings, etc.) als auch von den Ergebnissen (Releases, Incremente, Features, o.Ä.) bietet es wenig von dem, was wir von SAFe, Scrum & Co kennen. Man muss es anders betrachten.

Der erste "agile Aspekt", über den ich bereits geschrieben habe, ist die Resilienz. Wenn wir Agilität als die Fähigkeit definieren, in kurzen Zyklen reaktions- und lieferfähig zu sein, dann muss man verhindern, dass Störungen und Ausfälle die eigenen Systeme für längere Zeiträume betriebsunfähig machen.¹ Der Weg den Chaos Engineering wählt um das zu verhindern sind permanente Stresstests, durch die Schwachstellen möglichst früh erkannt und behoben werden können.

Darüber hinaus ergibt sich aber noch ein zweiter "agiler Aspekt", denn es wird nicht versucht, diese System-Resilienz auf einmal, also in einen Big Bang herbeizuführen. Stattdessen soll sie nach und nach wachsen und ausgebaut werden, was ziemlich genau dem iterativ-incrementellen 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 "incrementelle 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össere folgen, sobald auch diese kompensierbar sind nochmal grössere, etc., 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 Ausmass der Störfaktoren (in diesen Fällen steigende Nutzungs-Intensität und schrumpfender Speicherplatz) kann mit jedem Experiment hochgeschraubt werden, bis zu dem Punkt an dem selbst Grosstörungen wie der komplette Ausfall einer ganzen AWS-Region simuliert werden können.

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

Rein theoretisch liesse sich Chaos Engineering sogar nach Scrum umsetzen, mit jeweils einem Experiment als Sprintziel und den damit verbundenen Umsetzungs-, Monitoring- und Stabilisierungs-Massnahmen 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.

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

Eigentlich bin ich kein Fan davon in einem Arbeitskontext den Begriff  "Chaos" zu verwenden, da er in meinem Verständnis einen Zustand beschreibt in dem Arbeiten eigentlich nicht mehr möglich ist. "Chaos Engineering" hat sich allerdings mittlerweile als Name für ein bestimmtes Vorgehen durchgesetzt, auf das sich ein näherer Blick lohnt. Gut, dass Nora Jones, eine der Verfasserinnen des gleich benannten Buchs, regelmässig Vorträge zu diesem Thema hält.

Sehenswert ist dieser Vortrag aber nicht nur weil Jones erklärt was Chaos Engineering ist, er ist auch deshalb wichtig weil sie in ihm unterstreicht, dass der ganze Ansatz nur wenig bringt wenn er nur von wenigen Experten und Enthusiasten angewandt wird. Erst wenn sich die gesamte Produktentwicklung an den "Chaos-Experimenten" beteiligt entfaltet sich die ganze Wirkung.