WAF-REL-060 – Incident Response & Runbook Readiness
Beschreibung
Alle Produktions-Workloads MÜSSEN einen dokumentierten Incident Response (IR) Plan mit Severity-Definitionen, Eskalationspfaden und On-Call-Rotation haben. Runbooks MÜSSEN für alle kritischen Alerts existieren und direkt aus Alert-Notifications verlinkt sein. Post-Incident Reviews MÜSSEN für SEV1/SEV2 innerhalb von 5 Werktagen durchgeführt werden.
Rationale
Ohne definierten IR-Prozess steigt MTTR dramatisch, weil On-Call-Engineers unter Druck Schritte rekonstruieren, die bereits dokumentiert wurden. Runbooks kodieren institutionelles Wissen und ermöglichen konsistente Incident-Lösung unabhängig vom Dienst habenden Engineer. Post-Mortems verhindern Wiederholungen durch strukturierte Root Cause Analysis.
Bedrohungskontext
| Risiko | Beschreibung |
|---|---|
Verlängertes MTTR |
Ohne Runbooks verbringen Engineers wertvolle Minuten mit Diagnose statt Behebung. |
Wissensverlust |
Schlüssel-Engineer im Urlaub; kein Backup hat Kontextwissen für kritischen Service. |
Inkonsistente Severity |
Ohne klare Kriterien wird SEV1 als SEV3 behandelt; keine angemessene Eskalation. |
Incident-Wiederholung |
Derselbe Root Cause verursacht dritten Incident; keine Post-Mortem Action Items verfolgt. |
Anforderung
-
4 Severity-Stufen (SEV1–SEV4) mit objektiven, messbaren Kriterien
-
On-Call-Rotation mit primärem und sekundärem Kontakt konfiguriert
-
Runbooks für alle kritischen Alerts; direkt aus Alert-Body verlinkt
-
MTTR, MTTD und Incident-Frequenz als Metriken getrackt
-
Post-Incident Reviews für SEV1/SEV2 innerhalb 5 Werktage
-
Action Items aus Post-Mortems bis Zieldatum nachverfolgt
Implementierungsanleitung
-
Severity-Definitionen: YAML-Dokument mit messbaren Kriterien (error rate %, user impact %)
-
On-Call einrichten: PagerDuty/OpsGenie mit primärer und sekundärer Rotation
-
Top-5-Runbooks: Für die häufigsten 5 Alerts je Service Runbook schreiben
-
Alert-Beschreibung:
alarm_descriptionenthält Runbook-URL und Severity -
MTTR-Dashboard: Incident-Metriken in Grafana oder native Tool sichtbar machen
-
Post-Mortem-Kultur: Blameless Post-Mortem Template einführen; Pflicht für SEV1/SEV2
Reifegrad-Abstufung
| Level | Bezeichnung | Kriterien |
|---|---|---|
1 |
Ad-hoc |
Kein definierter Prozess; Incidents von verfügbaren Personen behandelt. |
2 |
Prozess dokumentiert |
Severity und Eskalation definiert; On-Call konfiguriert; Basis-Runbooks vorhanden. |
3 |
Runbooks verlinkt, MTTR getrackt |
Alle Critical Alerts mit Runbook-Link; MTTR monthly reviewed; Post-Mortems für SEV1/SEV2. |
4 |
Automatisierte Triage |
Automatische Diagnose-Daten bei Alert; Runbook-Schritte teilweise automatisiert. |
5 |
Self-Healing |
AIOps-Incident-Correlation; MTTR < 5 Minuten für bekannte Fehlerklassen. |
Terraform Checks
waf-rel-060.tf.aws.sns-topic-alarm-action
Prüft: CloudWatch Alarms haben alarm_actions und ok_actions für On-Call-Benachrichtigung.
| Compliant | Non-Compliant |
|---|---|
|
|
Remediation: alarm_actions und ok_actions auf SNS-Topic zeigen lassen.
alarm_description mit Runbook-URL und Severity-Klassifizierung befüllen.
Evidenz
| Typ | Pflicht | Beschreibung |
|---|---|---|
Governance |
✅ Pflicht |
Incident Response Plan mit Severity, Eskalationspfaden und On-Call-Struktur. |
Process |
✅ Pflicht |
Post-Incident Review Protokolle für alle SEV1/SEV2 Incidents letzter 12 Monate. |
Config |
Optional |
On-Call-Schedule in PagerDuty/OpsGenie mit aktueller Rotation. |
Governance |
Optional |
Runbook-Katalog mit Links zu allen Critical-Alert-Runbooks. |