Abstract — Die zunehmende Komplexität cloud-nativer Architekturen und die exponentielle Zunahme von Telemetriedaten übersteigen die Kapazität manueller Betriebsprozesse und erfordern eine intelligente Automatisierung des IT-Betriebs. Die vorliegende Arbeit bietet einen umfassenden Überblick über AIOps (Artificial Intelligence for IT Operations) und analysiert systematisch den aktuellen Forschungsstand entlang des Incident-Lifecycles. Ausgehend von den drei Säulen der Observability – Metriken, Logs und Traces – werden die Kernaufgaben Failure Perception, Root Cause Analysis und Auto-Remediation sowie die jeweils eingesetzten Methoden von klassischen ML-Verfahren bis hin zu Transformer-basierten Modellen untersucht. Ein besonderer Schwerpunkt liegt auf dem durch Large Language Models (LLMs) eingeleiteten Paradigmenwechsel: Die Arbeit analysiert LLM-Nutzungsstrategien wie Prompting, Fine-Tuning und Retrieval-Augmented Generation (RAG) sowie agentenbasierte Architekturen, insbesondere das ReAct-Framework und Multi-Agenten-Systeme, die den gesamten Incident-Lifecycle autonom verwalten können. Darüber hinaus werden das Agent-Cloud-Interface (ACI) und deterministische Übersetzungsschichten als Standardisierungsansätze für die Agenten-Cloud-Interaktion diskutiert. Die kritische Analyse identifiziert zentrale Herausforderungen: Sicherheitsrisiken durch Telemetrie-Manipulation mittels Adversarial Reward Hacking, Halluzinationsprobleme, Kosten-Nutzen-Abwägungen sowie organisatorische Adoptionsbarrieren. Anhand aktueller Benchmark-Frameworks wie AIOpsLab und MicroServo werden Evaluierungsmethoden und Leistungsvergleiche eingeordnet, und industrielle Berichte werden kritisch bewertet. Die Arbeit schließt mit Forschungsperspektiven zu kosteneffizienten Small Language Models, protokollseitig verankerten Sicherheitsarchitekturen und der Standardisierung von Agenten-Schnittstellen.
I. Einleitung
A. Motivation und Problemstellung
Moderne Softwaresysteme haben sich in den vergangenen Jahren grundlegend gewandelt. Der Übergang zu Cloud-nativen Architekturen, insbesondere die breite Adoption von Microservices und deren Orchestrierung mittels Kubernetes, hat die Entwicklung und Skalierung von Anwendungen zwar erheblich vereinfacht, zugleich jedoch die operative Komplexität drastisch erhöht [1]. In solchen verteilten Umgebungen können sich Fehler kaskadenartig über zahlreiche Dienste ausbreiten, wobei allein ein einstündiger Ausfall bei einem großen Cloud-Anbieter Verluste von geschätzten 100 Millionen US-Dollar verursachen kann [2].
Die Kapazität manueller Betriebsprozesse ist durch die Größe des DevOps-Teams begrenzt und kann nur linear wachsen, während Durchsatz und Arbeitsaufkommen häufig exponentiell zunehmen [3]. Darüber hinaus ist die Standardisierung manueller Abläufe aufgrund der Heterogenität von Qualifikation, Systemkenntnissen und Erfahrung innerhalb der Teams kaum zu gewährleisten. Manuelle Eingriffe sind zudem fehleranfällig. Selbst bei den zuverlässigsten Cloud-Anbietern wurden schwerwiegende Ausfälle durch menschliche Bedienfehler verursacht [3].
Die Folgen dieser Komplexität zeigen sich in zentralen Betriebskennzahlen: Die Mean Time to Detect (MTTD), Mean Time to Triage (MTTT) und insbesondere die Mean Time to Resolve (MTTR) bleiben in vielen Organisationen auf einem hohen Niveau. Gleichzeitig führt die wachsende Menge an Telemetriedaten – Metriken, Logs und Traces – zu einer Überlastung der Site-Reliability-Engineers (SREs), die als Alert Fatigue und operativer Toil die Effizienz weiter reduziert [1], [3]. Vor diesem Hintergrund wird eine intelligente Automatisierung des IT-Betriebs zunehmend unverzichtbar.
B. Evolution von AIOps
Die Grundlage für das Verständnis von AIOps bildet das DevOps-Paradigma, das die traditionelle Trennung zwischen Softwareentwicklung und IT-Betrieb aufhebt. DevOps integriert Coding, Testing, Deployment und Operations in einem Continuous-Integration/Continuous-Delivery-Modell (CI/CD), wobei DevOps-Engineers eine Ende-zu-Ende-Verantwortung für den gesamten Software-Lebenszyklus übernehmen [3]. Von DevOps abzugrenzen ist MLOps (Machine Learning Operations), das sich auf die Operationalisierung von ML-Modellen konzentriert – also deren Training, Versionierung, Deployment und Monitoring – während AIOps den Einsatz von KI für den IT-Betrieb selbst bezeichnet.
Der Begriff AIOps (Artificial Intelligence for IT Operations) wurde 2016 von Gartner geprägt. Gemäß der Gartner-Definition kombiniert AIOps „Big Data und maschinelles Lernen, um IT-Betriebsprozesse zu automatisieren, einschließlich Ereigniskorrelation, Anomalieerkennung und Kausalitätsbestimmung" [4], [3]. AIOps erschien bereits 2017 auf Gartners Hype Cycle for Artificial Intelligence und hat seitdem eine zunehmende Adoption in der Industrie erfahren.
Cheng et al. [3] beschreiben eine vierstufige AIOps-Reifegradskala, die den Transformationspfad strukturiert: (1) Manual Ops, bei dem alle Prozesse manuell durchgeführt werden; (2) Human-Centric AIOps, bei dem KI-Techniken als Assistenzsysteme einzelne Teilprozesse unterstützen, etwa durch dynamische Grenzwerte auf Basis von Anomalieerkennungsmodellen; (3) Machine-Centric AIOps, bei dem alle wesentlichen Betriebskomponenten – Monitoring, Detection, Triage und Remediation – durch komplexere KI-Verfahren gesteuert werden und Menschen primär in einer Human-in-the-Loop-Rolle zur Feinabstimmung agieren; sowie (4) Fully-Automated AIOps, bei dem die Plattform vollständig autonom operiert und die CI/CD-Pipeline zu einer CI/CD/CM/CC-Pipeline (Continuous Monitoring und Continuous Correction) erweitert wird.
Einen grundlegenden Umbruch markiert der Einsatz von Large Language Models (LLMs) und generativer KI (GenAI) im AIOps-Kontext. Während traditionelle AIOps-Methoden auf der Erkennung von Anomalien in strukturierten Daten basieren, ermöglichen LLMs durch Fähigkeiten wie In-Context Learning und Chain-of-Thought Reasoning ein logisches Schlussfolgern über unstrukturierte Daten und Systemgrenzen hinweg [5], [6]. Dies verschiebt den Fokus von der reinen Anomalieerkennung hin zur autonomen Entscheidungsfindung und Self-Healing: Chen et al. [2] prägen hierfür den Begriff AgentOps, bei dem LLM-basierte Agenten den gesamten Incident-Lifecycle – von der Erkennung über die Lokalisierung und Diagnose bis zur Mitigation – autonom verwalten. Shetty et al. [1] prognostizieren, dass solche Agenten Aufgaben in wenigen Minuten bewältigen können, für die selbst erfahrene Experten mehrere Stunden benötigen.
C. Aufbau der Arbeit
Die vorliegende Arbeit gliedert sich entlang des AIOps-Incident-Lifecycles in sechs aufeinander aufbauende Abschnitte. Abschnitt II behandelt die Datengrundlage und Observability, insbesondere die drei Säulen Metriken, Logs und Traces sowie deren Vorverarbeitung im LLM-Zeitalter. Abschnitt III widmet sich den Kernaufgaben des AIOps-Zyklus – Failure Perception, Root Cause Analysis und Auto-Remediation. In Abschnitt IV wird die Rolle von GenAI und Agentic AIOps behandelt, darunter LLMs als kognitive Engine, Agenten-Architekturen und das Agent-Cloud-Interface. Abschnitt V diskutiert die wesentlichen Herausforderungen und Risiken, von Prompt Injection über Halluzinationsprobleme bis hin zu operativen Kosten. Abschnitt VI befasst sich mit Evaluierung und Benchmarking, bevor Abschnitt VII die Ergebnisse zusammenfasst und einen Ausblick auf zukünftige Forschungsrichtungen gibt.
II. Datengrundlage und Observability
Dieser Abschnitt behandelt die Datengrundlage des AIOps-Frameworks – die Sensing-Ebene, ohne deren zuverlässige Implementierung keine intelligente Automatisierung möglich ist.
A. Die drei Säulen der Observability
Eine umfassende Observability bildet das Fundament jeder AIOps-Plattform. Sie ermöglicht es, den internen Zustand eines komplexen, verteilten Systems anhand seiner externen Ausgaben zu erschließen und zu bewerten [1]. In der Industrie wird häufig das Akronym MELT (Metrics, Events, Logs, Traces) verwendet; in der wissenschaftlichen Literatur hat sich hingegen eine Systematisierung in drei primäre, systemgenerierte Telemetriedatentypen etabliert: Metriken, Logs und Traces [3], [6], [7]. Events werden dabei in der Regel als Teilmenge der Logs betrachtet.
1) Metriken
Metriken sind numerische Zeitreihendaten, die in regelmäßigen Intervallen erhoben werden, um den quantitativen Zustand von Systemressourcen und Anwendungen zu erfassen. Cheng et al. [3] unterscheiden zwischen Compute-Metriken (z. B. CPU-Auslastung, Speicherverbrauch, Festplatten-I/O) und Service-Metriken (z. B. Antwortzeit, Durchsatz, Fehlerrate), während Zhang et al. [6] sie allgemeiner als quantitative Messwerte definieren, die den Ressourcenverbrauch und die Dienstgüte widerspiegeln.
Der Hauptvorteil von Metriken liegt in ihrer strukturierten Natur und der Effizienz, mit der sie gespeichert, komprimiert und abgefragt werden können. Dies macht sie besonders geeignet für das Echtzeit-Monitoring von Trends und das Auslösen von Alarmen bei Schwellwertüberschreitungen. Allerdings leiden Metriken in modernen Cloud-Umgebungen häufig unter hoher Dimensionalität und Rauschen, was die Identifikation relevanter Signale erschwert [6]. Zudem fehlt ihnen typischerweise der semantische Kontext, um die Ursache eines Problems zu erklären. Sie zeigen an, dass ein Problem existiert, jedoch selten warum.
2) Logs
Logs sind detaillierte, textbasierte Aufzeichnungen diskreter Ereignisse, die von Anwendungen, Betriebssystemen oder Netzwerkgeräten generiert werden. Im Gegensatz zu Metriken sind sie reich an semantischen Informationen und enthalten häufig spezifische Fehlermeldungen, Stack Traces oder Transaktions-IDs, die für die Fehlerdiagnose unerlässlich sind. Cheng et al. [3] beschreiben den typischen Analyseworkflow als dreistufigen Prozess aus Log Collection, Log Parsing und Log Mining.
Die zentrale Herausforderung bei der Verarbeitung von Logs ist ihr semi-strukturierter Charakter – jede Nachricht besteht aus einem statischen Template und dynamischen Parametern [3] – sowie das enorme Volumen, das in großen Systemen täglich erzeugt wird. Zhang et al. [6] betonen, dass Logs aufgrund ihres textuellen Charakters die natürlichste und zugleich wichtigste Datenquelle für LLM-basierte AIOps-Ansätze darstellen, da Sprachmodelle hier ihre Stärken in der Interpretation natürlicher Sprache und Programmcode voll entfalten können.
3) Traces
Distributed Tracing ermöglicht die Verfolgung einer einzelnen Anfrage über die gesamte Kette der involvierten Microservices hinweg. Ein Trace besteht aus mehreren Spans, wobei jeder Span den Namen, den Zeitstempel, die Dauer und Metadaten einer bestimmten Operation innerhalb eines Services repräsentiert [3]. In der Praxis kommen hierfür Open-Source-Frameworks wie Jaeger zum Einsatz [1].
Traces sind essentiell, um Latenz-Engpässe und Fehler in komplexen, lose gekoppelten Architekturen zu lokalisieren. Sie visualisieren den kausalen Pfad einer Transaktion und ermöglichen die Rekonstruktion von Abhängigkeiten zwischen Komponenten. Eine zentrale Herausforderung liegt im Sampling: Da das Speichern sämtlicher Traces unverhältnismäßig teuer wäre, werden in der Praxis häufig nur Stichproben oder gezielt Fehler-Traces persistiert, was dazu führen kann, dass sporadische Probleme unerkannt bleiben [3].
B. Weitere Datenquellen und Integration
Neben den drei Kernsäulen integrieren moderne AIOps-Systeme zunehmend weitere Datenquellen, um ein ganzheitliches Bild des Systemzustands zu erlangen.
Eine besondere Rolle spielen hierbei menschengenerierte Daten (Human-generated Data). Zhang et al. [6] systematisieren diese in vier Kategorien: Software Information (Quellcode, Konfigurationsdateien), QA-Paare aus internen Knowledge Bases oder Plattformen wie StackOverflow, Incident Reports aus Ticketsystemen wie Jira sowie technische Dokumentationen und Wikis. Diese Daten enthalten wertvolles Kontextwissen und historische Erfahrungswerte, die in reinen Telemetriedaten fehlen. LLMs sind besonders geeignet, dieses unstrukturierte Wissen mittels Retrieval-Augmented Generation (RAG) zu erschließen und bei der Diagnose neuer Fehler zu nutzen [8], [9].
Ein weiterer Trend ist die multimodale Datenfusion. Da Metriken, Logs und Traces häufig in isolierten Silos gespeichert werden, fällt es traditionellen Algorithmen schwer, Korrelationen über Datentypen hinweg zu erkennen [3], [10]. Neuere Ansätze zielen darauf ab, diese heterogenen Modalitäten in einen gemeinsamen Vektorraum (Embedding Space) zu projizieren. Dies ermöglicht es beispielsweise, einen Log-Eintrag direkt mit einem gleichzeitigen Anstieg einer Metrik in Beziehung zu setzen oder durch die Analyse von Traces den relevanten Suchraum für die Log-Analyse einzuschränken.
C. Datenvorverarbeitung im LLM-Zeitalter
Der Einsatz von Large Language Models transformiert nicht nur die Analyse, sondern auch die Vorverarbeitung (Preprocessing) von Betriebsdaten grundlegend.
Log Parsing: Traditionelle Log-Parsing-Methoden wie Drain oder Spell, die Cheng et al. [3] als die am weitesten verbreiteten und industriell skalierbarsten Verfahren identifizieren, basieren auf festen Regeln oder Clustering-Algorithmen, um den konstanten Teil einer Log-Nachricht (das Template) von den variablen Parametern zu separieren. Diese Ansätze stoßen jedoch an ihre Grenzen, wenn sich Log-Formate ändern oder neue, unbekannte Log-Typen auftreten. LLM-basierte Ansätze adressieren dieses Problem auf unterschiedliche Weise: LILAC nutzt einen adaptiven Parsing-Cache mit In-Context Learning (ICL), LLMParser evaluiert ICL und Few-Shot-Tuning auf Modellen wie Flan-T5 und LLaMA-7B, während DivLog einen RAG-basierten Ansatz verfolgt [6]. Diese Verfahren zeigen eine höhere Flexibilität und Genauigkeit, insbesondere im Zero-Shot-Setting, erfordern jedoch mehr Rechenressourcen.
Metric Imputation: In realen Monitoring-Systemen kommt es häufig zu Lücken in den Daten, etwa durch Netzwerkausfälle oder Neustarts von Monitoring-Agenten. Um die Qualität der nachgelagerten Anomalieerkennung zu gewährleisten, müssen diese fehlenden Werte plausibel rekonstruiert werden (Imputation). Während früher einfache statistische Methoden (z. B. lineare Interpolation) eingesetzt wurden, ermöglichen generative Modelle heute eine kontextabhängige Rekonstruktion. GatGPT kombiniert hierzu Graph-Attention-Netzwerke mit LLMs für die Metriken-Imputation, während CRILM LLM-generierte kontextuelle Deskriptoren zur Charakterisierung und Auffüllung fehlender Werte einsetzt [6].
III. Kernaufgaben des AIOps-Zyklus
Die operative Phase des IT-Betriebs lässt sich entlang des Incident-Lifecycles in drei aufeinander aufbauende Kernaufgaben gliedern. Diese entsprechen den in Abschnitt II beschriebenen Phasen Detect, Engage und Act [3]. Zunächst muss eine Anomalie überhaupt erkannt werden (Failure Perception), anschließend ist deren Ursache zu lokalisieren (Root Cause Analysis), bevor schließlich eine korrigierende Maßnahme eingeleitet werden kann (Auto-Remediation). Jede dieser Phasen wird durch eigene Metriken bewertet – die Mean Time to Detect (MTTD), Mean Time to Triage (MTTT) und Mean Time to Resolve (MTTR) – und bietet spezifische Ansatzpunkte für KI-gestützte Automatisierung. Dieser Abschnitt behandelt die drei Kernaufgaben systematisch und beleuchtet die jeweils eingesetzten Methoden, deren Leistungsfähigkeit sowie die zentralen Herausforderungen.
A. Failure Perception
Failure Perception umfasst die Erkennung anomaler Systemzustände anhand von Telemetriedaten und bildet den Ausgangspunkt jeder Incident-Response-Kette. Das Ziel ist die Minimierung der MTTD bei gleichzeitiger Reduktion von Fehlalarmen (False Positives), die als Alert Fatigue die Produktivität der Operations-Teams deutlich beeinträchtigen können [1], [3].
1) Anomalieerkennung auf Metriken
Die einfachste Form der Anomalieerkennung auf Metriken ist die regelbasierte Methode, bei der ein Alarm ausgelöst wird, wenn eine Metrik einen festgelegten Schwellwert überschreitet. Solche Ansätze sind jedoch zu unflexibel für komplexe Systeme: Ein zu niedriger Schwellwert erzeugt viele Fehlalarme, ein zu hoher führt dazu, dass echte Anomalien übersehen werden [3], [11]. Da Metriken als Time-Series-Daten vorliegen, wird die Anomalieerkennung typischerweise als Time Series Anomaly Detection bezeichnet.
Cheng et al. [3] systematisieren die Methoden anhand mehrerer Aspekte: Hinsichtlich des Lernparadigmas werden überwachte, unüberwachte und semi-überwachte Ansätze unterschieden, wobei unüberwachte Verfahren aufgrund des chronischen Mangels an gelabelten Anomaliedaten in der Praxis dominieren. Innerhalb der autonomen Methoden differenzieren die Autoren zwischen dichtebasierten Verfahren, die lokale Dichteschätzungen zur Erkennung von Ausreißern nutzen, Clustering-basierten Ansätzen, die Anomalien als Distanz zum Clusterzentrum quantifizieren, sowie rekonstruktionsbasierten Methoden, die den generativen Prozess der Daten nachbilden und den Rekonstruktionsfehler als Anomalie-Score verwenden. Hinsichtlich der Dimensionalität ist zu unterscheiden, ob univariate Zeitreihen (einzelne Metriken) oder multivariate Zeitreihen (Gruppen korrelierter Metriken) analysiert werden. Multivariate Ansätze sind in modernen Microservice-Umgebungen essenziell, da sie die Zusammenhänge zwischen verschiedenen Metriken eines Systems modellieren können, die bei einer isolierten Betrachtung einzelner Zeitreihen verloren gehen [3].
Hinsichtlich der eingesetzten Modellarchitekturen reicht das Spektrum von statistischen Methoden über baumbasierte Verfahren bis hin zu Deep-Learning-Modellen. Insbesondere rekurrente neuronale Netze (LSTMs), Variational Autoencoders (VAEs) und Transformer-Architekturen haben sich als leistungsfähig erwiesen [3]. Einen aktuellen Fortschritt markiert STMformer, ein Transformer-basiertes Modell, das speziell für die Zustandsvorhersage in Microservice-Umgebungen entwickelt wurde. STMformer nutzt dynamische Netzwerkverbindungsdaten und topologische Informationen, um die komplexen räumlich-zeitlichen Abhängigkeiten innerhalb verteilter Systeme nachzubilden, und integriert ein PatchCrossAttention-Modul, das die Auswirkungen kaskadierender Effekte global erfasst. In Evaluierungen erzielte STMformer eine Reduktion des Mean Absolute Error um 8,6 % und des Mean Squared Error um 2,2 % gegenüber führenden Vergleichsmethoden sowohl bei Kurzzeit- als auch bei Langzeitprognosen [12].
2) Anomalieerkennung auf Logs und Traces
Neben der metrischen Anomalieerkennung spielen Log- und Trace-basierte Verfahren eine ergänzende Rolle. Für die Log-basierte Anomalieerkennung hat sich ein mehrstufiger Workflow aus Log Parsing, Log Partitioning, Log Representation und der eigentlichen Anomalieerkennung etabliert [3]. Neuronale Modelle – darunter LSTM-basierte Sequenzmodelle wie DeepLog, Autoencoder und Transformer-basierte Sprachmodelle wie LogBERT – haben dabei klassische statistische Verfahren zunehmend abgelöst, da sie die semantische Bedeutung von Log-Einträgen besser erfassen und auch unbekannte Anomaliemuster erkennen können.
Trace-basierte Anomalieerkennung nutzt die topologische Struktur der Service-Graphen, um anomale Pfade in verteilten Systemen zu identifizieren. Durch die Kombination von Trace-Daten mit anderen Datenquellen (Metriken, Logs) in multimodalen Deep-Learning-Ansätzen – etwa durch Graph Neural Networks (GNNs) wie in DeepTraLog – können sowohl die Erkennungsgenauigkeit als auch die Lokalisierungsfähigkeit signifikant verbessert werden [3].
3) Herausforderungen
Die praktische Anomalieerkennung steht vor mehreren grundlegenden Herausforderungen. Erstens erschwert der Mangel an gelabelten Daten das Training und insbesondere die Evaluation von Erkennungsmodellen erheblich. Die Kennzeichnung von Anomalien erfordert tiefgreifendes Domänenwissen und ist extrem zeitaufwändig [3]. Zweitens stellt die Nichtstationarität (Concept Drift) realer Daten ein zentrales Problem dar: Zeitmuster von Metriken ändern sich kontinuierlich durch Softwareänderungen, saisonale Effekte oder Wachstumstrends, sodass ein einmal trainiertes Modell ohne regelmäßige Aktualisierung an Genauigkeit verliert [13], [14]. Poenaru-Olaru et al. [13] zeigen, dass driftbasiertes Retraining – bei dem das Modell nur bei erkannten Datenveränderungen neu trainiert wird – in vielen Fällen eine vergleichbare Genauigkeit wie periodisches Retraining erzielt und somit eine kosteneffiziente Lösung darstellt. Drittens müssen Erkennungssysteme zwischen echten, intrinsischen Anomalien und harmlosen, durch externe Faktoren verursachten Abweichungen (z. B. ein Anstieg der CPU-Auslastung als Folge eines geplanten Auto-Scaling-Vorgangs) unterscheiden können – eine Differenzierung, die in der Literatur als intrinsische vs. extrinsische Anomalieerkennung debattiert wird [3].
B. Root Cause Analysis (RCA)
Während die Failure Perception identifiziert, dass ein Problem existiert, zielt die Root Cause Analysis (RCA) darauf ab, die Ursache des Problems zu lokalisieren. RCA trägt zur Verringerung der MTTT und MTTR bei und stellt in komplexen Microservice-Architekturen mit hunderten voneinander abhängiger Dienste eine der anspruchsvollsten Aufgaben im AIOps-Zyklus dar [3], [10].
1) Topologie-Mapping und Graphenanalyse
In modernen Cloud-nativen Systemen sind die Abhängigkeiten zwischen Komponenten (Services, Pods, Nodes) hochgradig dynamisch und komplex. Eine zentrale Voraussetzung für die RCA ist daher die Rekonstruktion der Systemtopologie als Graph, der die funktionalen Beziehungen zwischen den Komponenten abbildet. Cheng et al. [3] unterscheiden zwei grundlegende Ansätze: Erstens können Topologiegraphen aus vorhandenem Domänenwissen wie Service-Graphen und Call-Graphen rekonstruiert werden. Zweitens können Kausalitätsgraphen automatisch aus den beobachteten Metriken mittels kausaler Entdeckungsmethoden abgeleitet werden. Der prominenteste Algorithmus hierfür ist der PC-Algorithmus (Peter-Clark-Algorithmus), der ausgehend von einem vollständig verbundenen ungerichteten Graphen Kanten durch bedingte Unabhängigkeitstests ausgeschlossen und anschließend die Kantenorientierungen durch die Identifikation von V-Strukturen bestimmt [3].
Auf dem konstruierten Graphen können verschiedene analytische Verfahren angewendet werden, um die Grundursache zu identifizieren. Random-Walk-basierte Methoden starten von einem anomalen Knoten und durchlaufen den Graphen, wobei die am häufigsten besuchten Knoten als wahrscheinlichste Ursachen gelten. Die Übergangswahrscheinlichkeiten werden dabei typischerweise auf Basis der Korrelation jeder Metrik mit den erkannten anomalen Metriken berechnet [3]. Alternative Verfahren nutzen PageRank-Varianten oder Breitensuche-Algorithmen zur kausalen Pfadanalyse.
2) Multimodale Fehlerdiagnose
Eine Einschränkung, die in unimodalen RCA-Ansätzen immer vorhanden ist, besteht darin, dass sie jeweils nur eine Perspektive des Systemzustands erfassen. Hou [10] identifiziert hierzu drei zentrale Defizite: Metrikbasierte Analyse verwechselt häufig Korrelation mit Kausalität, Log-Analyse ist durch die Qualität des Template-Minings limitiert, und Trace-Analyse leidet unter Sampling-Sparseness in Szenarien mit hoher Last. Um diese Defizite zu adressieren, verfolgen neuere Ansätze eine multimodale Fusion der drei Observability-Säulen.
Das von Hou [10] vorgeschlagene KylinRCA-Framework kombiniert dynamische kausale Entdeckung mit cross-modaler Graphanalyse. Es vereint die Vorteile zweier Forschungsstränge: Erstens die dynamische kausale Entdeckung, die mittels Temporal Causal Networks (TCN) und temporalen Perturbationsexperimenten kausale Beziehungen zwischen Metriken aufdeckt, und zweitens die multimodale Cross-Level-Fusion, die heterogene Daten (Metriken, Logs, Traces) über hierarchische Ebenen hinweg (Host–Pod–Service) in einem gemeinsamen Embedding-Raum verarbeitet. In Evaluierungen auf Industriedaten erzielte KylinRCA einen Entity-Lokalisierungs-F1-Score von 92,3 % und eine Causal-Chain-Accuracy von 88,1 %, was signifikante Verbesserungen gegenüber unimodalen Baselines darstellt [10].
3) LLM-gestützte RCA
Der Einsatz von Large Language Models eröffnet neue Möglichkeiten für die RCA, insbesondere bei der Interpretation komplexer Fehlerbilder und der Generierung verständlicher Diagnoseberichte. Goel et al. [15] präsentieren mit eARCO (Efficient Automated Root Cause Analysis) einen Ansatz, der Prompt-Optimierung mit historischen Incident-Daten kombiniert. Unter Nutzung von über 180.000 historischen Incidents von Microsoft werden kosteneffiziente, feinabgestimmte Small Language Models (SLMs) für die RCA-Empfehlungsgenerierung eingesetzt. Die Autoren zeigen, dass Prompt-Optimierung die Genauigkeit der RCA-Empfehlungen um 21 % gegenüber RAG-basierten LLMs und um 13 % gegenüber feinabgestimmten SLMs verbessert [15]. Ein weiterer vielversprechender Ansatz ist das Incident Triage, bei dem ML-Systeme Incidents automatisch dem verantwortlichen Team zuweisen. DeepTriage von Microsoft Azure kombiniert Gradient-Boosted-Classifier, Clustering-Methoden und Deep Neural Networks in einem Verbund und erreicht einen F1-Score von 82,9 %, wobei für besonders kritische Incidents Werte von bis zu 91,3 % erzielt werden [16].
Laut Zhang et al. [6] sind LLMs durch ihre Fähigkeiten im In-Context Learning und Chain-of-Thought Reasoning besonders geeignet, unstrukturierte Daten wie Logs, Incident Reports und technische Dokumentationen in den RCA-Prozess zu integrieren – Datenquellen, die traditionellen ML-Modellen weitgehend unzugänglich waren.
C. Auto-Remediation
Auto-Remediation, die finale Phase des Incident-Lifecycles, beschäftigt sich mit der Frage, wie ein erkanntes und diagnostiziertes Problem behoben werden kann. Ziel ist die Minimierung der MTTR bis hin zu einer vollständig autonomen Fehlerbehebung ohne menschliche Intervention [3].
1) Ebenen der Autonomie
Die Automatisierung der Remediation lässt sich entlang des in Abschnitt I beschriebenen AIOps-Reifegradmodells einordnen [3]. Auf der Stufe Human-Centric AIOps fungieren KI-Systeme als Empfehlungssysteme: Sie schlagen Remediation-Maßnahmen vor, die ein menschlicher Operator prüft und freigibt. Typische Aktionen umfassen den Neustart fehlerhafter Pods, das Draining von unhealthy Nodes oder das Rollback eines Deployments auf eine stabile Version [11]. Auf der Stufe Machine-Centric AIOps übernehmen KI-Agenten die Ausführung routinemäßiger Remediation-Aktionen autonom, während Menschen in einer Human-in-the-Loop-Rolle nur bei schwerwiegenden oder neuartigen Fehlern eingreifen. Auf der höchsten Stufe, Fully-Automated AIOps, operiert die Plattform vollständig autonom und erweitert die CI/CD-Pipeline um Continuous Monitoring und Continuous Correction (CI/CD/CM/CC) [3].
2) Methoden und Technologien
Traditionelle Auto-Remediation basiert auf vordefinierten Policies und Regeln, die für bekannte Fehlerkategorien feste Workflows spezifizieren. ML-basierte Ansätze erweitern dieses Konzept, indem sie aus historischen Incidents und deren Lösungen lernen, um die optimale Remediation-Strategie dynamisch zu bestimmen [3]. Ein prominentes Beispiel ist Narya, ein von Microsoft entwickeltes System zur Failure-Remediation für virtuelle Maschinen in Cloud-Umgebungen. Narya nutzt A/B-Testing und Reinforcement Learning, um unter verschiedenen Optionen (Live-Migration, Soft-Reboot, Service-Healing) die optimale Aktion auszuwählen, und erzielte signifikante Einsparungen bei VM-Ausfällen gegenüber statischen Methoden [3].
Bellala [11] beschreibt ein umfassendes Framework für Self-Healing Kubernetes-Ökosysteme, das AIOps-Prinzipien auf die gesamte Kubernetes-Management-Kette anwendet. Das Framework implementiert einen geschlossenen Observation-Action-Zyklus: Eine Observability-Plattform erfasst Metriken, Logs und Traces, ein AIOps-Engine analysiert die Daten mittels ML-basierter Anomalieerkennung und RCA, und eine Aktionsschicht führt die Remediation sicher über Kubernetes-Operatoren aus. Zentral ist dabei das Operator-Pattern: Anstatt imperative Befehle via kubectl auszuführen, deklariert die AIOps-Engine den gewünschten Zielzustand als Custom Resource, die ein dedizierter Remediation-Operator überwacht und kontrolliert umsetzt [11].
Im Kontext generativer KI ermöglicht der Einsatz von LLMs zudem die automatische Generierung von Reparaturskripten, bspw. Ansible Playbooks, Kubernetes-Manifest-Patches oder Shell-Kommandos, die auf den spezifischen Fehlerkontext zugeschnitten sind. Chen et al. [2] verfolgen mit dem Konzept AgentOps die Vision, dass LLM-basierte Agenten den gesamten Incident-Lifecycle – von der Erkennung über die Diagnose bis zur Mitigation – autonom verwalten. Ein zentrales Forschungsproblem bleibt jedoch die Sicherheit solcher autonomen Aktionen: Die Gewährleistung, dass KI-generierte Remediation-Maßnahmen keine unbeabsichtigten Nebeneffekte verursachen, erfordert robuste Validierungsmechanismen und stufenweise Freigabeprozesse, die in Abschnitt V vertieft diskutiert werden.
IV. GenAI und Agentic AIOps
Die in Abschnitt III beschriebenen Kernaufgaben werden traditionell durch spezialisierte ML-Modelle bearbeitet. Mit dem Einsatz generativer KI, insbesondere Large Language Models (LLMs) und darauf aufbauender autonomer Agenten, zeichnet sich jedoch ein Paradigmenwechsel im AIOps-Bereich ab. Im Folgenden werden die Rolle von LLMs als kognitive Engine, die Architektur agentenbasierter Systeme und die Standardisierung der Schnittstellen zwischen Agenten und Cloud-Infrastruktur behandelt.
A. LLMs als kognitive Engine
Die Transformer-Architektur [17] bildet das Fundament moderner LLMs und hat durch ihren Self-Attention-Mechanismus die Verarbeitung langer Kontextfenster und komplexer Abhängigkeiten grundlegend verbessert. Für AIOps sind dabei vor allem drei Fähigkeiten relevant, die LLMs von klassischen ML-Ansätzen unterscheiden: In-Context Learning (ICL) erlaubt es, aus wenigen im Prompt bereitgestellten Beispielen zu lernen, ohne erneutes Training; Chain-of-Thought (CoT) Reasoning ermöglicht mehrstufiges logisches Schlussfolgern; und die Verarbeitung natürlicher Sprache gestattet die direkte Interpretation unstrukturierter Daten wie Logs, Incident Reports und technischer Dokumentationen [5], [6].
1) LLM-Nutzungsstrategien
Zhang et al. [6] unterscheiden vier Hauptkategorien der LLM-Anwendung in AIOps. Prompting umfasst die Techniken Zero-Shot und Few-Shot, bei denen das Modell ohne bzw. mit wenigen Beispielen im Prompt Aufgaben löst. Goel et al. [15] demonstrieren mit eARCO, dass automatisierte Prompt-Optimierung die Genauigkeit von RCA-Empfehlungen um 21 % gegenüber RAG-basierten Ansätzen steigern kann, indem das System selbstständig optimale Instruktionen und semantisch ähnliche historische Beispiele für die Inferenz identifiziert. Fine-Tuning bezeichnet die Anpassung vortrainierter Modelle an domänenspezifische AIOps-Daten, wobei zwischen dem ressourcenintensiven vollständigen Fine-Tuning und parametereffizienten Methoden wie LoRA (Low-Rank Adaptation) und QLoRA unterschieden wird. Hybride Ansätze kombinieren Prompting und Fine-Tuning, etwa durch den Einsatz feinabgestimmter Small Language Models (SLMs) mit optimierten Prompts, wie in eARCO gezeigt [15]. Schließlich kommen agentenbasierte Methoden zum Einsatz, bei denen LLMs als zentrale Reasoning-Komponente in autonome Systeme integriert werden, die über Tool-Aufrufe mit ihrer Umgebung interagieren, ein Ansatz, der in Abschnitt IV-B vertieft wird.
2) Retrieval-Augmented Generation (RAG)
Um Halluzinationen zu reduzieren und das Modell mit aktuellem, domänenspezifischem Kontext anzureichern, hat sich Retrieval-Augmented Generation (RAG) als wirksame Technik etabliert. Vor der eigentlichen LLM-Inferenz wird dabei eine Retrievalphase eingeschoben, in der relevante Dokumente aus einer Wissensdatenbank – etwa historische Incident Reports, Runbooks, technische Dokumentationen oder QA-Paare aus internen Knowledge Bases – abgerufen und dem Prompt als Kontext hinzugefügt werden [8], [9].
Im AIOps-Kontext hat RAG besondere Relevanz, weil es das allgemeine Wissen eines LLMs mit dem spezifischen Wissen einer Organisation verknüpft. Zhang et al. [6] identifizieren RAG-basierte Ansätze in zahlreichen AIOps-Teilaufgaben, darunter Log Parsing (DivLog), Anomalieerkennung und Root Cause Analysis. Vitui und Chen [8] demonstrieren den Einsatz von RAG zur Erschließung von Plattformdokumentation in einer Red Hat OpenShift-Umgebung: Ein LLM-Agent kann über eine spezialisierte Vektordatenbank Installationsprozeduren und Konfigurationsanleitungen abrufen und kontextbezogen zusammenfassen, was den Engineer von aufwändiger manueller Dokumentationsrecherche entlastet.
B. Agenten-Architekturen
Mit dem Übergang von statischen LLM-Inferenzen zu interaktiven, werkzeuggestützten Agenten zeichnet sich die nächste Entwicklungsstufe im AIOps-Bereich ab. Ein isoliertes LLM bleibt auf die Informationen im Prompt beschränkt; ein LLM-basierter Agent hingegen kann aktiv mit seiner Umgebung interagieren, indem er Hypothesen formuliert, diagnostische Aktionen ausführt, deren Ergebnisse beobachtet und seine Schlussfolgerungen iterativ verfeinert [1], [2].
1) Das ReAct-Framework
Das von Yao et al. [18] eingeführte ReAct-Framework (Reasoning and Acting) liegt vielen AIOps-Agenten konzeptionell zugrunde. Es verbindet die Reasoning-Fähigkeiten von LLMs, insbesondere Chain-of-Thought-Prompting, mit der Möglichkeit, externe Werkzeuge aufzurufen und deren Ergebnisse in den Schlussfolgerungsprozess einzubeziehen. Der Agent operiert in einem iterativen Thought-Action-Observation-Zyklus: Er formuliert eine Überlegung (Thought), führt eine Aktion aus (Action), etwa den Aufruf einer API oder die Ausführung eines Shell-Befehls, und verarbeitet die resultierende Beobachtung (Observation), um den nächsten Schritt zu planen.
Konkret kann ein ReAct-Agent in der AIOps-Praxis etwa zunächst Logs eines fehlerhaften Services abrufen (get_logs), aus den Log-Einträgen eine Hypothese über die Fehlerursache ableiten, diese durch Abfrage von Metriken (get_metrics) oder Traces (get_traces) verifizieren und schließlich eine korrigierende Aktion wie das Patchen einer Kubernetes-Konfiguration via kubectl ausführen [1]. Shetty et al. [1] demonstrieren in einer Fallstudie, dass ein ReAct-Agent mit GPT-4-Backend eine Kubernetes-Fehlkonfiguration in 14 Sekunden erkennen und in 36 Sekunden mitigieren konnte, wobei durchschnittlich 10–12 Interaktionsrunden und Kosten von etwa 0,25 USD anfielen.
2) AgentOps und Multi-Agenten-Systeme
Chen et al. [2] prägen den Begriff AgentOps (Agent for Operations), um ein Paradigma zu beschreiben, in dem LLM-basierte Agenten nicht auf isolierte Aufgaben beschränkt sind, sondern den gesamten Incident-Lifecycle – Erkennung, Lokalisierung, Ursachenanalyse und Mitigation – autonom und Ende-zu-Ende verwalten. Gegenüber herkömmlichen AIOps-Ansätzen, die jeweils nur einzelne Phasen abdecken, bedeutet dies eine qualitative Weiterentwicklung.
Neben einfachen Single-Agent-Architekturen setzen neuere Arbeiten auf Multi-Agenten-Systeme, in denen spezialisierte Agenten kooperieren. Das FLASH-Framework implementiert ein Workflow-Automatisierungssystem, das komplexe Instruktionen in handhabbare, bedingte Segmente zerlegt und Hindsight Generation nutzt, um aus vergangenen Interaktionen zu lernen [2]. In der Evaluierung mit dem AIOpsLab-Benchmark erzielte FLASH mit 59,32 % die höchste Gesamtgenauigkeit unter vier getesteten Agenten, wobei es bei Mitigationsaufgaben 54,55 % erreichte, verglichen mit 36,36 % für ReAct und 27,27 % für einen reinen GPT-4-Agenten mit Shell-Zugang [2].
Vitui und Chen [8] evaluieren ReAct-basierte Agenten auf einer Red Hat OpenShift-Plattform mit neun integrierten Werkzeugen, darunter RAG-basierte Dokumentationssuche, Prometheus-Metrikabfrage und ML-basierte Kapazitätsplanung. Die Ergebnisse belegen deutliche Leistungsunterschiede zwischen den LLM-Familien: GPT-4o erzielt 100 % Genauigkeit bei komplexen Multi-Tool-Aufgaben (Advanced Reasoning), während kleinere Modelle wie GPT-3.5 Turbo an der korrekten Verkettung mehrerer Werkzeuge scheitern. Claude 3.5 Sonnet erreicht 95 % bei einfachen Aufgaben, zeigt jedoch bei komplexen Szenarien gelegentlich eine fehlerhafte Werkzeug-Reihenfolge [8].
3) Herausforderungen agentenbasierter Systeme
Die Evaluierung in AIOpsLab legt mehrere Schwächen heutiger LLM-Agenten offen [2]. So verschwenden Agenten häufig Interaktionsschritte durch unnötige Aktionen, etwa wiederholte API-Aufrufe mit identischen Parametern oder die Generierung nicht existierender APIs. Hinzu kommt die Informationsüberflutung durch umfangreiche Telemetriedaten und die damit verbundene Verschwendung des Kontextfensters: Agenten, die Metriken oder Traces undifferenziert aufnehmen, erschöpfen ihr Token-Budget ohne Gewinn. Ein weiteres Problem ist das Stagnieren der Selbstkorrektur. Im Gegensatz zu Coding-Agenten, die von Linter- und Test-Feedback profitieren, verbessert sich die Genauigkeit von AIOps-Agenten ab einer bestimmten Anzahl von Schritten nicht mehr, was auf den Bedarf an besserer Aufgabendekomposition und verbesserten Feedback-Mechanismen hinweist [2].
C. Das Agent-Cloud-Interface (ACI)
Die bisherige Forschung zu AIOps-Agenten zeigt, dass neben der Leistungsfähigkeit des zugrunde liegenden LLMs vor allem die Qualität der Schnittstelle zwischen Agent und Cloud-Umgebung die Effektivität des Gesamtsystems bestimmt [1].
1) Designprinzipien
Traditionelle Cloud-Interfaces wie Dashboards, CLI-Tools, Incident-Portale sind für menschliche Operatoren konzipiert und erweisen sich für LLM-basierte Agenten als problematisch. Während Menschen irrelevante Informationen zuverlässig ignorieren können, werden Agenten durch überflüssigen Kontext abgelenkt, was ihre Leistung beeinträchtigt [1]. Inspiriert vom Konzept des Agent-Computer-Interface aus der Softwareentwicklung formulieren Shetty et al. [1] das Agent-Cloud-Interface (ACI) als Orchestrator zwischen Agent und Cloud. Das ACI spezifiziert zwei Dimensionen: (1) den Aktionsraum, also die Menge der verfügbaren, dokumentierten APIs (z. B. get_logs, get_metrics, get_traces, exec_shell), und (2) die Zustandsrückmeldung, also wie der aktuelle Systemzustand nach jeder Aktion an den Agenten kommuniziert wird, einschließlich strukturierter Ausgaben, Fehlermeldungen und Tracebacks.
Chen et al. [2] implementieren dieses Konzept in AIOpsLab als sessionbasiertes System, in dem ein Orchestrator die Interaktion zwischen Agent und Microservice-Umgebung verwaltet. Der Orchestrator injiziert Probleme mittels Chaos Engineering, stellt dem Agenten Problembeschreibungen und API-Dokumentation bereit und evaluiert die Lösungen anhand vordefinierter Metriken wie Time-to-Detect und Time-to-Mitigate. Die Evaluierung zeigt, dass die Effizienz der verfügbaren Aktionen direkt die Agentenleistung beeinflusst: Zu wenige APIs schränken die Erkennung ein, während zu viele Argumente pro API die Leistung beeinträchtigen [1].
2) Deterministische Übersetzungsschichten
Das ACI-Konzept definiert den Interaktionsrahmen auf konzeptioneller Ebene. Auf der technischen Seite adressiert MCP-Diag von Lodha et al. [19] zwei konkrete Implementierungsbarrieren: das Stochastic Grounding Problem und die Security Gap. Das Stochastic Grounding Problem entsteht, weil CLI-Werkzeuge wie ping, traceroute oder dig unstrukturierte, herstellerspezifische Textausgaben erzeugen, deren probabilistisches Parsing durch ein LLM fehleranfällig ist. Die Security Gap ergibt sich aus dem Risiko, autonomen Agenten direkten Shell-Zugang zu gewähren, wodurch Prompt-Injection-Angriffe oder die unbeabsichtigte Ausführung destruktiver Befehle möglich werden.
MCP-Diag begegnet diesen Problemen mit einer hybriden Architektur auf Basis des Model Context Protocol (MCP). Eine deterministische Übersetzungsschicht konvertiert rohe CLI-Ausgaben serverseitig in typsichere JSON-Schemata, bevor sie dem LLM zur Verfügung gestellt werden. Das Modell interagiert somit ausschließlich mit strukturierten Datenobjekten, nicht mit unstrukturiertem Text. Ferner implementiert MCP-Diag einen obligatorischen Elicitation Loop, der die Ausführung jeder sicherheitskritischen Operation an eine explizite Freigabe durch einen menschlichen Operator auf Protokollebene bindet – ein Human-in-the-Loop-Mechanismus, der im Gegensatz zu einfach umgehbaren System-Prompts nicht durch Prompt Injection kompromittiert werden kann [19]. In einer Evaluierung über 500 Trials erzielte MCP-Diag 100 % Entity-Extraction-Genauigkeit bei einem Latenz-Overhead von weniger als 0,9 %, bei einem Anstieg der Kontext-Token-Nutzung um den Faktor 3,7 gegenüber einer unstrukturierten Baseline [19].
V. Herausforderungen und Risiken
Die in den vorangegangenen Abschnitten vorgestellten KI-Methoden, von spezialisierten ML-Modellen für die Anomalieerkennung bis hin zu LLM-basierten Agenten für die autonome Fehlerbehebung, versprechen erhebliche Effizienzgewinne im IT-Betrieb. Zugleich bringen sie jedoch neue Risiken mit sich, die bei einer unreflektierten Einführung die Zuverlässigkeit und Sicherheit der verwalteten Systeme gefährden können. Die zentralen Herausforderungen lassen sich in drei Bereiche gliedern: Sicherheitsrisiken durch die Manipulation von Eingabedaten, Vertrauensprobleme durch Halluzinationen und Automation Bias sowie operative Hürden bei Kosten, Modellpflege und der Einführung in Organisationen.
A. Sicherheit und Telemetrie-Manipulation
AIOps-Agenten treffen ihre Entscheidungen auf Grundlage von Telemetriedaten (Logs, Metriken und Traces), die bislang implizit als vertrauenswürdig angenommen wurden. Pasquini et al. [20] stellen diese Annahme grundlegend in Frage und präsentieren mit AIOpsDoom die erste systematische Sicherheitsanalyse von AIOps-Systemen. Die Autoren zeigen, dass Angreifer ohne privilegierten Zugang und ohne Kenntnis der internen Systemarchitektur Telemetriedaten gezielt manipulieren können, um AIOps-Agenten zu schädlichen Remediation-Aktionen zu verleiten.
Der Angriff basiert auf der Telemetry Injection: Durch das gezielte Auslösen von Fehlerereignissen über öffentliche Schnittstellen, etwa durch HTTP-Anfragen an nicht existierende Ressourcen oder mit manipulierten Header-Feldern wie User-Agent oder Referer, werden adversarielle Payloads in die Log-Daten des Zielsystems eingeschleust. AIOpsDoom automatisiert diesen Prozess durch einen Crawling- und Fuzzing-Ansatz, der systematisch alle erreichbaren Endpunkte einer Anwendung enumeriert und mit manipulierten Parametern anspricht [20].
Die dabei eingesetzten Payloads unterscheiden sich fundamental von klassischer Prompt Injection. Während Prompt-Injection-Angriffe versuchen, die Aufgabe des LLMs direkt zu überschreiben, nutzt Adversarial Reward-Hacking gezielt aus, dass der Agent darauf ausgelegt ist, sein operatives Ziel (die Identifikation einer Ursache und einer Remediation) möglichst effizient zu erfüllen. Die Payloads bestehen aus einem plausiblen, jedoch falschen Lead (einer erfundenen Fehlerursache) und einem schädlichen Body (der vorgeschlagenen Remediation), etwa dem Downgrade auf eine Softwareversion mit bekannten Sicherheitslücken. Der Agent übernimmt diese Information als vermeintliche Diagnose, ohne die Legitimität der Log-Einträge zu hinterfragen [20]. In Evaluierungen über 180 Trials mit GPT-4o und GPT-4.1 erzielte der Angriff eine durchschnittliche Erfolgsrate von 90 %, während konventionelle Prompt-Injection-Techniken unter identischen Bedingungen eine Erfolgsrate von 0 % aufwiesen. Bemerkenswert ist zudem, dass Adversarial-Reward-Hacking-Payloads die getesteten Prompt-Injection-Detektoren, darunter Microsofts PromptShields und Metas Prompt-Guard2, konsistent umgehen konnten [20].
Als Gegenmaßnahme schlagen Pasquini et al. [20] AIOpsShield vor, einen Verteidigungsmechanismus, der drei Eigenschaften von AIOps-Telemetrie ausnutzt: die endliche Menge möglicher Telemetrieausgaben, deren strukturierte Natur sowie die geringe Relevanz nutzergenerierter Inhalte für die Incident Response. In einer automatisierten Setup-Phase führt AIOpsShield eine Telemetry Taint Analysis durch, die mittels Fuzzing alle durch externe Eingaben beeinflussbaren Telemetrieeinträge identifiziert und daraus Parsing-Templates ableitet. Zur Laufzeit werden untrusted Felder in den Telemetriedaten automatisch durch abstrakte Platzhalter ersetzt, bevor sie dem Agenten übergeben werden. In der Evaluierung blockierte AIOpsShield sämtliche Angriffe, ohne die Agentenleistung auf dem AIOpsLab-Benchmark signifikant zu beeinträchtigen [20].
Einen komplementären Ansatz verfolgt MCP-Diag [19], das in Abschnitt IV eingeführt wurde. Die deterministische Übersetzungsschicht und der protokollseitig verankerte Elicitation Loop adressieren sowohl das Stochastic Grounding Problem als auch die Security Gap bei der Gewährung von Shell-Zugang an LLM-Agenten. Da der Human-in-the-Loop-Mechanismus auf Protokollebene implementiert ist, kann er im Gegensatz zu System-Prompts nicht durch Prompt Injection kompromittiert werden [19]. Diese Ergebnisse unterstreichen, dass die Sicherheitsarchitektur von AIOps-Systemen nicht nachträglich ergänzt, sondern als integraler Bestandteil des Systemdesigns konzipiert werden muss [20].
B. Halluzinationen und Vertrauen
Large Language Models können plausibel formulierte, jedoch faktisch inkorrekte Ausgaben erzeugen. Dieses Phänomen wird als Halluzination bezeichnet. Im AIOps-Kontext zeigt sich dieses Risiko in Form falscher Diagnosen, nicht existierenden API-Aufrufen oder fehlerhaften Remediation-Skripten, deren Ausführung im Produktivsystem schwerwiegende Folgen haben kann. Chen et al. [2] dokumentieren dieses Verhalten in der AIOpsLab-Evaluierung: Agenten generierten wiederholt Aufrufe nicht existierender APIs und verschwendeten Interaktionsschritte durch redundante Aktionen mit identischen Parametern. Zhang et al. [6] identifizieren die Halluzinationsneigung als eine der zentralen Limitationen LLM-basierter AIOps-Ansätze, insbesondere wenn Modelle ohne ausreichenden domänenspezifischen Kontext operieren.
Retrieval-Augmented Generation (RAG) stellt eine verbreitete Strategie zur Reduktion von Halluzinationen dar, indem das Modellwissen durch den Abruf relevanter Dokumente, etwa historische Incident Reports oder Runbooks, kontextuell angereichert wird [6], [8]. Goel et al. [15] zeigen jedoch, dass RAG allein nicht ausreicht: Prompt-Optimierung verbesserte die Genauigkeit von RCA-Empfehlungen um 21 % gegenüber RAG-basierten LLMs, was darauf hindeutet, dass die Art der Kontextaufbereitung ebenso entscheidend ist wie die bloße Verfügbarkeit externer Informationen. Fine-Tuning auf domänenspezifischen Daten mittels Small Language Models (SLMs) bietet eine weitere Möglichkeit, Halluzinationen zu reduzieren und zugleich die Inferenzkosten zu senken [15].
Neben diesen technischen Gegenmaßnahmen stellt auch die Mensch-KI-Interaktion eine eigenständige Herausforderung dar. Dai und Swaminathan [21] identifizieren zwei gegenläufige kognitive Verzerrungen, die den effektiven Einsatz von KI-Systemen erschweren: Automation Bias beschreibt die Tendenz, automatisiert generierte Empfehlungen unkritisch zu akzeptieren, selbst wenn diese fehlerhaft sind. Im AIOps-Kontext ist dies besonders relevant, da Operatoren unter Zeitdruck zur unreflektierten Übernahme von Agentenvorschlägen neigen können. Demgegenüber steht Algorithm Aversion, die Neigung, Algorithmen nach einem einzigen beobachteten Fehler grundsätzlich zu misstrauen, selbst wenn die algorithmische Leistung im Durchschnitt die menschliche übertrifft. Beide Effekte führen zu einer Fehlkalibrierung des Vertrauens, die den operativen Nutzen von AIOps-Systemen untergräbt.
Für den produktiven Einsatz von AIOps-Agenten ist daher ein kalibriertes Vertrauen erforderlich, das weder in Übervertrauen noch in pauschale Ablehnung mündet [21]. Dies erfordert zunächst geeignete Interface-Designs, die dem Operator Konfidenzwerte, alternative Diagnosen und die vom Agenten genutzten Evidenzen transparent machen. Darüber hinaus müssen die in Abschnitt IV beschriebenen Autonomiestufen konsequent umgesetzt werden: Auf der Stufe Human-Centric AIOps genehmigt der Operator jede Aktion explizit, auf der Stufe Machine-Centric AIOps operiert der Agent autonom innerhalb definierter Grenzen, eskaliert jedoch bei neuartigen oder kritischen Fehlern [3]. Bellala [11] betont in diesem Zusammenhang die Bedeutung des Operator-Patterns in Kubernetes, bei dem der gewünschte Zielzustand deklarativ spezifiziert wird und ein dedizierter Operator die kontrollierte Umsetzung überwacht, anstatt dem Agenten direkte imperative Befehle zu gestatten.
C. Operative Herausforderungen
1) Kosten und Inferenz-Latenz
Der Einsatz großer Sprachmodelle im operativen Betrieb verursacht erhebliche Kosten, die sich aus dem Token-Verbrauch pro Inferenzaufruf und der Anzahl der Interaktionsrunden pro Incident ergeben. Shetty et al. [1] beziffern die Kosten einer einzelnen Incident-Response-Session mit einem GPT-4-basierten Agenten auf circa 0,25 USD bei durchschnittlich 10–12 Interaktionsrunden. In Organisationen mit hunderten täglicher Incidents können sich diese Kosten erheblich akkumulieren. Zudem dokumentieren Chen et al. [2], dass Agenten häufig ihr Token-Budget durch die unreflektierte Verarbeitung umfangreicher Telemetriedaten verschwenden, ohne diagnostischen Mehrwert zu erzielen. Dieses Problem der Kontextfensterverschwendung treibt die Kosten weiter in die Höhe.
Die Leistungsunterschiede zwischen Modellfamilien verschärfen dieses Kosten-Nutzen-Dilemma. Vitui und Chen [8] zeigen, dass GPT-4o bei komplexen Multi-Tool-Aufgaben eine Genauigkeit von 100 % erzielt, während kleinere Modelle wie GPT-3.5 Turbo an der korrekten Verkettung mehrerer Werkzeuge scheitern. Feinabgestimmte SLMs bieten einen vielversprechenden Kompromiss: Goel et al. [15] demonstrieren, dass domänenadaptierte SLMs in Kombination mit Prompt-Optimierung eine vergleichbare Genauigkeit wie deutlich größere Modelle erreichen können, bei signifikant geringeren Inferenzkosten. Diese Ergebnisse deuten darauf hin, dass die Zukunft kosteneffizienter AIOps-Systeme weniger in der Skalierung der Modellgröße liegt als in der intelligenten Kombination spezialisierter, kleinerer Modelle mit optimierten Prompting-Strategien.
2) Model Drift und Wissensveralterung
AIOps-Modelle operieren in einer grundsätzlich veränderlichen Umgebung: Softwareänderungen, Infrastruktur-Migrationen und sich wandelnde Lastmuster verändern die statistischen Eigenschaften der Betriebsdaten kontinuierlich. Dieser als Concept Drift bezeichnete Effekt führt dazu, dass ein einmal trainiertes Modell ohne regelmäßige Aktualisierung an Genauigkeit verliert. Poenaru-Olaru et al. [13] untersuchen verschiedene Retraining-Strategien für Anomalieerkennungsmodelle und zeigen, dass driftbasiertes Retraining, bei dem das Modell nur bei erkannten Datenveränderungen neu trainiert wird, in den meisten Fällen eine vergleichbare Genauigkeit wie periodisches Retraining erzielt und somit eine kosteneffiziente Alternative darstellt. In Szenarien mit schnell wechselnden Daten bleibt periodisches Retraining jedoch vorzuziehen, um die maximale Vorhersagegenauigkeit zu gewährleisten [14].
Lyu et al. [22] verfolgen einen alternativen Ansatz und untersuchen, ob historische, bereits verworfene Modelle für neue Vorhersageaufgaben wiederverwendet werden können. Ihre Ergebnisse zeigen, dass Modellselektionsmechanismen, die auf temporaler Nähe basieren, häufig dem periodischen Retraining überlegen sind. Dieser Befund deutet darauf hin, dass nicht jede Datenveränderung ein vollständiges Neutraining rechtfertigt, sondern die gezielte Auswahl eines geeigneten historischen Modells effizienter sein kann.
Für LLM-basierte Ansätze stellt sich das Problem der Wissensveralterung zusätzlich auf der Ebene des parametrischen Modellwissens: Änderungen an Systemarchitekturen, neue Fehlerklassen oder aktualisierte Runbooks spiegeln sich nicht automatisch im Modell wider. RAG-basierte Architekturen adressieren dieses Problem teilweise, indem sie aktuelles Kontextwissen zur Inferenzzeit abrufen [6], [8]. Die Pflege und Aktualität der zugrunde liegenden Wissensdatenbanken bleibt jedoch eine organisatorische Aufgabe, die kontinuierlichen Aufwand erfordert.
3) Adoption und organisatorische Barrieren
Den technischen Fortschritten im Bereich AIOps steht eine nach wie vor langsame Einführung in der Praxis gegenüber. Zimelewicz et al. [23] dokumentieren in einer internationalen Umfrage mit 188 Teilnehmern aus 25 Ländern, dass MLOps-Prinzipien in der Praxis nur begrenzt umgesetzt werden und viele produktive ML-Modelle keinerlei Monitoring unterliegen. Die berichteten Probleme umfassen das Fehlen etablierter Monitoring-Praktiken, die Notwendigkeit, eigene Monitoring-Werkzeuge zu entwickeln, sowie Schwierigkeiten bei der Auswahl geeigneter Metriken.
Bendimerad et al. [24] berichten aus der Perspektive eines mittelständischen Softwareunternehmens über die praktischen Hürden bei der Implementierung einer On-Premise-AIOps-Infrastruktur. Kommerzielle Lösungen erwiesen sich aufgrund hoher Kosten, fehlender Abdeckung proprietärer Software und Bedenken hinsichtlich der Datenhoheit als ungeeignet. Die Autoren beschreiben den Aufbau einer vollständig auf Open-Source-Werkzeugen basierenden AIOps-Infrastruktur und betonen die Notwendigkeit sorgfältiger Designentscheidungen bei der Auswahl des Datenmanagementsystems und dessen Integration in bestehende Prozesse.
Vitui und Chen [8] identifizieren drei übergreifende Barrieren für die Einführung von AIOps: Erstens die Datenqualität, da AIOps-Methoden auf konsistente und vollständige Telemetriedaten angewiesen sind, die in heterogenen Produktivumgebungen selten gegeben ist. Zweitens die Umgebungskomplexität, die es erschwert, generisch trainierte Modelle ohne domänenspezifische Anpassung einzusetzen. Drittens die Qualifikationslücke innerhalb der Teams, die sowohl DevOps-Expertise als auch ML-Kenntnisse voraussetzt. Diese Kombination ist in der Praxis selten in einer Person vereint. Diese Befunde unterstreichen, dass der Erfolg von AIOps nicht allein von der algorithmischen Leistungsfähigkeit abhängt, sondern maßgeblich durch organisatorische Rahmenbedingungen, Investitionen in Datenqualität und den Aufbau interdisziplinärer Kompetenzen bestimmt wird.
VI. Evaluierung und Benchmarking
Die systematische Evaluierung von AIOps-Methoden stellt eine eigenständige Herausforderung dar, die über die bloße Anwendung klassischer ML-Metriken hinausgeht. Die Heterogenität der Aufgaben, von der Anomalieerkennung über die Root Cause Analysis bis zur autonomen Remediation, die Dynamik realer Cloud-Umgebungen und die zunehmende Integration generativer KI erfordern differenzierte Bewertungsansätze. Dieser Abschnitt behandelt zunächst die verwendeten Evaluierungsmetriken, stellt anschließend aktuelle Benchmark-Frameworks vor und ordnet schließlich die Befunde industrieller Berichte kritisch ein.
A. Evaluierungsmetriken
1) Klassische ML-Metriken
Für die Bewertung von Anomalieerkennungs-, Lokalisierungs- und Klassifikationsalgorithmen werden etablierte Metriken aus dem Bereich des maschinellen Lernens herangezogen. Precision quantifiziert den Anteil korrekt erkannter Anomalien an allen als anomal klassifizierten Datenpunkten, Recall den Anteil korrekt erkannter Anomalien an allen tatsächlich vorhandenen Anomalien, und der F1-Score bildet deren harmonisches Mittel. Sun et al. [25] differenzieren für die Anomalieerkennung auf Zeitreihendaten drei Auswertungsvarianten: Point-based, bei dem jeder einzelne Zeitpunkt bewertet wird, Range-based, bei dem zusammenhängende Anomaliebereiche als Einheit gelten, und Event-based, bei dem die korrekte Erkennung diskreter Anomalieereignisse bewertet wird. Für Root Cause Localization werden Accuracy@k-Metriken verwendet, die prüfen, ob die tatsächliche Ursache unter den Top-k Vorhersagen enthalten ist, sowie Micro-F1, Macro-F1 und Weighted-F1 für die Fehlerklassifikation [25].
2) Aufgabenspezifische Metriken
Über die reinen Klassifikationsmetriken hinaus definiert AIOpsLab [2] aufgabenspezifische Metriken entlang des Incident-Lifecycles: Time-to-Detect (TTD) misst die Zeitspanne von der Fehlerinjektion bis zur Erkennung durch den Agenten, Time-to-Mitigate (TTM) die Zeit von der Erkennung bis zur vollständigen Behebung. Ergänzend werden die Anzahl der Interaktionsschritte und der Token-Verbrauch als Effizienzindikatoren erfasst [2]. Diese Metriken sind insbesondere für die Bewertung agentenbasierter Systeme relevant, da sie neben der reinen Korrektheit auch die operative Effizienz und die Kosten einer Lösung abbilden.
3) GenAI-spezifische Bewertung
Die Evaluierung generativer KI-Systeme erfordert zusätzliche Kriterien, die über binäre Korrektheitsbewertungen hinausgehen. AIOpsLab implementiert hierfür optional eine LLM-as-Judge-Methodik, bei der ein separates Sprachmodell die Reasoning-Ketten der Agenten qualitativ bewertet [2]. Dies adressiert das Problem, dass ein Agent zwar die korrekte Antwort liefern, jedoch eine fehlerhafte Begründung formulieren kann, etwa wenn ein Agent eine Anomalie korrekt detektiert, seine Erklärung aber auf eine normale Systemaktivität referenziert, die mit dem injizierten Fehler nicht in Zusammenhang steht [2]. Für RCA-Empfehlungen setzen Goel et al. [15] auf eine Bewertung durch Incident-Verantwortliche, die die Genauigkeit und Nützlichkeit der generierten Empfehlungen beurteilen.
4) Operative KPIs
Deloitte [26] schlägt in einem Whitepaper einen dreistufigen KPI-Rahmen für die Bewertung von AIOps-Systemen im Produktivbetrieb vor. Direkte Indikatoren messen die Leistung der AIOps-Plattform selbst: den Prozentsatz der durch AIOps identifizierten Root Causes, den Anteil autonom gelöster Incidents und den durchschnittlichen manuellen Aufwand pro Incident. Indirekte Indikatoren umfassen traditionelle IT-Service-KPIs wie MTTR, MTTD und Mean Time Between Failures (MTBF). Business-Indikatoren quantifizieren den geschäftlichen Einfluss, etwa durch die Zuordnung eines finanziellen Werts zu jedem Incident [26]. Dieser KPI-Rahmen verdeutlicht, dass akademische Evaluierungen, die sich primär auf Korrektheit und Effizienz konzentrieren, nur einen Teilaspekt der Gesamtbewertung abdecken. Ob und in welchem Umfang die direkten und indirekten Indikatoren sich über die Zeit verbessern, bestimmt letztlich den Reifegrad einer AIOps-Implementierung.
B. Benchmark-Frameworks und Datensätze
1) Limitationen statischer Datensätze
Traditionelle AIOps-Benchmarks basieren überwiegend auf statischen Datensätzen, etwa aufgezeichneten Zeitreihen oder fest formatierten Frage-Antwort-Paaren [2], [25]. Diese Vorgehensweise weist mehrere grundlegende Defizite auf: Statische Daten bilden die dynamische, sich kontinuierlich verändernde Natur realer Cloud-Umgebungen nicht ab. Workloads und Incidents fluktuieren über die Zeit, und ein Algorithmus, der auf einem vorab aufgezeichneten Datensatz gute Ergebnisse erzielt, versagt möglicherweise unter veränderten Lastbedingungen. Zudem erlauben statische Benchmarks keine Interaktion: Ein Agent kann weder auf den Systemzustand reagieren noch diagnostische Aktionen ausführen [2]. Schließlich schränkt die Fixierung auf ein einzelnes Szenario die Vergleichbarkeit ein, da Algorithmen, die in einem bestimmten Fehlerszenario schwach abschneiden, in anderen Szenarien überlegen sein können [25].
2) AIOpsLab
AIOpsLab [2] adressiert diese Limitationen durch ein umfassendes Framework, das die Evaluierung von AIOps-Agenten in dynamischen, interaktiven Cloud-Umgebungen ermöglicht. Das Framework kombiniert fünf Kernkomponenten: den Einsatz realer Microservice-Anwendungen aus der DeathStarBench-Suite (SocialNetwork mit 28 Microservices und HotelReservation), eine integrierte Fehlerinjektion mittels Chaos Engineering über ChaosMesh, einen Workload-Generator, ein Telemetrie-Subsystem (Prometheus, Jaeger, Filebeat/Logstash) sowie den in Abschnitt IV beschriebenen Orchestrator mit Agent-Cloud-Interface [2].
AIOpsLab definiert eine vierstufige Aufgabentaxonomie mit steigender Komplexität: Detection (Erkennung einer Anomalie), Localization (Lokalisierung des fehlerhaften Services), Root Cause Analysis (Identifikation des Systemlayers und Fehlertyps) und Mitigation (interaktive Fehlerbehebung durch den Agenten). Die Fehlerinjektionen umfassen sowohl symptomatische Fehler (Network Loss, Pod Failure), die nur Detection- und Localization-Aufgaben erzeugen, als auch funktionale Fehler (fehlende Authentifizierung, Port-Fehlkonfiguration, fehlerhafte Container-Images), die Aufgaben auf allen vier Stufen ermöglichen [2].
Die Evaluierung von vier LLM-Agenten auf dem 48 Probleme umfassenden Benchmark offenbart erhebliche Leistungsunterschiede: FLASH erreicht mit 59,32 % die höchste Gesamtgenauigkeit, gefolgt von ReAct (55,93 %), GPT-4-w-Shell (49,15 %) und GPT-3.5-w-Shell (15,25 %). Bezeichnend ist, dass alle LLM-Agenten die traditionellen, nicht-LLM-basierten AIOps-Algorithmen bei Detection und Localization übertreffen, während die Mitigation-Aufgabe die größte Herausforderung darstellt. GPT-3.5 scheitert hier vollständig, und selbst FLASH erreicht nur 54,55 % [2]. Besonders aussagekräftig ist die Analyse der Schrittlimits: Während FLASH und ReAct mit steigender Schrittzahl bessere Ergebnisse erzielen, stagniert GPT-3.5 bereits ab fünf Schritten und produziert bei höheren Limits lediglich mehr Token ohne diagnostischen Mehrwert [2].
3) MicroServo
Einen komplementären Ansatz verfolgt MicroServo [25], das sich auf die szenarioorientierte Evaluierung spezialisierter AIOps-Algorithmen, im Gegensatz zu End-to-End-Agenten, konzentriert. Die zentrale Idee besteht darin, Evaluierungsszenarien durch gezielte Fehlerorchestrierung zu definieren und Algorithmen konsistent auf Echtzeitdaten aus einer live betriebenen Microservice-Umgebung (Google Online Boutique) zu bewerten [25].
Ein wesentliches Designmerkmal von MicroServo ist das Algorithm Hot-Plugging: Jeder Algorithmus wird in einem eigenen Docker-Container deployt, was Abhängigkeitskonflikte beseitigt und das Hinzufügen neuer Algorithmen mit minimalem Aufwand ermöglicht. Die Plattform stellt ein standardisiertes Datenformat für Metriken, Logs und Traces bereit, das als gemeinsame Schnittstelle für alle integrierten Algorithmen dient [25].
Die Ergebnisse von MicroServo demonstrieren den praktischen Nutzen szenarioorientierter Evaluierung: DeepLog, ein logbasierter Anomaliedetektor, erkennt Pod-Fehler mit vertretbarem Recall (0,33), versagt jedoch bei Stress-Fehler-Szenarien (Recall 0,13), da diese sich primär in Metriken und nicht in Logs zeigen. TimesNet, ein metrikbasiertes Modell, erzielt hingegen in beiden Szenarien hohe Recall-Werte (1,0), verliert aber bei der Precision [25]. Multimodale Algorithmen wie DiagFusion, die Metriken, Logs und Traces gemeinsam auswerten, erzielen in gemischten Szenarien die besten Ergebnisse für Root Cause Localization (Accuracy@1 von 0,52) und Fehlerklassifikation (Micro-F1 von 0,70) [25]. Diese Befunde unterstreichen, dass die Wahl des optimalen Algorithmus abhängig vom erwarteten Fehlerszenario ist und universelle Leaderboards ohne Szenario-Differenzierung irreführend sein können.
C. Industrielle Perspektiven
1) BigPanda Business Value Report
Der BigPanda Business Value Report [27] quantifiziert den geschäftlichen Nutzen der BigPanda-Plattform auf Basis von 23 Kunden-Assessments, die zwischen November 2024 und Juli 2025 durchgeführt wurden. Die berichteten Kennzahlen sind beachtlich: ein medianer jährlicher Nutzen von 2,85 Millionen USD, ein medianer ROI von 430 % und eine typische Amortisationszeit von unter einem Jahr. Das Ticketvolumen sank im Median um 43 %, die MTTR-Reduktionsraten lagen zwischen 19 % und 81 %, und die Alert-Noise-Reduktion erreichte bis zu 97 % [27].
Diese Ergebnisse sollten jedoch kritisch eingeordnet werden. Der Report wurde vollständig intern von BigPanda erstellt: Das Assessment-Team, die Methodik und die Datenerhebung liegen in der Hand des Anbieters selbst, ohne externe Validierung oder Peer-Review. Die Stichprobe ist auf große Unternehmen beschränkt: die mediane Jahresumsatzklasse der teilnehmenden Organisationen beträgt 5,97 Milliarden USD, fast zwei Drittel finden sich auf der Fortune-1000-Liste [27]. Die Übertragbarkeit der Ergebnisse auf mittelständische Unternehmen oder Organisationen mit geringerer operativer Komplexität ist daher fraglich. Zudem differenziert der Report zwischen Green Dollars (direkte Kosteneinsparungen wie reduzierte Headcounts), Blue Dollars (indirekte Effizienzgewinne wie Zeitersparnis, die nicht unmittelbar bilanzwirksam sind) und Teal Dollars (situationsabhängige Einsparungen) [27]. Ein Großteil der berichteten Einsparungen fällt in die Kategorie der Blue Dollars, also reale, aber schwer nachprüfbare Effizienzgewinne, die nicht direkt in eine Gewinn- und Verlustrechnung eingehen.
Trotz dieser methodischen Einschränkungen liefert der Report empirische Datenpunkte, die in der akademischen Literatur selten verfügbar sind. Die konsistente Berichterstattung über MTTR-Reduktionen, Ticket-Volumen-Senkungen und Alert-Noise-Filterraten deckt sich mit den in den Abschnitten III und V beschriebenen Herausforderungen der Alert Fatigue und des operativen Toil. Die Ergebnisse geben somit einen Hinweis auf das Potenzial von AIOps-Plattformen in großen Unternehmensumgebungen, sollten jedoch nicht als unabhängig validierte Benchmarks interpretiert werden.
2) Deloitte: AIOps-Reifegradmodell
Deloitte [26] präsentiert in einem Whitepaper ein hierarchisches AIOps-Modell, das die drei Phasen Observe, Engage und Act in acht aufeinander aufbauende Schichten gliedert: von der Observability als Fundament über Anomaly Detection, Event Correlation, Root Cause Analysis, Incident Identification und Incident Routing bis hin zur Resolution Automation und Resolution Generation. Zentral ist dabei das Konzept der AIOps Frontier, also der Schwelle im hierarchischen Modell, bis zu der AIOps in einer Organisation zuverlässig funktioniert [26]. Darüber hinaus definiert das Whitepaper fünf Reifegradstufen: Traditional IT Delivery, Observability, AI Support, AIOps und AIOps (mit GenAI) [26]. Dieses Stufenmodell deckt sich mit der vierstufigen Skala von Cheng et al. [3], erweitert diese jedoch um eine explizite Observability-Stufe, die den Aufbau einer belastbaren Datengrundlage als eigenständige Vorstufe hervorhebt.
Hervorzuheben ist, dass Deloitte die organisatorische Transformation als gleichrangig zur technischen Implementierung behandelt. Die Einführung eines zentralen AIOps-Teams, bestehend aus SRE, AI Engineering und Observability, sowie die Betonung von Organizational Change Management als unverzichtbare Begleitmaßnahme spiegeln eine praxisorientierte Sichtweise wider, die in rein technisch ausgerichteten akademischen Arbeiten oft zu kurz kommt [26]. Die berichteten Case Studies, darunter eine MTTR-Reduktion um 50 % und eine Senkung der Incident-Kosten um 85 % in einem Regierungsportal, liefern weitere Evidenz für den praktischen Nutzen [26].
Das Whitepaper weist jedoch typische Merkmale eines Beratungsdokuments auf: Die Fallstudien beruhen ausschließlich auf Projekten mit Deloitte-Beteiligung und verwenden proprietäre Konfigurationen (insbesondere Dynatrace als Observability-Plattform und ServiceNow als ITSM-System), deren Ergebnisse sich nicht ohne Weiteres auf andere Technologiestacks übertragen lassen. Eine standardisierte, reproduzierbare Benchmarking-Methodik fehlt. Zudem bleibt die Frage offen, wie die vorgeschlagene Organisationsstruktur in Unternehmen skaliert, die nicht über die Ressourcen verfügen, dedizierte Rollen für SRE, AI Engineering und Observability einzurichten. Diese Einschränkung behandeln Bendimerad et al. [24] in ihrem Erfahrungsbericht zur On-Premise-AIOps-Infrastruktur eines mittelständischen Unternehmens ausdrücklich.
VII. Fazit und Ausblick
Die vorliegende Arbeit hat den aktuellen Stand der AIOps-Forschung entlang des Incident-Lifecycles systematisch aufgearbeitet und dabei sowohl etablierte ML-basierte Methoden als auch den durch Large Language Models eingeleiteten Wandel analysiert.
Die Untersuchung der drei Kernaufgaben – Failure Perception, Root Cause Analysis und Auto-Remediation – zeigt, dass für jede Phase inzwischen leistungsfähige Verfahren existieren, die regelbasierte Ansätze in Genauigkeit und Skalierbarkeit übertreffen. Transformer-basierte Modelle wie STMformer verbessern die Zustandsvorhersage in Microservice-Umgebungen gegenüber bisherigen Methoden, während multimodale Frameworks wie KylinRCA durch die Fusion von Metriken, Logs und Traces Entity-Lokalisierung mit F1-Scores über 92 % erzielen. Die Auto-Remediation profitiert von Reinforcement-Learning-Ansätzen wie Narya und dem Operator-Pattern in Kubernetes, das deklarative Zielzustandsbeschreibungen mit kontrollierter Ausführung verbindet.
Der Einsatz von LLMs und darauf aufbauenden Agenten-Architekturen verschiebt den Fokus von spezialisierten Einzelmodellen hin zu generalistischen Systemen, die den gesamten Incident-Lifecycle autonom verwalten können. Das ReAct-Framework und Multi-Agenten-Systeme wie FLASH demonstrieren, dass LLM-basierte Agenten in interaktiven Benchmark-Umgebungen bereits Gesamtgenauigkeiten von knapp 60 % erreichen und dabei traditionelle Algorithmen bei Detection und Localization übertreffen. Gleichzeitig offenbaren die Evaluierungen in AIOpsLab systematische Schwächen: Agenten verschwenden Interaktionsschritte durch redundante Aktionen, erschöpfen ihr Kontextfenster durch die undifferenzierte Verarbeitung umfangreicher Telemetriedaten und stagnieren in ihrer Selbstreparaturfähigkeit nach einer bestimmten Anzahl von Schritten.
Diese technischen Einschränkungen werden durch erhebliche Sicherheitsrisiken verschärft. Die Ergebnisse von Pasquini et al. zeigen, dass Telemetrie-Manipulation über Adversarial Reward Hacking eine Erfolgsrate von 90 % erzielen kann, während klassische Prompt-Injection-Techniken unter denselben Bedingungen bei 0 % verbleiben. Deterministische Übersetzungsschichten wie MCP-Diag und AIOpsShield bieten erste Gegenmaßnahmen, verdeutlichen jedoch, dass Sicherheit als integraler Bestandteil des Systemdesigns konzipiert werden muss und nicht nachträglich ergänzt werden kann.
Neben den technischen Herausforderungen stellt die organisatorische Umsetzung eine zentrale Hürde dar. Die Abhängigkeit von konsistenten Telemetriedaten, die Notwendigkeit interdisziplinärer Kompetenzen an der Schnittstelle von DevOps und Machine Learning sowie die hohen Einstiegskosten kommerzieller Plattformen erschweren insbesondere für mittelständische Unternehmen die praktische Umsetzung. Die Diskrepanz zwischen den vielversprechenden Ergebnissen akademischer Benchmarks und den Anforderungen realer Produktivumgebungen bleibt ein ungelöstes Spannungsfeld.
Für die zukünftige Forschung lassen sich aus den identifizierten Lücken mehrere vorrangige Richtungen ableiten. Erstens versprechen feinabgestimmte Small Language Models einen kosteneffizienten Kompromiss zwischen Leistungsfähigkeit und Inferenzkosten – die Ergebnisse von eARCO belegen, dass domänenadaptierte SLMs mit optimierten Prompts eine vergleichbare Genauigkeit wie deutlich größere Modelle erreichen können. Zweitens erfordert die Absicherung autonomer Agenten gegen Telemetrie-Manipulation und Halluzinationen neue Architekturmuster, die über System-Prompt-basierte Schutzmaßnahmen hinausgehen und Validierungsmechanismen auf Protokollebene verankern. Drittens fehlt eine Standardisierung der Agenten-Schnittstellen: Das Agent-Cloud-Interface-Konzept und das Model Context Protocol bieten vielversprechende Ansätze, sind jedoch noch weit von einer branchenweiten Adoption entfernt. Schließlich bleibt die Evaluierungsmethodik ein offenes Problem – die Entwicklung szenariobasierter, dynamischer Benchmark-Frameworks, die sowohl die technische Korrektheit als auch die operative Effizienz und den geschäftlichen Nutzen erfassen, ist eine Voraussetzung für die belastbare Vergleichbarkeit von AIOps-Ansätzen.
Referenzen
[1] M. Shetty, Y. Chen, G. Somashekar, M. Ma, Y. Simmhan, X. Zhang, J. Mace, D. Vandevoorde, P. Las-Casas, S. M. Gupta, S. Nath, C. Bansal, and S. Rajmohan, “Building AI Agents for Autonomous Clouds: Challenges and Design Principles,” Jul. 2024, arXiv:2407.12165 [cs]. [Online]. Available: http://arxiv.org/abs/2407.12165
[2] Y. Chen, M. Shetty, G. Somashekar, M. Ma, Y. Simmhan, J. Mace, C. Bansal, R. Wang, and S. Rajmohan, “AIOpsLab: A Holistic Framework to Evaluate AI Agents for Enabling Autonomous Clouds,” Jan. 2025, arXiv:2501.06706 [cs]. [Online]. Available: http://arxiv.org/abs/2501.06706
[3] Q. Cheng, D. Sahoo, A. Saha, W. Yang, C. Liu, G. Woo, M. Singh, S. Saverese, and S. C. H. Hoi, “AI for IT Operations (AIOps) on Cloud Platforms: Reviews, Opportunities and Challenges,” Apr. 2023, arXiv:2304.04661 [cs]. [Online]. Available: http://arxiv.org/abs/2304.04661
[4] H. Mahesh, “Gartner Hype-Cycle for AI 2025: What the Future Holds in 2026?” Oct. 2025. [Online]. Available: https://testrigor.com/blog/gartner-hype-cycle-for-ai-2025/
[5] L. Zhang, T. Jia, M. Jia, Y. Wu, A. Liu, Y. Yang, Z. Wu, X. Hu, P. S. Yu, and Y. Li, “A Survey of AIOps for Failure Management in the Era of Large Language Models,” Jun. 2024, arXiv:2406.11213 [cs]. [Online]. Available: http://arxiv.org/abs/2406.11213
[6] L. Zhang, T. Jia, M. Jia, Y. Wu, A. Liu, Y. Yang, Z. Wu, X. Hu, P. S. Yu, and Y. Li, “A Survey of AIOps in the Era of Large Language Models,” Jun. 2025, arXiv:2507.12472 [cs]. [Online]. Available: http://arxiv.org/abs/2507.12472
[7] P. Bhosale, “Metrics, Logs, and Traces: A Unified Approach to Observability in Microservices,” Journal of Artificial Intelligence, Machine Learning and Data Science, vol. 1, no. 1, pp. 2084–2088, Nov. 2022. [Online]. Available: https://urfjournals.org/open-access/metrics-logs-and-traces-a-unified-approach-to-observability-in-microservices.pdf
[8] A. Vitui and T.-H. Chen, “Empowering AIOps: Leveraging Large Language Models for IT Operations Management,” Jan. 2025, arXiv:2501.12461 [cs]. [Online]. Available: http://arxiv.org/abs/2501.12461
[9] Y. Huo, C. Lee, J. Liu, T. Yang, and M. R. Lyu, “A Roadmap towards Intelligent Operations for Reliable Cloud Computing Systems.” arXiv, Oct. 2023, arXiv:2310.00677 [cs]. [Online]. Available: http://arxiv.org/abs/2310.00677
[10] J. Hou, “Research on fault diagnosis and root cause analysis based on full stack observability,” Sep. 2025, arXiv:2509.12231 [cs]. [Online]. Available: http://arxiv.org/abs/2509.12231
[11] K. R. Bellala, “Towards Autonomous Kubernetes: A Framework for AI-Driven Operations (AIOps),” International Journal of Innovative Science and Research Technology, pp. 1654–1661, Sep. 2025. [Online]. Available: https://www.ijisrt.com/towards-autonomous-kubernetes-a-framework-for-aidriven-operations-aiops
[12] Y. Xu, J. Ge, H. Tang, S. Ding, T. Li, and H. Li, “System States Forecasting of Microservices with Dynamic Spatio-Temporal Data,” Aug. 2024, arXiv:2408.07894 [cs]. [Online]. Available: http://arxiv.org/abs/2408.07894
[13] L. Poenaru-Olaru, N. Karpova, L. Cruz, J. Rellermeyer, and A. v. Deursen, “Is Your Anomaly Detector Ready for Change? Adapting AIOps Solutions to the Real World,” in Proceedings of the IEEE/ACM 3rd International Conference on AI Engineering – Software Engineering for AI, Apr. 2024, pp. 222–233, arXiv:2311.10421 [cs]. [Online]. Available: http://arxiv.org/abs/2311.10421
[14] L. Poenaru-Olaru, W. v. t. Hof, A. Stando, A. P. Trawinski, E. Kapel, J. S. Rellermeyer, L. Cruz, and A. v. Deursen, “Prepared for the Unknown: Adapting AIOps Capacity Forecasting Models to Data Changes,” Oct. 2025, arXiv:2510.10320 [cs]. [Online]. Available: http://arxiv.org/abs/2510.10320
[15] D. Goel, R. Magazine, S. Ghosh, A. Nambi, P. Deshpande, X. Zhang, C. Bansal, and S. Rajmohan, “eARCO: Efficient Automated Root Cause Analysis with Prompt Optimization,” Apr. 2025, arXiv:2504.11505 [cs]. [Online]. Available: http://arxiv.org/abs/2504.11505
[16] P. Pham, V. Jain, L. Dauterman, J. Ormont, and N. Jain, “DeepTriage: Automated Transfer Assistance for Incidents in Cloud Services,” Nov. 2020. [Online]. Available: https://arxiv.org/abs/2012.03665v1
[17] A. Vaswani, N. Shazeer, N. Parmar, J. Uszkoreit, L. Jones, A. N. Gomez, L. Kaiser, and I. Polosukhin, “Attention Is All You Need.” arXiv, Aug. 2023, arXiv:1706.03762 [cs]. [Online]. Available: http://arxiv.org/abs/1706.03762
[18] S. Yao, J. Zhao, D. Yu, N. Du, I. Shafran, K. Narasimhan, and Y. Cao, “ReAct: Synergizing Reasoning and Acting in Language Models.” arXiv, Mar. 2023, arXiv:2210.03629 [cs]. [Online]. Available: http://arxiv.org/abs/2210.03629
[19] D. Lodha, M. Panchal, and S. G. Kulkarni, “MCP-Diag: A Deterministic, Protocol-Driven Architecture for AI-Native Network Diagnostics.” arXiv, Jan. 2026, arXiv:2601.22633 [cs]. [Online]. Available: http://arxiv.org/abs/2601.22633
[20] D. Pasquini, E. M. Kornaropoulos, G. Ateniese, O. Akgul, A. Theocharis, and P. Efstathopoulos, “When AIOps Become ‘AI Oops’: Subverting LLM-driven IT Operations via Telemetry Manipulation,” Aug. 2025, arXiv:2508.06394 [cs]. [Online]. Available: http://arxiv.org/abs/2508.06394
[21] T. Dai and J. M. Swaminathan, “Artificial Intelligence and Operations: A Foundational Framework of Emerging Research and Practice.”
[22] Y. Lyu, H. Li, H. Li, and A. E. Hassan, “Can We Recycle Our Old Models? An Empirical Evaluation of Model Selection Mechanisms for AIOps Solutions,” May 2025, arXiv:2505.02961 [cs]. [Online]. Available: http://arxiv.org/abs/2505.02961
[23] E. Zimelewicz, M. Kalinowski, D. Mendez, G. Giray, A. P. S. Alves, N. Lavesson, K. Azevedo, H. Villamizar, T. Escovedo, H. Lopes, S. Biffl, J. Musil, M. Felderer, S. Wagner, T. Baldassarre, and T. Gorschek, “ML-Enabled Systems Model Deployment and Monitoring: Status Quo and Problems,” Feb. 2024, arXiv:2402.05333 [cs]. [Online]. Available: http://arxiv.org/abs/2402.05333
[24] A. Bendimerad, Y. Remil, R. Mathonat, and M. Kaytoue, “On-Premise AIOps Infrastructure for a Software Editor SME: An Experience Report,” Aug. 2023, arXiv:2308.11225 [cs]. [Online]. Available: http://arxiv.org/abs/2308.11225
[25] Y. Sun, J. Wang, Z. Li, X. Nie, M. Ma, S. Zhang, Y. Ji, L. Zhang, W. Long, H. Chen, Y. Luo, and D. Pei, “A Scenario-Oriented Benchmark for Assessing AIOps Algorithms in Microservice Management,” Jul. 2024, arXiv:2407.14532 [cs]. [Online]. Available: http://arxiv.org/abs/2407.14532
[26] Deloitte, “AIOps: How AI will transform the Art of IT Operations,” Jun. 2025, industry Whitepaper. [Online]. Available: https://www.deloitte.com/content/dam/assets-zone2/de/no-index/2025/risk-advisory/Deloitte_AIOps_How_AI_Will_Transform_the_Art_of_IT_Operations.pdf
[27] BigPanda, “The Business Value of the BigPanda Platform,” Oct. 2025, industry Report. [Online]. Available: https://www.bigpanda.io/wp-content/uploads/2025/10/bigpanda-report-business-value-of-the-bigpanda-platform.pdf
Leave a Reply
You must be logged in to post a comment.