Wie reduziert AIOps Alarmrauschen, identifiziert Ursachen und ermittelt die Business-Auswirkung?

AIOps reduziert Alarmrauschen, indem es viele Rohsignale in eine kleinere Anzahl von Incidents umwandelt. Anschließend nutzt es Zeit, Topologie, Metriken, Konfigurationsbeziehungen und historische Evidenz, um die wahrscheinlichste Ursache zu identifizieren. Die Business-Auswirkung ergibt sich, wenn man diese Ursache von der Infrastruktur aufwärts zu Workloads, Anwendungen, Services, Projekten und Verantwortlichen zurückverfolgt.

Ein brauchbares Ergebnis ist deshalb mehr als der Satz „die KI sagt, die GPU ist defekt". Gebraucht wird ein nachvollziehbarer Incident, der zeigt, welche Alarme gruppiert wurden, welche Evidenz auf die vermutete Komponente hindeutet, welche Services betroffen sind, wem sie gehören und welche Maßnahme empfohlen wird.

Warum bekommen Infrastruktur-Teams zu viele Alarme?

Infrastruktursysteme senden Alarme auf unterschiedlichen Ebenen, und ein einzelner realer Fehler kann viele Symptome erzeugen.

Nehmen wir an, eine Beschleunigerkarte entwickelt ein ECC-Problem. Der Karten-Monitor erzeugt einen Hardware-Alarm, danach setzt sich vielleicht der Treiber zurück und ein Container startet neu. Ein Trainings-Worker fällt womöglich aus, der Scheduler meldet einen fehlgeschlagenen Task, der API-Service reduzierte Kapazität und der Anwendungs-Monitor erhöhte Latenz.

Ohne Korrelation können so sechs Teams sechs Alarme für ein einziges Ereignis erhalten, und daraus entsteht Alarmmüdigkeit. Falsch sind die einzelnen Alarme dabei meist nicht, sie können alle technisch korrekt sein. Sie beschreiben nur unterschiedliche Folgen desselben Incidents.

Nützlich wird AIOps, wenn es die Evidenz bewahrt und gleichzeitig die Anzahl der Incident-Objekte senkt, die Operatoren verwalten müssen.

Wie funktioniert die Alarm-Aggregation?

Die Alarm-Aggregation gruppiert Rohereignisse, die wahrscheinlich zum selben Incident gehören. Das Betriebsmodell der Quelle nutzt dafür eine Zeitfenster-Aggregation für Alarme desselben Node und derselben Komponente.

Eine praxistaugliche Gruppierungsregel kann berücksichtigen:

Geräte-Identität
Komponenten-Identität
Zeitliche Nähe
Alarmtyp
Topologiebeziehung
Gemeinsamer Workload
Gemeinsame vorgelagerte Abhängigkeit
Wiederkehrendes Ereignismuster

Angenommen, auf einer Karte treten innerhalb von fünf Minuten zehn ECC-bezogene Ereignisse auf. Zehn separate Arbeitsaufträge wären dann meist wenig sinnvoll. Das System kann die Ereignisse stattdessen zu einem Incident zusammenfassen und alle zehn Rohereignisse als Evidenz aufbewahren.

Dabei sollte die Aggregation konservativ bleiben. Zu weit gefasste Regeln vermischen nicht zusammenhängende Fehler, zu enge lassen den Alarmsturm bestehen. Diese Balance gehört zu den schwierigsten Teilen des operativen Event-Managements.

Was ist die Unterdrückung nachgelagerter Alarme?

Die nachgelagerte Unterdrückung blendet Alarme aus oder stuft sie herab, wenn sie wahrscheinlich Folgen eines vorgelagerten Fehlers sind.

Angenommen, ein Top-of-Rack-Switch verliert die Stromversorgung. Dutzende Server werden unerreichbar, Container fallen bei Health-Checks durch und Anwendungen melden Timeouts. Weiß die Plattform, dass diese Server von diesem Switch abhängen, kann das Switch-Ereignis zum primären Incident werden, und die nachgelagerten Alarme hängen als Evidenz für die Auswirkung daran.

Löschen sollte man die Rohalarme nicht, denn sie können nützliche Details enthalten. Sie brauchen aber nicht alle einzeln die Aufmerksamkeit eines Operators.

Dafür sind Topologie- und Beziehungsdaten unverzichtbar. Ohne Informationen über Abhängigkeiten kann das System Ursache und Folge nicht zuverlässig unterscheiden.

Wie hilft Topologie bei der Ursachenanalyse?

Topologie gibt AIOps eine Landkarte davon, wie Komponenten und Services voneinander abhängen. Sie kann mehrere Ebenen umfassen:

Rack- und Stromversorgungsbeziehungen
Server- und Beschleuniger-Beziehungen
Netzwerkverbindungen
Speicherpfade
Cluster-Nodes
Container
Modell-Services
Anwendungen
Projekte
Business-Services

Tritt ein Incident auf, kann die Plattform prüfen, ob die betroffenen Objekte eine gemeinsame Abhängigkeit haben. Fallen fünf Workloads aus und laufen alle fünf auf einem Server, ist der Server ein starker Kandidat. Laufen sie auf mehreren Servern, nutzen aber alle ein Speichersystem, rückt der Speicher in den Fokus. Nutzen sie unterschiedliches Compute und unterschiedlichen Speicher, teilen sich aber einen Netzwerkpfad, sollten Sie diesen Pfad untersuchen.

Mit Topologie wird aus einer Alarmkorrelation per Keyword-Abgleich ein Schlussfolgern entlang echter Abhängigkeiten.

Wie helfen Zeitreihendaten bei der Ursachenidentifikation?

Zeitreihendaten zeigen, welche Änderung zuerst auftrat und welche Symptome folgten. Die Reihenfolge selbst ist Evidenz.

Angenommen, die Zeitleiste zeigt:

12:06 Uhr: GPU-ECC-Zähler steigt
12:07 Uhr: GPU-Reset tritt auf
12:08 Uhr: Container-Neustart beginnt
12:09 Uhr: Trainings-Task meldet Fehler
12:10 Uhr: Service-Kapazität sinkt

Diese Abfolge stützt die Hypothese einer Hardware-Ursache. Ein anderer Fall sieht so aus:

12:06 Uhr: Speicherlatenz steigt
12:07 Uhr: Wartezeit des Data-Loaders steigt
12:08 Uhr: GPU-Auslastung sinkt
12:09 Uhr: Dauer des Trainingsschritts steigt

Hier spricht wenig für einen GPU-Fehler.

AIOps sollte Zeitstempel nutzen, um korrelierte von zufälligen Ereignissen zu unterscheiden. Zeitliche Korrelation allein beweist allerdings keine Kausalität. Belastbarer wird das Ergebnis, wenn Zeit mit Topologie und bekannten Beziehungen kombiniert wird.

Was bedeutet ein Konfidenzwert für die Ursache?

Ein Konfidenzwert drückt aus, wie stark die verfügbare Evidenz eine Hypothese zur Ursache stützt. Die Evidenz selbst sollte er niemals ersetzen.

Eine nützliche Schlussfolgerung kann etwa so lauten: Die wahrscheinliche Ursache ist Beschleunigerkarte 3, mit hoher Konfidenz. Als Evidenz dient, dass die ECC-Fehleranzahl unmittelbar vor dem Worker-Neustart stieg, alle betroffenen Container an dieselbe Karte gebunden waren, die gleichartigen Karten auf dem Server gesund blieben und dieselbe Karte in der Vorwoche zwei ähnliche Incidents verzeichnete.

Damit kann man arbeiten. Mit einer Zahl wie „92 Prozent Konfidenz" ohne Erklärung kann man es nicht, denn Operatoren müssen sehen, warum das System zu seiner Schlussfolgerung gekommen ist. Das Betriebsmodell der Quelle verlangt ausdrücklich, dass die Evidenz für die Ursache einzeln sichtbar ist, und dieses Design schafft Vertrauen.

Wie unterscheidet AIOps Hardware- von Softwareproblemen?

AIOps unterscheidet Hardware und Software, indem es Evidenz über mehrere Ebenen hinweg vergleicht.

Bei Hardware achten Sie auf physische Signale oder Signale auf Geräteebene wie ECC-Ereignisse, BMC-Alarme, Temperatur, Stromversorgung, Link-Fehler, Festplattenfehler und wiederholte Geräte-Resets. Bei Software sind es Prozessausfälle, Konfigurationsänderungen, Abhängigkeitsfehler, Treiberprobleme, Anwendungsausnahmen oder Ressourcenerschöpfung ohne entsprechende Hardware-Evidenz.

Danach kommt das Timing ins Spiel. Ein Hardware-Ereignis vor einem Prozessabsturz stützt die eine Theorie, ein Konfigurations-Deployment vor demselben Absturz die andere.

Vergleichen Sie außerdem gleichartige Systeme. Entwickelt jeder Node mit einer neuen Treiberversion dasselbe Problem, ist der Treiber ein stärkerer Kandidat als fünf gleichzeitige Hardware-Ausfälle. Fällt dagegen eine Karte wiederholt aus, während baugleiche Karten gesund bleiben, ist Hardware wahrscheinlicher.

AIOps sollte deshalb domänenübergreifend arbeiten, weil eine einzelne Monitoring-Quelle selten genug Evidenz enthält.

Wie hilft eine CMDB bei AIOps?

Eine CMDB liefert die Beziehungsdaten, die für Auswirkungsanalyse und abhängigkeitsbasiertes Schlussfolgern nötig sind. Sie kann verknüpfen:

Karte mit Server
Server mit Rack
Server mit Cluster-Node
Node mit Container
Container mit Modell-Service
Modell-Service mit Anwendung
Anwendung mit Projekt
Projekt mit Verantwortlichem

Daraus ergeben sich drei nützliche Analyserichtungen. Die Aufwärtsanalyse fragt, welche Business-Services betroffen sind, die Abwärtsanalyse, welche Infrastrukturkomponente die wahrscheinliche Ursache ist. Die horizontale Analyse klärt, wem der betroffene Service gehört und welcher Workflow den Incident bearbeiten sollte.

Mehr zum Beziehungsmodell selbst lesen Sie unter wie eine CMDB Server, GPUs, Container, Anwendungen, Business-Services und Verantwortliche verknüpfen kann.

Wie ermittelt AIOps die Business-Auswirkung?

Die Business-Auswirkung ermittelt die Plattform, indem sie die Live-Beziehungen vom ausgefallenen Objekt zu den davon abhängigen Services durchläuft.

Wie schwer ein Server-Ausfall wiegt, hängt davon ab, was der Server trägt. Der eine hostet vielleicht einen Entwicklungs-Workload, der andere Inferenzkapazität für einen umsatzkritischen Service. Der Hardware-Alarm kann in beiden Fällen identisch sein, die Business-Auswirkung ist es nicht.

Die Plattform sollte dem Incident daher Business-Kontext anfügen. Nützliche Felder sind unter anderem:

Betroffener Service
Betroffenes Modell oder betroffene Anwendung
Projekt
Mandant
Fachbereich
Service-Tier
SLO-Risiko
Aktueller Traffic oder Workload
Verantwortlicher
Bereitschaftsteam

So lassen sich Incidents nach ihren Folgen priorisieren statt allein nach der Schwere des Hardware-Alarms.

Wie reduziert AIOps doppelte Incidents?

Gegen doppelte Incidents helfen Ereignisgruppierung, Topologie, Zeitfenster und die Erkennung gemeinsamer Ursachen.

Angenommen, 30 Alerts stammen von Containern auf einem ausgefallenen Node. Ist der Node bereits als gemeinsame Ursache erkannt, sollte die Plattform keine 30 unabhängigen Incidents eröffnen, sondern einen primären Incident anlegen und die Container-Alerts als betroffene Objekte anhängen. Fällt gleichzeitig ein zweiter, nicht zusammenhängender Node aus, bleibt das ein separater Incident, solange keine Evidenz die beiden verknüpft.

Deshalb brauchen Gruppierungsregeln Topologie und Objekt-Identität. Reine Textähnlichkeit würde nicht zusammenhängende Fehler zusammenführen, nur weil deren Alarmmeldungen ähnlich klingen.

Wie sollten historische Incidents genutzt werden?

Historische Incidents verbessern die Diagnose, weil sie zeigen, ob dasselbe Objekt oder Muster schon einmal ausgefallen ist. Nützliche historische Evidenz umfasst:

Frühere Incidents auf demselben Gerät
Frühere Incidents mit derselben Alarmabfolge
Bekannte Ursachen
Verwendete Runbooks
Reparaturmaßnahme
Ob die Maßnahme funktioniert hat
Austauschhistorie
Notizen nach dem Incident

Die Historie sollte leiten, aber nicht diktieren. Ein vergangener Netzwerkausfall und ein aktueller Hardware-Ausfall können ähnliche Anwendungssymptome erzeugen, also sollte das System die Evidenz vergleichen, bevor es die alte Lösung empfiehlt.

Am besten funktioniert eine Empfehlung, die ihre Herkunft offenlegt: „Das ähnelt Incident 1842, weil dieselbe ECC-Abfolge auf demselben Kartenmodell auftrat." Dann kann der Operator die Relevanz selbst beurteilen.

Was sollte geschehen, nachdem die Ursache identifiziert wurde?

Die Plattform sollte auf Basis von Ursache, Risiko und verfügbarem Runbook einen Weg zur Behebung empfehlen.

Bekannte, vorübergehende Probleme mit geringem Risiko können für die automatische Wiederherstellung infrage kommen. Bei kontrolliertem Risiko lassen sich freigegebene Skripte gemäß Richtlinie ausführen, während Änderungen mit hohem Risiko einen Vorschlag erzeugen und in einen Freigabe-Workflow gehen sollten.

Jede Maßnahme gehört mit dem Incident verknüpft, ihr Ergebnis wird zurückgeschrieben, und geschlossen wird der Incident erst, wenn die Wiederherstellung bestätigt ist. Daraus ergibt sich ein vollständiger Kreislauf:

Erkennen
Aggregieren
Diagnostizieren
Auswirkung bewerten
Empfehlen
Freigeben
Ausführen
Validieren
Überprüfen

Für das Zuverlässigkeits-Framework rund um diesen Kreislauf erklärt der Artikel darüber, wie SRE-Metriken wie MTTD, MTTR, SLO, Error Budgets und Burn Rate auf KI- und Infrastrukturbetrieb angewendet werden, wie sich messen lässt, ob der Prozess tatsächlich besser wird.

Kann AIOps Behebungsmaßnahmen sicher selbst ausführen?

Manche Maßnahmen lassen sich sicher automatisieren, der Automatisierungsgrad sollte sich aber am Risiko orientieren. Ein bekanntes, vorübergehendes Ereignis mit einer bewährten, reversiblen Lösung ist etwas anderes als ein Firmware-Update oder eine Änderung an der Netzwerkkonfiguration.

Das Betriebsmodell der Quelle nutzt drei Risikostufen. Maßnahmen mit geringem Risiko dürfen sich selbst wiederherstellen und automatisch geschlossen werden. Bei kontrolliertem Risiko laufen freigegebene Behebungs-Skripte mit Absicherungen und Rollback. Risikobehaftete Änderungen erfordern eine Workflow-Freigabe, eine Canary-Ausführung und eine vollständige Auditierung.

Auf die genaue Anzahl der Stufen kommt es weniger an als auf das Prinzip, dass die Leitplanken mit der Auswirkung stärker werden. AIOps sollte Operatoren helfen, bessere Entscheidungen zu treffen, und nicht zu einer unkontrollierten Änderungs-Engine werden.

Was sollte ein AIOps-Incident-Datensatz enthalten?

Ein nützlicher Incident-Datensatz bewahrt die Evidenzkette. Dazu gehören:

Primärer Incident
Rohalarme
Betroffene Objekte
Topologie-Kontext
Zeitleiste
Wahrscheinliche Ursache
Konfidenz oder Evidenzstärke
Betroffene Services
Verantwortlicher
Empfohlene Maßnahme
Freigabe-Protokoll
Ausführungsergebnis
Validierung der Wiederherstellung
Nachbereitung des Incidents

Solche Datensätze werden später zu nützlichem Trainingsmaterial für künftige Incidents. Ein Plattformbeispiel, das diesen evidenzbasierten geschlossenen Kreislauf nutzt, ist Sensaka.

Würde ich ein AIOps-Produkt bewerten, würde ich die Anzahl der KI-Funktionen auf der Marketing-Seite ignorieren und stattdessen einen echten Incident testen. Geben Sie dem Produkt einen Alarmsturm und lassen Sie es das Rauschen reduzieren, die wahrscheinliche Ursache zeigen, die Evidenz erklären, den betroffenen Service und Verantwortlichen identifizieren, eine Maßnahme empfehlen und belegen, was nach der Ausführung passiert ist. Schafft es diese Kette nicht vollständig, betreibt es Analytics und noch kein vollständiges operatives AIOps.