Störungen kommunizieren ist eine Disziplin für sich
Wenn in einem System etwas ernsthaft schiefläuft, beginnt für IT-Teams häufig eine doppelte Herausforderung: Das Problem muss technisch behoben werden – und gleichzeitig müssen Nutzer, Stakeholder und das Management informiert werden. Beides gleichzeitig gut zu machen ist schwieriger, als es klingt.
Incident-Kommunikation, die unter Druck schlecht läuft, kostet mehr als Nerven. Sie erzeugt zusätzliche Anfragen, verursacht Verwirrung über den tatsächlichen Status und kann das Vertrauen in die IT-Abteilung nachhaltig beschädigen – auch wenn das technische Team das Problem längst gelöst hat.
Bildquelle: Pexels / fauxels – Team in Besprechung als Symbolbild für koordinierte Incident-Kommunikation und Teamarbeit
Die zwei Kommunikationsstränge im Incident
Bei jeder ernsthafteren Störung existieren zwei parallele Kommunikationsstränge, die unterschiedliche Anforderungen haben:
Interne Kommunikation
Innerhalb des IT-Teams und mit direkt beteiligten Kolleginnen und Kollegen geht es um Präzision, technische Details und klare Zuständigkeiten. Wer koordiniert? Wer analysiert? Wer kommuniziert nach außen? Wer informiert das Management? Ohne klare Antworten auf diese Fragen entsteht schnell Chaos – mehrere Personen kommunizieren gleichzeitig nach außen mit unterschiedlichen Informationen, oder niemand informiert, weil alle damit beschäftigt sind, das Problem zu lösen.
Externe Kommunikation
Gegenüber Nutzern, Kunden, Dienstleister-Partnern und Management gelten andere Regeln. Zu viele technische Details verwirren, zu wenige Details erzeugen Misstrauen. Das Wichtigste nach außen: Was ist betroffen? Seit wann? Was wird getan? Wann gibt es das nächste Update?
Beide Stränge müssen bewusst getrennt und parallel bespielt werden. Teams, die das nicht vorbereiten, vermischen sie unter Druck – mit vorhersehbaren Konsequenzen.
Rollen im Incident klar verteilen
Eine der wirksamsten Maßnahmen für bessere Incident-Kommunikation ist die vorab festgelegte Rollenverteilung. Die wichtigsten Rollen:
- Incident Commander: Koordiniert den gesamten Incident, trifft Entscheidungen, hält den Überblick. Diese Person analysiert nicht selbst – sie koordiniert.
- Technische Analyse: Ein oder zwei Personen, die ausschließlich am Problem arbeiten, ohne durch Kommunikationsaufgaben abgelenkt zu werden.
- Communications Lead: Eine Person, die intern und extern kommuniziert, Status-Updates formuliert und Eskalationsentscheidungen vorbereitet.
- Scribe / Protokollant: Hält alle wichtigen Events, Zeitstempel und Entscheidungen schriftlich fest – unverzichtbar für das spätere Postmortem.
In kleinen Teams übernimmt eine Person mehrere Rollen. Wichtig ist, dass die Kommunikationsverantwortung explizit ist – nicht implizit beim Techniker landet, der gerade versucht, den Fehler zu finden.
Kommunikationsfrequenz und Inhalt
Ein häufiger Fehler: Updates werden nur dann gesendet, wenn es Neuigkeiten gibt. Das ist aus IT-Sicht logisch, aus Nutzerperspektive aber frustrierend. Wenn zwanzig Minuten nichts kommt, entstehen Fragen. Deshalb gilt als Faustregel: Regelmäßige Updates auch ohne neue Erkenntnisse.
„Wir untersuchen das Problem weiterhin, haben aber noch keine abschließende Ursache identifiziert. Nächstes Update in 30 Minuten." – Das ist besser als Stille.
Ein gutes Incident-Update enthält:
- Was betroffen ist: Konkret, nicht vage. „Alle Nutzer in der EU", nicht „einige Dienste".
- Aktueller Status: Wird untersucht / ist eingegrenzt / wird behoben / ist behoben.
- Zeitstempel: Wann ist das passiert? Wann wurde es erkannt?
- Nächster Kommunikationspunkt: Wann kommt das nächste Update?
Statusseiten als zentrales Kommunikationsinstrument
Eine öffentliche Statusseite ist 2026 für Dienste mit externen Nutzern ein Standard-Werkzeug. Statusseiten erlauben es, Störungsmeldungen strukturiert zu veröffentlichen, Komponenten-Status anzuzeigen und den Verlauf einer Störung mit Zeitstempeln zu dokumentieren.
Der Vorteil: Nutzer können sich selbst informieren, ohne den Support zu kontaktieren. Das reduziert das Ticket-Volumen während eines Incidents spürbar. Gleichzeitig schafft Transparenz Vertrauen – selbst wenn ein Dienst gerade nicht funktioniert.
Automatische Statusseiten-Integrationen, die Monitoring-Signale direkt in Statusänderungen umwandeln, gehen einen Schritt weiter: Wenn ein HTTP-Check fehlschlägt, wird der Komponentenstatus automatisch auf „degradiert" gesetzt. Das reduziert die Zeit zwischen Störungseintritt und öffentlicher Kommunikation deutlich.
Management-Kommunikation während eines Incidents
Eine oft unterschätzte Kommunikationslinie: das eigene Management. Führungspersonen brauchen bei ernsteren Störungen früh eine Einschätzung – nicht wegen technischer Neugier, sondern weil sie möglicherweise Entscheidungen treffen oder Kunden informieren müssen.
Für die Management-Kommunikation gilt: kürzer, klarer, geschäftsorientierter. Nicht „Der Datenbankindex ist fragmentiert", sondern „Bestellungen können gerade nicht abgewickelt werden. Wir erwarten, das in den nächsten 45 Minuten zu beheben." Wer das vorab als Vorlage hat, muss es unter Druck nicht erst formulieren.
Nachbereitung: Kommunikation im Postmortem nicht vergessen
Nach dem Incident endet die Kommunikationsaufgabe nicht. Ein sorgfältiges Postmortem analysiert nicht nur die technische Ursache, sondern auch, wie gut die Kommunikation während des Incidents funktioniert hat:
- Wann wurde erstmals intern kommuniziert?
- Wann wurde extern kommuniziert? War die Verzögerung angemessen?
- Waren die Updates klar und ausreichend?
- Gab es Verwirrung durch widersprüchliche Aussagen?
Diese Analyse verbessert systematisch die nächste Incident-Kommunikation. Teams, die nur den technischen Teil postmortemisieren, verlieren wertvolle Lernpotenziale.
Vorbereitung schlägt Improvisation
Die effektivste Maßnahme für bessere Incident-Kommunikation ist nicht eine neue Software, sondern Vorbereitung: Kommunikationsvorlagen für häufige Szenarien (Ausfall, Degradation, Datenverlust), klare Eskalationspfade, vorab definierte Rollen und eine öffentliche Statusseite, die im Ernstfall sofort genutzt werden kann.
Teams, die das im Normalbetrieb einrichten, handeln im Incident ruhiger, strukturierter und transparenter. Die technische Kompetenz ist selten das Problem. Die Kommunikation unter Druck schon eher – und die lässt sich trainieren.
Quellen: Google SRE Book – Incident Management (Google, 2016), PagerDuty Incident Response Guide (2023), Atlassian Incident Management Playbook (2024)
