Alert-Fatigue ist eine der häufigsten Ursachen für Fehler im On-Call-Betrieb. Wer nachts aus dem Schlaf gerissen wird und auf dem Smartphone 47 gleichzeitige Alerts vorfindet, von denen 40 das gleiche Grundproblem beschreiben, verliert wertvolle Minuten – oder begeht im schlechtesten Fall einen Fehler, weil wichtige Signale im Rauschen untergehen. KI-gestützte Eskalationsketten können hier strukturell helfen.
Das Problem: Zu viele Alerts, zu wenig Kontext
Die meisten Alerting-Systeme sind historisch darauf ausgelegt, lieber einen Alert zu viel als zu wenig auszulösen. Der Schwellenwert für eine CPU-Auslastung wird konservativ gesetzt, die Benachrichtigungen gehen an das gesamte On-Call-Team, und für jeden abhängigen Service gibt es einen eigenen Alert. Das Ergebnis: Bei einem einzelnen Netzwerkproblem landen zehn, zwanzig oder mehr Alerts auf dem Telefon der diensthabenden Person.
Dieses Muster erzeugt drei konkrete Probleme. Erstens: Zeit geht verloren, weil die erste Reaktion darin besteht, das eigentliche Problem aus der Flut von Symptom-Alerts herauszufiltern. Zweitens: Vertrauen in das Alerting-System sinkt, weil Teams lernen, Alerts zu ignorieren oder stumm zu schalten. Drittens: Eskalationen werden verzögert, weil unklar ist, ob ein Alert wirklich kritisch ist oder nur ein Folgeproblem eines bekannten Vorfalls.
Smarte Alert-Korrelation als erster Schritt
Der erste Hebel für besseres Alerting ist Korrelation: Mehrere Alerts, die das gleiche Grundproblem beschreiben, werden zu einem einzigen, kontext-reichen Ereignis zusammengefasst. Klassische Korrelationsregeln basieren auf festen Zeitfenstern und vordefinierten Abhängigkeitsbeziehungen. Das funktioniert gut für bekannte Fehlermuster, versagt aber bei neuartigen Problemen oder komplexen Kausalketten.
KI-Systeme können Korrelationen erkennen, ohne explizite Regeln zu benötigen. Machine-Learning-Modelle, die auf historischen Incident-Daten trainiert wurden, lernen, welche Alert-Kombinationen typischerweise auf dasselbe Grundproblem hinweisen. Ein plötzlicher Anstieg der Datenbanklatenz, gefolgt von Timeout-Alerts in mehreren Applikationsservices, wird als zusammenhängendes Ereignis erkannt – auch wenn die Services nicht explizit in der Abhängigkeitskarte miteinander verknüpft sind.
Dynamische Eskalationsketten: Wer bekommt welchen Alert?
Eskalationsketten legen fest, wer bei einem Incident benachrichtigt wird und in welcher Reihenfolge. Klassische Ketten sind statisch: Alert geht an Person A, wenn nicht quittiert, nach fünf Minuten an Person B, dann an C. Dieses Modell ignoriert Kontext vollständig.
Ein KI-gestütztes System kann die Eskalation kontextabhängig gestalten:
- Service-Expertise: Wer im Team hat in den letzten Monaten am häufigsten an diesem Service oder dieser Komponente gearbeitet? Diese Person wird direkt benachrichtigt.
- Tageszeit und Verfügbarkeit: Gibt es jemanden, der ohnehin gerade aktiv ist (laut letztem Login oder Kalender)? Dann geht die Benachrichtigung zuerst dorthin, um unnötige Weckrufe zu vermeiden.
- Incident-Typ: Ein Performance-Problem und ein Sicherheitsvorfall erfordern unterschiedliche Expertise. Das System leitet entsprechend zu unterschiedlichen Teams oder Personen.
- Historisches Muster: Dieser Fehler ist schon dreimal aufgetreten und wurde jedes Mal von derselben Person gelöst – sie bekommt die Benachrichtigung zuerst.
Automatische Severity-Einstufung
Eine der zeitaufwendigsten Aufgaben beim Empfang eines Alerts ist die Einstufung: Wie kritisch ist das wirklich? Ist das ein P1-Incident oder ein P3, der bis morgen früh warten kann? Diese Entscheidung erfordert Kontext, den ein starrer Schwellenwert nicht bieten kann.
Sprachmodelle und klassische ML-Klassifikatoren können hier zusammenarbeiten. Der Klassifikator wertet strukturierte Metriken aus – Fehlerrate, betroffene Nutzeranzahl, historische Korrelation mit kritischen Ausfällen. Das Sprachmodell aggregiert unstrukturierte Kontextinformationen: aktuelle Deployments, laufende Wartungen, bekannte technische Schulden in der betroffenen Komponente.
Das Ergebnis ist eine begründete Severity-Empfehlung, die dem On-Call-Team die erste Triagierung abnimmt. Wichtig: Die finale Entscheidung liegt immer beim Menschen. Das System empfiehlt, der Mensch entscheidet.
Automatische Alert-Anreicherung
Wer einen Alert erhält, braucht sofort Kontext, um handeln zu können. Ein gutes Alerting-System liefert nicht nur "Threshold exceeded", sondern beantwortet die wichtigsten Fragen direkt in der Benachrichtigung:
- Was genau ist passiert?
- Welche Services und Nutzer sind betroffen?
- Gab es ähnliche Incidents in der Vergangenheit?
- Welche Schritte haben beim letzten Mal geholfen?
- Gibt es ein verlinktes Runbook?
KI kann alle diese Informationen automatisch zusammenstellen und als strukturierten Context-Block an die Alert-Benachrichtigung anhängen. Der Empfänger öffnet die Benachrichtigung und hat sofort einen Überblick, ohne erst mehrere Dashboards öffnen zu müssen.
Stilles Lernen: Das System verbessert sich mit jedem Incident
Der entscheidende Vorteil KI-gestützter Eskalationsketten liegt in ihrer Fähigkeit zur kontinuierlichen Verbesserung. Jedes Incident hinterlässt Daten: Welche Eskalationsroute wurde gewählt? Wie schnell wurde das Problem gelöst? Wurde der Severity-Level nachträglich korrigiert? Wurden Alerts als False Positives markiert?
Diese Rückmeldungen fließen automatisch in die Modellverbesserung ein. Ein System, das heute noch gelegentlich False-Positive-Alerts produziert, lernt aus der Korrektur durch das Team und wird über Wochen und Monate präziser. Dieses stille Lernen ist einer der wesentlichen Vorteile gegenüber regelbasierten Systemen, die manuell gepflegt werden müssen.
Praktische Implementierungshinweise
Wer KI-gestützte Eskalationsketten einführen möchte, sollte schrittweise vorgehen. Ein vollständiger Umbau des Alerting-Systems über Nacht birgt erhebliche Risiken. Bewährt hat sich folgender Ansatz:
- Datenbasis aufbauen: Historische Incident-Daten mit Resolution-Zeiten, Eskalationspfaden und Feedback sammeln und aufbereiten.
- Korrelation zuerst: Alert-Clustering und Korrelation als ersten Use Case implementieren, da dies sofort sichtbaren Mehrwert liefert ohne das grundlegende Routing zu verändern.
- Shadow-Modus: KI-Empfehlungen parallel zum bestehenden System laufen lassen und gegen tatsächliche Entscheidungen vergleichen, bevor sie in die Produktion übergehen.
- Feedback-Loops einbauen: Mechanismen bereitstellen, mit denen On-Call-Teams Korrekturen direkt einpflegen können.
Fazit: Weniger Rauschen, schnellere Reaktion
KI-gestützte Eskalationsketten sind kein Ersatz für gutes Engineering, sondern eine Verstärkung davon. Sie helfen, das Signal aus dem Rauschen herauszufiltern, die richtigen Menschen zur richtigen Zeit zu benachrichtigen und jedem Incident von Beginn an den nötigen Kontext mitzugeben. Das Ergebnis ist messbar: niedrigere Mean Time to Acknowledge (MTTA), niedrigere Mean Time to Resolve (MTTR) und – nicht zu unterschätzen – weniger Burnout im On-Call-Team.
Quellen: PagerDuty State of Digital Operations Report 2026, Google SRE Workbook (sre.google), Prometheus Alerting Best Practices, OpsRamp AIOps Benchmark Report 2025/2026.
Bildquelle: Picsum Photos (picsum.photos) – lizenzfrei für kommerzielle Nutzung
