Incident Response Playbook für kleine und mittlere Teams

Rollen während eines Vorfalls

Klar verteilte Rollen eliminieren Chaos. Auch ein kleines Team braucht mindestens:

• Incident Commander (IC) - managt den Vorfall, trifft Entscheidungen und eskaliert. Schreibt selbst keinen Code.
• Technical Lead - die Person, die den Problembereich kennt. Schreibt den Fix.
• Communications Lead - aktualisiert die Status Page, informiert Kunden und Management. In einem kleinen Team kann das dieselbe Person wie der IC sein.
• Scribe - protokolliert die Timeline: wer was macht und wann. Entscheidende Grundlage für das Post-Mortem.

In einem Team bis 5 Personen werden üblicherweise IC und Technical Lead abgespalten, die übrigen Rollen übernimmt der IC.

Severity Levels

Definieren Sie 3-4 Schweregrade im Voraus:

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

SEV1 Vorgehen: die ersten 15 Minuten

1. 00:00 - Detektion. Ein 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 sich (Slack #incident-N oder Discord) und der Technical Lead wird gerufen.
3. 00:05 - Erstes Status-Update. Auf der öffentlichen 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 und Error-Logs. Was hat sich in den letzten 30-60 Min geändert?
5. 00:15 - Entscheidung: Rollback, Hotfix oder Workaround? Wenn nicht sofort klar, eskaliert der IC oder ruft weitere Ingenieure hinzu.

Kommunikation: die „5 + 30"-Regel

Aktualisieren Sie die Status Page während eines SEV1 mindestens alle 30 Minuten, 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 von 5 Minuten nach der Detektion erfolgen, unabhängig davon, ob Sie die Ursache bereits kennen.

Rollback als Standard

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

Voraussetzung für einen Rollback ist:

• Deployment-Versionierung (Docker Tags, Git Tags, Deployment Artifact)
• Datenbank-Migrationen, die backwards compatible sind (wenn die neue Version eine Spalte droppt, stellt die alte sie nicht wieder her)
• Ein dokumentiertes Rollback-Verfahren (Befehle, wie lange es dauert, wer es ausführen kann)

Post-Mortem innerhalb von 48 Stunden

Schreiben Sie nach jedem SEV1/SEV2-Vorfall ein Dokument mit dieser Struktur:

1. Summary - 2-3 Sätze dazu, was passierte, wie lange es dauerte und wen es betraf
2. Timeline - exakte Zeiten von Detektion, Schlüsselaktionen und Lösung
3. Root Cause - warum es passierte (technischer und prozessualer Grund)
4. Impact - Anzahl betroffener Kunden und 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", sondern lieber „Integration-Test für Payment-Flow innerhalb von 14 Tagen hinzufügen, Owner: X")

Blameless Post-Mortem Regel: Sie suchen keinen Schuldigen, sondern eine systemische Schwäche. „John hat eine schlechte Version deployed" ist die falsche Schlussfolgerung - die richtige lautet „der Deploy-Prozess enthielt keine Canary-Phase, die den Bug vor dem vollen Rollout abgefangen hätte".

On-Call-Rotation

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

• Wöchentliche Rotationen sind der ideale Kompromiss - kürzere brennen aus, längere überlasten den primären On-Caller
• Immer einen primären + sekundären On-Call einplanen. Der sekundäre übernimmt, wenn der primäre nicht innerhalb von 5 Min reagiert.
• Kompensieren Sie nächtliche und Wochenend-Paging (Zuschlag oder Freizeitausgleich)
• Führen Sie ein monatliches „On-Call Review" ein - wer wurde am häufigsten geweckt und was lässt sich automatisieren

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 lässt sich nicht unter Druck improvisieren. 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 →