Das Problem mit klassischen Eskalationsketten
Wer schon einmal als Teil einer On-Call-Rotation gearbeitet hat, kennt das Szenario: Es ist 2:47 Uhr, ein Alert kommt rein, das Monitoring zeigt einen erhöhten Fehlergrad bei einem Backend-Service. Die Eskalationskette sagt: erst Level-1, dann Level-2, dann Team-Lead. Doch der Alert betrifft eigentlich ein spezifisches Datenbankmodul, für das nur eine bestimmte Person im Team die nötige Expertise besitzt – die aber erst auf Level-3 in der Kette auftaucht.
Dieses strukturelle Problem ist keins aus Nachlässigkeit. Klassische Eskalationsketten sind linear und regelbasiert, weil das die einfachste Form ist, die sich verlässlich implementieren lässt. Aber Incidents sind selten linear. Sie haben Kontext, Komponenten und Ursachen, die über das hinausgehen, was eine statische Kette abbilden kann.
Wo KI in der Eskalationssteuerung ansetzt
KI-gestützte Eskalationssteuerung versucht, genau diese Lücke zu schließen – nicht indem sie die menschliche Entscheidung ersetzt, sondern indem sie den Kontext eines Incidents versteht und die Weiterleitung an die tatsächlich geeignete Person oder das richtige Team ermöglicht.
Der Ansatz funktioniert auf mehreren Ebenen:
- Incident-Klassifikation: Eingehende Alerts werden nicht nur nach Schweregrad, sondern nach inhaltlichem Typ klassifiziert. Ein erhöhter Datenbankfehler hat eine andere optimale Eskalationsstrategie als ein TLS-Zertifikatsproblem oder eine erhöhte Latenz im CDN-Layer.
- Kompetenz-Mapping: Das System pflegt ein dynamisches Modell davon, welche Personen welche Systemkomponenten kennen – gespeist aus vergangenen Incidents, Commit-Historien und dokumentierten Zuständigkeiten.
- Verfügbarkeitsberücksichtigung: Verfügbarkeit wird nicht nur aus dem Kalender gelesen, sondern aus Mustern. Wer hat in den letzten acht Stunden mehrfach auf Alerts reagiert? Wer ist bereits in einem aktiven Incident involviert?
- Kontextuelle Priorisierung: Ähnliche Incidents in der Vergangenheit liefern Referenzpunkte. War ein bestimmtes Problem letzte Woche schon dreimal eskaliert worden und jeweils von derselben Person gelöst? Das ist eine starke Indikation.
Wie das in der Praxis aussieht
Ein typischer KI-gestützter Eskalationsflow sieht heute so aus: Ein Alert tritt auf. Das System analysiert innerhalb von Sekunden den Alerttext, die betroffene Ressource, ähnliche historische Incidents und den aktuellen Bereitschaftsstatus aller relevanten Personen. Daraus leitet es eine priorisierte Empfehlung ab: "Primär: Sven K. (Datenbankexpertise, aktuell aktiv), sekundär: On-Call-Rotation Team Backend". Der Bereitschaftsdienst sieht diese Empfehlung und kann sie bestätigen, überschreiben oder weiterleiten.
Was sich verändert: Die erste Kontaktperson ist häufiger die richtige, nicht nur die erste in der Liste. Das reduziert Pingpong zwischen Teams und verkürzt die Zeit bis zur Incident-Lösung messbar.
Automatische Runbook-Verknüpfung
Viele Implementierungen verknüpfen die KI-Eskalation mit einer Runbook-Auswahl. Wenn das Modell den Incident klassifiziert, schlägt es gleichzeitig das relevanteste Runbook vor – oder fasst die relevanten Abschnitte zusammen, wenn das Runbook sehr lang ist. Das On-Call-Team sieht also nicht nur die Eskalationsempfehlung, sondern direkt den Lösungsweg.
Korrelation mehrerer Alerts
Ein klassisches Problem in großen Infrastrukturen: Ein einziges Netzwerkproblem erzeugt 47 Alerts aus verschiedenen abhängigen Systemen. Ohne Korrelation werden diese einzeln eskaliert, was zu mehrfachen parallelen Kontakten und erhöhtem Alert-Noise führt. KI-gestützte Systeme können diese Alerts in Echtzeit korrelieren und zu einer einzigen, kontextreichen Eskalation zusammenfassen.
Grenzen und Risiken
KI-gestützte Eskalation ist kein Allheilmittel. Wer die Technologie ohne klare Governance einführt, riskiert andere Probleme:
Fehlklassifikationen im Grenzbereich
Incidents, die keinem bekannten Muster entsprechen, sind genau die, bei denen KI-Klassifikation am schlechtesten abschneidet. Das sind häufig neue Systeme, unbekannte Abhängigkeiten oder komplexe Kaskadenausfälle. Ein Modell, das auf historischen Daten trainiert wurde, kann keine Erfahrung mit echten Neuheiten haben.
Kompetenz-Mapping-Drift
Das interne Modell davon, "wer kennt was", veraltet. Teams rotieren, Personen verlassen das Unternehmen, neue Dienste entstehen. Wenn das Kompetenz-Mapping nicht aktiv gepflegt wird, eskaliert das System an Personen, die längst nicht mehr die Richtigen sind.
Over-Automation
Teams, die zu stark auf KI-Eskalation vertrauen, verlieren das institutionelle Wissen darüber, wie manuelle Eskalationsentscheidungen getroffen werden. Im Fall eines KI-Systemausfalls kann das zu Orientierungslosigkeit führen.
Implementierungshinweise
Wer KI-gestützte Eskalation einführen möchte, sollte folgende Punkte beachten:
- Start mit Observing-Modus: Das System macht Empfehlungen, aber die finale Entscheidung liegt beim Menschen. Erst wenn das Vertrauen in die Klassifikationsqualität aufgebaut ist, können automatische Weiterleitungen in eng definierten Szenarien aktiviert werden.
- Explizites Feedback: On-Call-Mitglieder sollten einfach markieren können, ob eine Eskalationsempfehlung korrekt war. Dieses Feedback ist wertvolles Trainingssignal.
- Transparenz: Das System muss erklären können, warum es eine bestimmte Empfehlung gemacht hat. "Weil Person X die letzten 3 ähnlichen Incidents gelöst hat" ist nachvollziehbar. Eine Blackbox-Entscheidung ist es nicht.
- Fallback-Definition: Was passiert, wenn das KI-System nicht verfügbar ist oder keine zuverlässige Klassifikation liefert? Die klassische Eskalationskette muss immer als Fallback funktionieren.
Monitoring als Grundlage
Eine oft übersehene Voraussetzung: KI-gestützte Eskalation ist nur so gut wie die darunter liegenden Monitoring-Daten. Alerts müssen strukturiert, präzise und mit ausreichend Kontext versehen sein. Schlecht konfigurierte Monitore, die zu früh oder mit zu wenig Information feuern, beeinträchtigen die Klassifikationsqualität direkt. Das ist ein starkes Argument dafür, Monitoring-Qualität als eigenständiges Thema zu behandeln – nicht nur als Basis für Reaktionen, sondern als Enabler für intelligente Automatisierung.
Ausblick: Von Eskalation zu proaktiver Bereitschaft
Die mittelfristige Entwicklung geht über reaktive Eskalation hinaus. Systeme, die Incident-Muster kennen, könnten schon vor dem eigentlichen Alert die relevante Person informieren: "In den letzten drei Fällen mit diesem Muster hat sich ein Problem angekündigt – du könntest in der nächsten Stunde gebraucht werden." Das verschiebt die Bereitschaft von reaktiv zu proaktiv.
Kombiniert mit Predictive Monitoring, das Anomalien erkennt bevor sie zu echten Incidents werden, könnten die On-Call-Teams der Zukunft deutlich ruhigere Nächte haben – nicht weil weniger passiert, sondern weil mehr antizipiert wird.
Fazit
KI-gestützte Eskalationssteuerung ist kein Ersatz für gut strukturierte On-Call-Prozesse. Sie ist eine Ergänzung, die klassische Schwächen statischer Ketten – fehlende Kontextsensitivität, mangelnde Personalisierung, keine Korrelation paralleler Alerts – adressiert. Teams, die diese Technologie besonnen einführen, gewisse Grenzen kennen und transparente Fallback-Mechanismen bereithalten, können damit ihren Bereitschaftsdienst spürbar weniger belastend gestalten.
Bildquelle: Pexels / Mikhail Nilov – IT-Fachkraft bei der Analyse von Monitoring-Daten (Pexels License, freie Nutzung)
Quellen: PagerDuty AIOps-Dokumentation; OpsGenie Intelligent Alert Routing; Google SRE Workbook; interne Feldberichte von Engineering-Teams, Q1/Q2 2026
