{"id":28501,"date":"2026-02-20T22:08:47","date_gmt":"2026-02-20T21:08:47","guid":{"rendered":"https:\/\/blog.mi.hdm-stuttgart.de\/?p=28501"},"modified":"2026-02-20T22:08:49","modified_gmt":"2026-02-20T21:08:49","slug":"integration-von-ki-in-devops-ein-uberblick-uber-aiops-prinzipien-und-praktiken","status":"publish","type":"post","link":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/2026\/02\/20\/integration-von-ki-in-devops-ein-uberblick-uber-aiops-prinzipien-und-praktiken\/","title":{"rendered":"Integration von KI in DevOps: Ein \u00dcberblick \u00fcber AIOps-Prinzipien und -Praktiken"},"content":{"rendered":"\n

Abstract<\/strong> \u2014 Die zunehmende Komplexit\u00e4t cloud-nativer Architekturen und die exponentielle Zunahme von Telemetriedaten \u00fcbersteigen die Kapazit\u00e4t manueller Betriebsprozesse und erfordern eine intelligente Automatisierung des IT-Betriebs. Die vorliegende Arbeit bietet einen umfassenden \u00dcberblick \u00fcber AIOps (Artificial Intelligence for IT Operations) und analysiert systematisch den aktuellen Forschungsstand entlang des Incident-Lifecycles. Ausgehend von den drei S\u00e4ulen der Observability \u2013 Metriken, Logs und Traces \u2013 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\u00f6nnen. Dar\u00fcber hinaus werden das Agent-Cloud-Interface (ACI) und deterministische \u00dcbersetzungsschichten als Standardisierungsans\u00e4tze f\u00fcr die Agenten-Cloud-Interaktion diskutiert. Die kritische Analyse identifiziert zentrale Herausforderungen: Sicherheitsrisiken durch Telemetrie-Manipulation mittels Adversarial Reward Hacking, Halluzinationsprobleme, Kosten-Nutzen-Abw\u00e4gungen 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\u00dft mit Forschungsperspektiven zu kosteneffizienten Small Language Models, protokollseitig verankerten Sicherheitsarchitekturen und der Standardisierung von Agenten-Schnittstellen.<\/p>\n

I. Einleitung<\/h2>\n

A. Motivation und Problemstellung<\/h3>\n

Moderne Softwaresysteme haben sich in den vergangenen Jahren grundlegend gewandelt. Der \u00dcbergang 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\u00e4t drastisch erh\u00f6ht [1]. In solchen verteilten Umgebungen k\u00f6nnen sich Fehler kaskadenartig \u00fcber zahlreiche Dienste ausbreiten, wobei allein ein einst\u00fcndiger Ausfall bei einem gro\u00dfen Cloud-Anbieter Verluste von gesch\u00e4tzten 100 Millionen US-Dollar verursachen kann [2].<\/p>\n

Die Kapazit\u00e4t manueller Betriebsprozesse ist durch die Gr\u00f6\u00dfe des DevOps-Teams begrenzt und kann nur linear wachsen, w\u00e4hrend Durchsatz und Arbeitsaufkommen h\u00e4ufig exponentiell zunehmen [3]. Dar\u00fcber hinaus ist die Standardisierung manueller Abl\u00e4ufe aufgrund der Heterogenit\u00e4t von Qualifikation, Systemkenntnissen und Erfahrung innerhalb der Teams kaum zu gew\u00e4hrleisten. Manuelle Eingriffe sind zudem fehleranf\u00e4llig. Selbst bei den zuverl\u00e4ssigsten Cloud-Anbietern wurden schwerwiegende Ausf\u00e4lle durch menschliche Bedienfehler verursacht [3].<\/p>\n

Die Folgen dieser Komplexit\u00e4t zeigen sich in zentralen Betriebskennzahlen: Die Mean Time to Detect<\/em> (MTTD), Mean Time to Triage<\/em> (MTTT) und insbesondere die Mean Time to Resolve<\/em> (MTTR) bleiben in vielen Organisationen auf einem hohen Niveau. Gleichzeitig f\u00fchrt die wachsende Menge an Telemetriedaten \u2013 Metriken, Logs und Traces \u2013 zu einer \u00dcberlastung der Site-Reliability-Engineers (SREs), die als Alert Fatigue<\/em> und operativer Toil<\/em> die Effizienz weiter reduziert [1], [3]. Vor diesem Hintergrund wird eine intelligente Automatisierung des IT-Betriebs zunehmend unverzichtbar.<\/p>\n

B. Evolution von AIOps<\/h3>\n

Die Grundlage f\u00fcr das Verst\u00e4ndnis 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\u00fcr den gesamten Software-Lebenszyklus \u00fcbernehmen [3]. Von DevOps abzugrenzen ist MLOps<\/em> (Machine Learning Operations), das sich auf die Operationalisierung von ML-Modellen konzentriert \u2013 also deren Training, Versionierung, Deployment und Monitoring \u2013 w\u00e4hrend AIOps den Einsatz von KI f\u00fcr<\/em> den IT-Betrieb selbst bezeichnet.<\/p>\n

Der Begriff AIOps<\/em> (Artificial Intelligence for IT Operations) wurde 2016 von Gartner gepr\u00e4gt. Gem\u00e4\u00df der Gartner-Definition kombiniert AIOps \u201eBig Data und maschinelles Lernen, um IT-Betriebsprozesse zu automatisieren, einschlie\u00dflich Ereigniskorrelation, Anomalieerkennung und Kausalit\u00e4tsbestimmung" [4], [3]. AIOps erschien bereits 2017 auf Gartners Hype Cycle for Artificial Intelligence<\/em> und hat seitdem eine zunehmende Adoption in der Industrie erfahren.<\/p>\n

Cheng et al. [3] beschreiben eine vierstufige AIOps-Reifegradskala, die den Transformationspfad strukturiert: (1) Manual Ops<\/em>, bei dem alle Prozesse manuell durchgef\u00fchrt werden; (2) Human-Centric AIOps<\/em>, bei dem KI-Techniken als Assistenzsysteme einzelne Teilprozesse unterst\u00fctzen, etwa durch dynamische Grenzwerte auf Basis von Anomalieerkennungsmodellen; (3) Machine-Centric AIOps<\/em>, bei dem alle wesentlichen Betriebskomponenten \u2013 Monitoring, Detection, Triage und Remediation \u2013 durch komplexere KI-Verfahren gesteuert werden und Menschen prim\u00e4r in einer Human-in-the-Loop<\/em>-Rolle zur Feinabstimmung agieren; sowie (4) Fully-Automated AIOps<\/em>, bei dem die Plattform vollst\u00e4ndig autonom operiert und die CI\/CD-Pipeline zu einer CI\/CD\/CM\/CC-Pipeline (Continuous Monitoring und Continuous Correction) erweitert wird.<\/p>\n

Einen grundlegenden Umbruch markiert der Einsatz von Large Language Models<\/em> (LLMs) und generativer KI (GenAI) im AIOps-Kontext. W\u00e4hrend traditionelle AIOps-Methoden auf der Erkennung von Anomalien in strukturierten Daten basieren, erm\u00f6glichen LLMs durch F\u00e4higkeiten wie In-Context Learning<\/em> und Chain-of-Thought Reasoning<\/em> ein logisches Schlussfolgern \u00fcber unstrukturierte Daten und Systemgrenzen hinweg [5], [6]. Dies verschiebt den Fokus von der reinen Anomalieerkennung hin zur autonomen Entscheidungsfindung und Self-Healing<\/em>: Chen et al. [2] pr\u00e4gen hierf\u00fcr den Begriff AgentOps<\/em>, bei dem LLM-basierte Agenten den gesamten Incident-Lifecycle \u2013 von der Erkennung \u00fcber die Lokalisierung und Diagnose bis zur Mitigation \u2013 autonom verwalten. Shetty et al. [1] prognostizieren, dass solche Agenten Aufgaben in wenigen Minuten bew\u00e4ltigen k\u00f6nnen, f\u00fcr die selbst erfahrene Experten mehrere Stunden ben\u00f6tigen.<\/p>\n

C. Aufbau der Arbeit<\/h3>\n

Die vorliegende Arbeit gliedert sich entlang des AIOps-Incident-Lifecycles in sechs aufeinander aufbauende Abschnitte. Abschnitt II behandelt die Datengrundlage und Observability<\/em>, insbesondere die drei S\u00e4ulen Metriken, Logs und Traces sowie deren Vorverarbeitung im LLM-Zeitalter. Abschnitt III widmet sich den Kernaufgaben des AIOps-Zyklus<\/em> \u2013 Failure Perception, Root Cause Analysis und Auto-Remediation. In Abschnitt IV wird die Rolle von GenAI und Agentic AIOps<\/em> behandelt, darunter LLMs als kognitive Engine, Agenten-Architekturen und das Agent-Cloud-Interface. Abschnitt V diskutiert die wesentlichen Herausforderungen und Risiken<\/em>, von Prompt Injection \u00fcber Halluzinationsprobleme bis hin zu operativen Kosten. Abschnitt VI befasst sich mit Evaluierung und Benchmarking<\/em>, bevor Abschnitt VII die Ergebnisse zusammenfasst und einen Ausblick auf zuk\u00fcnftige Forschungsrichtungen gibt.<\/p>\n

II. Datengrundlage und Observability<\/h2>\n

Dieser Abschnitt behandelt die Datengrundlage des AIOps-Frameworks \u2013 die Sensing<\/em>-Ebene, ohne deren zuverl\u00e4ssige Implementierung keine intelligente Automatisierung m\u00f6glich ist.<\/p>\n

A. Die drei S\u00e4ulen der Observability<\/h3>\n

Eine umfassende Observability bildet das Fundament jeder AIOps-Plattform. Sie erm\u00f6glicht es, den internen Zustand eines komplexen, verteilten Systems anhand seiner externen Ausgaben zu erschlie\u00dfen und zu bewerten [1]. In der Industrie wird h\u00e4ufig das Akronym MELT<\/em> (Metrics, Events, Logs, Traces) verwendet; in der wissenschaftlichen Literatur hat sich hingegen eine Systematisierung in drei prim\u00e4re, systemgenerierte Telemetriedatentypen etabliert: Metriken<\/em>, Logs<\/em> und Traces<\/em> [3], [6], [7]. Events werden dabei in der Regel als Teilmenge der Logs betrachtet.<\/p>\n

1) Metriken<\/h4>\n

Metriken sind numerische Zeitreihendaten, die in regelm\u00e4\u00dfigen Intervallen erhoben werden, um den quantitativen Zustand von Systemressourcen und Anwendungen zu erfassen. Cheng et al. [3] unterscheiden zwischen Compute-Metriken<\/em> (z. B. CPU-Auslastung, Speicherverbrauch, Festplatten-I\/O) und Service-Metriken<\/em> (z. B. Antwortzeit, Durchsatz, Fehlerrate), w\u00e4hrend Zhang et al. [6] sie allgemeiner als quantitative Messwerte definieren, die den Ressourcenverbrauch und die Dienstg\u00fcte widerspiegeln.<\/p>\n

Der Hauptvorteil von Metriken liegt in ihrer strukturierten Natur und der Effizienz, mit der sie gespeichert, komprimiert und abgefragt werden k\u00f6nnen. Dies macht sie besonders geeignet f\u00fcr das Echtzeit-Monitoring von Trends und das Ausl\u00f6sen von Alarmen bei Schwellwert\u00fcberschreitungen. Allerdings leiden Metriken in modernen Cloud-Umgebungen h\u00e4ufig unter hoher Dimensionalit\u00e4t und Rauschen, was die Identifikation relevanter Signale erschwert [6]. Zudem fehlt ihnen typischerweise der semantische Kontext, um die Ursache eines Problems zu erkl\u00e4ren. Sie zeigen an, dass<\/em> ein Problem existiert, jedoch selten warum<\/em>.<\/p>\n

2) Logs<\/h4>\n

Logs sind detaillierte, textbasierte Aufzeichnungen diskreter Ereignisse, die von Anwendungen, Betriebssystemen oder Netzwerkger\u00e4ten generiert werden. Im Gegensatz zu Metriken sind sie reich an semantischen Informationen und enthalten h\u00e4ufig spezifische Fehlermeldungen, Stack Traces oder Transaktions-IDs, die f\u00fcr die Fehlerdiagnose unerl\u00e4sslich sind. Cheng et al. [3] beschreiben den typischen Analyseworkflow als dreistufigen Prozess aus Log Collection<\/em>, Log Parsing<\/em> und Log Mining<\/em>.<\/p>\n

Die zentrale Herausforderung bei der Verarbeitung von Logs ist ihr semi-strukturierter Charakter \u2013 jede Nachricht besteht aus einem statischen Template und dynamischen Parametern [3] \u2013 sowie das enorme Volumen, das in gro\u00dfen Systemen t\u00e4glich erzeugt wird. Zhang et al. [6] betonen, dass Logs aufgrund ihres textuellen Charakters die nat\u00fcrlichste und zugleich wichtigste Datenquelle f\u00fcr LLM-basierte AIOps-Ans\u00e4tze darstellen, da Sprachmodelle hier ihre St\u00e4rken in der Interpretation nat\u00fcrlicher Sprache und Programmcode voll entfalten k\u00f6nnen.<\/p>\n

3) Traces<\/h4>\n

Distributed Tracing erm\u00f6glicht die Verfolgung einer einzelnen Anfrage \u00fcber die gesamte Kette der involvierten Microservices hinweg. Ein Trace besteht aus mehreren Spans<\/em>, wobei jeder Span den Namen, den Zeitstempel, die Dauer und Metadaten einer bestimmten Operation innerhalb eines Services repr\u00e4sentiert [3]. In der Praxis kommen hierf\u00fcr Open-Source-Frameworks wie Jaeger<\/em> zum Einsatz [1].<\/p>\n

Traces sind essentiell, um Latenz-Engp\u00e4sse und Fehler in komplexen, lose gekoppelten Architekturen zu lokalisieren. Sie visualisieren den kausalen Pfad einer Transaktion und erm\u00f6glichen die Rekonstruktion von Abh\u00e4ngigkeiten zwischen Komponenten. Eine zentrale Herausforderung liegt im Sampling: Da das Speichern s\u00e4mtlicher Traces unverh\u00e4ltnism\u00e4\u00dfig teuer w\u00e4re, werden in der Praxis h\u00e4ufig nur Stichproben oder gezielt Fehler-Traces persistiert, was dazu f\u00fchren kann, dass sporadische Probleme unerkannt bleiben [3].<\/p>\n

B. Weitere Datenquellen und Integration<\/h3>\n

Neben den drei Kerns\u00e4ulen integrieren moderne AIOps-Systeme zunehmend weitere Datenquellen, um ein ganzheitliches Bild des Systemzustands zu erlangen.<\/p>\n

Eine besondere Rolle spielen hierbei menschengenerierte Daten<\/em> (Human-generated Data). Zhang et al. [6] systematisieren diese in vier Kategorien: Software Information<\/em> (Quellcode, Konfigurationsdateien), QA-Paare<\/em> aus internen Knowledge Bases oder Plattformen wie StackOverflow, Incident Reports<\/em> aus Ticketsystemen wie Jira sowie technische Dokumentationen<\/em> 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\u00dfen und bei der Diagnose neuer Fehler zu nutzen [8], [9].<\/p>\n

Ein weiterer Trend ist die multimodale Datenfusion<\/em>. Da Metriken, Logs und Traces h\u00e4ufig in isolierten Silos gespeichert werden, f\u00e4llt es traditionellen Algorithmen schwer, Korrelationen \u00fcber Datentypen hinweg zu erkennen [3], [10]. Neuere Ans\u00e4tze zielen darauf ab, diese heterogenen Modalit\u00e4ten in einen gemeinsamen Vektorraum (Embedding Space) zu projizieren. Dies erm\u00f6glicht 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\u00fcr die Log-Analyse einzuschr\u00e4nken.<\/p>\n

C. Datenvorverarbeitung im LLM-Zeitalter<\/h3>\n

Der Einsatz von Large Language Models transformiert nicht nur die Analyse, sondern auch die Vorverarbeitung (Preprocessing) von Betriebsdaten grundlegend.<\/p>\n

Log Parsing:<\/strong> Traditionelle Log-Parsing-Methoden wie Drain<\/em> oder Spell<\/em>, 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\u00e4tze sto\u00dfen jedoch an ihre Grenzen, wenn sich Log-Formate \u00e4ndern oder neue, unbekannte Log-Typen auftreten. LLM-basierte Ans\u00e4tze adressieren dieses Problem auf unterschiedliche Weise: LILAC<\/em> nutzt einen adaptiven Parsing-Cache mit In-Context Learning (ICL), LLMParser<\/em> evaluiert ICL und Few-Shot-Tuning auf Modellen wie Flan-T5 und LLaMA-7B, w\u00e4hrend DivLog<\/em> einen RAG-basierten Ansatz verfolgt [6]. Diese Verfahren zeigen eine h\u00f6here Flexibilit\u00e4t und Genauigkeit, insbesondere im Zero-Shot-Setting, erfordern jedoch mehr Rechenressourcen.<\/p>\n

Metric Imputation:<\/strong> In realen Monitoring-Systemen kommt es h\u00e4ufig zu L\u00fccken in den Daten, etwa durch Netzwerkausf\u00e4lle oder Neustarts von Monitoring-Agenten. Um die Qualit\u00e4t der nachgelagerten Anomalieerkennung zu gew\u00e4hrleisten, m\u00fcssen diese fehlenden Werte plausibel rekonstruiert werden (Imputation). W\u00e4hrend fr\u00fcher einfache statistische Methoden (z. B. lineare Interpolation) eingesetzt wurden, erm\u00f6glichen generative Modelle heute eine kontextabh\u00e4ngige Rekonstruktion. GatGPT<\/em> kombiniert hierzu Graph-Attention-Netzwerke mit LLMs f\u00fcr die Metriken-Imputation, w\u00e4hrend CRILM<\/em> LLM-generierte kontextuelle Deskriptoren zur Charakterisierung und Auff\u00fcllung fehlender Werte einsetzt [6].<\/p>\n

III. Kernaufgaben des AIOps-Zyklus<\/h2>\n

Die operative Phase des IT-Betriebs l\u00e4sst sich entlang des Incident-Lifecycles in drei aufeinander aufbauende Kernaufgaben gliedern. Diese entsprechen den in Abschnitt II beschriebenen Phasen Detect<\/em>, Engage<\/em> und Act<\/em> [3]. Zun\u00e4chst muss eine Anomalie \u00fcberhaupt erkannt werden (Failure Perception<\/em>), anschlie\u00dfend ist deren Ursache zu lokalisieren (Root Cause Analysis<\/em>), bevor schlie\u00dflich eine korrigierende Ma\u00dfnahme eingeleitet werden kann (Auto-Remediation<\/em>). Jede dieser Phasen wird durch eigene Metriken bewertet \u2013 die Mean Time to Detect<\/em> (MTTD), Mean Time to Triage<\/em> (MTTT) und Mean Time to Resolve<\/em> (MTTR) \u2013 und bietet spezifische Ansatzpunkte f\u00fcr KI-gest\u00fctzte Automatisierung. Dieser Abschnitt behandelt die drei Kernaufgaben systematisch und beleuchtet die jeweils eingesetzten Methoden, deren Leistungsf\u00e4higkeit sowie die zentralen Herausforderungen.<\/p>\n

A. Failure Perception<\/h3>\n

Failure Perception umfasst die Erkennung anomaler Systemzust\u00e4nde 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<\/em>), die als Alert Fatigue<\/em> die Produktivit\u00e4t der Operations-Teams deutlich beeintr\u00e4chtigen k\u00f6nnen [1], [3].<\/p>\n

1) Anomalieerkennung auf Metriken<\/h4>\n

Die einfachste Form der Anomalieerkennung auf Metriken ist die regelbasierte Methode, bei der ein Alarm ausgel\u00f6st wird, wenn eine Metrik einen festgelegten Schwellwert \u00fcberschreitet. Solche Ans\u00e4tze sind jedoch zu unflexibel f\u00fcr komplexe Systeme: Ein zu niedriger Schwellwert erzeugt viele Fehlalarme, ein zu hoher f\u00fchrt dazu, dass echte Anomalien \u00fcbersehen werden [3], [11]. Da Metriken als Time-Series-Daten vorliegen, wird die Anomalieerkennung typischerweise als Time Series Anomaly Detection<\/em> bezeichnet.<\/p>\n

Cheng et al. [3] systematisieren die Methoden anhand mehrerer Aspekte: Hinsichtlich des Lernparadigmas<\/em> werden \u00fcberwachte, un\u00fcberwachte und semi-\u00fcberwachte Ans\u00e4tze unterschieden, wobei un\u00fcberwachte 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\u00e4tzungen zur Erkennung von Ausrei\u00dfern nutzen, Clustering-basierten Ans\u00e4tzen, 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\u00e4t<\/em> ist zu unterscheiden, ob univariate Zeitreihen (einzelne Metriken) oder multivariate Zeitreihen (Gruppen korrelierter Metriken) analysiert werden. Multivariate Ans\u00e4tze sind in modernen Microservice-Umgebungen essenziell, da sie die Zusammenh\u00e4nge zwischen verschiedenen Metriken eines Systems modellieren k\u00f6nnen, die bei einer isolierten Betrachtung einzelner Zeitreihen verloren gehen [3].<\/p>\n

Hinsichtlich der eingesetzten Modellarchitekturen<\/em> reicht das Spektrum von statistischen Methoden \u00fcber baumbasierte Verfahren bis hin zu Deep-Learning-Modellen. Insbesondere rekurrente neuronale Netze (LSTMs), Variational Autoencoders (VAEs) und Transformer-Architekturen haben sich als leistungsf\u00e4hig erwiesen [3]. Einen aktuellen Fortschritt markiert STMformer<\/em>, ein Transformer-basiertes Modell, das speziell f\u00fcr die Zustandsvorhersage in Microservice-Umgebungen entwickelt wurde. STMformer nutzt dynamische Netzwerkverbindungsdaten und topologische Informationen, um die komplexen r\u00e4umlich-zeitlichen Abh\u00e4ngigkeiten innerhalb verteilter Systeme nachzubilden, und integriert ein PatchCrossAttention<\/em>-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\u00fcber f\u00fchrenden Vergleichsmethoden sowohl bei Kurzzeit- als auch bei Langzeitprognosen [12].<\/p>\n

2) Anomalieerkennung auf Logs und Traces<\/h4>\n

Neben der metrischen Anomalieerkennung spielen Log- und Trace-basierte Verfahren eine erg\u00e4nzende Rolle. F\u00fcr die Log-basierte Anomalieerkennung<\/em> hat sich ein mehrstufiger Workflow aus Log Parsing, Log Partitioning, Log Representation und der eigentlichen Anomalieerkennung etabliert [3]. Neuronale Modelle \u2013 darunter LSTM-basierte Sequenzmodelle wie DeepLog<\/em>, Autoencoder und Transformer-basierte Sprachmodelle wie LogBERT<\/em> \u2013 haben dabei klassische statistische Verfahren zunehmend abgel\u00f6st, da sie die semantische Bedeutung von Log-Eintr\u00e4gen besser erfassen und auch unbekannte Anomaliemuster erkennen k\u00f6nnen.<\/p>\n

Trace-basierte Anomalieerkennung<\/em> 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\u00e4tzen \u2013 etwa durch Graph Neural Networks (GNNs) wie in DeepTraLog<\/em> \u2013 k\u00f6nnen sowohl die Erkennungsgenauigkeit als auch die Lokalisierungsf\u00e4higkeit signifikant verbessert werden [3].<\/p>\n

3) Herausforderungen<\/h4>\n

Die praktische Anomalieerkennung steht vor mehreren grundlegenden Herausforderungen. Erstens erschwert der Mangel an gelabelten Daten<\/em> das Training und insbesondere die Evaluation von Erkennungsmodellen erheblich. Die Kennzeichnung von Anomalien erfordert tiefgreifendes Dom\u00e4nenwissen und ist extrem zeitaufw\u00e4ndig [3]. Zweitens stellt die Nichtstationarit\u00e4t<\/em> (Concept Drift) realer Daten ein zentrales Problem dar: Zeitmuster von Metriken \u00e4ndern sich kontinuierlich durch Software\u00e4nderungen, saisonale Effekte oder Wachstumstrends, sodass ein einmal trainiertes Modell ohne regelm\u00e4\u00dfige Aktualisierung an Genauigkeit verliert [13], [14]. Poenaru-Olaru et al. [13] zeigen, dass driftbasiertes Retraining \u2013 bei dem das Modell nur bei erkannten Datenver\u00e4nderungen neu trainiert wird \u2013 in vielen F\u00e4llen eine vergleichbare Genauigkeit wie periodisches Retraining erzielt und somit eine kosteneffiziente L\u00f6sung darstellt. Drittens m\u00fcssen Erkennungssysteme zwischen echten, intrinsischen Anomalien<\/em> und harmlosen, durch externe Faktoren verursachten Abweichungen (z. B. ein Anstieg der CPU-Auslastung als Folge eines geplanten Auto-Scaling-Vorgangs) unterscheiden k\u00f6nnen \u2013 eine Differenzierung, die in der Literatur als intrinsische vs. extrinsische Anomalieerkennung<\/em> debattiert wird [3].<\/p>\n

B. Root Cause Analysis (RCA)<\/h3>\n

W\u00e4hrend die Failure Perception identifiziert, dass<\/em> ein Problem existiert, zielt die Root Cause Analysis (RCA) darauf ab, die Ursache<\/em> des Problems zu lokalisieren. RCA tr\u00e4gt zur Verringerung der MTTT und MTTR bei und stellt in komplexen Microservice-Architekturen mit hunderten voneinander abh\u00e4ngiger Dienste eine der anspruchsvollsten Aufgaben im AIOps-Zyklus dar [3], [10].<\/p>\n

1) Topologie-Mapping und Graphenanalyse<\/h4>\n

In modernen Cloud-nativen Systemen sind die Abh\u00e4ngigkeiten zwischen Komponenten (Services, Pods, Nodes) hochgradig dynamisch und komplex. Eine zentrale Voraussetzung f\u00fcr 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\u00e4tze: Erstens k\u00f6nnen Topologiegraphen<\/em> aus vorhandenem Dom\u00e4nenwissen wie Service-Graphen und Call-Graphen rekonstruiert werden. Zweitens k\u00f6nnen Kausalit\u00e4tsgraphen<\/em> automatisch aus den beobachteten Metriken mittels kausaler Entdeckungsmethoden abgeleitet werden. Der prominenteste Algorithmus hierf\u00fcr ist der PC-Algorithmus (Peter-Clark-Algorithmus), der ausgehend von einem vollst\u00e4ndig verbundenen ungerichteten Graphen Kanten durch bedingte Unabh\u00e4ngigkeitstests ausgeschlossen und anschlie\u00dfend die Kantenorientierungen durch die Identifikation von V-Strukturen bestimmt [3].<\/p>\n

Auf dem konstruierten Graphen k\u00f6nnen verschiedene analytische Verfahren angewendet werden, um die Grundursache zu identifizieren. Random-Walk<\/em>-basierte Methoden starten von einem anomalen Knoten und durchlaufen den Graphen, wobei die am h\u00e4ufigsten besuchten Knoten als wahrscheinlichste Ursachen gelten. Die \u00dcbergangswahrscheinlichkeiten werden dabei typischerweise auf Basis der Korrelation jeder Metrik mit den erkannten anomalen Metriken berechnet [3]. Alternative Verfahren nutzen PageRank<\/em>-Varianten oder Breitensuche-Algorithmen zur kausalen Pfadanalyse.<\/p>\n

2) Multimodale Fehlerdiagnose<\/h4>\n

Eine Einschr\u00e4nkung, die in unimodalen RCA-Ans\u00e4tzen 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\u00e4ufig Korrelation mit Kausalit\u00e4t, Log-Analyse ist durch die Qualit\u00e4t des Template-Minings limitiert, und Trace-Analyse leidet unter Sampling-Sparseness in Szenarien mit hoher Last. Um diese Defizite zu adressieren, verfolgen neuere Ans\u00e4tze eine multimodale Fusion<\/em> der drei Observability-S\u00e4ulen.<\/p>\n

Das von Hou [10] vorgeschlagene KylinRCA<\/em>-Framework kombiniert dynamische kausale Entdeckung mit cross-modaler Graphanalyse. Es vereint die Vorteile zweier Forschungsstr\u00e4nge: Erstens die dynamische kausale Entdeckung, die mittels Temporal Causal Networks<\/em> (TCN) und temporalen Perturbationsexperimenten kausale Beziehungen zwischen Metriken aufdeckt, und zweitens die multimodale Cross-Level-Fusion, die heterogene Daten (Metriken, Logs, Traces) \u00fcber hierarchische Ebenen hinweg (Host\u2013Pod\u2013Service) 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\u00fcber unimodalen Baselines darstellt [10].<\/p>\n

3) LLM-gest\u00fctzte RCA<\/h4>\n

Der Einsatz von Large Language Models er\u00f6ffnet neue M\u00f6glichkeiten f\u00fcr die RCA, insbesondere bei der Interpretation komplexer Fehlerbilder und der Generierung verst\u00e4ndlicher Diagnoseberichte. Goel et al. [15] pr\u00e4sentieren mit eARCO<\/em> (Efficient Automated Root Cause Analysis) einen Ansatz, der Prompt-Optimierung mit historischen Incident-Daten kombiniert. Unter Nutzung von \u00fcber 180.000 historischen Incidents von Microsoft werden kosteneffiziente, feinabgestimmte Small Language Models<\/em> (SLMs) f\u00fcr die RCA-Empfehlungsgenerierung eingesetzt. Die Autoren zeigen, dass Prompt-Optimierung die Genauigkeit der RCA-Empfehlungen um 21 % gegen\u00fcber RAG-basierten LLMs und um 13 % gegen\u00fcber feinabgestimmten SLMs verbessert [15]. Ein weiterer vielversprechender Ansatz ist das Incident Triage<\/em>, bei dem ML-Systeme Incidents automatisch dem verantwortlichen Team zuweisen. DeepTriage<\/em> 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\u00fcr besonders kritische Incidents Werte von bis zu 91,3 % erzielt werden [16].<\/p>\n

Laut Zhang et al. [6] sind LLMs durch ihre F\u00e4higkeiten im In-Context Learning<\/em> und Chain-of-Thought Reasoning<\/em> besonders geeignet, unstrukturierte Daten wie Logs, Incident Reports und technische Dokumentationen in den RCA-Prozess zu integrieren \u2013 Datenquellen, die traditionellen ML-Modellen weitgehend unzug\u00e4nglich waren.<\/p>\n

C. Auto-Remediation<\/h3>\n

Auto-Remediation, die finale Phase des Incident-Lifecycles, besch\u00e4ftigt sich mit der Frage, wie<\/em> ein erkanntes und diagnostiziertes Problem behoben werden kann. Ziel ist die Minimierung der MTTR bis hin zu einer vollst\u00e4ndig autonomen Fehlerbehebung ohne menschliche Intervention [3].<\/p>\n

1) Ebenen der Autonomie<\/h4>\n

Die Automatisierung der Remediation l\u00e4sst sich entlang des in Abschnitt I beschriebenen AIOps-Reifegradmodells einordnen [3]. Auf der Stufe Human-Centric AIOps<\/em> fungieren KI-Systeme als Empfehlungssysteme: Sie schlagen Remediation-Ma\u00dfnahmen vor, die ein menschlicher Operator pr\u00fcft 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<\/em> \u00fcbernehmen KI-Agenten die Ausf\u00fchrung routinem\u00e4\u00dfiger Remediation-Aktionen autonom, w\u00e4hrend Menschen in einer Human-in-the-Loop<\/em>-Rolle nur bei schwerwiegenden oder neuartigen Fehlern eingreifen. Auf der h\u00f6chsten Stufe, Fully-Automated AIOps<\/em>, operiert die Plattform vollst\u00e4ndig autonom und erweitert die CI\/CD-Pipeline um Continuous Monitoring<\/em> und Continuous Correction<\/em> (CI\/CD\/CM\/CC) [3].<\/p>\n

2) Methoden und Technologien<\/h4>\n

Traditionelle Auto-Remediation basiert auf vordefinierten Policies und Regeln, die f\u00fcr bekannte Fehlerkategorien feste Workflows spezifizieren. ML-basierte Ans\u00e4tze erweitern dieses Konzept, indem sie aus historischen Incidents und deren L\u00f6sungen lernen, um die optimale Remediation-Strategie dynamisch zu bestimmen [3]. Ein prominentes Beispiel ist Narya<\/em>, ein von Microsoft entwickeltes System zur Failure-Remediation f\u00fcr 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\u00e4hlen, und erzielte signifikante Einsparungen bei VM-Ausf\u00e4llen gegen\u00fcber statischen Methoden [3].<\/p>\n

Bellala [11] beschreibt ein umfassendes Framework f\u00fcr Self-Healing Kubernetes<\/em>-\u00d6kosysteme, das AIOps-Prinzipien auf die gesamte Kubernetes-Management-Kette anwendet. Das Framework implementiert einen geschlossenen Observation-Action-Zyklus<\/em>: Eine Observability-Plattform erfasst Metriken, Logs und Traces, ein AIOps-Engine analysiert die Daten mittels ML-basierter Anomalieerkennung und RCA, und eine Aktionsschicht f\u00fchrt die Remediation sicher \u00fcber Kubernetes-Operatoren aus. Zentral ist dabei das Operator-Pattern<\/em>: Anstatt imperative Befehle via kubectl<\/code> auszuf\u00fchren, deklariert die AIOps-Engine den gew\u00fcnschten Zielzustand als Custom Resource, die ein dedizierter Remediation-Operator \u00fcberwacht und kontrolliert umsetzt [11].<\/p>\n

Im Kontext generativer KI erm\u00f6glicht der Einsatz von LLMs zudem die automatische Generierung von Reparaturskripten<\/em>, 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<\/em> die Vision, dass LLM-basierte Agenten den gesamten Incident-Lifecycle \u2013 von der Erkennung \u00fcber die Diagnose bis zur Mitigation \u2013 autonom verwalten. Ein zentrales Forschungsproblem bleibt jedoch die Sicherheit<\/em> solcher autonomen Aktionen: Die Gew\u00e4hrleistung, dass KI-generierte Remediation-Ma\u00dfnahmen keine unbeabsichtigten Nebeneffekte verursachen, erfordert robuste Validierungsmechanismen und stufenweise Freigabeprozesse, die in Abschnitt V vertieft diskutiert werden.<\/p>\n

IV. GenAI und Agentic AIOps<\/h2>\n

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.<\/p>\n

A. LLMs als kognitive Engine<\/h3>\n

Die Transformer-Architektur [17] bildet das Fundament moderner LLMs und hat durch ihren Self-Attention-Mechanismus die Verarbeitung langer Kontextfenster und komplexer Abh\u00e4ngigkeiten grundlegend verbessert. F\u00fcr AIOps sind dabei vor allem drei F\u00e4higkeiten relevant, die LLMs von klassischen ML-Ans\u00e4tzen unterscheiden: In-Context Learning<\/em> (ICL) erlaubt es, aus wenigen im Prompt bereitgestellten Beispielen zu lernen, ohne erneutes Training; Chain-of-Thought<\/em> (CoT) Reasoning erm\u00f6glicht mehrstufiges logisches Schlussfolgern; und die Verarbeitung nat\u00fcrlicher Sprache gestattet die direkte Interpretation unstrukturierter Daten wie Logs, Incident Reports und technischer Dokumentationen [5], [6].<\/p>\n

1) LLM-Nutzungsstrategien<\/h4>\n

Zhang et al. [6] unterscheiden vier Hauptkategorien der LLM-Anwendung in AIOps. Prompting<\/em> umfasst die Techniken Zero-Shot und Few-Shot, bei denen das Modell ohne bzw. mit wenigen Beispielen im Prompt Aufgaben l\u00f6st. Goel et al. [15] demonstrieren mit eARCO<\/em>, dass automatisierte Prompt-Optimierung die Genauigkeit von RCA-Empfehlungen um 21 % gegen\u00fcber RAG-basierten Ans\u00e4tzen steigern kann, indem das System selbstst\u00e4ndig optimale Instruktionen und semantisch \u00e4hnliche historische Beispiele f\u00fcr die Inferenz identifiziert. Fine-Tuning<\/em> bezeichnet die Anpassung vortrainierter Modelle an dom\u00e4nenspezifische AIOps-Daten, wobei zwischen dem ressourcenintensiven vollst\u00e4ndigen Fine-Tuning und parametereffizienten Methoden wie LoRA<\/em> (Low-Rank Adaptation) und QLoRA<\/em> unterschieden wird. Hybride Ans\u00e4tze<\/em> kombinieren Prompting und Fine-Tuning, etwa durch den Einsatz feinabgestimmter Small Language Models<\/em> (SLMs) mit optimierten Prompts, wie in eARCO gezeigt [15]. Schlie\u00dflich kommen agentenbasierte Methoden<\/em> zum Einsatz, bei denen LLMs als zentrale Reasoning-Komponente in autonome Systeme integriert werden, die \u00fcber Tool-Aufrufe mit ihrer Umgebung interagieren, ein Ansatz, der in Abschnitt IV-B vertieft wird.<\/p>\n

2) Retrieval-Augmented Generation (RAG)<\/h4>\n

Um Halluzinationen zu reduzieren und das Modell mit aktuellem, dom\u00e4nenspezifischem Kontext anzureichern, hat sich Retrieval-Augmented Generation<\/em> (RAG) als wirksame Technik etabliert. Vor der eigentlichen LLM-Inferenz wird dabei eine Retrievalphase eingeschoben, in der relevante Dokumente aus einer Wissensdatenbank \u2013 etwa historische Incident Reports, Runbooks, technische Dokumentationen oder QA-Paare aus internen Knowledge Bases \u2013 abgerufen und dem Prompt als Kontext hinzugef\u00fcgt werden [8], [9].<\/p>\n

Im AIOps-Kontext hat RAG besondere Relevanz, weil es das allgemeine Wissen eines LLMs mit dem spezifischen Wissen einer Organisation verkn\u00fcpft. Zhang et al. [6] identifizieren RAG-basierte Ans\u00e4tze in zahlreichen AIOps-Teilaufgaben, darunter Log Parsing (DivLog<\/em>), Anomalieerkennung und Root Cause Analysis. Vitui und Chen [8] demonstrieren den Einsatz von RAG zur Erschlie\u00dfung von Plattformdokumentation in einer Red Hat OpenShift-Umgebung: Ein LLM-Agent kann \u00fcber eine spezialisierte Vektordatenbank Installationsprozeduren und Konfigurationsanleitungen abrufen und kontextbezogen zusammenfassen, was den Engineer von aufw\u00e4ndiger manueller Dokumentationsrecherche entlastet.<\/p>\n

B. Agenten-Architekturen<\/h3>\n

Mit dem \u00dcbergang von statischen LLM-Inferenzen zu interaktiven, werkzeuggest\u00fctzten Agenten zeichnet sich die n\u00e4chste Entwicklungsstufe im AIOps-Bereich ab. Ein isoliertes LLM bleibt auf die Informationen im Prompt beschr\u00e4nkt; ein LLM-basierter Agent<\/em> hingegen kann aktiv mit seiner Umgebung interagieren, indem er Hypothesen formuliert, diagnostische Aktionen ausf\u00fchrt, deren Ergebnisse beobachtet und seine Schlussfolgerungen iterativ verfeinert [1], [2].<\/p>\n

1) Das ReAct-Framework<\/h4>\n

Das von Yao et al. [18] eingef\u00fchrte ReAct<\/em>-Framework (Reasoning and Acting) liegt vielen AIOps-Agenten konzeptionell zugrunde. Es verbindet die Reasoning-F\u00e4higkeiten von LLMs, insbesondere Chain-of-Thought-Prompting, mit der M\u00f6glichkeit, externe Werkzeuge aufzurufen und deren Ergebnisse in den Schlussfolgerungsprozess einzubeziehen. Der Agent operiert in einem iterativen Thought-Action-Observation<\/em>-Zyklus: Er formuliert eine \u00dcberlegung (Thought<\/em>), f\u00fchrt eine Aktion aus (Action<\/em>), etwa den Aufruf einer API oder die Ausf\u00fchrung eines Shell-Befehls, und verarbeitet die resultierende Beobachtung (Observation<\/em>), um den n\u00e4chsten Schritt zu planen.<\/p>\n

Konkret kann ein ReAct-Agent in der AIOps-Praxis etwa zun\u00e4chst Logs eines fehlerhaften Services abrufen (get_logs<\/code>), aus den Log-Eintr\u00e4gen eine Hypothese \u00fcber die Fehlerursache ableiten, diese durch Abfrage von Metriken (get_metrics<\/code>) oder Traces (get_traces<\/code>) verifizieren und schlie\u00dflich eine korrigierende Aktion wie das Patchen einer Kubernetes-Konfiguration via kubectl<\/code> ausf\u00fchren [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\u201312 Interaktionsrunden und Kosten von etwa 0,25 USD anfielen.<\/p>\n

2) AgentOps und Multi-Agenten-Systeme<\/h4>\n

Chen et al. [2] pr\u00e4gen den Begriff AgentOps<\/em> (Agent for Operations), um ein Paradigma zu beschreiben, in dem LLM-basierte Agenten nicht auf isolierte Aufgaben beschr\u00e4nkt sind, sondern den gesamten Incident-Lifecycle \u2013 Erkennung, Lokalisierung, Ursachenanalyse und Mitigation \u2013 autonom und Ende-zu-Ende verwalten. Gegen\u00fcber herk\u00f6mmlichen AIOps-Ans\u00e4tzen, die jeweils nur einzelne Phasen abdecken, bedeutet dies eine qualitative Weiterentwicklung.<\/p>\n

Neben einfachen Single-Agent-Architekturen setzen neuere Arbeiten auf Multi-Agenten-Systeme<\/em>, in denen spezialisierte Agenten kooperieren. Das FLASH<\/em>-Framework implementiert ein Workflow-Automatisierungssystem, das komplexe Instruktionen in handhabbare, bedingte Segmente zerlegt und Hindsight Generation<\/em> nutzt, um aus vergangenen Interaktionen zu lernen [2]. In der Evaluierung mit dem AIOpsLab-Benchmark erzielte FLASH mit 59,32 % die h\u00f6chste Gesamtgenauigkeit unter vier getesteten Agenten, wobei es bei Mitigationsaufgaben 54,55 % erreichte, verglichen mit 36,36 % f\u00fcr ReAct und 27,27 % f\u00fcr einen reinen GPT-4-Agenten mit Shell-Zugang [2].<\/p>\n

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\u00e4tsplanung. Die Ergebnisse belegen deutliche Leistungsunterschiede zwischen den LLM-Familien: GPT-4o erzielt 100 % Genauigkeit bei komplexen Multi-Tool-Aufgaben (Advanced Reasoning<\/em>), w\u00e4hrend 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].<\/p>\n

3) Herausforderungen agentenbasierter Systeme<\/h4>\n

Die Evaluierung in AIOpsLab legt mehrere Schw\u00e4chen heutiger LLM-Agenten offen [2]. So verschwenden Agenten h\u00e4ufig Interaktionsschritte durch unn\u00f6tige Aktionen, etwa wiederholte API-Aufrufe mit identischen Parametern oder die Generierung nicht existierender APIs. Hinzu kommt die Informations\u00fcberflutung<\/em> durch umfangreiche Telemetriedaten und die damit verbundene Verschwendung des Kontextfensters: Agenten, die Metriken oder Traces undifferenziert aufnehmen, ersch\u00f6pfen ihr Token-Budget ohne Gewinn. Ein weiteres Problem ist das Stagnieren der Selbstkorrektur<\/em>. 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].<\/p>\n

C. Das Agent-Cloud-Interface (ACI)<\/h3>\n

Die bisherige Forschung zu AIOps-Agenten zeigt, dass neben der Leistungsf\u00e4higkeit des zugrunde liegenden LLMs vor allem die Qualit\u00e4t der Schnittstelle<\/em> zwischen Agent und Cloud-Umgebung die Effektivit\u00e4t des Gesamtsystems bestimmt [1].<\/p>\n

1) Designprinzipien<\/h4>\n

Traditionelle Cloud-Interfaces wie Dashboards, CLI-Tools, Incident-Portale sind f\u00fcr menschliche Operatoren konzipiert und erweisen sich f\u00fcr LLM-basierte Agenten als problematisch. W\u00e4hrend Menschen irrelevante Informationen zuverl\u00e4ssig ignorieren k\u00f6nnen, werden Agenten durch \u00fcberfl\u00fcssigen Kontext abgelenkt, was ihre Leistung beeintr\u00e4chtigt [1]. Inspiriert vom Konzept des Agent-Computer-Interface<\/em> aus der Softwareentwicklung formulieren Shetty et al. [1] das Agent-Cloud-Interface<\/em> (ACI) als Orchestrator zwischen Agent und Cloud. Das ACI spezifiziert zwei Dimensionen: (1) den Aktionsraum<\/em>, also die Menge der verf\u00fcgbaren, dokumentierten APIs (z. B. get_logs<\/code>, get_metrics<\/code>, get_traces<\/code>, exec_shell<\/code>), und (2) die Zustandsr\u00fcckmeldung<\/em>, also wie der aktuelle Systemzustand nach jeder Aktion an den Agenten kommuniziert wird, einschlie\u00dflich strukturierter Ausgaben, Fehlermeldungen und Tracebacks.<\/p>\n

Chen et al. [2] implementieren dieses Konzept in AIOpsLab<\/em> 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\u00f6sungen anhand vordefinierter Metriken wie Time-to-Detect<\/em> und Time-to-Mitigate<\/em>. Die Evaluierung zeigt, dass die Effizienz der verf\u00fcgbaren Aktionen direkt die Agentenleistung beeinflusst: Zu wenige APIs schr\u00e4nken die Erkennung ein, w\u00e4hrend zu viele Argumente pro API die Leistung beeintr\u00e4chtigen [1].<\/p>\n

2) Deterministische \u00dcbersetzungsschichten<\/h4>\n

Das ACI-Konzept definiert den Interaktionsrahmen auf konzeptioneller Ebene. Auf der technischen Seite adressiert MCP-Diag<\/em> von Lodha et al. [19] zwei konkrete Implementierungsbarrieren: das Stochastic Grounding Problem<\/em> und die Security Gap<\/em>. Das Stochastic Grounding Problem entsteht, weil CLI-Werkzeuge wie ping<\/code>, traceroute<\/code> oder dig<\/code> unstrukturierte, herstellerspezifische Textausgaben erzeugen, deren probabilistisches Parsing durch ein LLM fehleranf\u00e4llig ist. Die Security Gap ergibt sich aus dem Risiko, autonomen Agenten direkten Shell-Zugang zu gew\u00e4hren, wodurch Prompt-Injection-Angriffe oder die unbeabsichtigte Ausf\u00fchrung destruktiver Befehle m\u00f6glich werden.<\/p>\n

MCP-Diag begegnet diesen Problemen mit einer hybriden Architektur auf Basis des Model Context Protocol<\/em> (MCP). Eine deterministische \u00dcbersetzungsschicht<\/em> konvertiert rohe CLI-Ausgaben serverseitig in typsichere JSON-Schemata, bevor sie dem LLM zur Verf\u00fcgung gestellt werden. Das Modell interagiert somit ausschlie\u00dflich mit strukturierten Datenobjekten, nicht mit unstrukturiertem Text. Ferner implementiert MCP-Diag einen obligatorischen Elicitation Loop<\/em>, der die Ausf\u00fchrung jeder sicherheitskritischen Operation an eine explizite Freigabe durch einen menschlichen Operator auf Protokollebene bindet \u2013 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 \u00fcber 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\u00fcber einer unstrukturierten Baseline [19].<\/p>\n

V. Herausforderungen und Risiken<\/h2>\n

Die in den vorangegangenen Abschnitten vorgestellten KI-Methoden, von spezialisierten ML-Modellen f\u00fcr die Anomalieerkennung bis hin zu LLM-basierten Agenten f\u00fcr die autonome Fehlerbehebung, versprechen erhebliche Effizienzgewinne im IT-Betrieb. Zugleich bringen sie jedoch neue Risiken mit sich, die bei einer unreflektierten Einf\u00fchrung die Zuverl\u00e4ssigkeit und Sicherheit der verwalteten Systeme gef\u00e4hrden k\u00f6nnen. Die zentralen Herausforderungen lassen sich in drei Bereiche gliedern: Sicherheitsrisiken durch die Manipulation von Eingabedaten, Vertrauensprobleme durch Halluzinationen und Automation Bias sowie operative H\u00fcrden bei Kosten, Modellpflege und der Einf\u00fchrung in Organisationen.<\/p>\n

A. Sicherheit und Telemetrie-Manipulation<\/h3>\n

AIOps-Agenten treffen ihre Entscheidungen auf Grundlage von Telemetriedaten (Logs, Metriken und Traces), die bislang implizit als vertrauensw\u00fcrdig angenommen wurden. Pasquini et al. [20] stellen diese Annahme grundlegend in Frage und pr\u00e4sentieren mit AIOpsDoom<\/em> 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\u00f6nnen, um AIOps-Agenten zu sch\u00e4dlichen Remediation-Aktionen zu verleiten.<\/p>\n

Der Angriff basiert auf der Telemetry Injection<\/em>: Durch das gezielte Ausl\u00f6sen von Fehlerereignissen \u00fcber \u00f6ffentliche Schnittstellen, etwa durch HTTP-Anfragen an nicht existierende Ressourcen oder mit manipulierten Header-Feldern wie User-Agent<\/code> oder Referer<\/code>, 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].<\/p>\n

Die dabei eingesetzten Payloads unterscheiden sich fundamental von klassischer Prompt Injection. W\u00e4hrend Prompt-Injection-Angriffe versuchen, die Aufgabe des LLMs direkt zu \u00fcberschreiben, nutzt Adversarial Reward-Hacking<\/em> gezielt aus, dass der Agent darauf ausgelegt ist, sein operatives Ziel (die Identifikation einer Ursache und einer Remediation) m\u00f6glichst effizient zu erf\u00fcllen. Die Payloads bestehen aus einem plausiblen, jedoch falschen Lead<\/em> (einer erfundenen Fehlerursache) und einem sch\u00e4dlichen Body<\/em> (der vorgeschlagenen Remediation), etwa dem Downgrade auf eine Softwareversion mit bekannten Sicherheitsl\u00fccken. Der Agent \u00fcbernimmt diese Information als vermeintliche Diagnose, ohne die Legitimit\u00e4t der Log-Eintr\u00e4ge zu hinterfragen [20]. In Evaluierungen \u00fcber 180 Trials mit GPT-4o und GPT-4.1 erzielte der Angriff eine durchschnittliche Erfolgsrate von 90 %, w\u00e4hrend 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].<\/p>\n

Als Gegenma\u00dfnahme schlagen Pasquini et al. [20] AIOpsShield<\/em> vor, einen Verteidigungsmechanismus, der drei Eigenschaften von AIOps-Telemetrie ausnutzt: die endliche Menge m\u00f6glicher Telemetrieausgaben, deren strukturierte Natur sowie die geringe Relevanz nutzergenerierter Inhalte f\u00fcr die Incident Response. In einer automatisierten Setup-Phase f\u00fchrt AIOpsShield eine Telemetry Taint Analysis<\/em> durch, die mittels Fuzzing alle durch externe Eingaben beeinflussbaren Telemetrieeintr\u00e4ge identifiziert und daraus Parsing-Templates ableitet. Zur Laufzeit werden untrusted Felder in den Telemetriedaten automatisch durch abstrakte Platzhalter ersetzt, bevor sie dem Agenten \u00fcbergeben werden. In der Evaluierung blockierte AIOpsShield s\u00e4mtliche Angriffe, ohne die Agentenleistung auf dem AIOpsLab-Benchmark signifikant zu beeintr\u00e4chtigen [20].<\/p>\n

Einen komplement\u00e4ren Ansatz verfolgt MCP-Diag<\/em> [19], das in Abschnitt IV eingef\u00fchrt wurde. Die deterministische \u00dcbersetzungsschicht und der protokollseitig verankerte Elicitation Loop adressieren sowohl das Stochastic Grounding Problem als auch die Security Gap bei der Gew\u00e4hrung 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\u00e4glich erg\u00e4nzt, sondern als integraler Bestandteil des Systemdesigns konzipiert werden muss [20].<\/p>\n

B. Halluzinationen und Vertrauen<\/h3>\n

Large Language Models k\u00f6nnen plausibel formulierte, jedoch faktisch inkorrekte Ausgaben erzeugen. Dieses Ph\u00e4nomen wird als Halluzination<\/em> bezeichnet. Im AIOps-Kontext zeigt sich dieses Risiko in Form falscher Diagnosen, nicht existierenden API-Aufrufen oder fehlerhaften Remediation-Skripten, deren Ausf\u00fchrung 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\u00e4tze, insbesondere wenn Modelle ohne ausreichenden dom\u00e4nenspezifischen Kontext operieren.<\/p>\n

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\u00fcber RAG-basierten LLMs, was darauf hindeutet, dass die Art der Kontextaufbereitung ebenso entscheidend ist wie die blo\u00dfe Verf\u00fcgbarkeit externer Informationen. Fine-Tuning auf dom\u00e4nenspezifischen Daten mittels Small Language Models (SLMs) bietet eine weitere M\u00f6glichkeit, Halluzinationen zu reduzieren und zugleich die Inferenzkosten zu senken [15].<\/p>\n

Neben diesen technischen Gegenma\u00dfnahmen stellt auch die Mensch-KI-Interaktion eine eigenst\u00e4ndige Herausforderung dar. Dai und Swaminathan [21] identifizieren zwei gegenl\u00e4ufige kognitive Verzerrungen, die den effektiven Einsatz von KI-Systemen erschweren: Automation Bias<\/em> 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 \u00dcbernahme von Agentenvorschl\u00e4gen neigen k\u00f6nnen. Demgegen\u00fcber steht Algorithm Aversion<\/em>, die Neigung, Algorithmen nach einem einzigen beobachteten Fehler grunds\u00e4tzlich zu misstrauen, selbst wenn die algorithmische Leistung im Durchschnitt die menschliche \u00fcbertrifft. Beide Effekte f\u00fchren zu einer Fehlkalibrierung des Vertrauens, die den operativen Nutzen von AIOps-Systemen untergr\u00e4bt.<\/p>\n

F\u00fcr den produktiven Einsatz von AIOps-Agenten ist daher ein kalibriertes Vertrauen<\/em> erforderlich, das weder in \u00dcbervertrauen noch in pauschale Ablehnung m\u00fcndet [21]. Dies erfordert zun\u00e4chst geeignete Interface-Designs, die dem Operator Konfidenzwerte, alternative Diagnosen und die vom Agenten genutzten Evidenzen transparent machen. Dar\u00fcber hinaus m\u00fcssen die in Abschnitt IV beschriebenen Autonomiestufen konsequent umgesetzt werden: Auf der Stufe Human-Centric AIOps<\/em> genehmigt der Operator jede Aktion explizit, auf der Stufe Machine-Centric AIOps<\/em> 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<\/em> in Kubernetes, bei dem der gew\u00fcnschte Zielzustand deklarativ spezifiziert wird und ein dedizierter Operator die kontrollierte Umsetzung \u00fcberwacht, anstatt dem Agenten direkte imperative Befehle zu gestatten.<\/p>\n

C. Operative Herausforderungen<\/h3>\n

1) Kosten und Inferenz-Latenz<\/h4>\n

Der Einsatz gro\u00dfer 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\u201312 Interaktionsrunden. In Organisationen mit hunderten t\u00e4glicher Incidents k\u00f6nnen sich diese Kosten erheblich akkumulieren. Zudem dokumentieren Chen et al. [2], dass Agenten h\u00e4ufig 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\u00f6he.<\/p>\n

Die Leistungsunterschiede zwischen Modellfamilien versch\u00e4rfen dieses Kosten-Nutzen-Dilemma. Vitui und Chen [8] zeigen, dass GPT-4o bei komplexen Multi-Tool-Aufgaben eine Genauigkeit von 100 % erzielt, w\u00e4hrend 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\u00e4nenadaptierte SLMs in Kombination mit Prompt-Optimierung eine vergleichbare Genauigkeit wie deutlich gr\u00f6\u00dfere Modelle erreichen k\u00f6nnen, bei signifikant geringeren Inferenzkosten. Diese Ergebnisse deuten darauf hin, dass die Zukunft kosteneffizienter AIOps-Systeme weniger in der Skalierung der Modellgr\u00f6\u00dfe liegt als in der intelligenten Kombination spezialisierter, kleinerer Modelle mit optimierten Prompting-Strategien.<\/p>\n

2) Model Drift und Wissensveralterung<\/h4>\n

AIOps-Modelle operieren in einer grunds\u00e4tzlich ver\u00e4nderlichen Umgebung: Software\u00e4nderungen, Infrastruktur-Migrationen und sich wandelnde Lastmuster ver\u00e4ndern die statistischen Eigenschaften der Betriebsdaten kontinuierlich. Dieser als Concept Drift<\/em> bezeichnete Effekt f\u00fchrt dazu, dass ein einmal trainiertes Modell ohne regelm\u00e4\u00dfige Aktualisierung an Genauigkeit verliert. Poenaru-Olaru et al. [13] untersuchen verschiedene Retraining-Strategien f\u00fcr Anomalieerkennungsmodelle und zeigen, dass driftbasiertes Retraining, bei dem das Modell nur bei erkannten Datenver\u00e4nderungen neu trainiert wird, in den meisten F\u00e4llen 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\u00e4hrleisten [14].<\/p>\n

Lyu et al. [22] verfolgen einen alternativen Ansatz und untersuchen, ob historische, bereits verworfene Modelle f\u00fcr neue Vorhersageaufgaben wiederverwendet werden k\u00f6nnen. Ihre Ergebnisse zeigen, dass Modellselektionsmechanismen, die auf temporaler N\u00e4he basieren, h\u00e4ufig dem periodischen Retraining \u00fcberlegen sind. Dieser Befund deutet darauf hin, dass nicht jede Datenver\u00e4nderung ein vollst\u00e4ndiges Neutraining rechtfertigt, sondern die gezielte Auswahl eines geeigneten historischen Modells effizienter sein kann.<\/p>\n

F\u00fcr LLM-basierte Ans\u00e4tze stellt sich das Problem der Wissensveralterung zus\u00e4tzlich auf der Ebene des parametrischen Modellwissens: \u00c4nderungen 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\u00e4t der zugrunde liegenden Wissensdatenbanken bleibt jedoch eine organisatorische Aufgabe, die kontinuierlichen Aufwand erfordert.<\/p>\n

3) Adoption und organisatorische Barrieren<\/h4>\n

Den technischen Fortschritten im Bereich AIOps steht eine nach wie vor langsame Einf\u00fchrung in der Praxis gegen\u00fcber. Zimelewicz et al. [23] dokumentieren in einer internationalen Umfrage mit 188 Teilnehmern aus 25 L\u00e4ndern, 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.<\/p>\n

Bendimerad et al. [24] berichten aus der Perspektive eines mittelst\u00e4ndischen Softwareunternehmens \u00fcber die praktischen H\u00fcrden bei der Implementierung einer On-Premise-AIOps-Infrastruktur. Kommerzielle L\u00f6sungen erwiesen sich aufgrund hoher Kosten, fehlender Abdeckung propriet\u00e4rer Software und Bedenken hinsichtlich der Datenhoheit als ungeeignet. Die Autoren beschreiben den Aufbau einer vollst\u00e4ndig auf Open-Source-Werkzeugen basierenden AIOps-Infrastruktur und betonen die Notwendigkeit sorgf\u00e4ltiger Designentscheidungen bei der Auswahl des Datenmanagementsystems und dessen Integration in bestehende Prozesse.<\/p>\n

Vitui und Chen [8] identifizieren drei \u00fcbergreifende Barrieren f\u00fcr die Einf\u00fchrung von AIOps: Erstens die Datenqualit\u00e4t<\/em>, da AIOps-Methoden auf konsistente und vollst\u00e4ndige Telemetriedaten angewiesen sind, die in heterogenen Produktivumgebungen selten gegeben ist. Zweitens die Umgebungskomplexit\u00e4t<\/em>, die es erschwert, generisch trainierte Modelle ohne dom\u00e4nenspezifische Anpassung einzusetzen. Drittens die Qualifikationsl\u00fccke<\/em> 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\u00e4higkeit abh\u00e4ngt, sondern ma\u00dfgeblich durch organisatorische Rahmenbedingungen, Investitionen in Datenqualit\u00e4t und den Aufbau interdisziplin\u00e4rer Kompetenzen bestimmt wird.<\/p>\n

VI. Evaluierung und Benchmarking<\/h2>\n

Die systematische Evaluierung von AIOps-Methoden stellt eine eigenst\u00e4ndige Herausforderung dar, die \u00fcber die blo\u00dfe Anwendung klassischer ML-Metriken hinausgeht. Die Heterogenit\u00e4t der Aufgaben, von der Anomalieerkennung \u00fcber die Root Cause Analysis bis zur autonomen Remediation, die Dynamik realer Cloud-Umgebungen und die zunehmende Integration generativer KI erfordern differenzierte Bewertungsans\u00e4tze. Dieser Abschnitt behandelt zun\u00e4chst die verwendeten Evaluierungsmetriken, stellt anschlie\u00dfend aktuelle Benchmark-Frameworks vor und ordnet schlie\u00dflich die Befunde industrieller Berichte kritisch ein.<\/p>\n

A. Evaluierungsmetriken<\/h3>\n

1) Klassische ML-Metriken<\/h4>\n

F\u00fcr die Bewertung von Anomalieerkennungs-, Lokalisierungs- und Klassifikationsalgorithmen werden etablierte Metriken aus dem Bereich des maschinellen Lernens herangezogen. Precision<\/em> quantifiziert den Anteil korrekt erkannter Anomalien an allen als anomal klassifizierten Datenpunkten, Recall<\/em> den Anteil korrekt erkannter Anomalien an allen tats\u00e4chlich vorhandenen Anomalien, und der F1-Score<\/em> bildet deren harmonisches Mittel. Sun et al. [25] differenzieren f\u00fcr die Anomalieerkennung auf Zeitreihendaten drei Auswertungsvarianten: Point-based<\/em>, bei dem jeder einzelne Zeitpunkt bewertet wird, Range-based<\/em>, bei dem zusammenh\u00e4ngende Anomaliebereiche als Einheit gelten, und Event-based<\/em>, bei dem die korrekte Erkennung diskreter Anomalieereignisse bewertet wird. F\u00fcr Root Cause Localization werden Accuracy@k<\/em>-Metriken verwendet, die pr\u00fcfen, ob die tats\u00e4chliche Ursache unter den Top-k<\/em> Vorhersagen enthalten ist, sowie Micro-F1<\/em>, Macro-F1<\/em> und Weighted-F1<\/em> f\u00fcr die Fehlerklassifikation [25].<\/p>\n

2) Aufgabenspezifische Metriken<\/h4>\n

\u00dcber die reinen Klassifikationsmetriken hinaus definiert AIOpsLab [2] aufgabenspezifische Metriken entlang des Incident-Lifecycles: Time-to-Detect<\/em> (TTD) misst die Zeitspanne von der Fehlerinjektion bis zur Erkennung durch den Agenten, Time-to-Mitigate<\/em> (TTM) die Zeit von der Erkennung bis zur vollst\u00e4ndigen Behebung. Erg\u00e4nzend werden die Anzahl der Interaktionsschritte und der Token-Verbrauch als Effizienzindikatoren erfasst [2]. Diese Metriken sind insbesondere f\u00fcr die Bewertung agentenbasierter Systeme relevant, da sie neben der reinen Korrektheit auch die operative Effizienz und die Kosten einer L\u00f6sung abbilden.<\/p>\n

3) GenAI-spezifische Bewertung<\/h4>\n

Die Evaluierung generativer KI-Systeme erfordert zus\u00e4tzliche Kriterien, die \u00fcber bin\u00e4re Korrektheitsbewertungen hinausgehen. AIOpsLab implementiert hierf\u00fcr optional eine LLM-as-Judge<\/em>-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\u00fcndung formulieren kann, etwa wenn ein Agent eine Anomalie korrekt detektiert, seine Erkl\u00e4rung aber auf eine normale Systemaktivit\u00e4t referenziert, die mit dem injizierten Fehler nicht in Zusammenhang steht [2]. F\u00fcr RCA-Empfehlungen setzen Goel et al. [15] auf eine Bewertung durch Incident-Verantwortliche, die die Genauigkeit und N\u00fctzlichkeit der generierten Empfehlungen beurteilen.<\/p>\n

4) Operative KPIs<\/h4>\n

Deloitte [26] schl\u00e4gt in einem Whitepaper einen dreistufigen KPI-Rahmen f\u00fcr die Bewertung von AIOps-Systemen im Produktivbetrieb vor. Direkte Indikatoren<\/em> messen die Leistung der AIOps-Plattform selbst: den Prozentsatz der durch AIOps identifizierten Root Causes, den Anteil autonom gel\u00f6ster Incidents und den durchschnittlichen manuellen Aufwand pro Incident. Indirekte Indikatoren<\/em> umfassen traditionelle IT-Service-KPIs wie MTTR, MTTD und Mean Time Between Failures<\/em> (MTBF). Business-Indikatoren<\/em> quantifizieren den gesch\u00e4ftlichen Einfluss, etwa durch die Zuordnung eines finanziellen Werts zu jedem Incident [26]. Dieser KPI-Rahmen verdeutlicht, dass akademische Evaluierungen, die sich prim\u00e4r auf Korrektheit und Effizienz konzentrieren, nur einen Teilaspekt der Gesamtbewertung abdecken. Ob und in welchem Umfang die direkten und indirekten Indikatoren sich \u00fcber die Zeit verbessern, bestimmt letztlich den Reifegrad einer AIOps-Implementierung.<\/p>\n

B. Benchmark-Frameworks und Datens\u00e4tze<\/h3>\n

1) Limitationen statischer Datens\u00e4tze<\/h4>\n

Traditionelle AIOps-Benchmarks basieren \u00fcberwiegend auf statischen Datens\u00e4tzen, 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\u00e4ndernde Natur realer Cloud-Umgebungen nicht ab. Workloads und Incidents fluktuieren \u00fcber die Zeit, und ein Algorithmus, der auf einem vorab aufgezeichneten Datensatz gute Ergebnisse erzielt, versagt m\u00f6glicherweise unter ver\u00e4nderten Lastbedingungen. Zudem erlauben statische Benchmarks keine Interaktion: Ein Agent kann weder auf den Systemzustand reagieren noch diagnostische Aktionen ausf\u00fchren [2]. Schlie\u00dflich schr\u00e4nkt die Fixierung auf ein einzelnes Szenario die Vergleichbarkeit ein, da Algorithmen, die in einem bestimmten Fehlerszenario schwach abschneiden, in anderen Szenarien \u00fcberlegen sein k\u00f6nnen [25].<\/p>\n

2) AIOpsLab<\/h4>\n

AIOpsLab [2] adressiert diese Limitationen durch ein umfassendes Framework, das die Evaluierung von AIOps-Agenten in dynamischen, interaktiven Cloud-Umgebungen erm\u00f6glicht. Das Framework kombiniert f\u00fcnf Kernkomponenten: den Einsatz realer Microservice-Anwendungen aus der DeathStarBench<\/em>-Suite (SocialNetwork<\/em> mit 28 Microservices und HotelReservation<\/em>), eine integrierte Fehlerinjektion mittels Chaos Engineering \u00fcber ChaosMesh<\/em>, einen Workload-Generator, ein Telemetrie-Subsystem (Prometheus, Jaeger, Filebeat\/Logstash) sowie den in Abschnitt IV beschriebenen Orchestrator mit Agent-Cloud-Interface [2].<\/p>\n

AIOpsLab definiert eine vierstufige Aufgabentaxonomie mit steigender Komplexit\u00e4t: Detection<\/em> (Erkennung einer Anomalie), Localization<\/em> (Lokalisierung des fehlerhaften Services), Root Cause Analysis<\/em> (Identifikation des Systemlayers und Fehlertyps) und Mitigation<\/em> (interaktive Fehlerbehebung durch den Agenten). Die Fehlerinjektionen umfassen sowohl symptomatische Fehler<\/em> (Network Loss, Pod Failure), die nur Detection- und Localization-Aufgaben erzeugen, als auch funktionale Fehler<\/em> (fehlende Authentifizierung, Port-Fehlkonfiguration, fehlerhafte Container-Images), die Aufgaben auf allen vier Stufen erm\u00f6glichen [2].<\/p>\n

Die Evaluierung von vier LLM-Agenten auf dem 48 Probleme umfassenden Benchmark offenbart erhebliche Leistungsunterschiede: FLASH erreicht mit 59,32 % die h\u00f6chste 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 \u00fcbertreffen, w\u00e4hrend die Mitigation-Aufgabe die gr\u00f6\u00dfte Herausforderung darstellt. GPT-3.5 scheitert hier vollst\u00e4ndig, und selbst FLASH erreicht nur 54,55 % [2]. Besonders aussagekr\u00e4ftig ist die Analyse der Schrittlimits: W\u00e4hrend FLASH und ReAct mit steigender Schrittzahl bessere Ergebnisse erzielen, stagniert GPT-3.5 bereits ab f\u00fcnf Schritten und produziert bei h\u00f6heren Limits lediglich mehr Token ohne diagnostischen Mehrwert [2].<\/p>\n

3) MicroServo<\/h4>\n

Einen komplement\u00e4ren 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<\/em>) zu bewerten [25].<\/p>\n

Ein wesentliches Designmerkmal von MicroServo ist das Algorithm Hot-Plugging<\/em>: Jeder Algorithmus wird in einem eigenen Docker-Container deployt, was Abh\u00e4ngigkeitskonflikte beseitigt und das Hinzuf\u00fcgen neuer Algorithmen mit minimalem Aufwand erm\u00f6glicht. Die Plattform stellt ein standardisiertes Datenformat f\u00fcr Metriken, Logs und Traces bereit, das als gemeinsame Schnittstelle f\u00fcr alle integrierten Algorithmen dient [25].<\/p>\n

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\u00e4r 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\u00fcr 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\u00e4ngig vom erwarteten Fehlerszenario ist und universelle Leaderboards ohne Szenario-Differenzierung irref\u00fchrend sein k\u00f6nnen.<\/p>\n

C. Industrielle Perspektiven<\/h3>\n

1) BigPanda Business Value Report<\/h4>\n

Der BigPanda Business Value Report [27] quantifiziert den gesch\u00e4ftlichen Nutzen der BigPanda-Plattform auf Basis von 23 Kunden-Assessments, die zwischen November 2024 und Juli 2025 durchgef\u00fchrt wurden. Die berichteten Kennzahlen sind beachtlich: ein medianer j\u00e4hrlicher 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].<\/p>\n

Diese Ergebnisse sollten jedoch kritisch eingeordnet werden. Der Report wurde vollst\u00e4ndig 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\u00dfe Unternehmen beschr\u00e4nkt: die mediane Jahresumsatzklasse der teilnehmenden Organisationen betr\u00e4gt 5,97 Milliarden USD, fast zwei Drittel finden sich auf der Fortune-1000-Liste [27]. Die \u00dcbertragbarkeit der Ergebnisse auf mittelst\u00e4ndische Unternehmen oder Organisationen mit geringerer operativer Komplexit\u00e4t ist daher fraglich. Zudem differenziert der Report zwischen Green Dollars<\/em> (direkte Kosteneinsparungen wie reduzierte Headcounts), Blue Dollars<\/em> (indirekte Effizienzgewinne wie Zeitersparnis, die nicht unmittelbar bilanzwirksam sind) und Teal Dollars<\/em> (situationsabh\u00e4ngige Einsparungen) [27]. Ein Gro\u00dfteil der berichteten Einsparungen f\u00e4llt in die Kategorie der Blue Dollars, also reale, aber schwer nachpr\u00fcfbare Effizienzgewinne, die nicht direkt in eine Gewinn- und Verlustrechnung eingehen.<\/p>\n

Trotz dieser methodischen Einschr\u00e4nkungen liefert der Report empirische Datenpunkte, die in der akademischen Literatur selten verf\u00fcgbar sind. Die konsistente Berichterstattung \u00fcber 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\u00dfen Unternehmensumgebungen, sollten jedoch nicht als unabh\u00e4ngig validierte Benchmarks interpretiert werden.<\/p>\n

2) Deloitte: AIOps-Reifegradmodell<\/h4>\n

Deloitte [26] pr\u00e4sentiert in einem Whitepaper ein hierarchisches AIOps-Modell, das die drei Phasen Observe<\/em>, Engage<\/em> und Act<\/em> in acht aufeinander aufbauende Schichten gliedert: von der Observability als Fundament \u00fcber 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<\/em>, also der Schwelle im hierarchischen Modell, bis zu der AIOps in einer Organisation zuverl\u00e4ssig funktioniert [26]. Dar\u00fcber hinaus definiert das Whitepaper f\u00fcnf Reifegradstufen: Traditional IT Delivery<\/em>, Observability<\/em>, AI Support<\/em>, AIOps<\/em> und AIOps (mit GenAI)<\/em> [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\u00e4ndige Vorstufe hervorhebt.<\/p>\n

Hervorzuheben ist, dass Deloitte die organisatorische Transformation als gleichrangig zur technischen Implementierung behandelt. Die Einf\u00fchrung eines zentralen AIOps-Teams, bestehend aus SRE, AI Engineering und Observability, sowie die Betonung von Organizational Change Management als unverzichtbare Begleitma\u00dfnahme 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\u00fcr den praktischen Nutzen [26].<\/p>\n

Das Whitepaper weist jedoch typische Merkmale eines Beratungsdokuments auf: Die Fallstudien beruhen ausschlie\u00dflich auf Projekten mit Deloitte-Beteiligung und verwenden propriet\u00e4re Konfigurationen (insbesondere Dynatrace<\/em> als Observability-Plattform und ServiceNow<\/em> als ITSM-System), deren Ergebnisse sich nicht ohne Weiteres auf andere Technologiestacks \u00fcbertragen lassen. Eine standardisierte, reproduzierbare Benchmarking-Methodik fehlt. Zudem bleibt die Frage offen, wie die vorgeschlagene Organisationsstruktur in Unternehmen skaliert, die nicht \u00fcber die Ressourcen verf\u00fcgen, dedizierte Rollen f\u00fcr SRE, AI Engineering und Observability einzurichten. Diese Einschr\u00e4nkung behandeln Bendimerad et al. [24] in ihrem Erfahrungsbericht zur On-Premise-AIOps-Infrastruktur eines mittelst\u00e4ndischen Unternehmens ausdr\u00fccklich.<\/p>\n

VII. Fazit und Ausblick<\/h2>\n

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.<\/p>\n

Die Untersuchung der drei Kernaufgaben \u2013 Failure Perception, Root Cause Analysis und Auto-Remediation \u2013 zeigt, dass f\u00fcr jede Phase inzwischen leistungsf\u00e4hige Verfahren existieren, die regelbasierte Ans\u00e4tze in Genauigkeit und Skalierbarkeit \u00fcbertreffen. Transformer-basierte Modelle wie STMformer verbessern die Zustandsvorhersage in Microservice-Umgebungen gegen\u00fcber bisherigen Methoden, w\u00e4hrend multimodale Frameworks wie KylinRCA durch die Fusion von Metriken, Logs und Traces Entity-Lokalisierung mit F1-Scores \u00fcber 92 % erzielen. Die Auto-Remediation profitiert von Reinforcement-Learning-Ans\u00e4tzen wie Narya und dem Operator-Pattern in Kubernetes, das deklarative Zielzustandsbeschreibungen mit kontrollierter Ausf\u00fchrung verbindet.<\/p>\n

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\u00f6nnen. 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 \u00fcbertreffen. Gleichzeitig offenbaren die Evaluierungen in AIOpsLab systematische Schw\u00e4chen: Agenten verschwenden Interaktionsschritte durch redundante Aktionen, ersch\u00f6pfen ihr Kontextfenster durch die undifferenzierte Verarbeitung umfangreicher Telemetriedaten und stagnieren in ihrer Selbstreparaturf\u00e4higkeit nach einer bestimmten Anzahl von Schritten.<\/p>\n

Diese technischen Einschr\u00e4nkungen werden durch erhebliche Sicherheitsrisiken versch\u00e4rft. Die Ergebnisse von Pasquini et al. zeigen, dass Telemetrie-Manipulation \u00fcber Adversarial Reward Hacking eine Erfolgsrate von 90 % erzielen kann, w\u00e4hrend klassische Prompt-Injection-Techniken unter denselben Bedingungen bei 0 % verbleiben. Deterministische \u00dcbersetzungsschichten wie MCP-Diag und AIOpsShield bieten erste Gegenma\u00dfnahmen, verdeutlichen jedoch, dass Sicherheit als integraler Bestandteil des Systemdesigns konzipiert werden muss und nicht nachtr\u00e4glich erg\u00e4nzt werden kann.<\/p>\n

Neben den technischen Herausforderungen stellt die organisatorische Umsetzung eine zentrale H\u00fcrde dar. Die Abh\u00e4ngigkeit von konsistenten Telemetriedaten, die Notwendigkeit interdisziplin\u00e4rer Kompetenzen an der Schnittstelle von DevOps und Machine Learning sowie die hohen Einstiegskosten kommerzieller Plattformen erschweren insbesondere f\u00fcr mittelst\u00e4ndische Unternehmen die praktische Umsetzung. Die Diskrepanz zwischen den vielversprechenden Ergebnissen akademischer Benchmarks und den Anforderungen realer Produktivumgebungen bleibt ein ungel\u00f6stes Spannungsfeld.<\/p>\n

F\u00fcr die zuk\u00fcnftige Forschung lassen sich aus den identifizierten L\u00fccken mehrere vorrangige Richtungen ableiten. Erstens versprechen feinabgestimmte Small Language Models einen kosteneffizienten Kompromiss zwischen Leistungsf\u00e4higkeit und Inferenzkosten \u2013 die Ergebnisse von eARCO belegen, dass dom\u00e4nenadaptierte SLMs mit optimierten Prompts eine vergleichbare Genauigkeit wie deutlich gr\u00f6\u00dfere Modelle erreichen k\u00f6nnen. Zweitens erfordert die Absicherung autonomer Agenten gegen Telemetrie-Manipulation und Halluzinationen neue Architekturmuster, die \u00fcber System-Prompt-basierte Schutzma\u00dfnahmen 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\u00e4tze, sind jedoch noch weit von einer branchenweiten Adoption entfernt. Schlie\u00dflich bleibt die Evaluierungsmethodik ein offenes Problem \u2013 die Entwicklung szenariobasierter, dynamischer Benchmark-Frameworks, die sowohl die technische Korrektheit als auch die operative Effizienz und den gesch\u00e4ftlichen Nutzen erfassen, ist eine Voraussetzung f\u00fcr die belastbare Vergleichbarkeit von AIOps-Ans\u00e4tzen.<\/p>\n

\n

Referenzen<\/h2>\n

[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, \u201cBuilding AI Agents for Autonomous Clouds: Challenges and Design Principles,\u201d Jul. 2024, arXiv:2407.12165 [cs]. [Online]. Available: http:\/\/arxiv.org\/abs\/2407.12165<\/p>\n

[2] Y. Chen, M. Shetty, G. Somashekar, M. Ma, Y. Simmhan, J. Mace, C. Bansal, R. Wang, and S. Rajmohan, \u201cAIOpsLab: A Holistic Framework to Evaluate AI Agents for Enabling Autonomous Clouds,\u201d Jan. 2025, arXiv:2501.06706 [cs]. [Online]. Available: http:\/\/arxiv.org\/abs\/2501.06706<\/p>\n

[3] Q. Cheng, D. Sahoo, A. Saha, W. Yang, C. Liu, G. Woo, M. Singh, S. Saverese, and S. C. H. Hoi, \u201cAI for IT Operations (AIOps) on Cloud Platforms: Reviews, Opportunities and Challenges,\u201d Apr. 2023, arXiv:2304.04661 [cs]. [Online]. Available: http:\/\/arxiv.org\/abs\/2304.04661<\/p>\n

[4] H. Mahesh, \u201cGartner Hype-Cycle for AI 2025: What the Future Holds in 2026?\u201d Oct. 2025. [Online]. Available: https:\/\/testrigor.com\/blog\/gartner-hype-cycle-for-ai-2025\/<\/p>\n

[5] L. Zhang, T. Jia, M. Jia, Y. Wu, A. Liu, Y. Yang, Z. Wu, X. Hu, P. S. Yu, and Y. Li, \u201cA Survey of AIOps for Failure Management in the Era of Large Language Models,\u201d Jun. 2024, arXiv:2406.11213 [cs]. [Online]. Available: http:\/\/arxiv.org\/abs\/2406.11213<\/p>\n

[6] L. Zhang, T. Jia, M. Jia, Y. Wu, A. Liu, Y. Yang, Z. Wu, X. Hu, P. S. Yu, and Y. Li, \u201cA Survey of AIOps in the Era of Large Language Models,\u201d Jun. 2025, arXiv:2507.12472 [cs]. [Online]. Available: http:\/\/arxiv.org\/abs\/2507.12472<\/p>\n

[7] P. Bhosale, \u201cMetrics, Logs, and Traces: A Unified Approach to Observability in Microservices,\u201d Journal of Artificial Intelligence, Machine Learning and Data Science<\/em>, vol. 1, no. 1, pp. 2084\u20132088, Nov. 2022. [Online]. Available: https:\/\/urfjournals.org\/open-access\/metrics-logs-and-traces-a-unified-approach-to-observability-in-microservices.pdf<\/p>\n

[8] A. Vitui and T.-H. Chen, \u201cEmpowering AIOps: Leveraging Large Language Models for IT Operations Management,\u201d Jan. 2025, arXiv:2501.12461 [cs]. [Online]. Available: http:\/\/arxiv.org\/abs\/2501.12461<\/p>\n

[9] Y. Huo, C. Lee, J. Liu, T. Yang, and M. R. Lyu, \u201cA Roadmap towards Intelligent Operations for Reliable Cloud Computing Systems.\u201d arXiv, Oct. 2023, arXiv:2310.00677 [cs]. [Online]. Available: http:\/\/arxiv.org\/abs\/2310.00677<\/p>\n

[10] J. Hou, \u201cResearch on fault diagnosis and root cause analysis based on full stack observability,\u201d Sep. 2025, arXiv:2509.12231 [cs]. [Online]. Available: http:\/\/arxiv.org\/abs\/2509.12231<\/p>\n

[11] K. R. Bellala, \u201cTowards Autonomous Kubernetes: A Framework for AI-Driven Operations (AIOps),\u201d International Journal of Innovative Science and Research Technology<\/em>, pp. 1654\u20131661, Sep. 2025. [Online]. Available: https:\/\/www.ijisrt.com\/towards-autonomous-kubernetes-a-framework-for-aidriven-operations-aiops<\/p>\n

[12] Y. Xu, J. Ge, H. Tang, S. Ding, T. Li, and H. Li, \u201cSystem States Forecasting of Microservices with Dynamic Spatio-Temporal Data,\u201d Aug. 2024, arXiv:2408.07894 [cs]. [Online]. Available: http:\/\/arxiv.org\/abs\/2408.07894<\/p>\n

[13] L. Poenaru-Olaru, N. Karpova, L. Cruz, J. Rellermeyer, and A. v. Deursen, \u201cIs Your Anomaly Detector Ready for Change? Adapting AIOps Solutions to the Real World,\u201d in Proceedings of the IEEE\/ACM 3rd International Conference on AI Engineering – Software Engineering for AI<\/em>, Apr. 2024, pp. 222\u2013233, arXiv:2311.10421 [cs]. [Online]. Available: http:\/\/arxiv.org\/abs\/2311.10421<\/p>\n

[14] L. Poenaru-Olaru, W. v. t. Hof, A. Stando, A. P. Trawinski, E. Kapel, J. S. Rellermeyer, L. Cruz, and A. v. Deursen, \u201cPrepared for the Unknown: Adapting AIOps Capacity Forecasting Models to Data Changes,\u201d Oct. 2025, arXiv:2510.10320 [cs]. [Online]. Available: http:\/\/arxiv.org\/abs\/2510.10320<\/p>\n

[15] D. Goel, R. Magazine, S. Ghosh, A. Nambi, P. Deshpande, X. Zhang, C. Bansal, and S. Rajmohan, \u201ceARCO: Efficient Automated Root Cause Analysis with Prompt Optimization,\u201d Apr. 2025, arXiv:2504.11505 [cs]. [Online]. Available: http:\/\/arxiv.org\/abs\/2504.11505<\/p>\n

[16] P. Pham, V. Jain, L. Dauterman, J. Ormont, and N. Jain, \u201cDeepTriage: Automated Transfer Assistance for Incidents in Cloud Services,\u201d Nov. 2020. [Online]. Available: https:\/\/arxiv.org\/abs\/2012.03665v1<\/p>\n

[17] A. Vaswani, N. Shazeer, N. Parmar, J. Uszkoreit, L. Jones, A. N. Gomez, L. Kaiser, and I. Polosukhin, \u201cAttention Is All You Need.\u201d arXiv, Aug. 2023, arXiv:1706.03762 [cs]. [Online]. Available: http:\/\/arxiv.org\/abs\/1706.03762<\/p>\n

[18] S. Yao, J. Zhao, D. Yu, N. Du, I. Shafran, K. Narasimhan, and Y. Cao, \u201cReAct: Synergizing Reasoning and Acting in Language Models.\u201d arXiv, Mar. 2023, arXiv:2210.03629 [cs]. [Online]. Available: http:\/\/arxiv.org\/abs\/2210.03629<\/p>\n

[19] D. Lodha, M. Panchal, and S. G. Kulkarni, \u201cMCP-Diag: A Deterministic, Protocol-Driven Architecture for AI-Native Network Diagnostics.\u201d arXiv, Jan. 2026, arXiv:2601.22633 [cs]. [Online]. Available: http:\/\/arxiv.org\/abs\/2601.22633<\/p>\n

[20] D. Pasquini, E. M. Kornaropoulos, G. Ateniese, O. Akgul, A. Theocharis, and P. Efstathopoulos, \u201cWhen AIOps Become \u2018AI Oops\u2019: Subverting LLM-driven IT Operations via Telemetry Manipulation,\u201d Aug. 2025, arXiv:2508.06394 [cs]. [Online]. Available: http:\/\/arxiv.org\/abs\/2508.06394<\/p>\n

[21] T. Dai and J. M. Swaminathan, \u201cArtificial Intelligence and Operations: A Foundational Framework of Emerging Research and Practice.\u201d<\/p>\n

[22] Y. Lyu, H. Li, H. Li, and A. E. Hassan, \u201cCan We Recycle Our Old Models? An Empirical Evaluation of Model Selection Mechanisms for AIOps Solutions,\u201d May 2025, arXiv:2505.02961 [cs]. [Online]. Available: http:\/\/arxiv.org\/abs\/2505.02961<\/p>\n

[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, \u201cML-Enabled Systems Model Deployment and Monitoring: Status Quo and Problems,\u201d Feb. 2024, arXiv:2402.05333 [cs]. [Online]. Available: http:\/\/arxiv.org\/abs\/2402.05333<\/p>\n

[24] A. Bendimerad, Y. Remil, R. Mathonat, and M. Kaytoue, \u201cOn-Premise AIOps Infrastructure for a Software Editor SME: An Experience Report,\u201d Aug. 2023, arXiv:2308.11225 [cs]. [Online]. Available: http:\/\/arxiv.org\/abs\/2308.11225<\/p>\n

[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, \u201cA Scenario-Oriented Benchmark for Assessing AIOps Algorithms in Microservice Management,\u201d Jul. 2024, arXiv:2407.14532 [cs]. [Online]. Available: http:\/\/arxiv.org\/abs\/2407.14532<\/p>\n

[26] Deloitte, \u201cAIOps: How AI will transform the Art of IT Operations,\u201d 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<\/p>\n

[27] BigPanda, \u201cThe Business Value of the BigPanda Platform,\u201d Oct. 2025, industry Report. [Online]. Available: https:\/\/www.bigpanda.io\/wp-content\/uploads\/2025\/10\/bigpanda-report-business-value-of-the-bigpanda-platform.pdf<\/p>\n<\/div>\n","protected":false},"excerpt":{"rendered":"","protected":false},"author":1314,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[1],"tags":[1207,150,9,154,963,1209,1208],"ppma_author":[1199,936,1202],"class_list":["post-28501","post","type-post","status-publish","format-standard","hentry","category-allgemein","tag-aiops","tag-ci-cd","tag-devops","tag-kubernetes","tag-llm","tag-rag","tag-rca"],"aioseo_notices":[],"jetpack_featured_media_url":"","jetpack-related-posts":[{"id":26389,"url":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/2024\/07\/26\/transforming-it-operations-is-aiops-the-future-of-enterprise-it\/","url_meta":{"origin":28501,"position":0},"title":"Transforming IT Operations: Is AIOps the Future of Enterprise IT?","author":"Milena Hristova","date":"26. July 2024","format":false,"excerpt":"Now more than ever, enterprises are always on the lookout for new ways to implement artificial intelligence algorithms across various sectors as they strive to remain competitive. AI is changing the way businesses operate, from automating routine tasks to making data-driven decisions like in the example of the Digital Twin.\u2026","rel":"","context":"In "Allgemein"","block_context":{"text":"Allgemein","link":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/category\/allgemein\/"},"img":{"alt_text":"","src":"https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2024\/07\/image-2.png?resize=350%2C200&ssl=1","width":350,"height":200,"srcset":"https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2024\/07\/image-2.png?resize=350%2C200&ssl=1 1x, https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2024\/07\/image-2.png?resize=525%2C300&ssl=1 1.5x"},"classes":[]},{"id":12032,"url":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/2020\/09\/30\/admin-panel-web-app-in-der-aws-cloud\/","url_meta":{"origin":28501,"position":1},"title":"Admin Panel (Web App) in der AWS Cloud","author":"ss447","date":"30. September 2020","format":false,"excerpt":"1. Einleitung Im Rahmen der Vorlesung \u201eSoftware Development for Cloud Computing\u201c haben wir uns als Gruppe dazu entschieden aufbauend auf teilweise bereits vorhandener Codebasis an einem Startup-Projekt weiterzuarbeiten. Der Hauptfokus lag bei uns auf dem Ausbau von DevOps-Aspekten und auf dem eines stabilen und sicheren Systems, welches auch in der\u2026","rel":"","context":"In "Cloud Technologies"","block_context":{"text":"Cloud Technologies","link":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/category\/scalable-systems\/cloud-technologies\/"},"img":{"alt_text":"","src":"https:\/\/i0.wp.com\/img.youtube.com\/vi\/qw9ZkWnvR4M\/0.jpg?resize=350%2C200","width":350,"height":200},"classes":[]},{"id":26208,"url":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/2024\/02\/29\/die-meere-der-systemtechnik-navigieren-eine-reise-durch-die-bereitstellung-einer-aktien-webanwendung-in-der-cloud\/","url_meta":{"origin":28501,"position":2},"title":"Die Meere der Systemtechnik navigieren: Eine Reise durch die Bereitstellung einer Aktien-Webanwendung in der Cloud","author":"mk306","date":"29. February 2024","format":false,"excerpt":"Auf zu neuen Ufern: Einleitung Die Cloud-Computing-Technologie hat die Art und Weise, wie Unternehmen Anwendungen entwickeln, bereitstellen und skalieren, revolutioniert. In diesem Beitrag, der im Rahmen der Vorlesung \u201c143101a System Engineering und Management\u201d entstanden ist, werden wir uns darauf konzentrieren, wie eine bereits bestehende Webanwendung zur Visualisierung und Filterung von\u2026","rel":"","context":"In "Cloud Technologies"","block_context":{"text":"Cloud Technologies","link":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/category\/scalable-systems\/cloud-technologies\/"},"img":{"alt_text":"","src":"https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2024\/02\/Dashboard2-Kopie-1.png?resize=350%2C200&ssl=1","width":350,"height":200,"srcset":"https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2024\/02\/Dashboard2-Kopie-1.png?resize=350%2C200&ssl=1 1x, https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2024\/02\/Dashboard2-Kopie-1.png?resize=525%2C300&ssl=1 1.5x, https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2024\/02\/Dashboard2-Kopie-1.png?resize=700%2C400&ssl=1 2x, https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2024\/02\/Dashboard2-Kopie-1.png?resize=1050%2C600&ssl=1 3x, https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2024\/02\/Dashboard2-Kopie-1.png?resize=1400%2C800&ssl=1 4x"},"classes":[]},{"id":26965,"url":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/2025\/02\/28\/wie-baut-man-eine-ci-cd-pipeline-mit-jenkins-auf\/","url_meta":{"origin":28501,"position":3},"title":"Wie baut man eine CI\/CD Pipeline mit Jenkins auf?","author":"Cedric Gottschalk","date":"28. February 2025","format":false,"excerpt":"Im Rahmen der Vorlesung \"System Engineering und Management (143101a)\" haben wir es uns zum Ziel gesetzt, mehr \u00fcber CI\/CD Pipelines zu lernen und eine eigene Pipeline f\u00fcr ein kleines Projekt aufzusetzen. Wir haben uns dabei entschieden, Jenkins f\u00fcr die CI\/CD Pipeline einzusetzen und eine kleine ToDo App mit dem Framework\u2026","rel":"","context":"In "System Engineering"","block_context":{"text":"System Engineering","link":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/category\/system-designs\/system-engineering\/"},"img":{"alt_text":"","src":"https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2025\/02\/ToDo-List-CICD-1.png?resize=350%2C200&ssl=1","width":350,"height":200,"srcset":"https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2025\/02\/ToDo-List-CICD-1.png?resize=350%2C200&ssl=1 1x, https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2025\/02\/ToDo-List-CICD-1.png?resize=525%2C300&ssl=1 1.5x, https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2025\/02\/ToDo-List-CICD-1.png?resize=700%2C400&ssl=1 2x, https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2025\/02\/ToDo-List-CICD-1.png?resize=1050%2C600&ssl=1 3x, https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2025\/02\/ToDo-List-CICD-1.png?resize=1400%2C800&ssl=1 4x"},"classes":[]},{"id":28372,"url":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/2026\/02\/18\/safeguards-in-der-ki-unterstutzten-softwareentwicklung\/","url_meta":{"origin":28501,"position":4},"title":"Safeguards in der KI-unterst\u00fctzten Softwareentwicklung","author":"Christoph Merck","date":"18. February 2026","format":false,"excerpt":"KI gest\u00fctzte Werkzeuge und autonome Agenten machen Softwareentwicklung schneller, schaffen aber neue Sicherheitsrisiken, weil sie eigenst\u00e4ndig Entscheidungen treffen und externe Tools nutzen k\u00f6nnen. Der Artikel zeigt, warum deshalb ein mehrschichtiges Safeguard Konzept n\u00f6tig ist, das klassische Ma\u00dfnahmen wie Code Reviews, Tests und statische sowie dynamische Analysen mit KI spezifischen Schutzmechanismen\u2026","rel":"","context":"In "Allgemein"","block_context":{"text":"Allgemein","link":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/category\/allgemein\/"},"img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":21683,"url":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/2021\/09\/18\/ynstagram-cloud-computing-mit-aws-serverless\/","url_meta":{"origin":28501,"position":5},"title":"Ynstagram – Cloud Computing mit AWS & Serverless","author":"ns144","date":"18. September 2021","format":false,"excerpt":"Im Rahmen der Vorlesung \u201cSoftware Development for Cloud Computing\u201d haben wir uns hinsichtlich des dortigen Semesterprojektes zum Ziel gesetzt einen einfachen Instagram Klon zu entwerfen um uns die Grundkenntnisse des Cloud Computings anzueignen. Grundkonzeption \/ Ziele des Projektes Da wir bereits einige Erfahrung mit React aufgrund anderer studentischer Projekte sammeln\u2026","rel":"","context":"In "Cloud Technologies"","block_context":{"text":"Cloud Technologies","link":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/category\/scalable-systems\/cloud-technologies\/"},"img":{"alt_text":"","src":"https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2021\/09\/Prasentation_CC_01.png?resize=350%2C200&ssl=1","width":350,"height":200,"srcset":"https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2021\/09\/Prasentation_CC_01.png?resize=350%2C200&ssl=1 1x, https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2021\/09\/Prasentation_CC_01.png?resize=525%2C300&ssl=1 1.5x, https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2021\/09\/Prasentation_CC_01.png?resize=700%2C400&ssl=1 2x, https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2021\/09\/Prasentation_CC_01.png?resize=1050%2C600&ssl=1 3x, https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2021\/09\/Prasentation_CC_01.png?resize=1400%2C800&ssl=1 4x"},"classes":[]}],"jetpack_sharing_enabled":true,"authors":[{"term_id":1199,"user_id":1314,"is_guest":0,"slug":"leonard_lais","display_name":"Leonard Lais\u00e9","avatar_url":"https:\/\/secure.gravatar.com\/avatar\/e543f96dae797a9d3a585e54c63fbc3406f0e91d6c938b7055536af3d0b40080?s=96&d=mm&r=g","0":null,"1":"","2":"","3":"","4":"","5":"","6":"","7":"","8":""},{"term_id":936,"user_id":1155,"is_guest":0,"slug":"michael_dick","display_name":"Michael Dick","avatar_url":"https:\/\/secure.gravatar.com\/avatar\/709f2a71925177dbd54b3120d4d93c394d6eaa32eae8409769f7247fac3be2cf?s=96&d=mm&r=g","0":null,"1":"","2":"","3":"","4":"","5":"","6":"","7":"","8":""},{"term_id":1202,"user_id":1317,"is_guest":0,"slug":"tom_flocken","display_name":"Tom Flocken","avatar_url":"https:\/\/secure.gravatar.com\/avatar\/228025319015e324c526241dc0c997160d0f0e665080818b5866b56690a29fa5?s=96&d=mm&r=g","0":null,"1":"","2":"","3":"","4":"","5":"","6":"","7":"","8":""}],"_links":{"self":[{"href":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/wp-json\/wp\/v2\/posts\/28501","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/wp-json\/wp\/v2\/users\/1314"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/wp-json\/wp\/v2\/comments?post=28501"}],"version-history":[{"count":5,"href":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/wp-json\/wp\/v2\/posts\/28501\/revisions"}],"predecessor-version":[{"id":28542,"href":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/wp-json\/wp\/v2\/posts\/28501\/revisions\/28542"}],"wp:attachment":[{"href":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/wp-json\/wp\/v2\/media?parent=28501"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/wp-json\/wp\/v2\/categories?post=28501"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/wp-json\/wp\/v2\/tags?post=28501"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/wp-json\/wp\/v2\/ppma_author?post=28501"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}