Wenn kritische Systeme ausfallen, entscheidet nicht allein die technische Kompetenz über die Qualität der Reaktion. Mindestens genauso wichtig ist die Koordination: Wer spricht mit wem? Wer entscheidet? Wie werden externe Stakeholder informiert? Ohne klare Antworten auf diese Fragen verwandeln sich Großstörungen in Kommunikationschaos – mit vermeidbaren Folgeschäden.
Das Koordinationsproblem bei Großstörungen
In kleinen Teams ist Incident-Koordination oft informal: Die betroffene Person ruft direkt beim Kollengen an, alle sitzen im gleichen Slack-Channel. Bei wachsenden Organisationen bricht dieses Modell zusammen. Mehrere Teams arbeiten parallel, jedes hat eigene Kommunikationskanäle, und niemand hat den Überblick, was gerade wirklich passiert und wer woran arbeitet.
Die Folge: Doppelarbeit, inkonsistente Statusinformationen, überforderte Einzelpersonen die gleichzeitig debuggen und kommunizieren sollen – und ein Postmortem, das niemand schreiben kann, weil der Ablauf nicht dokumentiert wurde.
Rollen im Incident-Koordinationssystem
Effektive Incident-Koordination basiert auf klar zugewiesenen Rollen. Die wichtigsten:
Incident Commander (IC)
Der Incident Commander ist die zentrale Entscheidungsinstanz während einer Störung. Er oder sie koordiniert die technischen Teams, entscheidet über Eskalationen und trägt die Verantwortung dafür, dass der Incident-Prozess läuft. Wichtig: Der IC löst das technische Problem nicht selbst – er hält die Koordination am Laufen und schirmt die technischen Teams vor ablenkenden Anfragen ab.
Scribe (Protokollführung)
Der Scribe dokumentiert den Incident-Verlauf in Echtzeit: Wann wurde was entdeckt? Welche Maßnahmen wurden eingeleitet? Welche Hypothesen wurden getestet? Diese Aufzeichnungen sind die Grundlage für das Postmortem und ermöglichen es, den Ablauf später vollständig nachzuvollziehen – auch wenn in der Hitze des Gefechts die Erinnerungen verschwimmen.
Communication Lead
Der Communication Lead übernimmt die externe Kommunikation: Statusseiten-Updates, Stakeholder-E-Mails, Management-Briefings. So kann das technische Team vollständig auf die Problemlösung fokussieren, ohne gleichzeitig Anfragen von Kunden, Führungskräften und anderen Teams beantworten zu müssen.
Subject Matter Experts (SMEs)
SMEs sind die Spezialisten für bestimmte Systeme oder Komponenten. Sie werden vom IC einbezogen, wenn ihr Fachgebiet relevant ist – und wieder entlassen, wenn ihre Zuarbeit abgeschlossen ist. Klare Ein- und Ausstiegspunkte für SMEs verhindern, dass zu viele Menschen gleichzeitig in einem War Room arbeiten.
Kommunikationskanäle strukturieren
Für Großstörungen empfehlen sich dedizierte, vom normalen Team-Traffic getrennte Kommunikationskanäle:
- Primärer Incident-Channel: Ein dedizierter Chat-Kanal (z.B. #incident-2026-08-23) für alle technischen Updates und Entscheidungen. Hier sprechen nur Beteiligte.
- Statusseite für externe Kommunikation: Öffentliche oder interne Statusseiten informieren Nutzer und Stakeholder automatisch, ohne den Incident-Channel zu fluten. Moderne Plattformen ermöglichen es, Incidentmeldungen direkt mit Monitoring-Alarmen zu verknüpfen.
- Management-Briefings separat: Statusupdates ans Management gehören nicht in den technischen Kanal. Kurze, regelmäßige Updates in festem Rhythmus (z.B. alle 30 Minuten) halten Führungskräfte informiert, ohne die Techniker zu unterbrechen.
- Voice-Bridge für Eskalationen: Bei komplexen Incidents mit mehreren Teams kann eine Voice-Konferenz effizienter sein als asynchroner Text. Kurze Sync-Calls mit klarer Agenda und Zeitlimit helfen bei Blockaden.
Eskalationspfade klar definieren
Eskalation bedeutet nicht Versagen – sie ist ein normaler Teil des Incident-Prozesses. Teams sollten vorab definieren:
- Ab welchem Schweregrad welche Personen benachrichtigt werden
- Welcher Zeitraum ohne Fortschritt eine Eskalation auslöst
- Wie und in welcher Form Stakeholder informiert werden
- Wann externe Unterstützung (Hersteller-Support, Spezialisten) eingeholt wird
Diese Regeln müssen schriftlich festgehalten sein – nicht als Erinnerung für Ruhephasen, sondern als Referenz unter Stress. Ein gut gepflegtes Runbook mit klaren Eskalationspfaden ersetzt Diskussionen im falschen Moment.
Praxis-Tipp: Jeder Schweregrad (P1, P2, P3) sollte einen eigenen Satz an Eskalations- und Kommunikationsregeln haben. Was bei einem P3 ein Slack-Update ist, ist bei einem P1 ein sofortiger Anruf beim Incident Commander.
Dokumentation während des Incidents
Die Qualität eines Postmortems hängt fast vollständig von der Qualität der Echtzeitdokumentation ab. Folgende Informationen sollte der Scribe festhalten:
- Zeitstempel aller wesentlichen Ereignisse
- Hypothesen und die Ergebnisse ihrer Tests
- Entscheidungen und die Person, die sie getroffen hat
- Maßnahmen und ihr Ergebnis
- Beteiligte Systeme und Komponenten
- Externe Kommunikation (was wurde wann gesagt?)
Diese Aufzeichnungen direkt in einem Incident-Dokument oder Ticket zu pflegen, spart im Nachgang erheblichen Aufwand und ermöglicht eine faktenbasierte Aufarbeitung.
Nach dem Incident: Übergang zum Postmortem
Wenn der Incident behoben ist, beginnt die Nachbetrachtung. Für einen reibungslosen Übergang empfehlen sich:
- Eine kurze synchrone Debriefing-Runde direkt nach dem Incident (15–30 Minuten)
- Zuweisung eines Postmortem-Autors innerhalb der nächsten 24 Stunden
- Zeitnahe Veröffentlichung des Postmortems (spätestens 5 Werktage nach dem Incident)
- Klare Action Items mit Verantwortlichen und Deadlines
Häufige Fehler und wie man sie vermeidet
Aus der Praxis bekannte Antipattern bei der Incident-Koordination:
- Zu viele Menschen im War Room: Mehr als fünf aktive Teilnehmende führen zu Stimmengewirr und Entscheidungslähmung. SMEs werden bei Bedarf einbezogen, nicht durchgehend.
- IC debuggt selbst: Sobald der Incident Commander anfängt, selbst zu debuggen, verliert er den Überblick. Die Rolle erfordert Konsequenz: koordinieren, nicht lösen.
- Keine externe Kommunikation: Stille ist die schlechteste Kommunikation. Auch ein "Wir sind informiert und arbeiten daran" ist besser als nichts.
- Manuelle Statusseiten-Updates vergessen: Unter Stress werden Statusseiten-Updates oft vergessen. Eine direkte Integration zwischen Monitoring und Statuspages verhindert das.
Fazit
Gute Incident-Koordination lässt sich erlernen und trainieren. Teams, die klare Rollen definieren, dedizierte Kommunikationskanäle nutzen und Eskalationspfade vorab festlegen, bewältigen Großstörungen signifikant ruhiger – und hinterlassen nachher eine Dokumentation, aus der echte Verbesserungen entstehen können.
Bildquelle: Pexels / Manuel Geissinger (pexels.com) – Foto-ID 325229
Quellen: Google SRE Book – Incident Management; PagerDuty Incident Response Guide; eigene Aufbereitung und Redaktion 2026.
