Der Incident-Management-Prozess Schritt für Schritt: vom Alert bis zum Postmortem (mit Vorlage)

Ein Incident-Management-Prozess ist die vereinbarte Abfolge von Schritten, Rollen und Kommunikationsregeln, der Ihre Organisation folgt – vom Moment, in dem etwas ausfällt, bis die Erkenntnisse dokumentiert und umgesetzt sind. Ohne einen solchen Prozess wird jede Störung improvisiert: Fünf Personen debuggen dasselbe Symptom, niemand informiert die Kundschaft, und zwei Wochen später weiß keiner mehr genau, was eigentlich passiert ist.

Dieser Leitfaden führt Sie Schritt für Schritt durch den Incident-Management-Prozess, vom ersten Alert bis zum Postmortem. Er ist bewusst werkzeugneutral gehalten: Sie können ihn mit einer spezialisierten Incident-Plattform genauso anwenden wie mit einem Chat-Kanal und einer Tabelle. Am Ende finden Sie eine beispielhafte Schweregrad-Matrix (SEV1 bis SEV4) und eine Postmortem-Vorlage zum Kopieren, die Sie an Ihr Team anpassen können.

Was ist ein Incident – und was nicht?

Bevor Sie einen Prozess entwerfen, brauchen Sie eine gemeinsame Definition. Eine praxistaugliche Variante: Ein Incident ist jedes ungeplante Ereignis, das einen Service für Nutzerinnen und Nutzer beeinträchtigt oder zu beeinträchtigen droht und eine koordinierte Reaktion erfordert. Entscheidend ist der zweite Teil. Ein einzelner abgestürzter Pod, den Kubernetes selbstständig neu startet, ist kein Incident. Ein ausfallender Zahlungsdienstleister, der für einen Teil der Kundschaft den Checkout blockiert, sehr wohl.

Halten Sie einige konkrete Auslöser schriftlich fest, damit die Person in Rufbereitschaft nicht erst diskutieren muss, ob sie einen Incident ausruft:

• Ein kundenrelevantes SLO verbraucht sein Error Budget so schnell, dass es innerhalb von Stunden oder Tagen aufgebraucht wäre.
• Eine kritische User Journey (Login, Checkout, Datenexport) schlägt im synthetischen Monitoring oder im Real User Monitoring fehl.
• Datenverlust, Datenkorruption oder ein vermuteter Sicherheitsvorfall – unabhängig davon, ob Auswirkungen sichtbar sind.
• Jede Situation, in der die diensthabende Person Hilfe eines anderen Teams braucht, um den Service wiederherzustellen.

Viele Teams folgen der Faustregel: Lieber früh ausrufen und später herabstufen. Ein Incident, der sich als harmlos herausstellt, kostet ein paar Minuten. Ein zu spät ausgerufener Incident kostet Stunden unkoordinierter Arbeit.

Rollen im Incident: Wer macht was?

Der wichtigste Grundsatz der Incident Response lautet: Koordination und Fehlersuche gehören in verschiedene Hände. Wer gerade die Datenbank repariert, sollte nicht gleichzeitig Kundenupdates formulieren. Ab mittlerem Schweregrad sollten Sie mindestens diese Rollen besetzen:

Incident Commander (IC)

Der Incident Commander verantwortet den Incident, nicht die technische Lösung. Der IC setzt Prioritäten, verteilt Aufgaben, entscheidet über Eskalationen, trifft die Entscheidung über riskante Maßnahmen (Rollback, Failover, Feature Flag deaktivieren) und erklärt den Incident für beendet. Ein guter IC fragt regelmäßig: „Was wissen wir, was probieren wir als Nächstes, und wer macht es?“ – und verschwindet nicht selbst in den Logs. Die Rolle kann ausdrücklich übergeben werden, etwa beim Schichtwechsel; diese Übergabe gehört in die Timeline.

Kommunikationsverantwortliche

Die oder der Kommunikationsverantwortliche steuert alle ausgehenden Informationen: interne Updates an Stakeholder, Einträge auf der Statusseite und bei Bedarf die Abstimmung mit Support und Account Management. Diese Rolle übersetzt technische Erkenntnisse in verständliche Sprache, hält den vereinbarten Update-Takt ein und schirmt das Team vor „Gibt es schon was Neues?“-Nachrichten ab.

Operations und Fachexpertinnen und -experten

Ops-Engineers und Fachexpertinnen und -experten (Subject Matter Experts, SMEs) übernehmen Analyse und Eindämmung. Der IC holt sie je nach betroffener Komponente dazu: Datenbank, Netzwerk, ein bestimmtes Service-Team oder die Ansprechperson beim Cloud-Anbieter. Sie berichten ihre Erkenntnisse an den IC und schlagen Maßnahmen vor, statt größere Änderungen stillschweigend umzusetzen.

Protokollführung (optional, für SEV1 empfohlen)

Bei langen oder schweren Incidents dokumentiert eine eigene Person die Timeline: Was wurde beobachtet, was entschieden, was geändert und wann? In kleinen Teams übernimmt das oft der IC oder die Kommunikationsrolle. Eine eigene Protokollführung erleichtert das Postmortem jedoch erheblich.

Schweregrade: eine beispielhafte SEV1–SEV4-Matrix

Der Incident-Schweregrad bestimmt, wie viele Personen alarmiert werden, wie schnell sie reagieren müssen und wie oft kommuniziert wird. Die folgende Matrix ist ein Beispiel zum Anpassen, kein Standard. Reaktionszeiten und Update-Takte sind illustrativ und sollten Ihre eigenen SLAs, Ihre Teamgröße und Ihr Rufbereitschaftsmodell widerspiegeln.

Schweregrad	Auswirkung (Beispiel)	Reaktionszeit (Beispiel)	Wer wird alarmiert (Beispiel)	Update-Takt (Beispiel)
SEV1	Kernservice ausgefallen oder Datenverlust für viele oder alle Kunden; Verdacht auf Sicherheitsvorfall	Bestätigung innerhalb von 5 Minuten, IC innerhalb von 15 Minuten benannt	Primäre und sekundäre Rufbereitschaft, Incident Commander, Kommunikationsrolle, Engineering Manager; Geschäftsführung informiert	Intern alle 15 Minuten, Statusseite alle 30 Minuten
SEV2	Wichtige Funktion für eine relevante Kundengruppe eingeschränkt oder nicht verfügbar; ggf. Workaround vorhanden	Bestätigung innerhalb von 15 Minuten	Primäre Rufbereitschaft, verantwortliches Team, Incident Commander; Kommunikationsrolle bei Bedarf	Intern alle 30 Minuten, Statusseite alle 60 Minuten
SEV3	Nebenfunktion eingeschränkt, begrenzte Kundenauswirkung oder erhöhter Error-Budget-Verbrauch ohne sichtbaren Ausfall	Bestätigung innerhalb 1 Stunde während der Geschäftszeiten	Primäre Rufbereitschaft des verantwortlichen Teams	Internes Update zu Beginn und bei Behebung; Statusseite optional
SEV4	Aktuell keine Kundenauswirkung; Risiko, das zum Incident werden kann (z. B. fehlschlagende Backups, ablaufendes Zertifikat)	Nächster Arbeitstag	Ticket an das verantwortliche Team, keine Alarmierung	Keine; Verfolgung im Ticket

Zwei Tipps aus der Praxis: Koppeln Sie den Schweregrad an die Auswirkung auf Nutzer, nicht an die technische Schwierigkeit. Und erlauben Sie dem IC, den Schweregrad jederzeit zu ändern. Dass ein Incident als SEV3 beginnt und nach zwanzig Minuten zu SEV1 wird, ist völlig normal.

Der Incident-Management-Prozess Schritt für Schritt

Jede Organisation benennt die Phasen etwas anders, der Kern ist aber stets gleich. Die folgende Variante mit sieben Schritten hat sich in der Praxis bewährt.

1. Erkennen. Ein Alert schlägt an, ein synthetischer Check scheitert oder ein Kunde meldet ein Problem. Die Qualität dieses Schritts misst die MTTD (Mean Time to Detect). Symptombasierte Alerts auf SLOs und Burn Rates erkennen echte Nutzerauswirkungen schneller und mit weniger Rauschen als Schwellenwerte auf einzelnen Hosts.
2. Bewerten und ausrufen. Die Person in Rufbereitschaft bestätigt den Alert, prüft die Auswirkung und entscheidet, ob es sich um einen Incident handelt. Falls ja, ruft sie ihn mit einem vorläufigen Schweregrad aus, eröffnet einen eigenen Kanal (zum Beispiel #inc-2026-10-17-checkout) und beginnt die Timeline.
3. Team bilden. Ein IC wird benannt (häufig zunächst die diensthabende Person, bis jemand übernimmt). Der IC alarmiert gemäß Schweregrad-Matrix die Kommunikationsrolle und die benötigten Fachleute.
4. Eindämmen. Zuerst den Service wiederherstellen, dann die Ursache klären. Typische Maßnahmen: das letzte Deployment zurückrollen, ein Feature Flag umschalten, in eine andere Region umschalten, hochskalieren oder einen auffälligen Client drosseln. Ein verlinktes Runbook für bekannte Fehlerbilder spart hier wertvolle Minuten.
5. Kommunizieren. Parallel zur Eindämmung veröffentlicht die Kommunikationsrolle das erste interne Update und bei sichtbarer Kundenauswirkung den ersten Statusseiten-Eintrag. Das wiederholt sich im vereinbarten Takt bis zur Behebung.
6. Beheben. Sobald die Nutzerauswirkung beendet und das System stabil ist, erklärt der IC den Incident für behoben, veröffentlicht ein abschließendes Update und plant das Postmortem. Das Monitoring bleibt noch eine Weile besonders aufmerksam, falls das Problem zurückkehrt.
7. Lernen. Ein Blameless Postmortem schreiben, Folgemaßnahmen mit Verantwortlichen und Fälligkeitsdatum vereinbaren und bis zum Abschluss verfolgen.

Die Zeit bis zur Wiederherstellung über diese Schritte hinweg wird meist als MTTR gemessen. Unser Beitrag Was ist MTTR? erklärt die verschiedenen Definitionen und warum es sich lohnt, jede Phase einzeln zu messen.

Kommunikationstakt und Statusseiten-Updates

Funkstille während eines Incidents wird als „Da kümmert sich niemand“ verstanden. Ein fester Takt beseitigt diesen Zweifel, auch wenn es nichts Neues zu berichten gibt. Jedes Update, ob intern oder extern, sollte vier Fragen beantworten: Was ist betroffen, wie groß ist die aktuelle Auswirkung, was tun wir, und wann kommt das nächste Update?

Auf der Statusseite gilt: sachlich bleiben und internen Fachjargon vermeiden. Diese einfache Struktur passt für die meisten Incidents:

• Untersuchung: „Wir untersuchen erhöhte Fehlerraten im Checkout. Einige Kunden können Zahlungen möglicherweise nicht abschließen. Nächstes Update in 30 Minuten.“
• Ursache identifiziert: „Als Ursache haben wir eine fehlerhafte Abhängigkeit identifiziert und spielen eine Korrektur aus. Zahlungen können vereinzelt weiterhin fehlschlagen.“
• Beobachtung: „Eine Korrektur wurde ausgerollt, die Fehlerraten sind wieder normal. Wir beobachten die Lage weiter.“
• Behoben: „Der Incident ist behoben. Zahlungen funktionieren seit 14:52 UTC wieder normal. Eine Zusammenfassung folgt.“

Verzichten Sie auf spekulative Ursachen und auf Zeitangaben zur Behebung, die Sie nicht halten können. Verwenden Sie in allen Updates und in der Timeline eine einheitliche Zeitzone; für verteilte Teams ist UTC die sicherste Wahl.

Die Timeline während des Incidents führen

Die Timeline ist das Rohmaterial für das Postmortem, und im Nachhinein lässt sie sich kaum noch genau rekonstruieren. Halten Sie Einträge deshalb sofort fest, mit Zeitstempel und einer kurzen, sachlichen Aussage. Gute Einträge umfassen:

• Beobachtungen: „14:07 UTC, p99-Latenz des payment-service über 4 s, Fehlerrate 12 %.“
• Entscheidungen: „14:15 UTC, IC entscheidet Rollback von Release 2026.10.17-3.“
• Maßnahmen und ihre Wirkung: „14:21 UTC, Rollback abgeschlossen; Fehlerrate unverändert.“
• Rollen- und Schweregradwechsel: „14:30 UTC, Schweregrad auf SEV1 erhöht, neuer IC: diensthabende SRE.“
• Kommunikation: „14:32 UTC, Statusseite aktualisiert (Ursache identifiziert).“

Es lohnt sich, Links zu den betrachteten Dashboards, Traces, Deployments und Log-Abfragen zu ergänzen, damit die Belege später nachvollziehbar bleiben. Viele Teams pinnen ein Timeline-Dokument im Kanal oder nutzen Incident-Werkzeuge, die Nachrichten und Alerts automatisch erfassen.

Das Blameless Postmortem

Ein Postmortem ist eine schriftliche Nachbetrachtung, die erklärt, was passiert ist, warum es passiert ist und was sich ändern wird. „Blameless“ bedeutet, dass die Analyse davon ausgeht, dass alle Beteiligten mit den damals verfügbaren Informationen und Werkzeugen vernünftig gehandelt haben. Die Frage lautet nie „Wer hat den Fehler gemacht?“, sondern „Was hat den Fehler möglich gemacht, und warum wurde er nicht früher bemerkt?“

Das hat nichts mit Nachsicht zu tun. Schuldzuweisungen führen zu schlechteren Daten: Details werden verschwiegen, Timelines bleiben vage, und dasselbe Fehlerbild kehrt zurück. Eine Blameless-Kultur liefert ehrliche Timelines und systemische Verbesserungen. Bewährte Regeln:

• Erstellen Sie den Entwurf innerhalb weniger Arbeitstage, solange die Erinnerung frisch ist.
• Beschreiben Sie Handlungen nach Rolle („die diensthabende Person“) statt nach Namen, wo immer möglich.
• Suchen Sie beitragende Faktoren im gesamten System: fehlende Alerts, unklare Runbooks, riskante Deployment-Wege, unklare Zuständigkeiten.
• Nutzen Sie eine strukturierte Methode wie die 5-Why-Methode oder einen Fehlerbaum; unser Leitfaden zur Root-Cause-Analyse vergleicht die gängigen Ansätze.
• Besprechen Sie das Postmortem gemeinsam mit allen Beteiligten und teilen Sie es anschließend breit im Unternehmen.

Postmortem-Vorlage zum Kopieren

Nutzen Sie die folgende Struktur als Ausgangspunkt. Kopieren Sie sie in Ihr Wiki oder Ihr Dokumentenwerkzeug und streichen Sie Abschnitte, die Sie nicht brauchen.

POSTMORTEM: [kurzer Titel des Incidents]

1. Metadaten
   - Incident-ID / Datum:
   - Schweregrad (anfänglich / final):
   - Dauer (Beginn der Auswirkung bis Behebung, UTC):
   - Incident Commander:
   - Kommunikationsverantwortliche:
   - Beteiligte / Fachexperten:
   - Autor des Postmortems und Review-Termin:

2. Zusammenfassung (3–5 Sätze)
   - Was ist passiert, wer war betroffen, wie wurde es behoben?

3. Auswirkung
   - Betroffene Services und User Journeys:
   - Betroffene Kunden / Regionen (ungefähr):
   - Verbrauchtes SLO / Error Budget:
   - Datenverlust oder Sicherheitsrelevanz (ja/nein, Details):

4. Timeline (UTC)
   - hh:mm  Erkennung: Wie wurde das Problem bemerkt?
   - hh:mm  Incident ausgerufen, Schweregrad:
   - hh:mm  Wichtige Beobachtungen, Entscheidungen, Maßnahmen:
   - hh:mm  Eindämmung umgesetzt:
   - hh:mm  Behoben:

5. Ursache und beitragende Faktoren
   - Auslösendes Ereignis:
   - Zugrunde liegende Ursache(n):
   - Beitragende Faktoren (Erkennung, Werkzeuge, Prozess, Zuständigkeit):

6. Was gut lief

7. Was schlecht lief

8. Wo wir Glück hatten

9. Folgemaßnahmen
   - Maßnahme | Typ (verhindern / erkennen / eindämmen / Prozess) | Verantwortlich | Fällig am | Ticket

10. Erkenntnisse und offene Fragen

Folgemaßnahmen, die wirklich umgesetzt werden

Ein Postmortem ohne erledigte Maßnahmen ist die Dokumentation des nächsten Incidents. Halten Sie Folgemaßnahmen deshalb wenige, konkret und klar zugeordnet. Bewährt hat sich eine Einteilung nach Typ: Maßnahmen, die ein Wiederauftreten verhindern (Bug beheben, Schutzmechanismus einbauen), Maßnahmen, die es schneller erkennen (neuer SLO-Alert, synthetischer Check), Maßnahmen, die es schneller eindämmen (Runbook, automatisierter Rollback), und Prozess-Änderungen (Zuständigkeiten, Rufbereitschaftsplan, Review-Schritte).

Nutzen Sie diese Checkliste beim Abschluss eines Postmortems:

• Jede Maßnahme hat genau eine verantwortliche Person und ein Fälligkeitsdatum.
• Jede Maßnahme steht im regulären Backlog des zuständigen Teams und verlinkt auf das Postmortem.
• Maßnahmen mit hoher Priorität aus SEV1-Incidents werden in einem regelmäßigen Termin bis zur Erledigung nachverfolgt.
• Verbesserungen an Erkennung und Runbooks werden überprüft, zum Beispiel durch Nachstellen des Szenarios an einem Game Day.
• Wiederkehrende Muster werden über mehrere Postmortems hinweg ausgewertet, nicht nur innerhalb eines einzelnen.

Wie Obseria unterstützt

Obseria ist eine OpenTelemetry-native Observability-Plattform, die Erkennung, Reaktion und Nachbereitung an einem Ort abdeckt – mit Datenhaltung in der EU. Alerts, Traces, Logs und Topologie teilen denselben Kontext, sodass Ihr Team ohne Werkzeugwechsel vom verbrauchten SLO zum betroffenen Service und seinen letzten Deployments gelangt.

• Incident-Management mit Rollen, Schweregraden und einer automatisch erfassten Timeline aus Alerts, Änderungen und Maßnahmen.
• Statusseiten, die die Kommunikationsrolle direkt aus dem Incident heraus aktualisieren kann.
• Obseria Intelligence schlägt wahrscheinliche Ursachen samt Belegen vor, und Automation führt Runbooks und Rollbacks als Workflows aus.
• SLOs mit Burn-Rate-Alerts, um Auswirkungen auf Nutzer früh und mit weniger Rauschen zu erkennen.

Wenn Sie sehen möchten, wie das mit Ihrer eigenen Telemetrie funktioniert, testen Sie Obseria kostenlos oder vereinbaren Sie eine Demo.