Ein kritisches System fällt aus. Mehrere Teams reagieren gleichzeitig. Nachrichten laufen durcheinander. Niemand weiß genau, wer an welchem Problem arbeitet. Wichtige Informationen gehen in langen Chat-Verläufen unter. Und die ganze Zeit steigen die Auswirkungen auf Nutzer und Geschäft. Dieses Szenario kennen viele IT-Teams aus schmerzhafter Erfahrung.
Dabei ist eine produktive Reaktion auf schwere Störungen kein Zufall – sie ist das Ergebnis konsequenter Vorbereitung, klar definierter Rollen und erprobter Kommunikationsstrukturen. Major Incident Management ist die Disziplin, die genau das ermöglicht: strukturiertes, koordiniertes Handeln in der Krise, auch wenn alles auf einmal passiert.
Was ein Major Incident ausmacht
Nicht jede Störung ist ein Major Incident. Einzelne Fehler, die das On-Call-Team routiniert beheben kann, fallen in den normalen Incident-Prozess. Ein Major Incident liegt vor, wenn mindestens eines der folgenden Kriterien erfüllt ist:
- Kritische Kundenfunktionen sind vollständig nicht verfügbar
- Signifikante Auswirkungen auf Umsatz, Reputation oder Datensicherheit
- Mehrere Teams oder Systeme sind gleichzeitig betroffen
- Keine sofortige Lösung absehbar – Ursache unklar, Behebungsdauer unbekannt
- Führungsebene oder externe Partner müssen informiert werden
Die genaue Schwelle muss jede Organisation für sich definieren und dokumentieren. Was in einem kleinen SaaS-Unternehmen ein P1-Incident ist, entspricht in einem Zahlungsdienstleister vielleicht einem alltäglichen P3. Entscheidend ist, dass es eine klare, bekannte Definition gibt – sodass die Einschätzung im Ernstfall keine Diskussion auslöst.
Die Schlüsselrollen im Major Incident
Große Störungen scheitern selten an fehlendem technischen Wissen. Sie scheitern an unklaren Verantwortlichkeiten, parallelen Aktivitäten ohne Koordination und fehlender Kommunikation nach außen. Klare Rollen lösen dieses Problem:
Incident Commander (IC)
Der Incident Commander hat die Gesamtverantwortung für die Incident-Reaktion. Er oder sie trifft Entscheidungen, koordiniert zwischen Teams, delegiert Aufgaben und sorgt dafür, dass alle Beteiligten fokussiert bleiben. Der IC repariert nichts selbst – das wäre eine Rollenüberschneidung, die Kapazität für Koordination kostet. Die technische Arbeit liegt bei den Engineers.
Communications Lead
Diese Rolle trägt die alleinige Verantwortung für alle Kommunikation nach außen: Statusseiten-Updates, interne Status-E-Mails, Kommunikation mit betroffenen Großkunden und – sofern nötig – öffentliche Stellungnahmen. Die Trennung von technischer Arbeit und Kommunikation ist entscheidend: Engineers können sich auf die Lösung konzentrieren, während der Communications Lead regelmäßige Updates aussendet.
Technical Lead
Der Technical Lead koordiniert die Engineers, die an der Ursachenanalyse und Behebung arbeiten. Er oder sie hält den Überblick, welche Hypothesen gerade geprüft werden, welche bereits widerlegt sind, und welche Tests laufen. Der Technical Lead ist die technische Schnittstelle zum Incident Commander.
Scribe (Protokollführer)
Oft unterschätzt, aber enorm wichtig: Der Scribe protokolliert in Echtzeit alle wichtigen Erkenntnisse, Entscheidungen, durchgeführten Aktionen und ihre Zeitpunkte. Dieses Protokoll ist die Grundlage für das spätere Postmortem und beantwortet im Chaos die Frage: Was haben wir wann versucht?
Der War Room: Digitaler Krisenstab
Während physische War Rooms früher Standard waren, findet Major Incident Management heute meist in digitalen Räumen statt: ein dedizierter Incident-Kanal, eine gemeinsame Videokonferenz und ein geteiltes Dokument für das Echtzeit-Protokoll.
Wichtig ist dabei die strikte Trennung des Incident-Kanals vom normalen Team-Chat. Im Incident-Kanal sprechen nur die relevanten Beteiligten, nach klaren Konventionen. Alle anderen beobachten passiv oder stellen Fragen in einen separaten Sidebar-Channel. Das reduziert den Kommunikationslärm erheblich und ermöglicht dem Incident Commander, den Überblick zu behalten.
Wie KI-Systeme den War Room unterstützen
In den vergangenen Jahren haben KI-gestützte Tools Einzug in den Incident-Response-Prozess gehalten. Ihr Beitrag ist sinnvoll – wenn sie in der richtigen Funktion eingesetzt werden:
Kontextaufbereitung und Hypothesenbildung
KI-Systeme, die auf Logs, Metriken und vergangene Incidents trainiert wurden, können bei einem neuen Incident innerhalb von Sekunden ähnliche historische Fälle abrufen: Was hat damals geholfen? Welche Dienste waren damals beteiligt? Diese Kontextualisierung spart wertvolle Minuten in der initialen Analyse.
Automatische Zusammenfassungen
In langen Incident-Kanälen mit Hunderten Nachrichten verlieren neue Teilnehmer schnell den Anschluss. KI-gestützte Zusammenfassungen kondensieren den bisherigen Verlauf auf wenige Kernaussagen: bekannte Ursachen, laufende Maßnahmen, offene Fragen. Das ermöglicht schnelles Onboarding neuer Helfer auch mitten im Incident.
Entwürfe für externe Kommunikation
Der Communications Lead muss regelmäßig Statusupdates verfassen – unter Stress und Zeitdruck. KI-Systeme können auf Basis des Echtzeit-Protokolls Entwürfe für Statusseiten-Einträge oder Kundenbenachrichtigungen generieren, die der Mensch dann prüft und freigibt. Das beschleunigt die externe Kommunikation ohne Qualitätsverlust.
Postmortem-Vorbereitung
Nach dem Incident übernimmt das KI-System das Rohprotokoll und erstellt einen strukturierten Postmortem-Entwurf: Timeline, beteiligte Systeme, Hypothesen und ihre Ergebnisse, Maßnahmen und ihre Wirksamkeit. Dieser Entwurf muss von Menschen überprüft und ergänzt werden – aber die zeitintensive Roharbeit entfällt.
Die entscheidenden 15 Minuten zu Beginn
Studien zeigen, dass die ersten Minuten eines Major Incidents die größten Weichen stellen. Wer in dieser Phase keine klare Struktur hat, kämpft oft für Stunden mit den Folgen. Empfehlenswert ist ein kurzes, standardisiertes Eröffnungsritual:
- Incident Commander benennen – explizit, nicht implizit
- Schweregrad bestätigen – ist das wirklich ein Major Incident?
- War Room öffnen – Kanal, Konferenz, Protokolldokument bereitstellen
- Ersten Statusupdate senden – nach außen: wir sind informiert, wir schauen uns das an
- Erste Hypothesen sammeln – nicht sofort testen, erst Überblick verschaffen
Kommunikation im Incident: Häufig und knapp
Schweigen im Incident erzeugt Misstrauen. Kurze, ehrliche Updates – auch ohne neue Erkenntnisse – halten alle informiert und reduzieren Rückfragen.
Die externe Kommunikation während eines Incidents folgt einem einfachen Prinzip: lieber häufige, kurze Updates als seltene, ausführliche. Kunden und Nutzer wollen wissen, dass jemand das Problem kennt und daran arbeitet – nicht unbedingt alle technischen Details. Ein Update im Rhythmus von 15 bis 30 Minuten ist in kritischen Phasen Standard.
Nach dem Incident: Das Postmortem als Lernmoment
Ein gut durchgeführter Major Incident endet nicht mit der Behebung des Problems. Das Postmortem – idealerweise blameless durchgeführt – analysiert, was passiert ist, warum es passiert ist und wie ähnliche Incidents in Zukunft vermieden oder schneller behoben werden können.
Wichtig: Nicht jedes Postmortem muss ein formales Dokument mit dutzenden Seiten sein. Für kleinere Major Incidents reicht oft ein strukturiertes Meeting mit einem klaren Protokoll. Entscheidend ist, dass konkrete Folgeaufgaben entstehen und verfolgt werden – sonst verpufft der Lerneffekt.
Fazit
Major Incident Management ist keine Krisenstimmung mit vielen Beteiligten – es ist strukturiertes Handeln unter Druck. Teams, die klare Rollen, erprobte Kommunikationswege und gute Werkzeuge haben, sind im Ernstfall deutlich effizienter als Teams, die improvisierten.
KI-Unterstützung kann dabei einen echten Beitrag leisten – nicht als Ersatz für menschliches Urteilsvermögen, sondern als Werkzeug für Kontextaufbereitung, Dokumentation und Kommunikationshilfe. Die Grundlage bleibt immer das, was vor dem Incident aufgebaut wird: Prozesse, Rollen und Übung.
Bildquelle: Foto von Pixabay via Pexels
Weiterführende Quellen: Google SRE Book – Managing Incidents (sre.google/sre-book); PagerDuty Incident Response Guide; Atlassian Incident Management Handbook
