Was vorher fertig sein muss
Eine etablierte On-Call-Rotation mit Eskalationspfaden und SLO-Definitionen existiert, sodass der Incident-Trigger einen klaren Empfänger hat.
Runbooks für die häufigsten Failure Modes der betroffenen Systeme existieren und sind aus dem Alarm-Kontext verlinkt.
Was vor Start vorliegen muss
Incident-Channel-Template (Slack, MS Teams) mit vorgefertigten Befehlen; Status-Page-Zugang; Pager-Tool (PagerDuty, Opsgenie, Grafana OnCall); Conference-Bridge oder Video-Call-Link; Logging-Dashboard pro Service; Eskalations-Liste.
Incident Commander (IC) koordiniert; Operations Lead (OL) führt technische Schritte; Communications Lead (CL) hält Stakeholder informiert; Scribe protokolliert Aktionen mit Zeitstempel; Subject Matter Experts (SMEs) auf Abruf.
Severity-Definition (SEV1-SEV3) mit klaren Kriterien; Eskalationspfade; Status-Page-Templates pro Severity; Liste der Stakeholder pro Severity; bekannte Service-Dependencies.
Erste IC-Übernahme binnen 5 min, Incident-Dauer offen, Hand-off alle 2 h
Pager-Alert öffnet automatisch einen Incident-Channel mit Topic, Severity, IC-Slot. Bot postet Rollenliste und nächste Schritte. Conference-Bridge im Topic. Status-Page wird bei SEV1/SEV2 automatisch in Investigating gesetzt.
Die eine Frage, die diese Methode beantwortet
Wer hält gerade welche Rolle, welcher Effekt soll als nächstes überprüft werden, und wann erfolgt das nächste Stakeholder-Update?
Marker: Phase
| Schritt | Dauer | Aktion | Hinweis |
|---|---|---|---|
1Phase 1: Aktivierung | 0-5 min | Erster Responder übernimmt IC-Rolle und postet im Channel: ich bin IC, Severity X, Hypothese Y. Channel-Topic mit IC-Name aktualisieren. Pager-Alarm bestätigen. | Wenn niemand IC übernimmt, eskaliert der Pager nach 5 min. IC-Übernahme ist explizit, nicht implizit. Kein „kümmert sich schon jemand?“. |
2Phase 2: Rollen besetzen | 5-15 min | IC ruft Operations Lead und Communications Lead. Scribe wird benannt. SMEs werden gezielt gepagert, nicht das ganze Team. Conference-Bridge wird gestartet, Channel bleibt das Hauptmedium. | IC bleibt Koordinator, nicht Operator. Wenn IC selbst tippt, fehlt jemand für den Überblick. Bei SEV1 sofort separaten OL benennen. |
3Phase 3: Investigation und Mitigation | variabel | OL führt Hypothesen-Tests, Scribe protokolliert mit Zeitstempel. IC koordiniert: was wurde getestet, was ist die nächste Aktion, wer macht. CL postet alle 30 min Status-Updates an Stakeholder. | Mitigation schlägt Ursachenfindung. Wenn ein Rollback verfügbar ist, OL rollt zurück, Ursachenanalyse folgt im Postmortem. Keine parallelen Aktionen ohne IC-Bestätigung. |
4Phase 4: Resolution und Hand-off | 15 min | IC bestätigt Recovery anhand SLO-Metriken, nicht anhand Bauchgefühl. Channel-Topic auf Resolved. Status-Page geschlossen. Bei langem Incident vorher Hand-off mit Übergabe an neuen IC alle 2 h. | Recovery braucht zwei aufeinanderfolgende grüne Mess-Intervalle. Wenn nur ein Tick grün ist, bleibt der Incident offen. Hand-off mit explizitem Übergabe-Statement (Status, offene Punkte, nächste Schritte). |
5Phase 5: Übergabe an Postmortem | 15 min nach Resolution | IC erstellt Postmortem-Ticket mit Incident-ID, verlinkt Channel-Log und Timeline. Postmortem-Termin binnen 5 Werktagen. Action Items aus dem Incident vorab im Ticket gesammelt. | Wer den Channel verlässt, bevor das Postmortem-Ticket existiert, riskiert dass die Lessons verloren gehen. Scribe ist verantwortlich für vollständigen Log-Export. |
Was am Ende rauskommt
Incident-Channel-Log mit Zeitstempeln aller Aktionen, Rollen-Zuordnung, Hypothesen, Mitigationen, Status-Page-Updates und Stakeholder-Mitteilungen, plus Postmortem-Ticket mit Incident-ID, Severity, Dauer und Owner.
Pro Incident eindeutige ID (INC-YYYY-NNNN). Channel-Log wird beim Schliessen archiviert. Postmortem-Dokument trägt dieselbe ID. Action-Item-Status wird im Header des Postmortems aktuell gehalten.
Kompakte Arbeitsvorlage für Incident Command mit Kontext, Input, Ergebnisartefakten und nächstem Schritt.
# Incident Command Arbeitsvorlage
## Ziel
Rollenbasierter Ansatz für die Koordination größerer Incidents.
## Kontext
Wann und wofür nutzen wir diese Methode?
## Input
Welche Daten, Beobachtungen, Entscheidungen oder Materialien liegen vor?
## Durchführung
Kurze Notizen entlang des Run Sheets.
## Ergebnisartefakte
- Incident Log:
- Action Tracker:
- Stakeholder Updates:
## Annahmen und offene Fragen
- ...
## Entscheidung / Nächster Schritt
Owner, Datum und Erfolgssignal.Konkret gefülltes Szenario
## Incident INC-2026-0847 — Channel-Log (Auszug)
**Severity**: SEV-2. **Dauer**: 35 min. **Status**: Resolved 09:47 UTC.
```
09:12 :alarm: PagerDuty SEV-2 order-api.error_rate >5%
09:13 @anna /ic-take — ich übernehme IC, Hypothese: deployment 09:05?
09:14 @ben /role ops-lead — OL gesetzt, prüfe deployment-revert-Option
09:15 @cara /role comms-lead — Status-Page auf Investigating, erste Mail an internal-stakeholders
09:18 @ben: kein deployment heute morgen, prüfe Connection-Pool
09:21 @ben: pool exhausted, korreliert mit batch-recon-202 ab 09:08
09:23 @anna: OL stoppt Batch, CL postet Mitigation-Update
09:33 @ben: Batch gestoppt, Error-Rate fällt
09:42 @anna: erstes grünes Intervall, halte offen
09:47 @anna: zweites grünes Intervall, /ic-resolve
09:48 @cara: Status-Page resolved, External Comms verschickt
09:55 @anna: Postmortem-Ticket POST-2026-0847 angelegt, Termin 16.05.
```
**Rollen-Hand-off**: keiner (Incident <2 h). **Action Items pre-Postmortem**: 3 (siehe Ticket).Symptome erkennen, gegensteuern
Incident Commander öffnet Shells, führt Befehle aus, verliert den Überblick über Aktionen anderer.
OL benennen und IC strikt auf Koordination beschränken. Wenn IC technisch eingreifen muss, IC-Rolle vorher übergeben.
Mehrere Hypothesen parallel, niemand weiss, was gerade getestet wird, doppelte Aktionen.
IC fasst alle 10 min explizit zusammen: Status, aktuelle Aktion, nächste Aktion. Keine parallelen Tests ohne Sync.
Erste externe Kommunikation kommt erst nach Resolution, Kunden eskalieren parallel.
CL postet ab SEV-2 alle 30 min, auch wenn kein Fortschritt. Schweigen erzeugt mehr Aufwand als ein nüchterner Zwischenstand.
Incident wird nach erstem grünen Tick geschlossen, fällt 10 min später wieder um.
Mindestens zwei aufeinanderfolgende grüne Mess-Intervalle vor Resolution. Bei kurzen Intervallen drei Ticks.
IC ist 6 h durchgängig auf, trifft müde Entscheidungen, Qualität sinkt.
Hand-off alle 2 h verbindlich, auch wenn IC bleiben will. Ausgeschlafener IC entscheidet besser als routinierter aber müder.
Channel wird archiviert, Lessons gehen verloren, dieselbe Klasse Incident wiederholt sich.
Postmortem-Ticket ist Teil der Resolution-Checkliste. Channel kann erst archiviert werden, wenn Ticket-Link gepostet ist.
Done-Signale, in unter einer Minute prüfbar
Zum Steckbrief für Zweck, ähnliche Methoden und Quellen — oder direkt zur nächsten Methode im Katalog.