Chaos Engineering

1) Grundprinzipien

Steady State als Ausgangshypothese. Norm klar definieren (z.B.: p95 <200 ms, Fehlerrate <0. 3%, kritischer Flowerfolg> 99. 5%).
Isolierte Variablen. Ändern Sie, wann immer möglich, einen Faktor auf einmal, um die Wirkung und die Verbesserung kausal zu verknüpfen.
Grad. Wir beginnen mit kleinen Amplituden in einer sicheren Umgebung → erweitern die Reichweite und Intensität.
Guardrails. Explizite Stopp-Bedingungen nach SLO/Alert/Fehlerbudget.
Wiederholbarkeit. Das Experiment muss deterministisch reproduzierbar sein (Skripte/Manifeste/IaC).
Ethik und Sicherheit. Keine echten persönlichen Daten und Finanztransaktionen in Risikoexperimenten.

2) Was ist ein „steady state“

• Die p50/p95/p99 Latenzen der wichtigsten Endpunkte.
• Anteil erfolgreicher Transaktionen und Umwandlung kritischer Pfade.
• Fehlerrate, Timeouts, Anteil der Abfragen „shed“ (abgeschnitten bei Sättigung).
• Selbstheilungsrate (MTTR), Rückfallresistenz (keine Stürme).
• Domain-Invarianten: keine „Nachteile in der Bilanz“, einmal ausgeführte Zahlungen, Konsistenz des Berichtstages usw.

3) Injektionskatalog (was wir „brechen“)

Netzwerk: Latenz, Jitter, Verlust/Duplikate, Bandbreitenbeschränkung, TLS-Breaks, DNS-Flapping.
Berechnungen: CPU-Überlastung, Speicherdruck/GC, Erschöpfung der Deskriptoren, Clock Skew.
Lagerung: hohe p95 I/O, ENOSPC, Leader-/Replikatausfall, Split-Brain, lange Fsync.
Abhängigkeiten: 5xx/429, „langsamer Erfolg“, Degradation externer APIs, Rate-Limit.
Daten: Nachrichten duplizieren/überspringen, Out-of-Order, „schmutzige“ Einträge, Versionskonflikte.
Operationen: fehlgeschlagene Freigabe/config, Ficha-Flag mit Bug, abgelaufenes Zertifikat, Schlüsselrotation.
Menschen und Prozesse: Unzugänglichkeit der Verantwortlichen, verzögerte Handaufschaltung, falsches Runbook.

4) Versuchsplanung (Vorlage)

1. Hypothese: „Bei + 300 ms zum Währungsservice p99 der Haupt-API <450 ms öffnet sich der Breaker, die Stale-Antwort wird vor ≤ 15 Minuten gegeben“.
2. Injektion: Ausfallprofil (Typ/Amplitude/Dauer) und Zielkontur.
3. Metriken/Log-Tags: Kennzeichnung 'chaos. experiment_id`, `phase=inject|recover`.
4. Guardrails: Abbruch bei 'error _ rate> 2%' oder p99> SLA × 2 länger als 1 Minute.
5. Ergebnisse/Output: Liste der Beobachtungen, Bugs, Verbesserungen, Arbeitsplan und Re-Run.

5) Beobachtbarkeit: Was ist obligatorisch

Tracing: Anforderungspfad durch Abhängigkeiten; degradierte Segmente sind markiert.
Ressourcenmetriken: CPU, Heap/GC, FD, Festplatten-IOPS/Lat, Netzwerk-Bandbreite, Warteschlangentiefe.
Geschäftsmetriken: Konversion/Erfolg der Operationen, Anteil der kompensierten Transaktionen.
Ereignisprotokolle: Öffnen/Schließen von Breakern, Retrays und deren Budget, Schalten des DB-Leiters.
Das Panel des Experiments: ein Live-Dashboard mit Guardrails-Schwellen und einem „roten Knopf“ der Abtreibung.

6) Guardrails und Sicherheit

Technisch: obere Grenzen der Fehlerrate/Latenz, sinkender Anteil erfolgreicher Operationen, DLQ-Wachstum.
Organisatorisch: Zeitfenster beteiligt on-call, Prinzip „eine Zone - ein Experiment“.
Daten/Compliance: nur Synthetik oder anonymisierte Kits; Verbot von Tests, die zu regulatorischen Verstößen führen.
Rollback: Ein fertiges Rollback/Disable Flag/Soft Drain-Verfahren.

7) Resistenzmuster, die sich manifestieren müssen

Zeitbudgets und Jitter-Retrays (keine Stürme).
Circuit Breaker mit Halböffnung und exponentieller Erholung.
Bulkheads: Isolierung von Pools nach Kritikalität (Zahlungen gegen Analysten).
Backpressure und Rate-Limit: vorhersehbarer Cutoff mit niedriger Priorität.
Cache mit Coalescing, Schutz vor „Aufwärmstürmen“.
Idempotenz von Nebenwirkungen und Saga mit kompensierenden Aktionen.
Quorums, Failover und Anti-Entropie für die Datenwiederherstellung.

8) Beispielszenarien (Sketche)

8. 1 Langsame Abhängigkeit (YAML)

yaml experiment: slow-downstream target: svc:api inject:
dependency:
name: currency mode: add_latency p95_ms: 300 duration: 10m guardrails:
error_rate: "< 1. 5%"
p99_latency: "< 450ms"
expectations:
breaker_open: true stale_data_served: "<= 15m"

8. 2 Verlust des OBD-Leiters

Injektion: Führerstopp/erzwungene Wiederwahl.
Warten: temporäres Schreibverbot, Lesen aus dem Quorum, WAL/Outbox-Sicherheit, automatische Replikationswiederherstellung, kein doppelter Eintrag.

8. 3 ENOSPC auf der Log-Disc

Injektion: Füllen Sie die Scheibe bis zu 95-100%.
Warten: Notfallrotation von Protokollen, Sicherheit kritischer Protokolle, Deaktivieren unkritischer Protokolle, Alert und Auto-Remediation.

8. 4 Burst-Verkehr + Shading

Injektion: × 3 RPS für 5 Minuten auf heißem Endpoint.
Erwartung: Verwerfen niedriger Priorität, stabiler p95 „Kern“, keine Kaskade von Retrays.

9) Automatisierung in CI/CD

Chaos-Rauch im Stapel für jede Freisetzung (kurze Injektionen bei sicheren Amplituden).
Nachtläufe durch den Katalog von Experimenten (Matrix-Dienste × Arten von Fehlern).
Gates: Eine Freigabe wird blockiert, wenn die „Belastbarkeit unterhalb der Schwelle“ liegt (z.B. Fallback-Erfolgsquote <95%).
Artefakte: Bericht, Traces, CPU/Heap Flamgraphen, Metrik- und Config-Snap-Shots.

10) Game Days (Spieltage)

• Rollen: Versuchsleiter, Metrikbeobachter, Rollback-Operator, Unternehmensvertreter.
• Szenarien: Cache-Degradation, AZ-Teilausfall/Failover-Region, „schlechte Freigabe“, Nicht-Verfügbarkeit des externen Anbieters.
• Ergebnisse: gefundene Lücken im Runbook, Verbesserungen bei Alerts, Anpassung von SLOs und Retraybudgets.

11) Chaos für Daten, Ereignisse und ML

Datenströme: Tests für Duplikate, Auslassungen, Out-of-Order, Verzögerungen; Validierung von idempotenten Consumern und DLQ-Strategien.
Speicher: Indexdegradation, Hot-Partition, Blockierungskonflikt, Replikation unter der Verzögerung.
ML: Verzögerung des Fitch-Stores, Rollback zum Baseline-Modell, Qualitätsverschlechterung der Eingabedaten (Drift) - das System sollte „sanft stumpf“ sein, nicht fallen.

12) Anti-Muster

Chaos ohne Beobachtbarkeit: Man ist „blind“, die Schlüsse sind spekulativ.
Injektionen sofort in Proda ohne Stage und Guard Rails.
„Ein großes Experiment“ auf einmal - es ist unklar, was genau funktioniert hat.
Planlose Chaos-Aktionen ohne Hypothesen und Retest nach Fixierungen.
Konzentration nur auf die Infrastruktur - Geschäftsinvarianten werden vergessen.
Menschen/Prozesse ignorieren: Alerts, On-Call, Runbook sind Teil des Systems.

13) Praxisreife (Modell)

1. Ad-hoc: Einzelinjektionen lokal.
2. Stage Chaos: Skriptkatalog, wiederholbare Läufe, Dashboards.
3. Release-Chaos: Rauchchaos in jeder Veröffentlichung, Tore, Berichte.
4. Prod-Chaos mit Einschränkungen: wenig Verkehr, strenge Guardrails, bereites Rollback.
5. Kontinuierliche Stabilität: Auto-Experimente, SLO-Steuerung, Verbesserungen als Arbeitsfluss.

14) Integration mit architektonischen Praktiken

Resilienztests: Chaos-Experimente ergänzen Fault-Injections und Degradationsszenarien.
Belastungstests: Kombinierte „Load + Failure“ -Experimente zeigen Kaskaden und Sturm von Retrays.
Politik als Code/RBAC/ABAC: guardrails, Rollback-Schritte und Limits als Politik gestalten.
Einwilligungs-/Datenschutzmanagement: Lassen Sie keine Experimente zu, die den Datenverarbeitungsmodus stören.
Geo-Architektur: Chaos-Failover von Regionen und Verknüpfung von Daten mit Jurisdiktionen.

15) Mini-Rezepte (Pseudocode)

Braker + Degradierung

if breaker. open():
return serve_stale(cache. max_age=15m)
try:
res = call(dep, timeout=250ms)
return res except Timeout:
breaker. trip()
return serve_stale()

Limiter + Shading

if cpu. load() > 0. 85 or queue. depth() > HIGH:
if req. priority < HIGH: return 503_SHED limiter. acquire()

Idempotente Nebenwirkung

key = "payout:"+external_id if kv. exists(key): return kv. get(key)
res = side_effect()
kv. put(key, res, ttl=30d)
return res

16) Checkliste des Architekten

1. Steady State und Guardrails definiert?
2. Gibt es ein Skriptverzeichnis (Netzwerk/CPU/Speicher/Abhängigkeiten/Daten/Betrieb)?
3. Deckt die Beobachtbarkeit Ressourcen, Latenzschwänze, Geschäftsinvarianten ab?
4. Sind Timeouts/Retrays/Breaker/Limiter/Bulkheads enthalten und parametrierbar?
5. Runbook und „roter Knopf“ vorbereitet?
6. Gibt es Chaos-Rauch im Stage und Nightly-Experimente?
7. „Sichere“ Fenster und Rollen an Spieltagen vorgeschrieben?
8. Sind die Experimente reproduzierbar (IaC/Skripte), werden die Ergebnisse versioniert?
9. Verbesserungen werden durch Aufgaben erfasst, Retests durchgeführt?
10. Daten und ML-Pipelines abgedeckt, nicht nur HTTP?

Schluss

Chaos Engineering verwandelt „unvorhergesehene Vorfälle“ in vorhersehbare Szenarien. Die Resilienzhypothese, kontrollierte Injektionen, harte Guardrails, reichhaltige Beobachtbarkeit und die Disziplin der Retests sind Werkzeuge, die das Risiko von Releases reduzieren und das Vertrauen in die Plattform erhöhen. Infolgedessen versteht das Team die Grenzen des Systems, weiß, wie man elegant degradiert und dem Benutzer den Service auch bei Ausfällen schnell zurückgibt.