AIOps: Störungserkennung und Ursachenanalyse

Moderne Systeme erzeugen Millionen von Signalen; Bereitschaftsteams ertrinken in Alarmen und verlieren die ersten kritischen Minuten mit der Suche in Dashboards. AIOps verbindet statistische Anomalieerkennung, Alarm- Korrelation und seit etwa 2024 LLM-basierte „KI-SRE“-Agenten, die Telemetrie abfragen, jüngste Änderungen prüfen und eine Ursache mit Belegen vorschlagen. Der realistische Nutzen sind schnellere Ersteinschätzung und weniger Alarmrauschen; eine vollständig autonome Diagnose ist noch nicht zuverlässig.

Problem & Nutzen

• Heute: Monitoring-Werkzeuge lösen je Komponente Alarme mit statischen Schwellwerten aus. Ein einzelner Fehler (fehlerhaftes Deployment, überlastete Datenbank, abgelaufenes Zertifikat) löst Dutzende Alarme aus. Das Bereitschaftspersonal korreliert von Hand über Metriken, Logs, Traces, Deployments und Chat, oft nachts. Das Wissen liegt in wenigen erfahrenen Köpfen und in alten Postmortems.
• Nutzen durch KI: (1) dynamische Basislinien statt statischer Schwellwerte; (2) Bündelung zusammengehöriger Alarme zu einer Störung; (3) topologie- und änderungsbewusste Rangfolge wahrscheinlicher Ursachen; (4) ein Agent, der die ersten Untersuchungsschritte übernimmt (Abfragen, Log-Suche, Vergleich jüngster Deployments), bevor ein Mensch alarmiert wird; (5) automatische Entwürfe für Zeitleiste und Postmortem.
• Die Evidenz ist gemischt: Herstellermaterial behauptet große MTTR-Senkungen, doch unabhängige Zahlen sind selten. In öffentlichen Forschungs-Benchmarks finden LLM-Agenten die exakte Ursachenmenge nur in einer Minderheit der Fälle (etwa 21 % bei OpenRCA 2.0, wobei sie oft mindestens einen richtigen Service nennen) [1][2]. Messen Sie an Ihrer eigenen Störungshistorie, bevor Sie einer Herstellerzahl vertrauen.

Varianten

• Plattformeigenes AIOps: kausale KI innerhalb einer Observability-Suite (Dynatrace, Datadog, Elastic, Grafana).
• KI-SRE-Agent: ein eigenständiger Ermittler über mehrere Werkzeuge, ausgelöst durch einen Alarm oder einen Slack/Teams-Thread.
• Ereignis-Korrelationsschicht: Deduplizierung und Rauschminderung vor der Alarmierung (PagerDuty, BigPanda-Stil).
• Fehlersuche in Kubernetes/Cloud-nativen Umgebungen: Open-Source-Agenten, die Pod-Abstürze und fehlgeschlagene Rollouts erklären.
• Verwandt, aber getrennt: Sicherheitsalarme gehören zu SEC-001/SEC-005; Anomalien an Maschinensensoren zu ANOM-005/PRED-006.

So funktioniert es

1. Telemetrie (OpenTelemetry-Metriken/-Logs/-Traces) + Änderungsereignisse (CI/CD, Feature-Flags, Konfiguration)
2. Anomalieerkennung (dynamische Baselines, Change-Point-Erkennung, Anomalien in Log-Mustern)
3. Alarmkorrelation & Deduplizierung (Zeit, Topologie, Textähnlichkeit)
4. ein Vorfall
5. Untersuchung: Topologie-/Kausalgraph + LLM-Agent (Metriken abfragen, Logs durchsuchen, Deployments vergleichen, Runbooks und ähnliche frühere Vorfälle abrufen)
6. priorisierte Hypothesen mit Belegverweisen und Konfidenz
7. Mensch-in-der-Schleife: Bereitschaftsdienst bestätigt; Behebung nur über freigegebene Runbook-Aktionen
8. Zeitleiste, Entwurf der Statusseite, Entwurf des Postmortems
9. Rückmeldung zur Verbesserung der Priorisierung

• Erkennung: saisonale Zeitreihenmodelle, robuste Statistik, Detektoren im Stil von Isolation Forest, Mining von Log-Vorlagen; überwiegend klassisches ML, günstig und ausgereift.
• Kausale/Topologie-Schlussfolgerung: Ein Abhängigkeitsgraph (Service-Map, Kubernetes, CMDB) schränkt die in Frage kommenden Ursachen ein; deterministische Kausal-Engines sind berechenbarer als reines LLM-Schlussfolgern.
• LLM-Agent: Reasoning-Modell mit Werkzeugen (PromQL/SQL/Log-Abfragen, Deployment-Historie, Ticket-Suche), das Hypothesen mit zitierten Belegen erzeugt. Standardmäßig nur lesend.
• Mensch-in-der-Schleife (Human-in-the-Loop): Der Agent schlägt vor; Ingenieure geben jede zustandsändernde Aktion frei (Rollback, Neustart, Skalierung). Frage-/Verweigerungsmodi je Werkzeug sind bei führenden Produkten Standard.

Datenaufbereitung

AIOps braucht Telemetrie: Metriken, Logs und Traces, Änderungsereignisse (Deployments, Feature-Flags), die Service-Topologie sowie frühere Störungen mit Runbooks. In einem KMU sind diese über Monitoring-Werkzeuge, Logdateien auf Servern, ein Ticketsystem, Wikis und Chat-Threads verstreut. Typische Lücken: uneinheitliche Log-Formate, fehlende Trace-IDs, kein Service-Inventar oder keine CMDB, nicht gekennzeichnete historische Störungen, Alarmrauschen sowie personenbezogene Daten oder Geheimnisse in Logs.

Schritte der Aufbereitung: 1. Die Erfassung mit einem OpenTelemetry Collector und einheitlichen Labels für Service, Umgebung und Version standardisieren. 2. Deployments und Konfigurationsänderungen als Ereignisse erfassen, denn die meisten Störungen hängen mit einer Änderung zusammen. 3. Eine einfache Service-Map aufbauen (auch eine gepflegte YAML-Datei) mit Verantwortlichen. 4. Zuerst die Alarme bereinigen: Duplikate und flackernde Regeln entfernen. 5. Frühere Postmortems und Runbooks in kurze, aktuelle Dokumente überführen und Störungen mit bestätigter Ursache kennzeichnen (PREP-013, PREP-019, PREP-020). 6. Personenbezogene Daten und Token in der Pipeline schwärzen (PREP-022).

Grober Anteil am Gesamtaufwand: 30-40 Prozent; die Telemetrie-Pipeline und die gekennzeichneten Störungen machen den Hauptteil aus, die KI-Schicht ist vergleichsweise leicht. Zum Extrahieren von Daten aus Altsystemen siehe PREP-005, für einen Bereitschaftscheck GUIDE-003.

Umsetzungswege

Welcher Weg für wen

• KMU: A. Eine ausgereifte AIOps- oder KI-SRE-Funktion in einer Observability-Suite, für die Sie ohnehin zahlen (Dynatrace, Datadog, Elastic, Checkmk), ist günstiger, als Erkennung und Korrelation selbst zu bauen.
• Großunternehmen: B. Kernservices, eine individuelle Topologie- und CMDB-Integration und eine interne KI-Plattform rechtfertigen einen werkzeugnutzenden Agenten auf Cloud-KI-Diensten über Ihrer bestehenden Telemetrie.
• Entwickler: C. HolmesGPT, K8sGPT und Prometheus mit einem Ollama- oder vLLM-Modell laufen lokal und kosten keine Lizenz pro Arbeitsplatz.
• Öffentlicher Sektor: C. Logs enthalten oft Daten von Bürgern oder Beschäftigten, und die Beschaffung bevorzugt souveränes Hosting; daher passt selbst betriebene Open-Source-Erkennung mit lokalen Modellen.

Weg A — Kaufen (Standardsoftware; empfohlen für die meisten Organisationen)

• Observability-Suiten mit KI: Dynatrace (Davis Causal AI / Dynatrace Intelligence), Datadog (Watchdog-Anomalieerkennung, Bits-AI-SRE-Agent), Elastic Observability (AI Assistant, Korrelation im Stil von Attack Discovery), Grafana Cloud (Assistant, adaptive Alarmierung), New Relic, Splunk Observability, IBM Instana. Dynatrace und Elastic bieten EU-Regionen oder selbst verwaltete Bereitstellung; Datadog hat einen EU-Standort (datadoghq.eu).
• Werkzeuge für Störungsmanagement und KI-SRE: PagerDuty (Event Intelligence, SRE-Agent), incident.io (Slack-nativer Störungsablauf, von KI entworfene Zeitleisten), Rootly, Komodor (Kubernetes) sowie neuere KI-SRE-Start-ups. Prüfen: EU-Datenresidenz, Nur-Lese-Standard, Audit-Protokoll, welche Telemetriequellen unterstützt werden.
• EU-Optionen: Checkmk (Deutschland, Open Core), Icinga/NETWAYS (Deutschland), Instana über IBM-EU-Regionen, Elastic (Unternehmen niederländischen Ursprungs, selbst betreibbar).
• A wählen, wenn: Sie bereits eine Observability-Plattform nutzen; der Agent kann dann Daten verwenden, die dort schon vorliegen.

Weg B — Auf Cloud-KI-Diensten aufbauen

• Telemetrie: OpenTelemetry-Collectors in ein in der EU gehostetes Backend (Grafana Tempo/Loki/Mimir, ClickHouse-basierte Speicher, Elastic).
• Schlussfolgern: führende Reasoning-Modelle (Claude, Gemini, GPT, Mistral) mit Werkzeugnutzung über einen MCP- Server oder Funktionsaufrufe an Ihre Prometheus-/Loki-/Kubernetes-APIs; Endpunkte in EU-Regionen (Azure OpenAI EU, Vertex AI EU, Amazon Bedrock Frankfurt, Mistral).
• B wählen, wenn: Sie eigene Werkzeuge und einen eigenen Datenumfang brauchen, aber ein Cloud-Modell akzeptieren.

Weg C — Selbst betreiben (Open Source)

• Erkennung und Korrelation: Prometheus + Alertmanager, Grafana, OpenSearch/Elastic, Anomalie-Bibliotheken im Netflix-Stil, Merlion/Darts/Prophet für Zeitreihen; Keep (Open-Source-Alarmverwaltung).
• Agenten: HolmesGPT (CNCF Sandbox, Robusta) und K8sGPT für Kubernetes; eigene Agenten auf Open-Weight-Modellen (z. B. Qwen3, Llama, Mistral, gpt-oss-Familien), betrieben über vLLM oder Ollama [4].
• Hardware: HW3 für ein Reasoning-Modell mit ca. 30-120B; HW2 funktioniert für kleinere Modelle mit schwächerem Schlussfolgern. Logs können personenbezogene Daten enthalten, was ein starkes Argument für den Eigenbetrieb ist.

Weg D — Eigenes Training

Lohnt sich selten. Möglich für sehr große Betreiber: Detektoren auf der eigenen Metrik-Historie trainieren, ein kleines Modell auf gekennzeichneten Paaren aus Störung und Ursache feintunen oder Graphmodelle über die Topologie trainieren. Das braucht Hunderte gut gekennzeichnete Störungen mit bestätigten Ursachen, die die meisten Teams nicht haben.

Stand der Technik (2026)

• Anomalieerkennung und Alarmbündelung sind ausgereift und in jeder großen Suite zur Standardleistung geworden.
• Kausale KI auf der Topologie (im Stil von Dynatrace) ist deterministisch und erklärbar; LLM-Agenten bringen Breite (Logs, Tickets, Code), sind aber weniger reproduzierbar.
• KI-SRE-Agenten wurden 2025-2026 als Produkte etabliert: Sie untersuchen parallel, zitieren Abfragen und behalten standardmäßig nur lesenden Zugriff. Fähigkeiten und Preise in Anbietervergleichen stammen weitgehend von den Anbietern selbst [5].
• Benchmarks: RCAEval (735 Fehlerfälle, 3 Microservice-Systeme, 15 Baselines) und OpenRCA (335 Fälle) testen die Diagnose; OpenRCA 2.0 ergänzt schrittweise kausale Annotationen und zeigt, dass LLM- Agenten oft einen plausiblen Service nennen, ohne einen verifizierten Kausalpfad (laut Veröffentlichung) [1][2][3].
• Grenzen: erfundene Ursachen mit überzeugender Erzählung; schlechte Observability (fehlende Traces, uneinheitliche Labels) begrenzt die Genauigkeit; neuartige Fehlerbilder, die in der Historie fehlen; Kaskadenfehler, bei denen Symptome die Ursache verdecken; Prompt Injection über Log-Inhalte; Kosten wiederholter Abfragen.

Gemeinsame Bausteine & Kombinationen

• Telemetrie- und Log-Stack gemeinsam mit CODE-011 (Log-Analyse und Zusammenfassung) und CODE-018 (LLM-Observability, gleiches OpenTelemetry-Tracing).
• Agenten- und Werkzeugschicht (Reasoning-LLM + MCP-Werkzeuge + Workflow-Engine) gemeinsam mit CODE-009 (Infrastructure-as-Code-Assistent), CODE-014 (Fehler-Triage und automatisierte Behebung; von der Ursache zum Fix-PR) und AGENT-002 (Workflow-Automatisierung).
• Nachbarn: SEC-001 und SEC-005 (Triage von Sicherheitsalarmen, UEBA) nutzen eine ähnliche Korrelation, haben aber andere Bedrohungs- und Compliance-Profile; ANOM-005 und PRED-006 wenden Anomalieerkennung auf Maschinensensoren an.

Aufwand, Kosten & Kennzahlen

• Weg A: Wochen bis zur Aktivierung; die Kosten bestehen überwiegend aus Plattformlizenzen und KI-Guthaben bzw. -Verbrauch, die mit dem Untersuchungsvolumen wachsen können. Abrechnung prüfen.
• Weg B: 2-4 Monate für einen brauchbaren lesenden Ermittler; die Modellkosten je Untersuchung sind gering gegenüber der Zeit der Ingenieure, doch die Kosten der Telemetrie-Abfragen können überwiegen.
• Weg C: 3-6 Monate, GPU-Server plus Zeit von Bereitschafts- bzw. Plattform-Ingenieuren.
• Kennzahlen: MTTD, MTTR, Alarme je Störung (Rauschquote), Anteil der Störungen mit korrekter Top-3- Hypothese (gemessen an Postmortems), Rate falscher Alarmierungen, nächtliche Bereitschaftsstunden, Vorlaufzeit der Postmortems, von Ingenieuren bewertete Nützlichkeit der KI-Zusammenfassungen.

Menschen & Veränderung

Früh einbinden: die Leitung Betrieb/SRE (Prozessverantwortliche) und die Bereitschaftsteams (Endanwender) von Anfang an, da sie die Qualität der Hypothesen beurteilen. Die IT-Sicherheit prüft den lesenden Zugriff und die Aktionen des Agenten (GUIDE-013). Die/der Datenschutzbeauftragte wird gebraucht, weil Logs und Traces Benutzer-IDs und IP-Adressen enthalten können. Die Geschäftsführung entscheidet über das Budget und darüber, welche Aktionen überhaupt je automatisiert werden dürfen.

Betriebsrat: ja, in der Praxis. Observability-Plattformen erfassen, wer was getan hat, Reaktionszeiten und die Leistung der Bereitschaft. Nach §87 Abs. 1 Nr. 6 BetrVG genügt die objektive Eignung zur Überwachung (BAG), die Mitbestimmung greift also auch dann, wenn Überwachung nicht das Ziel ist. §90 Abs. 1 Nr. 3 verlangt die rechtzeitige Unterrichtung über KI-gestützte Arbeitsprozesse; §80 Abs. 3 erlaubt einen KI-Sachverständigen. Vereinbaren Sie eine Betriebsvereinbarung, die eine individuelle Leistungsbewertung aus Störungsdaten ausschließt und den Zugriff begrenzt (GUIDE-004). Öffentlicher Sektor: Personalrat.

Datenschutz: Prüfen Sie personenbezogene Daten in Logs, schließen Sie mit dem Anbieter einen AVV und führen Sie eine DSFA durch, wenn Logs Einzelpersonen systematisch identifizieren (GUIDE-005).

KI-Kompetenz: Schulen Sie das Bereitschaftspersonal darin, Hypothesen in der Rangfolge zu hinterfragen und Belege zu prüfen (GUIDE-006).

Pilot und Kommunikation: Betreiben Sie das System mehrere Wochen im reinen Vorschlagsmodus bei einem Team oder Service und vergleichen Sie mit den menschlichen Ursachenfeststellungen (GUIDE-009, GUIDE-008). Typische Sorgen sind Überwachung und Kompetenzverlust. Begegnen Sie ihnen, indem Sie veröffentlichen, was protokolliert wird, die Nutzung für individuelle Beurteilungen untersagen und Behebungen hinter menschlicher Freigabe halten.

Risiken, Regulierung & Compliance

• KI-Verordnung (AI Act): in der Regel minimales Risiko. Ausnahme: KI als Sicherheitskomponente bei Verwaltung und Betrieb kritischer digitaler Infrastruktur (Anhang III Nr. 2) kann hochriskant sein; bewerten Sie dies bei Betreibern von Energie-, Verkehrs- oder ähnlicher Infrastruktur. Nutzen Sie AIOps nicht zur Mitarbeiterüberwachung oder Leistungsbewertung des Bereitschaftspersonals (Regeln für Personal/Beschäftigtenüberwachung, Betriebsrat). Die Pflicht zur KI-Kompetenz (Art. 4) gilt für Betreiber [6].
• DSGVO: Logs und Traces enthalten oft IP-Adressen, Benutzer-IDs, E-Mail-Adressen und manchmal Nutzdaten. Schwärzen Sie am Collector (OpenTelemetry-Prozessoren), begrenzen Sie die Aufbewahrung, schließen Sie einen AVV und halten Sie Telemetrie und Prompts in der EU.
• NIS2 / DORA: wesentliche/wichtige Einrichtungen und Finanzunternehmen haben Pflichten zur Störungserkennung, zur Meldung (Frühwarnung innerhalb von 24 h nach NIS2) und zum Risiko bei IKT-Drittanbietern; KI-Anbieter gelten nach DORA als IKT- Drittanbieter [7][8].
• Sicherheit: Agenten mit Produktions-Zugangsdaten sind ein lohnendes Ziel. Nutzen Sie minimale Rechte, lesende Token, Freigabeschranken für Schreibaktionen und behandeln Sie Log-Text als nicht vertrauenswürdige Eingabe (Prompt Injection).

Erste Schritte

1. Erfassen Sie als Ausgangswert MTTD/MTTR, Alarme je Störung und die 10 lautesten Alarme der letzten 90 Tage.
2. Sichern Sie zuerst die Telemetrie-Qualität: OpenTelemetry-Instrumentierung, einheitliche Service-Namen, Deploy- und Feature-Flag-Ereignisse im selben Speicher.
3. Aktivieren Sie Alarmbündelung und Anomalieerkennung in Ihrer bestehenden Plattform; werten Sie zwei Wochen lang aus.
4. Erproben Sie einen lesenden KI-Ermittler an 20 früheren Störungen (Wiedergabe) und bewerten Sie die Top-3-Genauigkeit gegen Postmortems.
5. Führen Sie ihn bei einem Bereitschaftsteam mit Rückfrage-vor-Handlung-Rechten ein und erweitern Sie dann die Behebung über geprüfte Runbooks.

Quellen

1. RCAEval: A Benchmark for Root Cause Analysis of Microservice Systems with Telemetry Data — https://arxiv.org/abs/2412.17015
2. OpenRCA 2.0: From Outcome Labels to Causal Process Supervision — https://arxiv.org/html/2606.27154
3. OpenRCA (Microsoft) benchmark repository — https://github.com/microsoft/OpenRCA
4. HolmesGPT (CNCF, Robusta) — https://github.com/robusta-dev/holmesgpt
5. Datadog Bits AI SRE documentation — https://docs.datadoghq.com/bits_ai/bits_ai_sre/
6. Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj
7. Directive (EU) 2022/2555 (NIS2) — https://eur-lex.europa.eu/eli/dir/2022/2555/oj
8. Regulation (EU) 2022/2554 (DORA) — https://eur-lex.europa.eu/eli/reg/2022/2554/oj
9. OpenTelemetry documentation — https://opentelemetry.io/docs/