Chaos-Engineering-Experimente mit Claude designen: Hypothesen, Blast-Radius und Vorbereitung

1. Chaos Engineering ist kein zufälliges Kaputtmachen

Der Begriff Chaos Engineering führt häufig zu einem Missverständnis: Es geht nicht darum, wahllos Dinge im produktiven System kaputtzumachen und zu schauen, was passiert, sondern darum, eine konkrete Hypothese über das erwartete Verhalten des Systems unter einer definierten Störung wissenschaftlich zu überprüfen. Ein seriöses Experiment beginnt immer mit einem Satz wie: Wenn ein einzelner Pod des Empfehlungsdienstes ausfällt, erwarten wir, dass der Checkout-Flow ohne spürbare Verzögerung weiterläuft, weil ein Fallback auf einen Cache greift.

Claude ist ein hervorragendes Werkzeug, genau diese Hypothesen präzise zu formulieren, weil das Formulieren einer testbaren, falsifizierbaren Aussage in der Praxis oft schwerer fällt als die eigentliche technische Umsetzung der Fehlerinjektion. Ein gut formuliertes Experiment lässt sich später eindeutig als bestanden oder gescheitert bewerten, ein schwammig formuliertes Experiment liefert am Ende nur eine vage Beobachtung ohne belastbaren Erkenntnisgewinn.

2. Eine testbare Steady-State-Hypothese mit Claude formulieren

Der Ausgangspunkt jedes Chaos-Experiments ist die Definition eines Steady State, also messbarer Kennzahlen, die im Normalbetrieb ein bestimmtes Verhalten zeigen, etwa eine Fehlerquote unter 0,5 Prozent und eine p95-Latenz unter 400 Millisekunden für den Checkout-Endpunkt. Claude hilft dabei, aus einer groben Beschreibung des Systems und seiner erwarteten Redundanz eine präzise, messbare Hypothese abzuleiten, die sich direkt in eine Prometheus-Query zur automatisierten Überprüfung während des Experiments übersetzen lässt.

Wichtig ist, die Hypothese so zu formulieren, dass sie tatsächlich scheitern kann, denn nur dann liefert das Experiment einen echten Erkenntnisgewinn. Eine Hypothese wie das System sollte robust sein ist wertlos, weil sie sich nicht objektiv widerlegen lässt, während eine Hypothese wie die Fehlerquote bleibt während des gesamten Experiments unter 1 Prozent klar überprüfbar ist und im Erfolgsfall wie im Scheitern eine konkrete Aussage über die tatsächliche Resilienz liefert.

# Prompt-Beispiel für Claude
"Formuliere eine testbare Steady-State-Hypothese für folgendes
Szenario: Der Empfehlungsdienst läuft mit drei Replikas hinter
einem Kubernetes-Service. Ein Pod soll gezielt beendet werden.
Erwartetes Verhalten: Checkout-Flow bleibt unbeeinträchtigt.
Formuliere die Hypothese messbar anhand von Fehlerquote und p95-Latenz."

3. Netzwerklatenz-Experimente mit Claude vorbereiten

Netzwerklatenz zwischen Services ist eine der realistischsten und gleichzeitig am seltensten getesteten Fehlerarten, obwohl langsame, aber nicht komplett ausgefallene Abhängigkeiten in der Praxis deutlich häufiger vorkommen als vollständige Ausfälle. Claude hilft, aus einer Beschreibung der Zielarchitektur ein konkretes Experiment mit Werkzeugen wie Chaos Mesh oder Toxiproxy abzuleiten, das eine definierte zusätzliche Latenz zwischen zwei Services einführt, etwa 300 Millisekunden zwischen dem Checkout-Service und dem Zahlungsdienstleister.

Besonders hilfreich ist Claude beim Durchdenken realistischer Latenzverteilungen statt eines starren Fixwerts, da echte Netzwerkprobleme selten eine perfekt konstante Verzögerung erzeugen, sondern eher eine Verteilung mit gelegentlichen Ausreißern. Ein entsprechendes Experiment mit Jitter bildet reale Bedingungen deutlich besser ab und deckt Timeout-Konfigurationen auf, die auf eine konstante Latenz ausgelegt wurden, aber bei variabler Latenz versagen.

apiVersion: chaos-mesh.org/v1alpha1
kind: NetworkChaos
metadata:
  name: payment-latency-experiment
spec:
  action: delay
  mode: all
  selector:
    namespaces: ["checkout"]
    labelSelectors:
      app: payment-client
  delay:
    latency: "300ms"
    jitter: "100ms"
  duration: "10m"

4. Pod-Kill-Experimente für Kubernetes mit Claude entwerfen

Pod-Kill-Experimente prüfen, ob das gewählte Deployment-Muster tatsächlich die versprochene Redundanz liefert, etwa ob ein Kubernetes-Service bei Ausfall eines von drei Replikas den Traffic nahtlos auf die verbleibenden zwei umleitet, ohne dass Requests verloren gehen. Claude kann aus einer Beschreibung des Deployments ein konkretes Litmus- oder Chaos-Mesh-Manifest ableiten, inklusive sinnvoller Auswahlkriterien für den zu tötenden Pod, etwa gezielt den Pod mit der ältesten Startzeit statt eines rein zufälligen.

Ein oft übersehener Aspekt, den Claude beim Entwurf zuverlässig anspricht, ist der Unterschied zwischen dem Töten eines einzelnen Pods und dem gleichzeitigen Ausfall mehrerer Pods derselben Verfügbarkeitszone, was ein deutlich realistischeres und gefährlicheres Szenario darstellt als ein einzelner Pod-Neustart, den Kubernetes ohnehin routinemäßig handhabt. Claude regt an, das Experiment stufenweise von einem einzelnen Pod bis zu einem kompletten Zonenausfall zu steigern, statt gleich mit dem drastischsten Szenario zu beginnen.

5. Ressourcenlimits und Erschöpfungsexperimente durchdenken

Experimente, die CPU- oder Speicherlimits eines Containers künstlich ausreizen, decken auf, wie ein System auf Ressourcenknappheit reagiert, etwa ob ein Out-of-Memory-Kill zu einem sauberen Neustart führt oder ob nicht persistierte Zustände dabei verloren gehen und Daten inkonsistent zurückbleiben. Claude hilft, ein solches Experiment präzise zu spezifizieren, inklusive der Frage, welcher Anteil der verfügbaren Ressourcen künstlich belegt werden soll, um realistisch, aber nicht sofort katastrophal zu sein.

Ein Aspekt, den Claude in diesem Kontext regelmäßig anspricht, ist der Unterschied zwischen einem harten, sofortigen Ressourcenlimit und einem graduell steigenden Verbrauch über mehrere Minuten, weil beide Szenarien unterschiedliche Fehlerpfade im System auslösen können, etwa unterschiedliches Verhalten von Autoscaling-Regeln oder unterschiedliche Reaktionszeiten von Health-Checks.

apiVersion: chaos-mesh.org/v1alpha1
kind: StressChaos
metadata:
  name: memory-exhaustion-experiment
spec:
  mode: one
  selector:
    namespaces: ["checkout"]
    labelSelectors:
      app: checkout-service
  stressors:
    memory:
      workers: 1
      size: "512MB"
  duration: "5m"

6. Blast-Radius vor dem ersten Produktionsexperiment eingrenzen

Bevor ein Experiment jemals in Produktion läuft, muss der maximale mögliche Schaden bewusst begrenzt werden, der sogenannte Blast-Radius. Claude eignet sich gut, um systematisch alle Dimensionen durchzugehen, in denen sich der Blast-Radius eingrenzen lässt: nur ein einzelner Pod statt aller Replikas, nur ein kleiner Prozentsatz des Traffics statt der gesamten Nutzerbasis, ein enges Zeitfenster außerhalb von Stoßzeiten statt eines unbegrenzten Experiments und eine klar definierte Kill-Switch-Bedingung, bei deren Erreichen das Experiment automatisch sofort abgebrochen wird.

Besonders wertvoll ist es, Claude explizit nach dem schlimmstmöglichen Ausgang eines geplanten Experiments zu fragen, bevor es überhaupt gestartet wird. Diese bewusste Vorabreflexion deckt häufig Lücken auf, etwa dass ein geplantes Netzwerklatenz-Experiment theoretisch auch einen Zahlungsanbieter-Webhook betreffen könnte, der bei Timeout doppelte Belastungen auslöst, ein Risiko, das beim reinen Fokus auf die technische Umsetzung leicht übersehen wird.

7. Claude als Werkzeug zur Vorbereitung, nicht zur automatischen Ausführung

Ein zentraler Grundsatz, der bei jedem Einsatz von Claude im Chaos-Engineering-Kontext gelten sollte: Claude bereitet Experimente vor, formuliert Hypothesen, generiert Manifeste und hilft beim Durchdenken des Blast-Radius, aber die tatsächliche Ausführung eines Experiments in einer produktiven Umgebung bleibt eine bewusste, von Menschen kontrollierte Entscheidung mit definiertem Startzeitpunkt und anwesenden Verantwortlichen, die im Ernstfall sofort eingreifen können.

Ein automatisiertes System, das eigenständig entscheidet, wann und wie stark ein Chaos-Experiment in Produktion ausgeführt wird, ist ein fundamental anderes Risikoprofil als ein vorbereitetes Manifest, das ein Mensch nach Prüfung manuell startet. Claude Code kann durchaus helfen, die Ausführungs-Skripte selbst zu schreiben und zu testen, der eigentliche Startbefehl in Produktion sollte aber immer von einer Person mit vollem Kontext über den aktuellen Systemzustand ausgelöst werden.

8. Ein Experiment-Runbook mit Claude vorbereiten

Zu jedem geplanten Chaos-Experiment gehört ein kurzes Runbook, das vor dem Start festhält, welche Metriken beobachtet werden, welcher Zustand als Abbruchkriterium gilt und wie ein manueller Rollback im Notfall aussieht. Claude eignet sich gut, um aus der formulierten Hypothese und dem definierten Blast-Radius automatisch ein solches Runbook als strukturierte Checkliste zu erzeugen, die während des Experiments Schritt für Schritt abgearbeitet werden kann.

Ein solches Runbook sollte außerdem explizit festhalten, wer während des Experiments die Entscheidungsgewalt für einen sofortigen Abbruch hat, denn in der Praxis führt Unklarheit über Verantwortlichkeiten häufiger zu eskalierten Vorfällen als das Experiment selbst. Claude kann diese Rollenverteilung als festen Bestandteil der generierten Vorlage vorschlagen, sodass sie nicht bei jedem Experiment neu vergessen wird.

9. Grenzen: Claude kennt eure produktive Topologie nicht

Claude kennt weder die tatsächliche aktuelle Topologie eures produktiven Systems noch versteckte Abhängigkeiten, die nirgendwo dokumentiert sind, etwa einen ungeschützten internen Cronjob, der zufällig zur gleichen Zeit läuft wie das geplante Experiment. Jeder von Claude generierte Experimentplan muss deshalb von jemandem mit aktuellem Systemwissen gegengeprüft werden, bevor er auch nur in einer Staging-Umgebung ausgeführt wird, geschweige denn in Produktion.

Chaos Engineering lebt außerdem von einer Kultur der psychologischen Sicherheit, in der Teams offen über Schwachstellen sprechen, die ein Experiment aufdeckt, ohne dass daraus Schuldzuweisungen entstehen. Claude kann bei der technischen Vorbereitung erheblich unterstützen, den organisatorischen Reifegrad und die Disziplin für regelmäßige, gut vorbereitete Game-Days muss das Team selbst aufbauen und pflegen.

10. Zusammenfassung

11. FAQ: Chaos Engineering mit Claude: Häufige Fragen