Incident Response Playbook für kleine und mittlere Teams

Kurz gesagt: Wenn am Freitag um 23:30 der Produktionsserver fällt, ist es nicht die Zeit, einen Prozess von Grund auf zu erfinden. Ein Incident Response Playbook ist ein Dokument, das Rollen, Kommunikation und Verfahren definiert, bevor Sie sie brauchen. Hier ist ein minimales Playbook geeignet für ein 5-20 Personen Team.

Rollen während eines Vorfalls

Klare Rollen eliminieren Chaos. Auch ein kleines Team braucht mindestens:

• Incident Commander (IC) - managt den Vorfall, trifft Entscheidungen, eskaliert. Schreibt keinen Code.
• Technical Lead - die Person, die den Problembereich kennt. Schreibt den Fix.
• Communications Lead - aktualisiert Status Page, Kunden, Management. Für ein kleines Team kann das gleiche wie IC sein.
• Scribe - schreibt Timeline, wer was macht, wann. Entscheidend für Post-Mortem.

In einem Team bis 5 Personen typisch IC + Technical Lead = 2 Rollen geteilt, andere übernimmt IC.

Severity Levels

Definieren Sie 3-4 Schweregrade im Voraus:

• SEV1 (Critical) - Hauptservice komplett nicht verfügbar. Sofort reagieren, auch nachts paging.
• SEV2 (Major) - erhebliche Degradation (Teil der Features, einige Benutzer). Reaktion innerhalb 30 Min während Arbeitszeit, innerhalb 1 Std außerhalb.
• SEV3 (Minor) - geringe Auswirkung, Workaround existiert. Reaktion bis zum nächsten Arbeitstag.
• SEV4 (Cosmetic) - keine user-facing Auswirkung, geht in normale Queue.

SEV1 Vorgehen: die ersten 15 Minuten

1. 00:00 - Detektion. Alert kommt vom Monitoring oder vom Kunden. Jemand in der On-Call-Rotation bestätigt, dass es ein echtes Problem ist.
2. 00:02 - IC-Aktivierung. Ein dedizierter Kommunikationskanal öffnet (Slack #incident-N oder Discord). Technical Lead wird gerufen.
3. 00:05 - Erstes Status-Update. Auf öffentlicher Status Page: „Untersuchen Berichte über [Problem]." E-Mail an interne Personen, die es wissen sollten.
4. 00:10 - Initial Diagnostics. Prüfen Sie kürzliche Deploys, Monitoring-Grafen, Error-Logs. Was änderte sich in den letzten 30-60 Min?
5. 00:15 - Entscheidung: Rollback, Hotfix oder Workaround? Wenn nicht sofort klar, IC eskaliert oder ruft weitere Ingenieure.

Kommunikation: die „5 + 30"-Regel

Aktualisierung der Status Page mindestens alle 30 Minuten während SEV1, auch wenn Sie keine neuen Infos haben. „Untersuchen noch, ETA noch unbekannt" ist ein besseres Update als Stille - Kunden wissen wenigstens, dass jemand am Problem arbeitet.

Das erste Update muss innerhalb 5 Minuten nach Detektion erfolgen. Unabhängig davon, ob Sie die Ursache kennen.

Rollback als Default

Bei SEV1, der kurz nach einem Deploy begann, ist Rollback die erste Wahl, nicht Hotfix. Hotfix unter Druck in der Nacht ist Quelle weiterer Bugs. Rollback stellt einen bekannt guten Zustand wieder her und gibt Zeit für ruhige Diagnostik am Morgen.

Für Rollback brauchen Sie:

• Deployment-Versionierung (Docker Tags, Git Tags, Deployment Artifact)
• Datenbank-Migrationen backwards compatible (wenn neue Version eine Spalte droppt, die alte erholt sich nicht)
• Dokumentiertes Rollback-Verfahren (Befehle, wie lange es dauert, wer es ausführen kann)

Post-Mortem innerhalb 48 Stunden

Nach jedem SEV1/SEV2-Vorfall schreiben Sie ein Dokument mit Struktur:

1. Summary - 2-3 Sätze was passierte, wie lange dauerte, wen es betraf
2. Timeline - exakte Zeiten von Detektion, Schlüsselaktionen, Lösung
3. Root Cause - warum es passierte (technischer Grund + prozessualer Grund)
4. Impact - Anzahl betroffener Kunden, Business Impact
5. What went well - was wir gut gemacht haben (würdigen Sie das Team)
6. What went wrong - wo wir Zeit verloren haben
7. Action items - konkrete Aufgaben mit Owner und Deadline (nicht „besser testen" - lieber „Integration-Test für Payment-Flow innerhalb 14 Tage hinzufügen, Owner: X")

Blameless Post-Mortem Regel: Sie suchen keinen Schuldigen, Sie suchen eine systemische Schwäche. „John hat eine schlechte Version deployed" ist die falsche Schlussfolgerung - die richtige ist „der Deploy-Prozess enthielt keine Canary-Phase, die den Bug vor vollem Rollout abfangen würde."

On-Call-Rotation

Für ein Team mit 24/7-Produkt:

• Wöchentliche Rotationen - kürzer brennt aus, länger bedeutet Kontinuität des Kontexts
• Immer primärer + sekundärer On-Call. Sekundärer übernimmt, wenn primärer nicht innerhalb 5 Min reagiert.
• Kompensation (Extra-Payment, Time-Off) für nächtliche und Wochenend-Paging
• Monatliches „On-Call Review" - wer wurde oft geweckt, was kann automatisiert werden

Werkzeuge

• Monitoring (ePulz.io, Datadog, New Relic) - Detektion + Alerting
• Paging (PagerDuty, Opsgenie, Better Stack) - Eskalation, Rotation, SMS/Voice
• Status Page (eigene, ePulz.io, StatusPage.io) - externe Kommunikation
• Runbook Hosting (Notion, GitHub Wiki, interne Docs) - Playbooks und Runbooks
• Postmortem Template (Confluence, Notion Template) - Standardisierung

Fazit

Incident Response kann nicht unter Druck improvisiert werden. 30 in das Schreiben eines Playbooks investierte Minuten zahlen sich beim ersten größeren Ausfall aus - weniger Chaos, kürzere MTTR, bessere Kommunikation mit Kunden und ein Team, das weiß, was zu tun ist.

Beginnen Sie mit automatischer Detektion

ePulz.io löst die ersten Minuten von Incident Response: Detektion + Alerting via E-Mail, Telegram und Webhook zu Slack / Discord / PagerDuty.

Monitoring starten →