KI-SRE-Agenten erklärt: Was AI SRE in der Incident Response heute leistet, wo die Grenzen liegen und wie die Einführung sicher gelingt

AI SRE bezeichnet den Einsatz von KI-Agenten, die einen Teil der Arbeit von Site Reliability Engineers während und nach Incidents übernehmen: Alerts lesen, Telemetrie abfragen, Änderungen korrelieren, eine Ursache vorschlagen und anschließend die Dokumentation vorbereiten. Mehrere Anbieter von Observability- und Incident-Management-Software bieten inzwischen KI-SRE-Funktionen an, und viele Engineering-Teams experimentieren mit eigenen Agenten auf Basis allgemeiner Sprachmodelle.

Dieser Artikel ist bewusst herstellerneutral. Er zeigt, was ein KI-SRE-Agent in der Incident Response heute realistisch leisten kann, wo seine Grenzen liegen, wie Sie ihn einführen, ohne neue Risiken zu schaffen, und wie das Model Context Protocol (MCP) Coding-Agenten Zugriff auf Observability-Daten gibt. Sie finden außerdem eine Tabelle, mit der Sie entscheiden, wo ein Mensch eingebunden bleibt, und eine Checkliste für die Einführung zum Kopieren.

Was ein KI-SRE-Agent eigentlich ist

Ein KI-SRE-Agent ist kein Chatbot neben dem Dashboard. Er arbeitet in einer Schleife: Er erhält ein Ziel (etwa „Erkläre, warum der Latenz-Alert im Checkout ausgelöst hat“), entscheidet, welche Werkzeuge er aufruft, liest die Ergebnisse, bildet eine Hypothese und fragt weiter ab, bis er antworten kann oder abbrechen muss. Entscheidend sind die Werkzeuge. Typisch sind:

• Abfrageschnittstellen für Logs, Metriken und Traces
• Eine Service-Map oder ein Topologie-Graph mit den Abhängigkeiten
• Die Historie von Deployments, Feature-Flags und Konfigurationsänderungen
• Incident-Einträge, frühere Postmortems und Runbooks
• Optional Schreibaktionen, etwa ein Ticket anlegen, in einen Kanal posten oder eine Automatisierung starten

Das Sprachmodell liefert Schlussfolgerungen und Sprache, die Werkzeuge liefern Fakten. Ein Agent mit starkem Modell und schlechten Werkzeugen produziert selbstbewusste, aber allgemeine Antworten. Ein Agent mit solidem Modell und sehr guten, sauber abgegrenzten Werkzeugen ist oft deutlich nützlicher. Das ist der wichtigste Punkt, bevor Sie ein Produkt für KI Incident Response bewerten.

KI-SRE-Agenten bauen auf älteren AIOps-Ansätzen auf, etwa Anomalieerkennung, Event-Korrelation und Rauschunterdrückung. Den Hintergrund erläutert unser Beitrag Was ist AIOps?

Was AI SRE heute leisten kann

Alert-Triage

Sobald ein Alert auslöst, kann der Agent Kontext sammeln, bevor ein Mensch den Laptop aufklappt: Welcher Service ist betroffen, welche verwandten Alerts gab es zur selben Zeit, gab es letzte Woche einen ähnlichen Alert, welches Team ist zuständig und was empfehlen die Richtlinien zum Incident-Schweregrad? Für die Kollegin oder den Kollegen in der Rufbereitschaft wird aus einem nackten Alert so ein kurzes Briefing. Auch das Zusammenfassen doppelter und abhängiger Alerts zu einem Incident passt gut und hilft, Alert Fatigue zu reduzieren.

Analyse über alle Signale hinweg

Die meiste Zeit geht in Incidents beim Wechseln zwischen Werkzeugen verloren: hier ein Latenzgraph, dort ein Fehlerlog, woanders ein Trace und die Deployment-Liste in noch einem System. Ein Agent kann diese Abfragen parallel ausführen und die Ergebnisse nebeneinanderlegen: „Die Fehlerrate von payment-api stieg um 14:02 Uhr, die ersten Fehler sind Timeouts zur Inventar-Datenbank, ein Deployment von inventory-service endete um 13:58 Uhr, und die Traces zeigen, dass die neue Version pro Request eine eigene Verbindung öffnet.“ Möglich wird das erst durch Topologiedaten, denn sie sagen dem Agenten, welche vor- und nachgelagerten Services er prüfen sollte.

Beweisketten statt bloßer Antworten

Ein guter KI-SRE-Agent nennt nicht einfach eine Ursache. Er zeigt eine Beweiskette: Jede Aussage ist mit der Abfrage, der Logzeile, dem Trace oder dem Change-Event verknüpft, das sie stützt, und er nennt die verworfenen Hypothesen samt Begründung. Das ist wichtiger als die Qualität der Schlussfolgerung selbst. Eine Beweiskette prüft ein Engineer in einer Minute, eine bloße Behauptung muss er von Grund auf neu untersuchen. Die Methode dahinter ist klassische Root-Cause-Analyse, nur schneller ausgeführt.

Vorschläge zur Behebung

Auf Basis der Hypothese kann der Agent nächste Schritte vorschlagen: Deployment zurückrollen, einen Pool skalieren, ein Feature-Flag deaktivieren oder einem bestimmten Runbook folgen. Ein Vorschlag, der auf ein bestehendes, geprüftes Runbook verweist, ist wesentlich sicherer als eine Prozedur, die sich das Modell selbst ausdenkt.

Postmortem-Entwürfe und Kommunikation

Nach dem Incident kann der Agent aus Alerts, Chatnachrichten, Änderungen und Aktionen eine Timeline erstellen und einen ersten Entwurf des Postmortems schreiben. Während des Incidents kann er Statusmeldungen für Stakeholder vorformulieren. Die Analyse der beitragenden Faktoren und die Folgemaßnahmen bleiben in menschlicher Verantwortung, aber niemand beginnt mehr mit einem leeren Dokument. Wie ein solcher Entwurf aufgebaut sein sollte, zeigt unser Beitrag zum Incident-Management-Prozess mit Postmortem-Vorlage.

Wo die Grenzen liegen

Die folgenden Grenzen haben weniger mit dem Modell zu tun als mit der Umgebung, in der der Agent arbeitet.

• Datenqualität: Wenn Services uneinheitlich benannt sind, Logs keine Trace-IDs enthalten oder Metriken keine sinnvollen Labels haben, kann der Agent Signale nicht besser korrelieren als ein Mensch. Oft sogar schlechter, weil er nicht weiß, welche Felder unzuverlässig sind.
• Fehlender Kontext: Viele Ursachen liegen außerhalb der Telemetrie: eine geänderte Drittanbieter-API, ein manueller Eingriff in die Datenbank, eine Marketingkampagne mit plötzlich dreifachem Traffic. Was in keinem abfragbaren System steht, findet der Agent nicht.
• Halluzinationen: Sprachmodelle können plausible, aber falsche Erklärungen liefern, Metriknamen erfinden oder einen Graphen falsch lesen. Ohne Belege kann eine falsche Hypothese ein ganzes Incident-Team in die falsche Richtung schicken.
• Berechtigungen: Ein Agent mit weitreichenden Zugangsdaten ist ein attraktives Angriffsziel und eine Quelle für Unfälle. Prompt Injection über Loginhalte, zu großzügige API-Tokens und Aktionen ohne Freigabe sind reale Risiken.
• Neuartige Fehler: Agenten sind am stärksten bei Fehlermustern, die bekannten ähneln. Wirklich neue Fehlerbilder brauchen weiterhin erfahrene Engineers.
• Kosten und Laufzeit: Umfangreiche Analysen erzeugen viele Abfragen. Ohne Grenzen für Abfrageumfang und Zeiträume wird ein Agent genau dann langsam und teuer, wenn Geschwindigkeit zählt.

Welche Aufgaben passen zu einem KI-Agenten und wo bleibt der Mensch eingebunden?

Nutzen Sie diese Tabelle als Ausgangspunkt, wenn Sie entscheiden, was Sie delegieren. Passen Sie sie an Ihre Risikobereitschaft und Ihr regulatorisches Umfeld an.

Aufgabe	Geeignet für einen KI-Agenten?	Mensch eingebunden?
Alert mit Zuständigkeit, verwandten Alerts und letzten Änderungen anreichern	Ja, hoher Nutzen bei geringem Risiko	Nein, nur lesend
Doppelte und abhängige Alerts gruppieren	Ja	Gruppierungsregeln regelmäßig prüfen
Schweregrad vorschlagen	Ja, als Vorschlag	Ja, Incident Commander bestätigt
Logs, Metriken und Traces über Services hinweg abfragen	Ja, Kernstärke	Nein, nur lesend
Beweiskette aufbauen und Hypothesen gewichten	Ja	Ja, Engineer prüft die Belege
Runbook oder Behebungsschritt vorschlagen	Ja	Ja, Engineer entscheidet
Rollback oder Skalierung ausführen	Teilweise, nur vordefinierte und umkehrbare Aktionen	Ja, ausdrückliche Freigabe pro Aktion
Produktive Konfiguration oder Daten ändern	Nein, heute nicht	Nur Menschen
Statusseiten-Updates vorformulieren	Ja	Ja, ein Mensch veröffentlicht
Postmortem-Timeline entwerfen	Ja	Ja, das Team prüft und verantwortet die Schlüsse
Folgemaßnahmen und Prioritäten festlegen	Eingeschränkt, nur Vorschläge	Ja, Team und Verantwortliche entscheiden

So führen Sie einen KI-SRE-Agenten sicher ein

Mit reinem Lesezugriff beginnen

In der ersten Phase erhält der Agent Lesezugriff auf Telemetrie, Topologie und Änderungshistorie und sonst nichts. Auch Lesezugriff braucht Grenzen: Legen Sie fest, welche Datenbestände er abfragen darf, maskieren Sie personenbezogene Daten, bevor sie ihn erreichen, und begrenzen Sie die Zeiträume von Abfragen. Viele Teams betreiben den Agenten zunächst im „Schattenmodus“: Er untersucht echte Incidents parallel, seine Ergebnisse werden aber nur mit denen der Menschen verglichen.

Freigabe-Workflows vor jeder Schreibaktion

Wenn Sie Aktionen zulassen, beginnen Sie mit risikoarmen, umkehrbaren Schritten wie dem Anlegen eines Tickets oder dem Posten einer Zusammenfassung. Produktive Aktionen wie Rollbacks sollten nur als vordefinierte Automatisierungen mit ausdrücklichem Freigabeschritt verfügbar sein, idealerweise durch den Incident Commander. Der Agent schlägt vor, ein Mensch gibt frei, die Automatisierung führt aus.

Leitplanken setzen

• Allow-Listen für Werkzeuge und Aktionen statt offenem API-Zugriff
• Eigene, kurzlebige Zugangsdaten für den Agenten mit minimalen Rechten
• Loginhalte und Tickettexte als nicht vertrauenswürdige Eingaben behandeln, die Prompt Injection enthalten können
• Rate Limits und Budgets für Abfragen und Modellaufrufe
• Ein klarer Stopp-Mechanismus: Menschen können jede Analyse und Automatisierung jederzeit anhalten

Audit-Logs führen

Jeder Werkzeugaufruf, jede Abfrage, jeder Vorschlag und jede freigegebene Aktion sollte mit Zeitstempel, Eingabe, Ausgabe und der freigebenden Person protokolliert werden. Audit-Logs brauchen Sie für Compliance, aber auch, um den Agenten selbst zu debuggen, wenn er danebenliegt.

Nutzen messen, nicht Eindruck

Demos beeindrucken immer. Legen Sie vorab fest, an welchen Kennzahlen Sie erkennen, ob der Agent in Ihrer Umgebung hilft:

• Zeit bis zur ersten brauchbaren Hypothese: Minuten vom Alert bis zu einer Hypothese, die das zuständige Team für verfolgenswert hält.
• Akzeptanzrate: Anteil der Vorschläge (Hypothesen, Runbooks, Schweregrade), die Menschen übernehmen.
• Fehlleitungsquote: Wie oft lag die führende Hypothese des Agenten falsch und hat Zeit gekostet?
• Auswirkung auf MTTD und Lösungszeit im Vergleich zu einem Referenzzeitraum vor der Einführung.
• Feedback der Engineers: ein einfaches Daumen hoch oder runter pro Analyse, ausgewertet in den Incident-Retrospektiven.

Messen Sie über genügend Incidents, um ein Muster zu erkennen, und vergleichen Sie Vergleichbares: Ein ruhiger Monat ist kein fairer Maßstab für einen turbulenten.

Checkliste für die Einführung von KI-SRE-Agenten

Übernehmen Sie diese Checkliste in Ihren Einführungsplan und haken Sie jeden Punkt ab, bevor Sie in die nächste Phase wechseln.

CHECKLISTE: EINFÜHRUNG KI-SRE-AGENT

Phase 0 - Grundlagen
[ ] Einheitliche Service-Namen in Logs, Metriken und Traces
[ ] Trace-Kontext wird weitergegeben; Logs enthalten Trace-IDs
[ ] Topologie / Service-Map vorhanden und aktuell
[ ] Deployments, Feature-Flags und Konfigurationsänderungen als Events erfasst
[ ] Runbooks geprüft und für den Agenten lesbar abgelegt
[ ] Personenbezogene Daten vor der Speicherung maskiert oder verworfen

Phase 1 - Nur lesend / Schattenmodus
[ ] Eigene Agenten-Identität mit Lesezugriff nach Least Privilege
[ ] Allow-Liste der Datenquellen und Abfragegrenzen festgelegt
[ ] Agent untersucht echte Incidents parallel, ohne dass gehandelt wird
[ ] Jede Analyse zeigt eine Beweiskette mit Links
[ ] Referenzwerte erfasst: MTTD, Lösungszeit, Zeit bis zur ersten Hypothese

Phase 2 - Unterstützte Reaktion
[ ] Agenten-Briefing wird im Incident-Kanal gepostet
[ ] Vorschläge (Schweregrad, Runbook, Hypothese) werden bewertet
[ ] Akzeptanzrate und Fehlleitungsquote werden gemessen
[ ] Postmortem-Entwürfe werden erzeugt und vom Team geprüft

Phase 3 - Freigegebene Aktionen
[ ] Nur vordefinierte, umkehrbare Automatisierungen verfügbar
[ ] Ausdrückliche Freigabe pro Aktion, freigebende Person protokolliert
[ ] Not-Aus getestet
[ ] Vollständiges Audit-Log von Werkzeugaufrufen, Prompts, Ausgaben, Aktionen

Laufend
[ ] Monatliche Auswertung der Kennzahlen und abgelehnten Vorschläge
[ ] Mindestens quartalsweise Prüfung von Berechtigungen und Prompt Injection
[ ] Runbooks ergänzen, wenn der Agent wiederholt auf Lücken stößt

Wie MCP Coding-Agenten Zugriff auf Observability-Daten gibt

Das Model Context Protocol (MCP) ist ein offenes Protokoll, das standardisiert, wie KI-Anwendungen sich mit externen Werkzeugen und Datenquellen verbinden. Statt für jeden Assistenten eine eigene Integration zu bauen, stellt ein System einen MCP-Server mit einer Reihe von Werkzeugen bereit, und jeder MCP-fähige Client kann sie nutzen. Viele Coding-Agenten und KI-gestützte IDEs unterstützen MCP bereits.

Für Observability heißt das: Eine Entwicklerin kann ihren Coding-Agenten fragen „Welche Fehler hat mein letztes Deployment von checkout-service verursacht?“ oder „Zeig mir die langsamsten Spans dieses Endpunkts in der letzten Stunde“, und der Agent fragt das Observability-Backend über den MCP-Server ab. Anschließend kann er die Antwort mit dem geöffneten Code abgleichen, einen Fix vorschlagen und auf den Trace verweisen, der das Problem belegt.

Es gelten dieselben Leitplanken wie für einen KI-SRE-Agenten:

• Standardmäßig nur lesende Werkzeuge bereitstellen und auf die Rechte der Person beschränken
• Begrenzte Ergebnismengen zurückgeben, damit der Agent keine kompletten Datenbestände in seinen Kontext lädt
• Sensible Felder bereits in der Pipeline maskieren, nicht erst im Prompt
• Werkzeugaufrufe protokollieren, damit nachvollziehbar ist, welche Daten die Plattform verlassen haben

MCP schließt die Lücke zwischen Produktion und Code: Incidents lassen sich leichter reproduzieren, und Fixes können vor dem Release an echter Telemetrie geprüft werden.

Wie Obseria unterstützt

Obseria ist eine OpenTelemetry-native Observability-Plattform mit Hosting in der EU. Die KI-SRE-Funktionen folgen den Prinzipien aus diesem Artikel: Belege vor Schlussfolgerungen, Aktionen unter menschlicher Kontrolle und Daten, die vor der Speicherung bereinigt werden.

• Der KI-SRE-Agent analysiert Logs, Metriken, Traces, Topologie und Change-Events in Obseria Lake und TopoGraph und präsentiert seine Ergebnisse als Beweiskette.
• Obseria Pipeline maskiert personenbezogene Daten und filtert vor der Speicherung, sodass der Agent nur sieht, was er sehen soll.
• Behebungen laufen über Automation-Workflows und Runbooks mit Freigabeschritten, integriert in das Incident Management und mit Audit-Logging.
• Der MCP-Server gibt Coding-Agenten abgegrenzten, lesenden Zugriff auf Ihre Observability-Daten.

Wenn Sie sehen möchten, wie eine belegbasierte Analyse auf echter Telemetrie aussieht, vereinbaren Sie eine Demo mit unserem Team.