DR-Pläne mit Chaos Engineering testen
Aufs Glatteis führen
Veröffentlicht in Ausgabe 11/2025 - SCHWERPUNKT
Chaos Engineering klingt auf den ersten Blick wenig vertrauenerweckend, doch derlei Tools erweisen sich in der Praxis als ungemein nützliche Helfer. Die strukturelle und funktionale Komplexität moderner IT-Infrastrukturen ist in der Regel sehr hoch, damit erschwert sich die Risikoanalyse signifikant. Chaos Engineering will dieses Problem durch Szenarien lösen, bei denen das Systemverhalten unter Einwirkung von Störungen wie Netzwerküberlastung oder Begrenzung der Rechenressourcen analysiert wird.
Neuer Testansatz
Traditionelle Verfahren – darunter Unit-, Integrations-, Stress- und Robustheitstests – konzentrieren sich in erster Linie auf die Validierung von Korrektheit und Leistung unter den erwarteten Bedingungen in Umgebungen vor der Bereitstellung von bestimmten Diensten. Dieser Ansatz kommt in der Regel in isolierten und kontrollierten Infrastrukturen zum Einsatz. Es wird geprüft, ob sich Systemkomponenten bei bekannten Eingaben korrekt verhalten. Doch in modernen, verteilten IT-Landschaften versagen solche Methoden, wenn es darum geht, kaskadierende oder neu auftretende Fehler aufzudecken. Insbesondere die Identifikation von asynchronen Interaktionen und dynamischem Laufzeitverhalten macht die Fehlersuche schwierig.
Chaos Engineering begegnet diesen Einschränkungen, indem es kontrolliert Fehler in Produktions- oder produktionsähnliche Systeme einführt. Dieser Ansatz dient dazu, die Ausfallsicherheit des gesamten Systems zu untersuchen. Anstatt die Funktionalität mit vordefinierten Testskripten zu validieren, simulieren Chaosexperimente Fehler wie Dienstausfälle und Latenzspitzen. Das Ziel dabei ist es, das Systemverhalten und die Wiederherstellung unter ungünstigen Laufzeitbedingungen zu bewerten. Anders formuliert: Chaos-Engineering-Testing simuliert reale Ausfälle und deren Ursachen deutlich realitätsnaher als traditionelle Verfahren. Dieser Ansatz ist insbesondere geeignet, um versteckte Schwachstellen aufzudecken, die herkömmliche Testwerkzeuge übersehen.
Chaos Engineering klingt auf den ersten Blick wenig vertrauenerweckend, doch derlei Tools erweisen sich in der Praxis als ungemein nützliche Helfer. Die strukturelle und funktionale Komplexität moderner IT-Infrastrukturen ist in der Regel sehr hoch, damit erschwert sich die Risikoanalyse signifikant. Chaos Engineering will dieses Problem durch Szenarien lösen, bei denen das Systemverhalten unter Einwirkung von Störungen wie Netzwerküberlastung oder Begrenzung der Rechenressourcen analysiert wird.
Neuer Testansatz
Traditionelle Verfahren – darunter Unit-, Integrations-, Stress- und Robustheitstests – konzentrieren sich in erster Linie auf die Validierung von Korrektheit und Leistung unter den erwarteten Bedingungen in Umgebungen vor der Bereitstellung von bestimmten Diensten. Dieser Ansatz kommt in der Regel in isolierten und kontrollierten Infrastrukturen zum Einsatz. Es wird geprüft, ob sich Systemkomponenten bei bekannten Eingaben korrekt verhalten. Doch in modernen, verteilten IT-Landschaften versagen solche Methoden, wenn es darum geht, kaskadierende oder neu auftretende Fehler aufzudecken. Insbesondere die Identifikation von asynchronen Interaktionen und dynamischem Laufzeitverhalten macht die Fehlersuche schwierig.
Chaos Engineering begegnet diesen Einschränkungen, indem es kontrolliert Fehler in Produktions- oder produktionsähnliche Systeme einführt. Dieser Ansatz dient dazu, die Ausfallsicherheit des gesamten Systems zu untersuchen. Anstatt die Funktionalität mit vordefinierten Testskripten zu validieren, simulieren Chaosexperimente Fehler wie Dienstausfälle und Latenzspitzen. Das Ziel dabei ist es, das Systemverhalten und die Wiederherstellung unter ungünstigen Laufzeitbedingungen zu bewerten. Anders formuliert: Chaos-Engineering-Testing simuliert reale Ausfälle und deren Ursachen deutlich realitätsnaher als traditionelle Verfahren. Dieser Ansatz ist insbesondere geeignet, um versteckte Schwachstellen aufzudecken, die herkömmliche Testwerkzeuge übersehen.
Allerdings weisen Experten explizit darauf hin, dass Chaos Engineering kein Ersatz für herkömmliche Tests, sondern vielmehr als Ergänzung zu bewerten ist. Während herkömmliche Methoden die Systemkorrektheit unter erwarteten Bedingungen bestätigen, validiert Chaos Engineering das Systemverhalten unter bekannten Fehlern und realen Ausfallszenarien. Manche sprechen auch von einem Paradigmenwechsel – von der Fail-Validierung vor der Bereitstellung zur Bewertung der Ausfallsicherheit nach der Bereitstellung. Genau dieser Ansatz macht Chaos Engineering für die komplexen, verteilten Infrastrukturen von heute unverzichtbar.
Chaos Engineering im Disaster Recovery
Die bewusste Fehlerinjektion in bestehende IT-Systeme bereitet manch Verantwortlichem sicher schon bei der Vorstellung Bauchschmerzen. Doch Chaos Engineering folgt keinem willkürlichen Prinzip, sondern orientiert sich in hohem Maße an wissenschaftlichen Standards. Wissenschaftliche Studien stützen sich üblicherweise auf Experimente beziehungsweise entwickeln Hypothesen, die es zu überprüfen gilt; im Anschluss folgt ein Vergleich mit einer Kontrollgruppe. Auch Chaos Engineering verfolgt exakt diesen Ansatz.
Ausgehend von einem Stabilitätszustand (Steady State) entwickelt die IT-Abteilung Hypothesen, welche möglichen Risiken es gibt und was in kritischen Situationen passieren könnte. Daraus leitet sich die Entwicklung eines Chaosexperiments ab. Ein solches ist durch die Einschleusung spezifischer Fehler wie Latenzen, CPU-Ausfall oder ein Netzwerk-Blackhole gekennzeichnet. Im Verlauf der Tests ist das Ziel ein Abgleich von prognostizierten und realen Vorfällen. Aufbauend auf einer Risikoanalyse lassen sich mögliche Schwachstellen bestimmen und Vorhersagen bezüglich des Systemverhaltens treffen. Von besonderer Relevanz ist dabei die Entwicklung von Incidence-spezifischen Metriken. Dabei wird üblicherweise zwischen Schlüssel- und Kundenmetriken unterschieden.
Selbstredend laufen die Tests nicht auf Produktivsystemen, sondern in Eins-zu-eins-Kopien. Doch auch dort sollte immer ein Backupkonzept existieren, da nie exakt absehbar ist, wie eine Umgebung unter unvorhersehbaren Eingriffen reagieren wird. In der Regel ist auch eine Reversal-Funktion und eine Abbruchoption gegeben. Das Ergebnis zeigt, ob die Umgebung robust genug ist oder ob gezielte Nachbesserungen nötig sind.
Die Wahl der richtigen Tools
Die Aufgaben einer Chaos-Engineering-Plattform lassen sich wie folgt zusammenfassen: Sie evaluiert unternehmerische Schlüsselkomponenten, um sicherzustellen, dass sie mit den betrieblichen Anforderungen und Zielen des Unternehmens übereinstimmen. Entsprechende Plattformen verfügen hierfür über fünf Hauptkomponenten: die Experimentdesign-, die Fehlerinjektions-, die Beobachtbarkeits-, die Analyse- sowie die Automatisierungs- und Integrationseinheit.
Um die Potenziale von Chaos-Engineering-Testverfahren zu erschließen, bedarf es des Einsatzes entsprechender Werkzeuge. Inzwischen gibt es eine kleine, aber feine Auswahl. Sie reicht von vergleichsweise einfachen Open-Source-Tools wie Chaos Monkey [1] bis hin zu kommerziellen Produkten wie das in Deutschland entwickelte Steadybit [2]. Auch in der Stoßrichtung unterscheiden sie sich: Manche sind für die Prüfung von Cloudumgebungen, andere für die Analyse von Netzwerken, (Micro-)Services oder Docker-Instanzen konzipiert.
Grundsätzlich handelt es sich um eine recht junge Softwarekategorien. Das von Netflix entwickelte Chaos Monkey gibt es schon seit 2011, es gilt als Wegbereiter. Seit 2015 wird Chaos Engineering auch von anderen Akteuren wie Amazon und Google thematisiert. Das gestiegene Interesse an derlei Instrumenten hängt unmittelbar mit den Veränderungen in den IT-Infrastrukturen zusammen: Mit dem Aufkommen von Cloud- und Microservices sowie verteilten Umgebungen gestaltet sich die Identifikation von Fehlern deutlich schwieriger. Bei monolithischen Architekturen war das Fehlerverhalten noch einfacher zu überblicken. Chaos-Testing-Tools haben also vornehmlich wegen der Verbreitung von Cloud-, DevOps- und Kubernetes-Ansätzen an Bedeutung gewonnen.
Zu den bekanntesten Werkzeugen zählen Gremlin [3] und LitmusChaos [4]. Gremlin wird seit 2017 entwickelt und gilt als Marktführer. Der Fokus des Tools liegt in der Prüfung der Zuverlässigkeit von Enterprise-Umgebungen. Aus dem Open-Source-Umfeld stammt LitmusChaos, das speziell für cloudnative IT-Landschaften (primär Kubernetes) konzipiert ist. Es hilft Teams dabei, die Fehlertoleranz und Stabilität ihrer Anwendungen unter realistischen Störungsszenarien zu testen. Welches das geeignete Werkzeug ist, hängt primär von den Zielplattformen, den Experimenttypen, aber auch von den finanziellen und technologischen Potenzialen eines Unternehmens ab.
| Kriterium | Gremlin | LitmusChaos |
|---|---|---|
| Lizenzmodell | Kommerziell (kostenpflichtig, SaaS, agentenbasiert) | Open Source (Apache 2.0, kostenlos) |
| Zielplattformen | Multiplattform: VMs, Bare Metal, Docker, Kubernetes, Cloud (AWS, Azure et cetera) | Kubernetes-native (nur für K8s und cloudnative Workloads) |
| UI / Benutzer- freundlichkeit | Sehr benutzerfreundliche Weboberfläche und CLI | Webportal vorhanden, aber etwas komplexer in Einrichtung und Navigation |
| Experimenttypen | CPU, Memory, Shutdown, Network Latency/Loss, DNS, Disk et cetera. | Netzwerk, CPU, Memory, Node Drain, Pod Kill, Custom HTTP Tests und weitere |
| Sicherheitsfeatures | MFA, RBAC, Audit Logs, Agenten-Isolation | RBAC über Kubernetes, Namespace-Isolation |
| Integration (CI/CD & Monitoring) | APIs, SDKs, Webhooks, DataDog, Splunk, New Relic | ArgoCD, Jenkins, GitLab CI, Prometheus, Grafana |
| Workflow-Orchestrierung | Scenarios und Scheduler über UI | Argo-Workflows (grafisch und YAML), GitOps-tauglich |
Client-Server-Aufbau mit Gremlin
Auch bei der konkreten Nutzung der Chaos-Engineering-Werkzeuge ergeben sich Unterschiede. Der Marktführer Gremlin stützt sich auf eine Client-Server-Architektur, wobei auf den zu prüfenden Systemen der Einsatz von Gremlin-Agenten erforderlich ist. Deren Steuerung erfolgt serverseitig über das Modul "Gremlin Control Plane". Der Agent ist in unterschiedlichen Umgebungen einsetzbar, insbesondere mit Kubernetes, VMs, Containern und Cloudplattformen.
Grundsätzlich empfiehlt es sich, den Agenten nicht auf einem netzwerkbasierten Dateisystem zu installieren; so vermeiden Sie Latenz- und Verbindungsprobleme. Die Installation auf einem lokal gemounteten Dateisystem verbessert die Leistung und Zuverlässigkeit und verringert das Risiko von Datenverlusten. Weiterhin ist zu beachten, dass der Gremlin-Agent sicher neben Service-Meshes wie Istio [5] installiert werden kann. Gremlin koordiniert Netzwerktests, ohne die Regeln oder Konfiguration eines Service-Meshes zu modifizieren. Der Agent benötigt darüber hinaus verschiedene Berechtigungen:
- "CLIENTS_READ": Ermöglicht das Lesen aller Clientinformationen
- "CLIENTS_WRITE": Erlaubt das Bearbeiten aller Clientinformationen
- "TEAM_SECURITY_READ": Ermöglicht das Lesen von teambezogenen Anmeldeinformationen
Damit der Agent mit dem Gremlin-Server kommunizieren kann, muss der Client sich am Gremlin-System authentifizieren. Am einfachsten geht das, wenn Sie die Client-Konfigurationsdatei während der Installation herunterladen. Gremlin generiert automatisch eine vorformatierte Konfigurationsdatei, die alles enthält, was Sie für die Authentifizierung benötigen, einschließlich der Team-ID. Die Datei lässt sich über die webbasierte Teamseite über die Registerkarte "Configuration" mittels "Configuration File" herunterladen.
Kopieren Sie die Datei nach "/etc/gremlin/config.yaml" und starten Sie den Gremlin-Dienst neu. Unter Windows lautet der Standardpfad wie folgt: "C:\ProgramData\Gremlin\Agent\config.yaml". Über die Agenten-Konfigurationsdatei bestimmen Sie beispielsweise, wie die konkreten Angriffsszenarien aussehen. Dabei sollten Sie dem Ansatz "Start small" folgen, also zunächst mit weniger gravierenden Eingriffen in Staging- oder Testumgebungen starten.
Die Agenten-Konfigurationsdatei verwendet eine Kennung zur Identifikation des Gremlin-Systems. Ein Agent wird zudem über "GREMLIN_TEAM_ID" einem Team zugeordnet. Die Option "push_metrics: true" sorgt dafür, dass Systemmetriken zur Darstellung der Experimenteffekte in Echtzeit an die Steuerungsebene gesendet werden. Dies ist besonders wichtig für Monitoring und Echtzeitauswertung. Grundsätzlich lassen sich auch Daten zu laufenden Prozessen zur Dienst-ermittlung an Gremlin schicken. Doch diese Option ist ab der Gremlin-Agenten-Version 2.42.0 mit "collect_processes: false" deaktiviert. Wann immer Sie Änderungen an der Datei "config.yaml" vornehmen, ist ein Neustart des Gremlin-Dienstes notwendig.
Ziele und Angriffsvarianten definieren
Zur konkreten Fehlerinjektion müssen Sie zunächst die Ziele definieren. Ein aktivierter Agent informiert den Gremlin-Server kontinuierlich über den Zustand des Zielsystems. Gremlin spricht einmal von Angriffen, dann wieder von Experimenten, gemeint ist aber derselbe Vorgang: die Prüfung des Zielsystems auf etwaige Reaktionen. Gremlin unterscheidet zwischen drei Experimentkategorien:
- Ressourcenexperimente: Check auf plötzliche Änderungen beim Verbrauch von Rechenressourcen
- Netzwerkexperimente: Prüfen unzuverlässiger Netzwerkbedingungen
- Zustandsexperimente: Testen von unerwarteten Änderungen in einer Umgebung, etwa Stromausfälle, Knotenausfälle, Taktabweichungen oder Anwendungsabstürze
Um ein Experiment auf einem Zielsystem durchzuführen, melden Sie sich zunächst über das Webinterface am Gremlin-Server an. Im Menü "Experiments" legen Sie mit "New Experiment" eine neue Testkonfiguration an. Dazu wählen Sie zunächst den Systemtyp aus. Nach der Typauswahl müssen Sie spezifische Ziele bestimmen. Die Selektion prüfen Sie mithilfe des Diagramms "Blast Radius". Das Diagramm zeigt alle Hosts, Container und Kubernetes-Ressourcen an und hebt die Ressourcen hervor, auf die sich Ihr Experiment auswirkt.
Nach der Typauswahl müssen Sie die Zielplattformen definieren. Für alle drei Textvarianten könnten Sie spezifische Ziele bestimmen; alternativ können Sie mithilfe von Tags Zielgruppen festlegen. In der Standardansicht präsentiert Ihnen Gremlin eine nach Tags gruppierte Ansicht der Ziele. Dank des benutzerfreundlichen Web-GUI gestaltet sich die Überprüfung und Verfeinerung des Blast-Radius einfach. Das zugehörige Diagramm hebt die Hosts, Container und etwaige Kubernetes-Ressourcen hervor, die von dem Experiment betroffen sein könnten. Mit "Percent to impact" bestimmen Sie die Effekte auf eine zufällig ausgewählte Teilmenge. Wenn Sie beispielsweise zehn Hosts prüfen und den Wert auf 20 Prozent setzen, sucht sich Gremlin zwei Hosts als Experimentziel aus.
Gremlin nimmt standardmäßig alle neu erkannten Ziele auf, die den Zielkriterien entsprechen. Dieses Konzept erweist sich beispielsweise in Clustern mit automatischer Skalierung als sinnvoll. Ist das nicht gewünscht, deaktivieren Sie das Kontrollkästchen "Include New Targets". In den Settings des Experiments steuern Sie die zeitliche Ausführung. Diese kann mit "Random within a time frame" auch zufällig innerhalb eines Zeitfensters erfolgen. Mit einem Klick auf "Run Experiment" starten Sie die Prüfung.
Das Durchführen von Experimenten vereinfacht sich durch die Bereitstellung verschiedener Experimenttypen. Bei "State" und "Resource" können Sie alle, beliebige oder bestimmte Container innerhalb eines ausgewählten Pools als Ziele definieren. Gremlin kennt außerdem den Typ "Network" und verschiedene Attack-Varianten ("Process Killer", "Shutdown" und "Time Travel").
Ergebnisse richtig deuten
Die Ergebnisse der Tests gibt Gremlin auf dem Dashboard beziehungsweise im Menü "Reports" aus. Unter "Attack Details" sehen Sie die Ergebnisse laufender und abgeschlossener Prüfungen. Dem Menü "Experiment / Experiment Details" entnehmen Sie weitere Details. Für spezifische Ressourcenexperimente kann Gremlin automatisch Metriken vom Ziel erfassen und ausgeben. Das erlaubt Ihnen die zeitnahe Prüfung, ohne ein Observability-Tool öffnen zu müssen. Bei CPU-Experimenten sehen Sie die CPU-Auslastung; bei Speicherexperimenten untersuchen Sie die RAM-Auslastung im Vergleich zur Kapazität. Bei Shutdown-Experimenten erkennen Sie sofort, ob und wann ein Ziel offline gegangen ist.
Ein weiteres nützliches Werkzeug sind die Szenarien. Dabei handelt es sich um einen Mix aus Health Checks und Gremlin-Experimenten. Damit können Sie ein oder mehrere Experimente nacheinander und/oder parallel mithilfe von Verzweigungen ausführen. Dies ist nützlich, um beispielsweise vergangene Ausfälle nachzustellen, komplexe Ausfälle in der Praxis zu simulieren oder mehrere Aspekte eines Systems gleichzeitig zu testen.
Um Ihnen die Arbeit so einfach wie möglich zu machen, verfügt Gremlin im Menü "Scenarios" über eine Reihe vorkonfigurierter Szenarien. In der Gremlin-Terminologie werden diese als "Recommended Scenarios" bezeichnet; Sie finden diese im gleichnamigen Untermenü. Diese bilden reale Fehlermodi ab und können bequem an die jeweiligen Testanforderungen adaptiert werden.
Eine weitere Besonderheit von Gremlin ist die Funktion "GameDay", die über den gleichnamigen Menüeintrag verfügbar ist. Dabei handelt es sich um eine organisierte Teamveranstaltung, bei der Sie Chaos Engineering üben, Ihren Incident-Response-Prozess testen, vergangene Ausfälle validieren oder unbekannte Probleme in Ihren Diensten identifizieren. Im Rahmen eines solchen Projekts können Sie bis zu 20 Szenarien durchspielen.
LitmusChaos: Fokus auf die Cloud
Einen alternativen Ansatz verfolgt das quelloffene LitmusChaos: Hier kommt ein cloudnativer Ansatz zum Erstellen, Verwalten und Überwachen von Chaos-Engineering-Tests zum Einsatz. Die Plattform selbst läuft als eine Reihe von Microservices und verwendet Kubernetes Custom Resources (CRs), um die Chaos-Absicht sowie die Steady-State-Hypothese zu definieren. Das Herzstück dieser Umgebung ist das "Chaos Control Plane". Das sogenannte "ChaosCenter" als zentrales Managementtool dient dem Aufbau, der Planung und der Visualisierung von LitmusChaos-Workflows.
In der Praxis bedient sich LitmusChaos zweier Ressourcen: "ChaosExperiment" dient dem Gruppieren der Konfigurationsparameter eines bestimmten Fehlers. "ChaosEngine" hingegen verknüpft Kubernetes-Anwendungs-Workloads beziehungsweise die von Infrastrukturkomponenten mit einem durch "ChaosExperiment" beschriebenen Fehler. Die Ergebnisse werden von "ChaosResults" visualisiert. Dem Bericht entnehmen Sie dann die Details zur Fehlerinjektion und erkennen den Status der Fehlerrücknahme. Der "ChaosExporter" liest die Ergebnisse und stellt die Informationen als Prometheus-Metriken bereit. Über die webbasierte Administration ist zudem die Auswahl der Agenten einfach; die Entwickler bezeichnen sie als "ChaosAgents". Auch bei dieser Umgebung können Sie die Experimente zeitgesteuert ausführen.
Über den LitmusChaos Hub [6] stehen vordefinierte Experimentkonfigurationen zum Download bereit. Über die Plattform können Entwickler oder Anbieter ihre Chaos-Testkonfigurationen austauschen. Dort waren im Juli 2025 über 50 verschiedene vordefinierte Experimentkonfigurationen verzeichnet. Die Schwierigkeit besteht – wie auch bei anderen Chaos-Engineering-Tools – weniger in der Durchführung von Experimenten, sondern in der gezielten Nachbearbeitung und Optimierung der eigenen Infrastruktur.
Fazit
Die Veränderungen in modernen IT-Landschaften verlangen nach neuen Werkzeugen, um möglichen Fehlerquellen auf den Grund zu gehen. Moderne Systeme, Anwendungen und Infrastrukturen beherbergen nicht selten Dutzende oder gar Hunderte Services. Deren Interaktionen schaffen neue Fehlerquellen, denen Admins mit traditionellen Werkzeugen kaum beikommen. Chaos-Engineering-Tools wie Gremlin und LitmusChaos helfen, das Verhalten solcher Systeme unter realen Störungen zu testen – bevor sie in der Produktion Schaden anrichten.
(ln)
Links
[1] Chaos Monkey: https://netflix.github.io/chaosmonkey/
[2] Steadybit: https://steadybit.com/
[3] Gremlin: https://www.gremlin.com/chaos-engineering
[4] LitmusChaos: https://litmuschaos.io/
[5] Istio: https://istio.io/
[6] LitmusChaos Hub: https://hub.litmuschaos.io/