Chaos Engineering (II)
 |
| 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.1 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.
