Chaos Engineering ist die Disziplin, Experimente an einem System durchzuführen, indem gezielt Fehler eingespeist werden, etwa beendete Instanzen, Netzwerklatenz oder nicht erreichbare Abhängigkeiten. Ziel ist Vertrauen in die Widerstandsfähigkeit unter realen Störungen. Jedes Experiment beginnt mit einer Hypothese zum Normalzustand und nutzt Observability-Daten, um sie zu bestätigen oder zu widerlegen.
Was Chaos Engineering ist
Chaos Engineering behandelt Resilienz als etwas, das experimentell geprüft und nicht einfach angenommen wird. Statt darauf zu warten, dass um drei Uhr nachts ein Node abstürzt oder eine Abhängigkeit langsam wird, führen Teams diesen Fehler bewusst und kontrolliert herbei und beobachten die Reaktion des Systems. Es geht nicht darum, Dinge um ihrer selbst willen kaputtzumachen, sondern Schwachstellen zu finden: einen fehlenden Timeout, einen Retry-Sturm oder ein Failover, das nie wirklich getestet wurde. Und zwar dann, wenn das Team vorbereitet und die Auswirkung klein ist.
Bekannt wurde die Praxis durch Netflix. Dort entstand um 2010 im Zuge der Migration zu AWS Chaos Monkey, ein Werkzeug, das zufällig Produktionsinstanzen beendet; später folgten die Principles of Chaos Engineering. Heute nutzen Teams den Ansatz weit über Streaming-Plattformen hinaus, vom Kubernetes-Cluster bis zum Zahlungssystem.
Grundprinzipien
Die Principles of Chaos Engineering beschreiben ein Experiment in fünf Schritten:
- Normalzustand (Steady State) definieren als messbare Ausgabe, die normales Verhalten anzeigt, etwa erfolgreiche Checkouts pro Minute oder ein SLO, nicht interne Werte wie CPU.
- Hypothese aufstellen, dass der Normalzustand in Kontroll- und Experimentgruppe erhalten bleibt.
- Reale Ereignisse variieren: Serverabstürze, volle Platten, Netzwerkpartitionen, Latenz, Zeitabweichungen, Fehler in Abhängigkeiten, Lastspitzen.
- Experimente in Produktion ausführen, wo möglich, denn Staging bildet echten Traffic und echte Konfiguration selten ab.
- Experimente automatisieren und kontinuierlich ausführen sowie den Blast Radius minimieren, damit eine falsche Hypothese möglichst wenige Nutzer trifft.
Ein Experiment ist erfolgreich, wenn die Hypothese widerlegt wird: Das Team hat etwas gelernt, bevor ein Incident es auf die harte Tour lehrt.
Warum Observability die Voraussetzung ist
Ein Experiment ist nur so gut wie die Fähigkeit, seine Wirkung zu sehen. Ohne verlässliche Baseline des Normalzustands erkennen Sie nicht, ob 200 ms zusätzliche Latenz das Nutzererlebnis verschlechtert haben. Ohne Traces sehen Sie nicht, welcher nachgelagerte Service den Fehler verstärkt hat. Vor dem ersten Experiment sollten folgende Punkte stehen:
- Nutzerbezogene SLOs und Dashboards, die den Normalzustand in Echtzeit zeigen.
- Distributed Tracing über die betroffenen Aufrufpfade, um die Ausbreitung eines Fehlers zu verfolgen.
- Funktionierendes Alerting, denn ein Experiment, das hätte alarmieren müssen und es nicht tat, ist selbst ein Befund.
- Eine klare Abbruchbedingung, etwa eine Schwelle der Burn Rate, die das Experiment automatisch stoppt.
Beispielexperiment
Ein beispielhaftes Experiment für einen Checkout-Service, der einen Zahlungsanbieter aufruft:
| Element | Definition |
|---|---|
| Normalzustand | Checkout-Erfolgsquote mindestens 99,5 %, p99-Latenz unter 1,2 s |
| Hypothese | Fügt die Payment-API bei 10 % der Aufrufe 2 s Latenz hinzu, halten Timeouts und Circuit Breaker den Checkout im Normalzustand |
| Fehler | 2 s Latenz auf ausgehenden Traffic zur Payment-API für einen Canary-Pod |
| Blast Radius | Ein Pod, etwa 5 % des Traffics, 15 Minuten |
| Abbruch | Checkout-Erfolg 2 Minuten lang unter 99 % |
Ein typischer Befund: Der Timeout des HTTP-Clients war länger als der des vorgelagerten Gateways, sodass Nutzer Fehler sahen, obwohl der Service irgendwann eine Antwort erhielt. Die Korrektur ist klein; sie im Ernstfall zu finden, wäre teuer gewesen.
Werkzeuge und Formate
Verbreitete Open-Source-Werkzeuge für Kubernetes sind Chaos Mesh und LitmusChaos, beides CNCF-Projekte. Cloud-Anbieter bieten verwaltete Dienste wie AWS Fault Injection Service und Azure Chaos Studio. Toxiproxy simuliert Netzwerkbedingungen zwischen Services in Tests. Viele Organisationen beginnen mit Game Days: geplanten Sitzungen, in denen ein Team ein Szenario manuell durchspielt, seinen Runbooks folgt und prüft, ob Alerts, Dashboards und Eskalationswege wie erwartet funktionieren.
So gelingt der Einstieg
Bewährt hat sich ein schrittweises Vorgehen. Wählen Sie zuerst eine kritische Nutzerreise aus und machen Sie ihren Normalzustand sichtbar. Führen Sie dann einen manuellen Game Day außerhalb der Produktion mit einem einfachen Fehler durch, etwa dem Beenden einer Instanz, und prüfen Sie, ob Alerts auslösen und Dashboards erklären, was passiert ist. Wiederholen Sie anschließend dasselbe Experiment in Produktion mit sehr kleinem Blast Radius während der Arbeitszeit, wenn alle Verantwortlichen des Service erreichbar sind. Erst danach lohnt die Automatisierung, zum Beispiel als geplanter Job oder als Schritt in der Release-Pipeline, und der Umfang wächst Abhängigkeit für Abhängigkeit. Jeder Schritt endet mit einem kurzen schriftlichen Ergebnis: Hypothese, Resultat, behobene Punkte.
Typische Fehler
Große, unkontrollierte Experimente in Produktion ohne Abbruchmechanismus beschädigen das Vertrauen in die Praxis. Wer interne Metriken statt des nutzerbezogenen Normalzustands misst, übersieht die tatsächliche Wirkung. Und wer Ergebnisse, Korrekturen und Folgeaufgaben nicht festhält, etwa in einem Postmortem, verschenkt das Gelernte.
Wie Obseria unterstützt
Obseria liefert die Sicht auf den Normalzustand, auf die Chaos-Experimente angewiesen sind: SLOs, aktuelle Service-Maps aus Obseria TopoGraph und Traces, die zeigen, wie sich ein eingespeister Fehler ausbreitet. Synthetisches Monitoring prüft kritische Abläufe während des Experiments konstant, und Burn-Rate-Alerts können als automatisches Abbruchsignal dienen.
