Chaos Engineering in der Praxis: Hypothesen, Störungen und belastbare Systeme – unsere Learnings aus „What is Chaos Engineering?“ von Jürgen Etzlstorfer (Microsoft Österreich)

Warum Chaos Engineering jetzt zählt

In „What is Chaos Engineering?“ machte Jürgen Etzlstorfer (Microsoft Österreich) unmissverständlich klar: Chaos Engineering ist kein Bauchgefühl und keine spontane Mutprobe, sondern eine Ingenieursdisziplin. Ziel ist es, in kontrollierter Weise Fehler in Anwendungen und ihre Umgebung einzuführen, um die Auswirkungen auf das Gesamtsystem zu verstehen und gezielt zu verbessern. Statt „mal schnell“ eine Maschine abzuschalten, steht ein methodischer Ansatz im Vordergrund – mit Hypothese, Experiment, Messung und Verbesserung.

Ein zentraler Punkt: Gerade Cloud‑Anwendungen und verteilte Systeme müssen aktiv auf Ausfälle vorbereitet werden. Ob Kubernetes Workloads über Knoten verteilt, ein Load Balancer umschwenkt oder ein Microservice nicht erreichbar ist – jedes Unbekenntnis im Verhalten kostet im Ernstfall Zeit. Und Zeit ist Entwicklerzeit. Etzlstorfer erinnerte daran, dass Ausfälle unmittelbar Feature‑Entwicklung und Produktverbesserung verdrängen, weil Bugfixes, Konfigurationsanpassungen und Stabilitätsmaßnahmen Priorität gewinnen. Chaos Engineering ist deshalb ein Hebel für Qualität und Resilienz – und damit für den Fortschritt am Produkt selbst.

Problemraum: Verteilte Systeme, orchestrierte Workloads und fragile Annahmen

Etzlstorfer ordnete den Problemraum mit einem einfachen, aber wirksamen Bild ein: Die Anwendung ist nur die Spitze einer Pyramide. Darunter liegen Schichten wie Compute, Netzwerk, Datenbanken, Container‑Orchestrierung (z. B. Kubernetes) und oft auch externe Drittanbieter. Jede dieser Schichten kann ausfallen – und die Anwendung muss robust reagieren.

Er betonte zudem, wie sehr wir Entwicklerinnen und Entwickler auf Annahmen bauen: „Natürlich ist das Netzwerk verfügbar.“ – „Natürlich hat die Umgebung genug CPU und Storage.“ – „Natürlich antwortet der Drittservice.“ Diese Selbstverständlichkeiten gelten im Labor oft, im Produktionsbetrieb aber nur bedingt. Es gibt Dinge, von denen wir wissen, dass wir sie wissen. Dinge, von denen wir wissen, dass wir sie nicht wissen. Und Dinge, an die wir nie gedacht haben. Genau deshalb sollten Anwendungen so gestaltet werden, dass sie auch bei Ausfällen außerhalb des unmittelbaren Scopes weiter sinnvoll reagieren.

Kubernetes als Orchestrierungslayer

Für alle, die Kubernetes noch nicht im Detail kennen, fasste Etzlstorfer die Rolle prägnant zusammen: Ein Orchestrierungslayer für containerisierte Anwendungen, der Workloads zwischen Servern verschieben kann. Das bedeutet: Anwendungen müssen mit Skalierung, Shutdowns, Umzügen zwischen Knoten, Failover‑Szenarien und Load‑Balancing umgehen können. Chaos Engineering hilft, diese Verhaltensweisen frühzeitig zu überprüfen.

Microservices und Kaskadeneffekte

In Microservice‑Architekturen genügt der Ausfall eines einzigen Services, um die Gesamtverfügbarkeit zu beeinträchtigen. Dependencies multiplizieren Risiken. Wer Microservices baut, testet mit Chaos Engineering nicht nur einzelne Services, sondern die systemische Widerstandsfähigkeit der gesamten Architektur.

Von der Hypothese zum Experiment: So wird Resilienz messbar

Der Weg zu belastbaren Systemen beginnt mit einer klaren Hypothese und einer definierten „steady state“-Bedingung. Etzlstorfer nannte als Beispiel eine Zielantwortzeit von 200 ms. Die Leitfrage: Bleibt der steady state unter definierten Störungen erhalten?

• Hypothese: „Unser System antwortet mit < 200 ms.“
• Experiment: „In einem High‑Availability‑Setup entfernen wir einen Knoten.“
• Beobachtung: „Unter Last – halten wir weiterhin die 200 ms?“

Fällt die Antwort positiv aus, ist die Anwendung resilient gegenüber genau diesem Fehlerbild. Wenn nicht, haben wir eine Schwäche identifiziert. Mögliche Maßnahmen: Skalierung, eine andere Konfiguration des Load Balancers oder Caching. Der Punkt ist nicht, jede denkbare Störung zu eliminieren, sondern gezielt, wiederholbar und messbar zu verbessern.

SRE‑Konzepte als Messrahmen: SLI und SLO

Die Metriken und Zielgrößen entnimmt Chaos Engineering erprobten Konzepten aus dem Site Reliability Engineering:

• Service Level Indicator (SLI): Ein messbarer Indikator, z. B. die Fehlerquote von Login‑Requests oder die Antwortzeit eines Frontend‑Services.
• Service Level Objective (SLO): Ein Zielwert für den SLI, z. B. „Antwortzeit < 200 ms über 10 Minuten“ oder „Login‑Fehlerquote < 2 % über einen definierten Zeitraum“.

Mit SLIs und SLOs wird Resilienz operationalisiert. Nach jedem Experiment lässt sich klar entscheiden, ob die Ziele erreicht wurden oder nicht – und welche Maßnahmen folgen.

Wo Chaos injizieren? Ebenen, Störmuster und Rahmenwerk

Störungen können auf unterschiedlichen Ebenen angesetzt werden – und sollten es auch, je nach Fragestellung:

• In der Anwendung: gezielte Pausen/Delays im Code. Wichtig: Chaos ist nicht das Einschleusen von Bugs, sondern das bewusste Einführen kontrollierter Verzögerungen oder Pausen.
• Auf dem Betriebssystem: z. B. CPU‑ oder IO‑Stress.
• Im Netzwerk: Paketverlust, Latenzerhöhung, vollständige Unterbrechung.
• In Cloud‑Ressourcen und Infrastruktur: Knoten entfernen, Storage verknappen, Services nicht verfügbar machen.

Entscheidend ist laut Etzlstorfer, nicht ad hoc und manuell „an Kabeln zu ziehen“, sondern ein Framework zu nutzen. Idealerweise deklarativ definiert – im Sinne von Infrastructure as Code –, damit Experimente reproduzierbar, dokumentiert und orchestrierbar sind.

Tools, die Etzlstorfer hervorhob

• Chaos Monkey (Netflix): ein früher Pionier, „zumindest nach seinem Kenntnisstand“ nicht mehr verfügbar.
• Litmus Chaos (Open Source): weit verbreitet, mit Bibliotheken an Störaktionen.
• Chaos Mesh (Open Source): bildet die Grundlage für Azure Chaos Studio.
• Gremlin (kommerziell): seit Jahren am Markt.

Gemeinsam ist diesen Werkzeugen, dass sie Kataloge vordefinierter Chaos‑Aktionen mitbringen (z. B. CPU/Storage erschöpfen, Netzwerk kappen), diese starten/stoppen und orchestrieren können. Der Rat: Diese Fähigkeiten nutzen – statt eigene Ad‑hoc‑Skripte zu basteln.

Vom Einmal‑Experiment zur kontinuierlichen Praxis

Etzlstorfer zog eine klare Parallele zum Lasttest: Niemand würde Lasttests „einmal im Monat“ laufen lassen und dann als erledigt betrachten. Stattdessen gehören sie in die Pipeline – zu jedem Feature, jedem Bugfix, jeder Version. So auch Chaos Engineering: Nicht punktuell, sondern kontinuierlich.

Ein dedizierter „Chaos“-Stage in der Pipeline

Als konkretes Beispiel stellte Etzlstorfer das Open‑Source‑Projekt Captain vor, in dem er selbst stark involviert ist. Die Idee: Eine eigene Pipeline‑Stufe, die explizit Chaos‑Experimente enthält. Das Abbild einer modernen CI/CD‑Linie könnte so aussehen:

1. Deploy der Anwendung in den Chaos‑Stage.
2. Start der Lasttests (z. B. mit K6 oder JMeter).
3. Start der Chaos‑Experimente mit dem gewählten Framework.
4. Warten, bis Tests abgeschlossen sind (z. B. 10 Minuten oder eine Stunde – Dauer ist kontextabhängig).
5. Triggern der SLO‑Evaluation: Metriken aus Tools wie Prometheus oder Dynatrace abrufen und gegenüber den festgelegten Zielen evaluieren.
6. Ergebnis interpretieren: SLO erfüllt → Resilienz bestätigt. SLO verfehlt → Schwäche identifiziert, nächste Iteration planen.

Captain orchestriert diese Abfolge und stellt die Bausteine bereit, um Evaluation und Abläufe zu automatisieren. Die Botschaft: Aus Ad‑hoc‑Chaos wird kontinuierliches Chaos‑Testing – und damit ein reifer, ingenieurmäßiger Prozess.

Ein konkreter Ablauf – Schritt für Schritt

Basierend auf Etzlstorfers Talk lässt sich ein praxistauglicher Ablauf wie folgt strukturieren:

1. Steady State definieren

• Welche SLI/SLO sind ausschlaggebend? Beispiel: „Antwortzeit < 200 ms über 10 Minuten“ oder „Login‑Fehlerquote < 2 % über den Release‑Zyklus“.
• Welche Last betrachten wir? Realistische Lastprofile über Lasttests simulieren.

1. Hypothese formulieren

• Beispiel: „Bei Ausfall eines Knotens bleibt die Antwortzeit unter 200 ms.“
• Alternativ: „Wenn ein Drittservice ausfällt, bleibt die Login‑Fehlerquote < 2 %.“

1. Störung festlegen

• Knoten entfernen (HA‑Szenario).
• Netzwerk für bestimmte Services unterbrechen.
• CPU‑/Storage‑Erschöpfung simulieren.
• In der Anwendung gezielte Delays setzen (keine Bugs einbauen!).

1. Experiment deklarativ beschreiben und automatisieren

• Chaos‑Framework wählen (z. B. Litmus Chaos, Chaos Mesh, Gremlin).
• Experimente als Code definieren, sodass sie reproduzierbar sind.

1. Last und Chaos kombinieren

• Lasttest (z. B. K6 oder JMeter) parallel zu Chaos‑Experimenten ausführen.
• Beobachten, ob SLIs innerhalb der SLO‑Grenzen bleiben.

1. Messen und evaluieren

• Metriken aus Metrik‑/Tracing‑Tools (z. B. Prometheus, Dynatrace) einsammeln.
• SLO‑Bewertung auslösen und Entscheidungen datenbasiert treffen.

1. Ergebnisorientiert verbessern

• Bei Zielerreichung: Experiment dokumentieren, als Regressionstest behalten.
• Bei Zielverfehlung: Engpass adressieren – z. B. Skalierung, Load‑Balancer‑Konfiguration, Caching –, erneut testen.

1. Pipeline‑Integration sicherstellen

• „Chaos‑Stage“ fest verankern, um jede Änderung automatisch zu validieren.

Dieser Ablauf spiegelt exakt die Kernideen des Talks: Hypothese → Experiment → Messung → Verbesserung – und das als fortlaufender Prozess statt einmaliger Aktion.

Wichtige Prinzipien, die Etzlstorfer betonte

• Kontrolliert statt willkürlich: Keine Ad‑hoc‑Experimente durch das manuelle Abschalten von Maschinen, sondern definierte, deklarative Experimente mit passender Orchestrierung.
• Systemdenken statt App‑Tunnelblick: Die Anwendung sitzt auf einem Stack – jede Schicht kann ausfallen. Resilienz ist eine Eigenschaften des Gesamtsystems.
• Annahmen hinterfragen: Genug Compute, zuverlässige Netzwerke, verfügbare Drittservices – diese Annahmen sind oft ungetestet. Chaos‑Experimente machen implizite Annahmen explizit.
• Metrik‑getrieben entscheiden: SLIs wählen, SLOs festlegen, Experimente messen und auswerten.
• Kontinuität geht vor Einmaligkeit: Wie bei Lasttests gilt: In die Pipeline integrieren, jede Änderung prüfen, Regressionen vermeiden.

Typische Störszenarien – und was wir daraus lernen

Etzlstorfer nannte exemplarisch mehrere Störmuster, die in modernen Stacks große Wirkung entfalten. Der Lerneffekt entsteht nicht aus der reinen Störung, sondern aus der Verknüpfung mit SLIs/SLOs und Last.

• Knoten entziehen in HA‑Setups: Prüft, ob die Architektur wirklich ausfallsicher ist und Last korrekt umverteilt wird.
• Netzwerk kappen: Deckt Abhängigkeiten und Timeouts auf – reagiert die Anwendung fail‑safe oder hängt sie?
• CPU/Storage erschöpfen: Testet Backpressure‑Strategien und Graceful Degradation.
• In‑App‑Delays: Simuliert langsame Downstream‑Services oder interne Engpässe.

Der Output ist binär und doch aussagekräftig: SLO getroffen oder verfehlt. Daraus leiten sich konkrete Maßnahmen ab – z. B. mehr Instanzen, anderer Failover‑Modus, zwischengeschaltetes Caching.

Rollen und Zuständigkeiten im Teamkontext

Auch wenn der Talk explizit Entwickler adressierte, ist die Quintessenz teamübergreifend: Jede Stunde, die in ungeplante Entstörung fließt, fehlt in der Feature‑Entwicklung. Chaos Engineering schafft die Grundlage, Resilienz als Teamziel zu leben – Entwickler, Ops, SREs. Der Fokus liegt auf wiederholbaren Experimenten, nachvollziehbaren Metriken und klaren Entscheidungen. Genau das spart am Ende jene Zeit, die wir in Neues investieren wollen.

Von der Theorie zur Gewohnheit: So bleibt Chaos Engineering wirksam

• Klein anfangen, fokussiert messen: Ein oder zwei SLOs, ein klares Störszenario (z. B. Knotenverlust) – und loslegen.
• Experimente standardisieren: Deklarativ beschreiben, versionieren, in die Pipeline integrieren.
• Last hinzugeben: Nur unter relevanter Last sind die Ergebnisse aussagekräftig.
• Evaluation automatisieren: Nach jedem Durchlauf SLOs bewerten lassen, Ergebnisse transparent machen.
• Ergebnisse in Verbesserungen übersetzen: Architektur‑ und Konfigurationsanpassungen gezielt vornehmen, erneut testen.

Diese Schritte sind genau die, die Etzlstorfer skizziert: ein konsistenter, wiederholbarer Prozess – nicht das eine „spektakuläre“ Experiment.

Fazit: Ein reifer Weg zu resilienten Systemen

„What is Chaos Engineering?“ von Jürgen Etzlstorfer (Microsoft Österreich) destilliert die Praxis auf einen klaren Kern: Definiere den Normalzustand, injiziere gezielte Störungen, miss gegen SLOs – und automatisiere den Zyklus in der Pipeline. Werkzeuge wie Litmus Chaos, Chaos Mesh (Basis für Azure Chaos Studio) und Gremlin liefern die Bausteine. Lasttests (z. B. K6 oder JMeter) und Metrik‑Quellen (z. B. Prometheus, Dynatrace) schließen den Kreis.

Vor allem aber ist die Haltung entscheidend: Chaos Engineering ist eine Ingenieursdisziplin. Wer dies verinnerlicht, verhindert Ad‑hoc‑Aktionen, gewinnt belastbare Erkenntnisse und schützt die knappste Ressource im Team – die Entwicklerzeit.

Kern‑Takeaways für Engineering‑Teams

• Starte mit Hypothesen und definierten steady‑state‑Metriken (SLIs/SLOs).
• Integriere Chaos‑Experimente in die Pipeline, nicht als einmalige Aktion.
• Nutze etablierte Tools statt ad‑hoc Eingriffen.
• Messe systematisch und evaluiere SLOs nach jedem Experiment.
• Verbessere gezielt: Skalierung, Load Balancing, Caching – was die Messung nahelegt.
• Denke in Schichten: Die Anwendung ist nur die Spitze; jede Ebene kann ausfallen.
• Entwickle für den Ernstfall: Deine Anwendung sollte auch außerhalb des eigenen Scopes sinnvoll reagieren.

Damit wird Chaos Engineering vom Buzzword zur praktischen Qualitätssicherung – mit klaren Metriken, reproduzierbaren Experimenten und kontinuierlicher Verbesserung, genau so, wie es in „What is Chaos Engineering?“ vorgestellt wurde.