WAF-REL-090 – Chaos Engineering & Fault Injection
Beschreibung
Produktions- und Staging-Workloads MÜSSEN quartalsweise strukturierte Chaos-Experimente mit dokumentierten Hypothesen durchführen. Experimente MÜSSEN Stop Conditions definieren. Jedes Experiment MUSS zuerst in Staging validiert werden, bevor es in Produktion läuft. Ergebnisse MÜSSEN dokumentiert und in Reliability Improvements überführt werden.
Rationale
Chaos Engineering validiert Reliability-Behauptungen empirisch. SLOs, Circuit Breaker, Multi-AZ-Konfigurationen und Health Checks sind Behauptungen über das System-Verhalten unter Fehlerbedingungen. Ohne Chaos Testing bleiben diese Behauptungen unvalidiert. Nur durch kontrollierte Fehler-Injektion kann eine Organisation wissen, dass ihre Resilience-Maßnahmen tatsächlich funktionieren.
Bedrohungskontext
| Risiko | Beschreibung |
|---|---|
Unbekannte Failure Modes |
Resilienz-Lücken werden erst im echten Disaster entdeckt. |
Unvalidierte Reliability Claims |
Circuit Breaker konfiguriert, aber nie getriggert – unklar ob korrekt. |
Ungetestete Recovery |
Multi-AZ deployed, aber AZ-Failover-Zeit unbekannt – RTO nicht validiert. |
Versteckte Kopplung |
Abhängigkeiten, die nur bei spezifischen Fehlermustern sichtbar werden. |
Anforderung
-
Hypothesis-driven Experiments: "Wenn X ausfällt, erwarten wir Y innerhalb von Z Sekunden"
-
Stop Conditions: automatischer Abbruch wenn SLO-Alarm ausgelöst
-
Staging First: jedes Experiment zuerst in Staging, dann schrittweise in Produktion
-
Blast Radius Limit: max. 25% der Instanzen beim ersten Experiment einer Art
-
Ergebnisdokumentation: Hypothese, erwartet, tatsächlich, Actions
-
Quartalsweise mindestens 3 dokumentierte Experimente pro Team
Implementierungsanleitung
-
Hypothesen-Liste erstellen: Welche Failure Modes sind für diesen Service relevant?
-
Staging-Experimente starten: Mit kleinstem Blast Radius beginnen (1 Pod, 10% Instanzen)
-
Stop Conditions: CloudWatch Alarm oder Prometheus Alert als Abbruchbedingung konfigurieren
-
AWS FIS verwenden: Experiment Template mit stop_condition Resource konfigurieren
-
Ergebnisse dokumentieren: YAML-Experiment-Dokument mit Hypothese und Outcome
-
Actions tracken: Findings in Reliability Debt Register (WAF-REL-100) eintragen
Reifegrad-Abstufung
| Level | Bezeichnung | Kriterien |
|---|---|---|
1 |
Keine Chaos-Tests |
Resilienz nur durch Produktions-Incidents bekannt. |
2 |
Ad-hoc Tests |
Gelegentliche manuelle Tests ohne Dokumentation. |
3 |
Strukturiert + dokumentiert |
Hypothesis-driven; quartalsweise; AWS FIS / Azure Chaos Studio; Ergebnisse dokumentiert. |
4 |
Produktions-Chaos kontrolliert |
Produktion mit Stop Conditions; GameDay jährlich; Experimente in Release-Pipeline. |
5 |
Kontinuierlich + ML |
Automatisierte Low-Blast-Radius Experimente; ML-Anomalieerkennung. |
Terraform Checks
waf-rel-090.tf.aws.fis-experiment-template
Prüft: AWS FIS Experiment Template hat stop_condition und description.
| Compliant | Non-Compliant |
|---|---|
|
|
Remediation: stop_condition Block mit CloudWatch Alarm hinzufügen.
description mit Hypothesen-Text befüllen.
Evidenz
| Typ | Pflicht | Beschreibung |
|---|---|---|
Process |
✅ Pflicht |
Quartalsweise Chaos-Experiment-Berichte: Hypothese, Erwartung, Ergebnis, Actions. |
Governance |
✅ Pflicht |
Chaos Engineering Charter mit Genehmigungsprozess und Blast-Radius-Limits. |
IaC |
Optional |
AWS FIS Experiment Templates oder Azure Chaos Studio Workflow-Konfigurationen. |
Process |
Optional |
GameDay-Bericht des letzten Jahres. |