Große Incidents: Koordination statt Chaos

Es ist Dienstagmittag und ein kritischer Service stellt den Betrieb ein. Telefone klingeln, der Chat füllt sich und drei Teams suchen nach der Ursache, jedes in seiner eigenen Schicht. Der Leiter des Betriebs versucht herauszufinden, wer betroffen ist, der Service Desk möchte wissen, was er den Anrufern sagen soll, und das Management fragt, wann es behoben wird. Niemand hat das vollständige Bild.

Ein großes Incident ist ein Stresstest für Menschen und Systeme gleichermaßen. Ingenieure arbeiten unter Druck, während sie dieselben Fragen wieder und wieder beantworten. Externe Updates werden in Eile geschrieben und widersprechen sich oft. Und wenn es vorbei ist, ist es schwer zu rekonstruieren, was wann und warum passiert ist.

Warum das Runbook allein nicht ausreicht

Wir sehen oft Organisationen mit einem gut geschriebenen Verfahren für große Incidents. Das Problem liegt woanders. Wenn das Verfahren benötigt wird, fehlen die erforderlichen Informationen:

• Die Auswirkungen werden erraten. Wer weiß, welche Services auf dem betroffenen Server laufen? Oft eine Person, die mit etwas anderem beschäftigt ist.
• Änderungen werden nachträglich rekonstruiert. „Hat jemand etwas geändert?“ wird immer gefragt. Die Antwort kommt aus E-Mails und Erinnerungen.
• Vendors werden ad hoc kontaktiert. Wer hält den Vertrag, was verspricht die Reaktionszeit und wen soll man anrufen? Diese Informationen werden aus einem gemeinsamen Ordner herausgesucht.
• Die Kommunikation beginnt von vorne. Jedes Mal anders, jedes Mal unter Druck geschrieben.

Alle diese Informationen existieren irgendwo in der Organisation. Sie sind nur nicht greifbar, wenn es darauf ankommt.

Koordination läuft auf gemeinsamen Fakten

Ein gut geführtes großes Incident hat einen klaren Koordinator, eine einzige Quelle der Wahrheit und einen stetigen Rhythmus von Updates. Aber der Koordinator benötigt Fakten, keine Vermutungen: welche Services und Kunden sind betroffen, was hat sich kürzlich um die betroffenen Komponenten geändert, wer ist auf der Seite des Vendors verantwortlich und wer muss informiert werden? Je mehr davon im Voraus bereit ist, desto mehr Kapazität bleibt für die eigentliche Lösung.

Wie Eywo Stratum es handhabt

Eywo Stratum bindet das Incident an Daten, die bereits im System sind. Wenn ein Incident gegen ein CMDB-Element erhoben wird, schlägt es den betroffenen Service, die Auswirkungen und das Resolver-Team vor. Die Priorität folgt aus Auswirkungen und Dringlichkeit. Das Incident kann als groß gekennzeichnet werden, damit es die erforderliche Behandlung erhält.

Wenn das Incident im Monitoring beginnt, gruppiert das Event-Management verwandte Alerts in eine Situation basierend auf CMDB-Topologie, Service und Zeit und zeigt die wahrscheinliche Ursache zusammen mit verwandten Änderungen an. Ein Incident wird aus der Situation in einem Schritt oder automatisch erstellt. Das Team beginnt mit einer Situation mit Kontext, nicht mit tausend separaten Alerts.

Wenn ein Teil der Lösung bei einem Vendor liegt, kann das Incident gemäß dem Service-Vertrag eskaliert werden. Das System weiß, welche Elemente der Vertrag abdeckt und welche SLA der Vendor zugesagt hat. Niemand sucht nach einem Vertrag, während die Uhr tickt.

E-Mail- und Slack-Benachrichtigungen folgen Regeln und Vorlagen. Die richtigen Leute hören von dem Incident, ohne eine Runde von Telefonanrufen, und die Nachrichten sehen konsistent aus.

Der optionale KI-Assistent hilft, wo Zeit unter Druck verloren geht. Er schlägt ein Incident aus einer Situation vor, findet ähnliche vergangene Incidents und entwirft Kundenkommunikationen. Dies sind Vorschläge, keine Entscheidungen. Eine Person entscheidet immer, was gesendet wird und wie vorgegangen wird.

Danach bleibt die vollständige Zeitachse im Audit-Trail. Die Überprüfung nach dem Incident basiert auf einem Protokoll, nicht auf Erinnerungen.

Ruhe, wenn es zählt

Große Incidents können nicht ausgeschlossen werden. Was Sie sicherstellen können, ist, dass die ersten Minuten nicht damit verbracht werden, nach Informationen zu suchen. Wenn die Auswirkungen bekannt sind, Änderungen nachvollziehbar sind, der Vendor nur einen Klick entfernt ist und die Kommunikation entworfen ist, können sich Ingenieure auf die Lösung konzentrieren und der Koordinator auf die Menschen. Und wenn es vorbei ist, können alle nach Hause gehen, wissend, dass die Reaktion auf Fakten basierte.

Große Incidents sind Teil der Standard-Edition; die Ereigniskorrelation in Situationen, die vertragsbasede Vendor-Eskalation und der KI-Assistent sind in der Business-Edition enthalten.