Incident und Change Signale im Cloud Betrieb bündeln

Ausgangslage

Der Konzern betreibt mehrere Cloud Plattformen mit insgesamt über 320 Services für interne Produkte und Kundenlösungen. Im IT Betrieb arbeiten 4 Plattformteams und ein zentrales Operations Center mit zusammen rund 25 Vollzeitkräften. Pro Arbeitstag entstehen im Schnitt 280 Incidents und 180 Changes, verteilt auf Ticketing System, Monitoring, Deployment Pipelines und Chat Kanäle. Ein Incident benötigt im Mittel 40 Minuten Bearbeitungszeit, ein Change inklusive Dokumentation rund 60 Minuten. On Call Bereitschaften werden aus Monitoring und Tickets gesteuert, doch Abhängigkeiten zwischen Services und parallelen Changes sind nur in verstreuten Dokumenten und Köpfen vorhanden.

Die Herausforderung

Im Alltag müssen die Teams entscheiden, welche Incidents zuerst bearbeitet werden, welche Changes verschoben werden sollten und wann zusätzliche Fachkräfte eingebunden werden. Monitoring erzeugt täglich hunderte Alarme, Tickets enthalten Freitextbeschreibungen, während geplante Changes in Deployment Tools und Wikis dokumentiert sind. Die Zusammenführung dieser Signale erfolgt manuell durch erfahrene Mitarbeitende, die sich Informationen aus mehreren Systemen zusammensuchen. Kritische Ketteneffekte, etwa ein Incident in einem Kernservice während eines parallelen Changes, werden oft erst spät erkannt. Das führt zu verlängerten Ausfallzeiten, ungeplanten Nachtschichten und hohem Abstimmungsaufwand zwischen Plattformteams, Produktentwicklung und Fachbereichen.

Warum das bisher ungelöst blieb

Die Verantwortlichen sahen das Problem seit Jahren, priorisierten aber andere Vorhaben im Plattformausbau. Ein klassisches IT Projekt schien zu groß, weil mehrere Systeme und Teams betroffen sind, gleichzeitig war der Aufwand für manuelle Abstimmung zu hoch, um ihn zu ignorieren. Versuche mit zusätzlichen Dashboards blieben wirkungslos, da sie nur technische Metriken aggregierten und keinen Bezug zu Tickets, Changes und geschäftlicher Kritikalität herstellten. Ohne eine Lösung, die Signale aus verschiedenen Quellen versteht, zusammenführt und konkrete Handlungsvorschläge macht, blieb die Koordination stark personenabhängig.

Eingeführt wurde ein agentischer Workflow, der Signale aus Monitoring, Ticketing System, Deployment Pipelines und Chat Kanälen kontinuierlich bündelt. Das System ordnet Incidents und Changes betroffenen Services zu, bewertet Kritikalität anhand hinterlegter Geschäftsimpact Klassen und erkennt Konflikte, etwa parallele Changes an einem bereits gestörten Kernservice. Für On Call Teams stellt der Workflow eine konsolidierte Sicht auf aktuelle Vorfälle, geplante Eingriffe und bekannte Abhängigkeiten bereit. Er erzeugt Vorschläge zur Priorisierung, empfiehlt Eskalationen an Fachteams und unterstützt bei der Dokumentation von Entscheidungen für Audits. Die Plattformteams behalten ihre bestehenden Tools, erhalten aber eine übergreifende Steuerungsschicht, die Kontext und Handlungsschritte strukturiert.

Wo generative KI arbeitet

Generative KI analysiert Freitext in Tickets und Chats, fasst Symptome und Auswirkungen zusammen und ordnet sie Services sowie Geschäftsbereichen zu. Sie erkennt Muster in Incidents und Changes, formuliert priorisierte Handlungsvorschläge und erstellt verständliche Zusammenfassungen für Übergaben und Audits.

Übertragbarkeit

Das Muster, technische und organisatorische Signale in einem agentischen Workflow zu bündeln, lässt sich gut auf andere komplexe Betriebsumgebungen übertragen. Überall dort, wo mehrere Systeme, Freitextbeschreibungen und parallele Eingriffe zusammenkommen, kann ein solcher Ansatz helfen, kritische Fälle früher sichtbar zu machen und Fachkräfte von manueller Abstimmung zu entlasten. Wichtig ist, dass ein grundlegender Katalog von Objekten, Kritikalität und Abhängigkeiten vorhanden ist, den der Workflow nutzen und schrittweise verfeinern kann.