Chaos Engineering: Nachhaltigkeit von Systemen

Chaos Engineering: Nachhaltigkeit von Systemen

1) Warum Chaos-Engineering

• Überprüfung der Hypothesen über das Systemverhalten und Validierung des SLO;
• versteckte SPOFs, falsche Timeouts/Retrays, Kaskadeneffekte erkennen;
• Übungsteams: Spieltage, Runbook-Training, Kommunikation;
• bilden eine Kultur der „Nachhaltigkeit standardmäßig“ und nicht „hoffen auf das Beste“.

Wichtig: Chaos Engineering ≠ „alles kaputt machen“. Dies ist eine wissenschaftliche Methode: Steady-State → Hypothese → Experiment → Schlussfolgerungen → Verbesserungen.

2) Grundzyklus des Experiments

1. Steady-State (Basislinie): Welche SLIs sind stabil? (z.B. Erfolg ≤500 ms in 99. 95%).
2. Hypothese: Bei einem Verlust von einem AZ p95 steigen <10% und die Verfügbarkeit ≥99. 9%.
3. Experiment: geplantes Folt mit begrenztem Radius und Stop-Kriterien.
4. Beobachtung: Metriken/Traces/Logs, Burn-Rate SLO, Business SLI (z.B. erfolgreiche Einzahlungen).
5. Verbesserungen: Fundstücke erfassen, Timeouts/Limits/Routing ändern, Runbook aktualisieren.
6. Automatisierung/Regression: Wiederholen Sie im Zeitplan, fügen Sie CI/CD und Spieltage Kalender hinzu.

3) Sicherheitsgeländer (safety first)

Blast Radius: Wir beginnen mit einem schmalen - ein Pod/instance/Route/namespace.
Guardrails: Alerts auf SLO Burn-Rate (schnell/langsam), Retraylimits, QPS-Limit, Incident Budget.
Stop-Kriterien: „wenn error-rate> X% oder p99> Y ms N Minuten - sofort stop und rollback“.
Fenster: On-Call-Arbeitszeiten, benachrichtigte Stakeholder, eingefrorene Releases.
Kommunikation: IC/Tech lead/Comms, klarer Kanal (Kriegsraum), Meldungsmuster.

4) Fehlerklassen und Hypothesenideen

Netzwerk: Delay/Jitter/Loss, partieller Port Drop, „Flying“ Kommunikation zwischen Diensten/PSP.
Computer/Knoten: Prozesse töten, CPU überhitzen, Dateideskriptoren erschöpfen, enge Verbindungspools.
Speicher und DB: Wachstum der Laufwerke Latenz, lag Repliken, Stop ein Shard/Leader, Split-Brain.
Abhängigkeiten: Degradation externer APIs, Provider Limits, 5xx/429 Bursts.
Change Management: fehlgeschlagene Veröffentlichung, schlechte Ficha-Flagge, teilweise Rollout.
Perimeter: CDN degradiert, DNS/Anycast drift, WAF/Bot Protection Failure.
Region/AZ: Totalverlust oder „partieller“ Vorfall (etwas schlimmer und unvorhersehbar).

5) Werkzeuge und Techniken

Kubernetes: Chaos Mesh, Litmus, PowerfulSeal, kube-monkey.
Clouds: AWS Fault Injection Simulator (FIS), Fault Domains in der Cloud.
Netzwerk/Proxy: Toxiproxy (TCP-Gift), tc/netem, iptables, Envoy fault (delay/abort), Istio fault injection.
Prozesse/Knoten: 'stress-ng', cgroups/CPU-throttle, disk fill.
Traffic-Routing: GSLB/DNS-Gewichte, kanarische/blau-grüne Umschaltung für Failover-Prüfungen.

6) Beispielszenarien (Kubernetes)

6. 1 Delay/abort auf der Strecke (Istio VirtualService)

yaml apiVersion: networking. istio. io/v1alpha3 kind: VirtualService metadata: { name: api-chaos }
spec:
hosts: ["api. internal"]
http:
- route: [{ destination: { host: api-svc } }]
fault:
delay: { percentage: { value: 5 }, fixedDelay: 500ms }
abort: { percentage: { value: 1 }, httpStatus: 503 }

Hypothese: Client-Timeouts/Retrays und CBs halten p95 <300ms und error-rate <0. 5%.

6. 2 Pod Kill (Chaos Mesh)

yaml apiVersion: chaos-mesh. org/v1alpha1 kind: PodChaos metadata: { name: kill-one-api }
spec:
action: pod-kill mode: one selector:
namespaces: ["prod"]
labelSelectors: { "app": "api" }
duration: "2m"

Hypothese: Balancer und HPA kompensieren den Verlust einer Instanz ohne p99-Wachstum> 20%.

6. 3 Netzwerkchaos (Verzögerung zur DB)

yaml apiVersion: chaos-mesh. org/v1alpha1 kind: NetworkChaos metadata: { name: db-latency }
spec:
action: delay mode: all selector: { namespaces: ["prod"], labelSelectors: {"app":"payments"} }
delay: { latency: "120ms", jitter: "30ms", correlation: "25" }
direction: to target:
selector: { namespaces: ["prod"], labelSelectors: {"role":"db"} }
mode: all duration: "5m"

Hypothese: Pools/Timeouts/Cache reduzieren den Einfluss; p95 Zahlungen bleiben ≤ SLO.

6. 4 Füllen der Festplatte

yaml apiVersion: chaos-mesh. org/v1alpha1 kind: IOChaos metadata: { name: disk-fill-logs }
spec:
action: fill mode: one selector: { labelSelectors: {"app":"ingest"} }
volumePath: /var/log size: "2Gi"
duration: "10m"

Hypothese: Die Rotation der Protokolle/Quoten/Alerts wird vor der Degradation der Routen ausgelöst.

7) Experimente außerhalb der K8s

7. 1 Toxiproxy (lokal/Integration)

bash toxiproxy-cli create psp --listen 127. 0. 0. 1:9999 --upstream psp. prod:443 toxiproxy-cli toxic add psp -t latency -a latency=200 -a jitter=50 toxiproxy-cli toxic add psp -t timeout -a timeout=1000

7. 2 Envoy HTTP-Fehler (Perimeter/Mesh)

yaml fault:
delay: { fixed_delay: 0. 3s, percentage: { numerator: 10, denominator: HUNDRED } }
abort: { http_status: 503, percentage: { numerator: 1, denominator: HUNDRED } }

7. 3 AWS FIS (Beispielidee)

Experiment „Kill“ N% EC2 in der Auto Scaling Group, EBS-Latenz künstlich anheben, NAT-GW in einem AZ ausschalten.
Integrierte Stopp-Kriterien für CloudWatch SLO-Metriken.

8) Beobachtbarkeitsmetriken während Chaos

SLO/SLI: fraction of good requests, p95/p99, burn-rate.
RED-Modell auf kritischen Routen (Rate, Errors, Duration).
Pools: Warten auf Verbindung p95, Dienstprogramm.
DB: lag Repliken, Schlösser, p95 Anfragen Drift.
Netzwerk: retransmits, RTT, dscp/ecn Verhalten.
Business SLI: Transaktionserfolg (Einzahlungen/Checkout),% Retouren/Fehler.
Tracing: Selektive Traces (Beispiele), Korrelation von Release-Annotationen.

9) Integration mit SLO/Error-budget

Experimente innerhalb des Fehlerbudgets planen: Das Chaos darf die Quartalsziele nicht „durchkreuzen“.
Burn-Rate-Alerts als automatischer Kill-Switch.
Berichterstattung: „wie viel Budget verbrannt“, „welche Abweichungen steady-state“.

10) Spieltage (Übungen)

Szenario: Kurzlegende (z.B. „Region-Ost verloren“), Injektionsschritte, SLO-Ziele, Rollen, Zeit.
Bewertung: RTO/RPO ist sachlich, Qualität der Kommunikation, Korrektheit des Runbooks.
Retro: Liste der Verbesserungen mit Eigentümern und Fristen, Aktualisierung der Dokumentation/Dashboards.

11) Automatisierung und CI/CD

Smoke-Chaos: kurze Staging-Tests bei jeder Freigabe (z.B. 1 Pod-Kill + 200 ms Delay pro Route).
Nacht/Woche: schwerere Szenarien (5-15 min) mit Bericht.
Promo-Gates: Wenn p95/Fehler> Schwelle auf canary - Auto-Rollback.
Repositories mit Versuchskatalog (YAML + Runbook + SLO-Thresholds).

12) Anti-Muster

„Break Prod ohne Geländer“: keine Stop-Kriterien, kein On-Call → das Risiko eines echten Vorfalls.
Einmalige Aktion statt Prozess.
Chaos ohne Steady-State: Es ist nicht klar, was als Erfolg/Misserfolg zu betrachten ist.
Übermäßige Retrays → Selbst-DDoS bei der Injektion von Verzögerungen.
Business SLI ignorieren: „Technar“ -Erfolge bei Zahlungsausfällen/Aufträgen.
Mangel an Post-Analyse und Eigentümer von Verbesserungen.

13) Checkliste Umsetzung (0-45 Tage)

0-10 Tage

Definieren Sie steady-state SLI (user + business).
Werkzeug auswählen (Chaos Mesh/Litmus/Toxiproxy/FIS).
Beschreiben Sie das Geländer: blast radius, stop-Kriterien, Fenster, Rollen.

11-25 Tage

Führen Sie die ersten Experimente durch: Pod-Kill, 100-200 ms Delay pro kritischem Upstream, Drop 1% der Pakete.
Konfigurieren Sie Burn-Rate-Alerts, verknüpfen Sie Kill-Switch mit Stop-Kriterien.
Verbringen Sie den ersten Spieltag, sammeln Sie Retro und Fixes.

26-45 Tage

Hinzufügen von Skripten auf AZ-Ebene/Abhängigkeiten (externes PSP, DB-Lag).
Automatisieren Sie das nächtliche Chaos auf Staging; Vorbereitung von „saisonalen“ Szenarien (Peaks).
Versuchskatalog und regelmäßige Berichte für das Management/SRE.

14) Reifegradkennzahlen

≥80% der kritischen Routen haben die beschriebenen Experimente und Steady-State-Metriken.
Der Auto Kill-Switch wird ausgelöst, wenn die p99/error-rate Schwellenwerte überschritten werden.
Vierteljährlich - AZ Level Game-Day/Region; ≥1 Mal/Monat - Zielszenario der Abhängigkeiten.
Die MTTR sinkt nach einem Zyklus von Verbesserungen, die Korrelation „Release ↔ Incident“ nimmt ab.
Der Anteil „unerwarteter“ Stürze bei realen Störungen tendiert → gegen Null.
Dashboards zeigen „Resilienz“ als KPIs (Burn-Rate, Erholungszeit, Anteil erfolgreicher DR-Aktionen).

15) Beispiele für Guardrails und Stop-Trigger

Stop bei: 'http _ req _ failed> 1%' 3 Minuten, 'p99> 1000 ms' 3 Fenster, 'deposit _ success <99. 5%`.
Reduzierter Blast-Radius: Manifest-Auto-Rollback, GSLB-Gewichte zurückgeben, Fehlerinjektionen deaktivieren.
Stop-Befehl: einzelne Schaltfläche/Skript mit Ursachenprotokollierung.

16) Kultur und Prozesse

Chaos ist Teil des SRE-Rhythmus, nicht „extrem“.
Transparente Berichte, Erkennung von Schwachstellen, Korrekturmaßnahmen.
On-Call-Training, Simulation der Kommunikation mit Kunden/Partnern.
Verknüpfung mit SLA/SLO und Budgets: Chaos sollte die Zuverlässigkeit erhöhen, nicht untergraben.

17) Fazit

Chaos Engineering macht aus der „Hoffnung auf Neun“ nachweisbare Nachhaltigkeit. Formulieren Sie Steady-State, setzen Sie Geländer, brechen Sie klein und kontrolliert, beobachten Sie SLO und Business SLI, erfassen und automatisieren Sie Verbesserungen. Dann werden aus echten Störungen überschaubare Ereignisse: ein vorhersehbares RTO, ein sicheres Error-Budget und die Bereitschaft des Teams, ohne Panik zu handeln.