Reduzierung der Alarmermüdung mit KI-Agenten

Die Teams für Site Reliability Engineering (SRE) und DevOps sind erschöpft. Ausufernde IT-Anlagen, eine Überlastung mit Tools und die Rufbereitschaft spielen allesamt eine Rolle bei einem übergreifenden Problem – der Alarmermüdung.

Alarmermüdung (im Englischen auch „Alert Fatigue“ genannt) bezieht sich auf „einen Zustand geistiger und operativer Erschöpfung, der durch eine überwältigende Anzahl von Alarmen verursacht wird“. Es untergräbt die Reaktionsfähigkeit und Effizienz von DevOps, dem Security Operations Center (SOC), Site Reliability Engineering (SRE) und anderen Teams, die für die IT-Leistung und -Sicherheit verantwortlich sind, und ist ein weit verbreitetes, folgenreiches Problem.

 Der Bericht „2023 State of Threat Detection“ von Vectra (basierend auf einer Umfrage unter 2.000 IT-Sicherheitsanalysten in Unternehmen mit 1.000 oder mehr Mitarbeitern) ergab, dass SOC-Teams durchschnittlich 4.484 Alarme pro Tag erhalten. Davon werden 67 % aufgrund einer hohen Anzahl von Fehlalarmen und Alarmermüdung ignoriert. Der Bericht ergab außerdem, dass 71 % der Analysten glauben, dass ihr Unternehmen bereits „ohne ihr Wissen kompromittiert wurde, weil es an Transparenz und Vertrauen in die Fähigkeiten der Bedrohungserkennung mangelt“.

Während der Vectra-Bericht einen sicherheitsspezifischen Fokus hat, sind Teams, die mit der Überwachung der Anwendungs- und Infrastrukturleistung beauftragt sind, mit einer ähnlichen Überlastung konfrontiert. Eine einzige Fehlkonfiguration kann beispielsweise Hunderte oder Tausende von Leistungswarnungen auslösen. Dies ist ein „Alarmsturm“, der IT-Teams ablenken oder desensibilisieren kann und zu verzögerten Reaktionen auf kritische Warnungen und echte Probleme führt. Und diese echten Probleme können kostspielig sein.

Was führt zu diesem Burnout und kann agentische KI Teil einer skalierbaren Lösung sein?

Es gibt hier mehrere Schuldige. Eine erdrückende Menge an Telemetriedaten wird oft als einer von ihnen genannt, wobei die Konzentration auf die Datenmenge jedoch ein zentrales Problem verdeckt: die Datenqualität und den Kontext.

Wenn Teams mit minderwertigen, kontextlosen Daten arbeiten, die von Dutzenden verschiedener Feeds zu Threat-Intelligence oder Leistung stammen, sind Probleme vorprogrammiert. In einer solchen Umgebung häufen sich Fehlalarme und redundante Warnungen. Gleichzeitig lenkt das Grundrauschen mit geringer Priorität von echten Bedrohungen und Leistungsproblemen ab. Diese „Fehlalarme“ können IT-, DevOps- und Sicherheitsteams das Leben schwer machen.

Das einfache Übertragen dieser riesigen Telemetriedatenströme in ein Large Language Model (LLM) ist ebenfalls keine brauchbare Lösung. Es wäre einerseits eine Verschwendung von Rechenleistung und andererseits e in Einfallstor für die Erzeugung von Halluzinationen.

Eine praktische Lösung beginnt mit der Entwicklung eines Workflows, der Rohdaten synthetisiert und diese hochwertigeren, kontextreichen Daten auf einer zentralen Plattform zusammenfasst. Dort können sie für die unternehmensweite Observability und das Training lokaler KI-Modelle verwendet werden.

Unternehmen verwenden oft viele Lösungen zur Leistungs- und Sicherheitsüberwachung – in großen Unternehmen gibt es durchschnittlich 76 Sicherheitstools. Diese Tools können team- oder produktspezifisch oder spezifisch für eine bestimmte IT-Umgebung sein (z. B. On-Premises- oder Cloud-Lösungen ).

Jedes dieser Tools kann für die Überwachung von Dutzenden oder Hunderten von Anwendungen, Programmierschnittstellen (APIs) oder Servern zuständig sein, die jeweils ihre eigene Datenpipeline speisen. Bei solchen Silos können getrennte Tools mehrere Warnmeldungen erzeugen, die auf dasselbe zugrunde liegende Problem zurückzuführen sind. Dieser Mangel an Integration schränkt die Sichtbarkeit ein, was wiederum die Korrelation und die Ursachenanalyse erschwert. In der Folge verschwenden SREs Zeit mit der Verfolgung der einzelnen Warnmeldungen, bevor sie die Redundanzen identifizieren können.

Wenn Datenströme nicht in ein umfassendes Überwachungssystem integriert sind, verfügen IT-Teams nicht über die systemweite Observability, die für eine effiziente Korrelation von Warnmeldungen, Ursachenanalyse und Abhilfemaßnahmen erforderlich ist.

Noch schlimmer ist, dass diese fehlende Integration die Wirksamkeit der Automatisierungstools für das Alarmmanagement, wie z. B. die Priorisierung von Alarmen und Korrelationsworkflows, die zur Erkennung und Lösung von Problemen und zur Verringerung der Anzahl von Alarmen eingerichtet wurden, beeinträchtigt. So müssen die Teams die einzelnen Punkte manuell miteinander verbinden – eine mühsame und zeitaufwändige (wenn nicht gar unmögliche) Aufgabe.

Eine im Bericht „Adaptive Defense: Custom Alerts for Modern Threats“ von Deloitte zitierte Umfrage ergab, dass „mangelnde Transparenz oder fehlender Kontext durch Sicherheitstools dazu führte, dass 47 % der Angriffe in einem Zeitraum von 12 Monaten nicht erkannt wurden“.

Während einzelne Agenten nicht unbedingt eine Zentralisierung benötigen, erleichtert eine zentralisierte Plattform, auf der die Daten der Agenten zusammengefasst werden, die systemweite Analyse, Speicherung und Visualisierung.

Ja … mit einer gezielten Strategie.

Ein kürzlich veröffentlichter MIT-Bericht löste mit der Behauptung, dass 95 % der Unternehmen keine Rendite aus ihren Investitionen in generative KI erzielen, einen wahren Sturm der Entrüstung aus. 

Abgesehen von der aufrüttelnden Statistik und den zahlreichen Meinungen, die der Bericht auslöste, wurde hier ein wichtiges Thema herausgestellt: Viele KI-Projekte scheitern an „brüchigen Workflows, fehlendem kontextbezogenem Lernen und falscher Abstimmung mit dem Tagesgeschäft“. Wie Marina Danilevsky, Senior Research Scientist bei IBM, in einem kürzlich erschienenen „Mixture of Experts“-Podcast anmerkt, sind die erfolgreichsten Bereitstellungen „zielgerichtet, definiert und adressieren einen echten Problembereich“.

Der MIT-Bericht unterstreicht die Tatsache, dass Unternehmen, die KI als eine Art Allheilmittel betrachten oder als etwas, das willkürlich in einen Prozess eingepasst werden kann, wahrscheinlich keinen Nutzen aus ihrer Investition ziehen werden. Unternehmen, die KI-Tools strategisch in ihre Workflows zur Lösung eines bestimmten Problems integrieren und diese Tools im Laufe der Zeit weiterentwickeln, haben bessere Erfolgsaussichten.

Mithilfe einer Observability- oder Security-Lösung, die adaptives maschinelles Lernen, kontextbezogene Priorisierung, erklärbare KI, KI-gestützte Automatisierung und Echtzeitdaten in eine integrierte Strategie einbezieht, können Teams stärkere Workflows erstellen, die zur Korrelation, Priorisierung und Behebung von Leistungs- oder Sicherheitswarnungen beitragen.

KI-Agenten können herkömmliche Systeme, die auf statischen Regeln und voreingestellten Schwellenwerten beruhen, verbessern, indem sie Faktoren wie die Bedeutung von Assets, Leistungsgarantien, Risikoprofile und historische Trends berücksichtigen. 

Denken Sie zum Beispiel an einen Workflow zur Erkennung und Behebung eines Vorfalls und daran, wie ein KI-Agent ein SRE-Team unterstützen könnte.

Das Alarmsystem erhält eine Meldung über eine hohe CPU-Auslastung eines Knotens in einem Kubernetes-Cluster. In einem herkömmlichen System müssen SREs möglicherweise MELT-Daten (Metriken, Ereignisse, Logs, Traces) und Abhängigkeiten untersuchen, um die Ursache zu ermitteln.

In diesem hypothetischen agentenbasierten Workflow nutzt der Agent den Wissensgraphen des Observability-Tools und die topologiebewusste Korrelation, um nur die Telemetriedaten abzurufen, die mit dem Alarm in Zusammenhang stehen (z. B. Protokolle für die auf diesem Knoten laufenden Dienste, die jüngsten Bereitstellungen, Telemetriedaten vom Kubernetes-API-Server oder Load Balancern, die den Traffic zum Knoten oder Cluster leiten). Mit diesen zusätzlichen Informationen kann der Agent unverarbeitete Alarme anreichern und kontextreiche Telemetriedaten für ein lokales KI-Modell bereitstellen, das anhand der Leistungsdaten und Benchmarks des Unternehmens trainiert wurde.

Der Agent schließt irrelevante Informationen aus, z. B. Protokolle für nicht verwandte Dienste, die zufällig auf demselben Cluster laufen. Während dieser Kontextsammlung kann der Agent auch verwandte Signale identifizieren und Alarme, die wahrscheinlich auf dieselbe Ursache zurückzuführen sind, miteinander in Beziehung setzen und gruppieren, um sie als einen Vorfall zu untersuchen.

Mit diesen Informationen kann das Modell dann eine Hypothese vorschlagen. Der Agent kann auch weitere Informationen anfordern (z. B. Containerkonfigurationen oder Zeitreihendaten rund um die Nutzungsspitze), um die Modellhypothese zu überprüfen und zu verfeinern, indem er vor dem Vorschlag einer wahrscheinlichen Ursache zusätzlichen Kontext hinzufügt.

Der Einsatz von erklärbarer KI und Agenten ist ein entscheidender Teil der Lösung des Vertrauensproblems, des „Blicks in die Blackbox“ oder der internen Abläufe eines KI-Tools.

Erklärbare künstliche Intelligenz (Explainable Artificial Intelligence, XAI) „bezeichnet zusammenfassend eine Reihe von Prozessen und Methoden, anhand derer menschliche Nutzer die von Algorithmen des maschinellen Lernens erzeugten Ergebnisse und Ausgaben verstehen und ihnen vertrauen können“.

Zusätzlich zur wahrscheinlichen Ursache kann der Agent eine Erklärung durch seine Gedankenkette (seinen Denkprozess) sowie unterstützende Beweise liefern, die zeigen, wie er zu der vorgeschlagenen wahrscheinlichen Ursache gekommen ist. Dank dieser Erklärbarkeit und der unterstützenden Beweise:

-       können Menschen erkennen, warum etwas auf eine bestimmte Weise empfohlen oder gefiltert wurde

-       wird die nötige Transparenz geschaffen, um die Analyse und den Vorschlag des Agenten zu überprüfen und zu beurteilen, ob dies vertrauenswürdig ist

Die SRE-Analyse und die Bewertung der Agentenempfehlungen können in das Modell zurückgeführt werden, um die Genauigkeit weiter zu verbessern.

Es gibt mehrere Wege zur Lösung. Teams können entscheiden, wie viel Autonomie sie einem Agenten zugestehen wollen, oder diese Autonomie je nach Art des Vorfalls, Schweregrad, Umgebung oder anderen Faktoren festlegen. Die nächsten Schritte umfassen:

-       Validierung: Ein Agent kann Schritte generieren, mit denen SRE- und DevOps-Teams überprüfen können, ob die vom Agenten identifizierte Ursache korrekt ist. So bleibt der menschliche Einfluss auf das System erhalten.

-       Runbook: Nach der Validierung kann der Agent eine Schritt-für-Schritt-Anleitung mit Abhilfeschritten (ein Runbook) erstellen. Dies ist ein Skript, dem Teammitglieder bei der Lösung des Problems folgen können.

-        Automatisierungsskripte: Der Agent kann auch die von ihm vorgeschlagenen Aktionen ausführen und Workflows (Automatisierungsskripte) erstellen. Er kann diese Runbook-Schritte in ein Ansible-Playbook-Snippet mit der Befehlssyntax und den Parametern für die Schritte umwandeln.

-       Dokumentation:Agenten können automatisch eine Dokumentation erstellen, z. B. einen Bericht nach einem Vorfall, der den Vorfall, die getroffenen Maßnahmen und die Gründe dafür zusammenfasst. Darüber hinaus kann ein Agent eine Zusammenfassung des Arbeitsfortschritts erstellen, die Personen, die mit der Aufgabe noch nicht vertraut sind, einen schnellen Überblick über den aktuellen Stand der Dinge verschafft. Diese Dokumentation kann für das verstärkende Lernen verwendet werden.   

All diese Schritte tragen dazu bei, die Vorfallsreaktion zu optimieren und die mittlere Zeit bis zur Reparatur zu verkürzen. Hier finden Sie ein Video, das ein ähnliches hypothetisches Szenario veranschaulicht.

KI-Frameworks können zur Verbesserung verschiedener Aspekte der Alarmmüdigkeit eingesetzt werden, z. B. zur Priorisierung von umsetzbaren Alarmen in einer IT-Umgebung.

In einem Artikel aus dem Jahr 2023 mit dem Titel „That Escalated Quickly: An ML Framework for Alert Prioritization“ stellen Gelman et al. ein Framework für maschinelles Lernen vor, das entwickelt wurde, um die Alarmermüdung mit minimalen Änderungen an bestehenden Workflows durch ein Bewertungssystem für die Alarmstufe und die Handlungsfähigkeit auf Vorfallsebene zu reduzieren. Anhand von realen Daten konnte das TEQ-Modell die Reaktionszeit auf relevante Vorfälle um 22,9 % reduzieren und 54 % der Falschmeldungen unterdrücken (mit einer Erkennungsrate von 95,1 %). Außerdem wurde die Anzahl der Warnmeldungen bei einzelnen Vorfällen um 14 % reduziert^{. 1}

In „Advancing Autonomous Incident Response: Leveraging LLMs and Cyber Threat Intelligence“ zeigen Tellache et al., wie ein auf Retrieval-Augmented Generation (RAG) basierendes Framework die Lösung von Vorfällen durch die Integration von Daten aus Cyberthreat-Intelligence-Quellen verbessern kann.² Eine ähnliche Lösung, die Agenten zur Erweiterung des RAG-Ansatzes einsetzt, könnte zur Erweiterung des Kontexts von Leistungsdaten verwendet werden. Ein Beispiel wäre das Abrufen vereinbarter Leistungsschwellenwerte aus den Service Level Agreements (SLAs) des Unternehmens, um zu entscheiden, welche Anwendungswarnungen priorisiert werden müssen.

Ein IT-Team könnte mehrere Agenten zur Verbesserung der Alarmprozesse einsetzen, von denen jeder auf eine andere Facette der Alarmermüdung abzielt (z. B. einen Triage-Agenten, der kritische Bedrohungen zur sofortigen Bearbeitung herausfiltert, oder einen Routing-Agenten, der nach Prioritäten geordnete Alarme erfasst und sie zusammen mit der Dokumentation und Analyse an das zuständige Team weiterleitet).

Indem sie Daten an einen zentralen Knotenpunkt weiterleiten, können Unternehmen blinde Flecken beseitigen und den Agenten ein umfassenderes Verständnis der Umgebung vermitteln, in der sie arbeiten. KI ist am effektivsten, wenn sie mit qualitativ hochwertigen, vertrauenswürdigen Daten arbeitet. Eine zentralisierte Plattform kann dabei helfen, die einheitliche Anwendung von Data-Governance-Standards sicherzustellen. Wenn Unternehmen KI-Lösungen skalieren, spielt diese Plattform eine entscheidende Rolle bei der Wahrung der Einheitlichkeit der Datenverwaltung und der Agentenbereitstellung in den verschiedenen Geschäftsbereichen.

Kann ein Unternehmen einfach „KI“ einsetzen und die Flut von Warnmeldungen abfangen? Nein. Können gut geschulte Modelle und Agenten dabei helfen, Telemetriedaten zu synthetisieren und zu analysieren und Alarme zu sortieren, um IT-Teams eine Pause zu gönnen? Hier besteht viel mehr Anlass zu Optimismus.

Der erfolgreiche Einsatz von KI und Agenten zur Verringerung der Alarmermüdung hängt von einigen wichtigen Faktoren ab: der Ausrichtung auf einen bestimmten Anwendungsfall, der strategischen Implementierung sowie der Fähigkeit der KI, in dynamischen Umgebungen zu lernen und sich zu verbessern. Die Verantwortlichen in den Unternehmen müssen verstehen, was erforderlich ist. Sie müssen bereit sein, die kulturellen Veränderungen vorzunehmen und die notwendigen Ressourcen bereitzustellen, damit das System funktioniert. Und nicht zuletzt müssen sie einen Anbieter finden, dessen Tools sich an die Bedürfnisse des Unternehmens anpassen lassen.