Incident-Response-Flussdiagramm: vom ersten Alarm bis zum Postmortem

Um drei Uhr morgens liest niemand eine zehnseitige Incident-Richtlinie. Wer Rufbereitschaft hat, muss schnell vier Dinge wissen: Ist das echt, ist es ein Incident, wer muss noch Bescheid wissen und was ist zuerst zu tun? Ein einseitiges Flussdiagramm beantwortet diese Fragen in der Reihenfolge, in der sie aufkommen, und es ist der Teil der Richtlinie, an den sich die Leute tatsächlich halten.

Dieser Beitrag baut ein Incident-Response-Flussdiagramm für ein Engineering-Team auf, das einen Produktivdienst betreibt: Triage, die Kriterien für das Ausrufen eines Incidents, Schweregrad und Rollen, Mitigation und das Postmortem, das den Kreis schließt. Am Ende stehen Zeichentipps, mit denen ein Flussdiagramm auch unter Stress brauchbar bleibt.

Was das Flussdiagramm entscheiden muss

Ein Incident-Prozess ist eine Reihe von Entscheidungen mit ein paar länger laufenden Tätigkeiten dazwischen. Die Entscheidungen gehören ins Diagramm, formuliert als Fragen mit beschrifteten Antworten:

• Ist der Alarm echt und handlungsrelevant? Wenn nicht, ist der Alarm das Problem.
• Ist es ein Incident? Wenn nicht, ist es normale Arbeit mit einem Ticket.
• Wie schwer ist er? Der Schweregrad entscheidet, wer alarmiert und wer informiert wird.
• Ist der Dienst wiederhergestellt? Wenn nicht, probiere die nächste Mitigation oder eskaliere.

Alles andere, etwa wie man ein Deployment zurückrollt oder auf eine andere Datenbank umschaltet, gehört in Runbooks, auf die das Diagramm verlinkt.

Wann du einen Incident ausrufst

Beim Ausrufen zögern Teams, und dieses Zögern ist teuer. Das Kapitel Managing Incidents in Googles SRE-Buch plädiert dafür, früh auszurufen: Es ist besser, einen Incident auszurufen, eine einfache Lösung zu finden und ihn wieder zu schließen, als den Prozess erst Stunden nach Beginn eines wachsenden Problems zu starten. Das Team in diesem Kapitel ruft einen Incident aus, wenn einer dieser Punkte zutrifft:

1. Ein zweites Team wird zur Behebung gebraucht.
2. Der Ausfall ist für Kunden sichtbar.
3. Das Problem ist nach einer Stunde konzentrierter Analyse ungelöst.

Schreib deine eigenen Kriterien ins Diagramm, direkt neben die Entscheidung. Klare Kriterien nehmen dem Ausrufen die sozialen Kosten.

Rollen

Dasselbe Kapitel beschreibt eine Struktur, die auf dem Incident Command System beruht. Auch ein kleines Team profitiert davon, die Rollen zu benennen, denn der häufigste Fehler ist, dass eine Person alle übernimmt:

Der Incident Commander führt außerdem ein lebendes Incident-Dokument und übergibt am Schichtende ausdrücklich: Der abgebende Commander kündigt die Übergabe an und wartet auf eine Bestätigung.

Fähigkeiten im Incident-Management verkümmern, wenn sie nicht genutzt werden. Dasselbe Kapitel schlägt vor, das Vorgehen auch auf betriebliche Änderungen anzuwenden, die mehrere Teams oder Zeitzonen betreffen, und vergangene Incidents im Rollenspiel durchzugehen, damit der Prozess vor dem nächsten echten Incident vertraut ist. Eine neue Person in der Rufbereitschaft anhand eines alten Incidents durch das Flussdiagramm zu führen, ist ein günstiger Anfang.

Schweregrade

Die Definitionen von Schweregraden unterscheiden sich von Firma zu Firma. Sieh die folgenden als Beispiel und schreib deine eigenen ins Diagramm:

Das Flussdiagramm Schritt für Schritt

1. Bestätigen und triagieren. Wenn der Alarm auslöst, bestätige ihn, damit die Eskalation stoppt, und sieh dir dann Umfang und Auswirkung an.
2. Echt und handlungsrelevant? Ein falscher oder nicht handlungsrelevanter Alarm wird nachjustiert oder gelöscht und dann geschlossen.
3. Ist es ein Incident? Wende die Kriterien an. Wenn nicht, behandle ihn als normale Arbeit mit einem Ticket.
4. Ausrufen. Benenne den Incident Commander, öffne einen Kanal und das Incident-Dokument.
5. Schweregrad. Bei SEV-1 und SEV-2 postet eine Kommunikationsleitung auf der Statusseite und verschickt regelmäßige Updates.
6. Zuerst mitigieren. Rolle zurück, schalte auf ein Ersatzsystem um, deaktiviere das Feature-Flag oder wirf Last ab. Die erste Priorität im SRE-Buch ist, die Blutung zu stoppen, den Dienst wiederherzustellen und Beweise zu sichern; die Ursache kommt später.
7. Wiederhergestellt? Wenn nicht, probiere die nächste Mitigation oder eskaliere, und durchlaufe die Schleife erneut.
8. Lösen. Bestätige mit Metriken, beobachte weiter und übergib das System zurück an den Normalbetrieb.
9. Postmortem und Maßnahmen. Schreib ein Blameless Postmortem, lass es reviewen und schließ den Incident, wenn die Maßnahmen erfasst sind.

So liest du es:

• Ja geht nach rechts, Nein nach unten. Jede Entscheidung folgt derselben Konvention, sodass der Hauptpfad nach rechts verläuft und die frühen Ausstiege nach unten abzweigen.
• Links, die Erstreaktion. Der Alarm wird bestätigt und triagiert. Alarme, die nicht echt oder nicht handlungsrelevant sind, und Ereignisse, die kein Incident sind, enden bei Done.
• Dritte Spalte, der Incident. Er wird ausgerufen, nach Schweregrad geprüft und mitigiert. Bei SEV-1 und SEV-2 kommt rechts eine Kommunikationsleitung hinzu.
• Die Schleife. „Service restored?“ schickt dich zurück zur Mitigation, bis die Antwort Ja lautet.
• Rechte Spalte, der Abschluss. Lösen, das Blameless Postmortem schreiben und schließen, wenn die Maßnahmen erfasst sind.
• Notizen enthalten die Kriterien für das Ausrufen und die Schweregrade, damit niemand ein weiteres Dokument öffnen muss.

Das Postmortem schließt den Kreis

Das Kapitel Postmortem Culture im SRE-Buch nennt typische Auslöser, etwa für Nutzer sichtbare Ausfälle oder Beeinträchtigungen über einem Schwellenwert und Datenverlust jeder Art. Ein Postmortem ist blameless, wenn es beitragende Ursachen in Systemen und Prozessen sucht, ohne Menschen die Schuld zu geben; sonst hören die Leute auf, Probleme anzusprechen. Zeichne das Postmortem als Dokument mit verantwortlicher Person und Frist ins Diagramm, und markiere den Incident erst als geschlossen, wenn seine Maßnahmen erfasst sind.

Sicherheitsvorfälle brauchen mehr als dieses Diagramm: Beweissicherung, rechtliche und regulatorische Schritte und oft ein eigenes Team. NIST SP 800-61 Rev. 3, veröffentlicht im April 2025, ist die übliche Referenz. Verbinde einen Sicherheitszweig mit diesem Prozess, statt einen zu improvisieren.

Zeichentipps für Flussdiagramme unter Stress

• Ein Start, klare Enden. Jeder Pfad sollte irgendwo enden, auch wenn das „Done“ ist.
• Entscheidungen als Ja-Nein-Fragen, mit beiden Ausgängen beschriftet, und Ja und Nein verlassen die Form jedes Mal an denselben Seiten.
• Schleifen sichtbar machen. „Nächste Mitigation probieren“ ist eine Schleife, keine Fußnote.
• Höchstens fünfzehn Formen. Details gehören in Runbooks, die von den Schritten verlinkt sind.
• Zeigen, wo die Verantwortung wechselt. Für eine Version mit Bahnen pro Rolle startest du mit der Vorlage für bereichsübergreifende Flussdiagramme.
• Dort ablegen, wo die Rufbereitschaft nachschaut. Verlinke das Diagramm im Runbook oder bette das Live-Diagramm ein, statt einen Screenshot einzufügen.

Wenn dein Prozess viele Teams und formelle Übergaben umfasst, kann ein BPMN-Diagramm ihn genauer modellieren; für die Rufbereitschaft ist ein Flussdiagramm leichter zu verfolgen.

In Archboard nachbauen

1. Melde dich mit Google oder GitHub an und leg ein Diagramm an.
2. Füge aus dem Flussdiagramm-Pack einen Start / Ende-Node für den Start und jedes Ende hinzu, einen Prozess für jeden Schritt und eine Entscheidung für jede Frage.
3. Füge ein Dokument für das Postmortem hinzu.
4. Verbinde die Formen. Die Entscheidungsform markiert ihre rechte Ecke mit Y und ihre untere Ecke mit N; zeichne Ja deshalb nach rechts und Nein nach unten, beschrifte beide und führe den Ausgang „nicht wiederhergestellt“ zurück zur Mitigation.
5. Füge aus dem Basis-Pack Notiz-Nodes mit deinen Kriterien für das Ausrufen und deinen Schweregraden hinzu.

Das Beispiel nutzt 15 Diagramm-Nodes und bleibt damit im Free-Plan. Die Seite zum Flussdiagramm-Tool zeigt die anderen Formen und das Swimlane-Layout.

FAQ

Wem sollte das Incident-Response-Flussdiagramm gehören? Dem Team, das die Rufbereitschaft organisiert. Überprüfe es nach jedem Incident, bei dem jemand nicht wusste, was als Nächstes zu tun ist.

Sollte jeder Alarm ein Incident sein? Nein. Die meisten Alarme sollten als normale Arbeit behandelt werden. Ruf einen Incident aus, wenn deine Kriterien erfüllt sind, und im Zweifel lieber früh.

Brauche ich bei kleinen Incidents einen Incident Commander? Jemand muss den Überblick behalten. Bei einem kleinen Incident ist die Person in Rufbereitschaft der Commander, und das laut auszusprechen verhindert, dass zwei Leute dasselbe auf unterschiedliche Weise reparieren.

Wann sollte das Postmortem geschrieben werden? Bald, solange die Details frisch sind. Setz eine Frist, die dein Team einhalten kann, schreib sie ins Diagramm und verfolge die Maßnahmen.

Sollte das Flussdiagramm Sicherheitsvorfälle abdecken? Füge einen Zweig hinzu, der sie an deinen Prozess für Sicherheitsvorfälle übergibt. Der hat andere Schritte, etwa Beweissicherung und rechtliche Prüfung.

Kostenlos starten — ein Seat, keine Kreditkarte.