Wer kennt es nicht: Das System läuft wochenlang stabil, die Tests sind grün, das Monitoring zeigt keine Auffälligkeiten. Dann fällt etwas aus – und das Team stellt fest, dass ein Dienst ohne seine ausgefallene Abhängigkeit nicht funktioniert, obwohl das niemand so explizit gebaut hat. Chaos Engineering ist der Versuch, solche Schwachstellen zu finden, bevor die Produktion es tut.
Was Chaos Engineering wirklich bedeutet
Der Begriff geht auf Netflix zurück. 2011 veröffentlichte das Unternehmen sein Tool Chaos Monkey, das in der Produktionsumgebung zufällig Instanzen herunterfährt – mit dem Ziel, die Resilienz des Gesamtsystems zu testen und sicherzustellen, dass kein einzelner Ausfall zu einem vollständigen Systemversagen führt.
Die zugrunde liegende Idee ist älter als Netflix: Wer wissen will, ob ein System unter Stress standhält, muss es unter kontrollierten Bedingungen stressen. Chaos Engineering formalisiert diesen Gedanken zu einem wiederholbaren Prozess mit klaren Hypothesen, definierten Beobachtungen und dokumentierten Auswertungen.
Die Kernfrage lautet immer: Wie verhält sich das System, wenn Komponente X ausfällt? Und die Antwort sollte aus einem Experiment kommen – nicht aus einer Annahme.
Die vier Grundprinzipien
Gute Chaos-Engineering-Experimente folgen einem gemeinsamen Rahmen:
- Normalzustand definieren: Was ist der erwartete, messbare Normalzustand des Systems? Das kann eine Antwortzeit unter 200 ms sein, eine Fehlerrate unter 0,1 % oder eine Verfügbarkeit von 99,9 %.
- Hypothese formulieren: „Wenn Datenbankknoten B ausfällt, wird die Applikation weiterhin Leseanfragen über die verbleibenden Knoten bearbeiten, ohne dass die Fehlerrate sichtbar steigt."
- Experiment durchführen: Gezielt Störung einführen – einen Pod killen, Netzwerklatenz erhöhen, DNS-Auflösung blockieren.
- Ergebnis beobachten und auswerten: Hat das System wie erwartet reagiert? Wenn ja: Vertrauen gestärkt. Wenn nein: Schwachstelle gefunden und behoben.
Einstieg ohne Netflix-Budget
Viele IT-Teams schrecken vor Chaos Engineering zurück, weil sie es mit komplexen Kubernetes-Setups und dedizierten SRE-Teams verbinden. Das ist verständlich, aber nicht zwingend. Selbst in kleinen Umgebungen lassen sich mit wenig Aufwand wertvolle Erkenntnisse gewinnen.
Ein einfacher Einstieg ist der manuelle Game Day. Das Team plant einen festen Termin, wählt ein einzelnes Experiment – etwa „Wir stoppen den Cache-Dienst für fünf Minuten" – und beobachtet, wie die Applikation reagiert. Kein spezielles Tool, kein komplexer Automatisierungsrahmen. Nur ein gezielter Eingriff, ein Monitoring-Dashboard und ein Protokoll.
Bereits ein solcher Game Day liefert oft überraschende Erkenntnisse: Fehlerseiten, die nie getestet wurden; Timeouts, die nirgendwo im Code konfiguriert sind; Abhängigkeiten, die niemand im Team so explizit kannte.
Werkzeuge für strukturiertes Vorgehen
Wer wiederholbarer und skalierbarer vorgehen möchte, findet inzwischen mehrere gut nutzbare Werkzeuge:
- Chaos Toolkit: Ein Python-basiertes CLI-Tool, das Experimente als JSON- oder YAML-Dateien beschreibt und ausführt. Es integriert sich mit Kubernetes, AWS, Azure und weiteren Plattformen. Gut geeignet für Teams, die Experimente versionieren und im Zeitverlauf vergleichen möchten.
- Pumba: Ein leichtgewichtiges Tool für Docker-Umgebungen. Pumba kann Container gezielt stoppen, pausieren oder Netzwerkverzögerungen einführen – ideal für kleinere Deployments ohne Kubernetes.
- LitmusChaos: Für Kubernetes-Umgebungen bietet LitmusChaos eine umfangreiche Bibliothek von Chaos-Experimenten sowie eine Web-UI, die auch weniger erfahrene Teammitglieder bedienen können.
- tc (Traffic Control): Linux-Bordmittel, das sich nutzen lässt, um auf Netzwerkebene Latenz, Paketverlust oder Bandbreitenbeschränkungen zu simulieren – ohne spezielle Software zu installieren.
KI und Chaos Engineering: Neue Möglichkeiten 2026
KI-Werkzeuge beginnen auch im Bereich Chaos Engineering Einzug zu halten. Sprachmodelle werden eingesetzt, um aus bestehenden Systemarchitekturen automatisch Hypothesen für Experimente zu generieren. Statt manuell zu überlegen, welche Komponente wie kritisch ist, analysiert das Modell Abhängigkeitsgraphen und Service-Maps und schlägt Experimente vor.
Erste kommerzielle Anbieter haben damit begonnen, KI-gestützte Empfehlungen für Fehlerinjektionspunkte anzubieten. Dabei lernen die Systeme aus früheren Experimenten und priorisieren Tests, die mit hoher Wahrscheinlichkeit neue Schwachstellen aufdecken – statt bekannte Muster zu wiederholen.
Für die meisten Teams bleibt das derzeit noch ein Ausblick. Aber es zeigt die Richtung: Chaos Engineering wird zugänglicher, automatisierbarer und besser in bestehende SRE-Prozesse integrierbar.
Die Verbindung zu Monitoring und SLOs
Chaos Engineering ohne gutes Monitoring ist blind. Das Monitoring muss während des Experiments laufen und messen, ob der definierte Normalzustand aufrechterhalten wird. SLOs – Service Level Objectives – bilden dabei einen natürlichen Rahmen: Sie definieren, was „gut genug" bedeutet, und machen messbar, ob ein Experiment innerhalb oder außerhalb des Error Budgets bleibt.
Ein Experiment, das die Fehlerrate für fünf Minuten auf 2 % treibt, ist im Kontext eines Error Budgets bewertbar: Wenn das monatliche Budget 43 Minuten auf 99,9-%-Niveau erlaubt, verbraucht ein einziges Experiment fünf davon. Das ist ein akzeptables Investment, wenn die gewonnene Erkenntnis echte Schwachstellen aufdeckt.
FreshCore als externe Beobachtungsebene
Während Chaos-Experimente laufen, liefert FreshCore eine wertvolle Außenperspektive: HTTP-Monitore messen, ob Services von außen erreichbar bleiben. Heartbeat-Monitore zeigen, ob interne Prozesse wie Hintergrundjobs oder Scheduler weiterlaufen. Server-Monitoring gibt Einblick in Ressourcenverbrauch unter gezielt erzeugter Last.
Diese externe Sicht ist besonders wertvoll, weil interne Monitoring-Systeme manchmal selbst von einem Experiment betroffen sind. Ein außerhalb der zu testenden Infrastruktur laufender Monitor liefert ein verlässlicheres Bild davon, was Endnutzer tatsächlich erleben würden.
Fazit
Chaos Engineering ist keine Spielerei für Konzerne mit eigenen SRE-Abteilungen. Es ist eine strukturierte Methode, um das Vertrauen in ein System auf Basis von Evidenz zu begründen – statt auf Annahmen. Der Einstieg ist auch mit kleinen Teams und einfachen Mitteln möglich. Und die Erkenntnisse sind fast immer überraschend. Wer anfängt zu fragen, was passiert, wenn eine Komponente ausfällt, macht seinen Betrieb robuster – noch bevor ein echter Ausfall die Antwort liefert.
Bildquelle: Barrett Lyon / OPTE Project, Wikimedia Commons, CC BY 2.5. (Visualisierung von Internet-Verbindungen und Netzwerktopologie, Stand Januar 2005)
