Jeder Anbieter von Observability-Lösungen bringt mittlerweile etwas auf den Markt, das als „AI SRE“ bezeichnet wird. Cloud-Anbieter haben eines. Plattformen für das Incident-Management haben eines. Ihr Monitoring-Tool hat wahrscheinlich im letzten Quartal eines hinzugefügt.
Für die meisten Entwicklerteams stellt sich nicht mehr die Frage , ob generative KI bei der Fehlerbehebung eingesetzt werden soll. Die Frage ist vielmehr, wie man dies umsetzt, ohne am Ende einen teuren Chatbot zu haben, dem die Entwickler schon nach der zweiten falschen Antwort kein Vertrauen mehr schenken.
Diese zweite falsche Antwort ist das eigentliche Problem.
GenAI scheitert im operativen Einsatz nicht daran, dass die Technologie nutzlos ist. Es scheitert, wenn Teams sie für die falsche Aufgabe einsetzen, sie in der falschen Reihenfolge einführen oder die Sicherheitsvorkehrungen außer Acht lassen, die dafür sorgen, dass man sich auch um 3 Uhr morgens sicher auf ihre Ergebnisse verlassen kann.
Entscheidend ist, zu wissen, was zuerst automatisiert werden soll, was überprüft werden muss und wann es unbedenklich ist, die KI Maßnahmen ergreifen zu lassen.
Seien Sie zunächst ehrlich, was GenAI gut kann
Die Ergebnisse aus der Branche sind konkret. Der Azure SRE Agent von Microsoft hat Diagnosedaten zu mehr als 18.000 Vorfällen gesammelt und meldet Einsparungen von über 10.000 Ingenieursstunden. Der Bits AI SRE von Datadog verzeichnet eine Verkürzung der Zeit bis zur Lösung um bis zu 95 %, indem Hypothesen anhand von Live-Telemetriedaten überprüft werden. PagerDuty hat einen persistenten Speicher in sein System integriert, da sich die Informationen darüber, was einen Vorfall beim letzten Mal behoben hat, mit jedem neuen Vorfall summieren.
Es gibt jedoch noch ein ebenso wichtiges Ergebnis: Eine gründliche Auswertung von ClickHouse aus dem Jahr 2025 ergab, dass die heutigen LLMs bei einer unkritischen Anwendung bei der Fehlerdiagnose keine besseren Ergebnisse erzielen als erfahrene SREs. Was die reine Diagnosegenauigkeit angeht, hat der erfahrene Mensch nach wie vor die Nase vorn.
Wo KI eindeutig hilft, ist die Geschwindigkeit der Zusammenfassung – sie verwandelt vierzig unübersichtliche Warnmeldungen, drei Dashboards und einen Protokollstrom in eine schlüssige Zeitleiste, erstellt einen Entwurf für die Nachbetrachtung und zeigt auf, wo man zuerst nachsehen sollte.
Das sind die zwanzig Minuten Vorarbeit, mit denen jeder Vorfall beginnt, und genau dieser Teil lässt sich heute tatsächlich automatisieren.
Unser Ansatz für den Einsatz von GenAI bei der Behebung von Störungen ist daher ganz einfach:
Die Untersuchung beschleunigen. Die Analyse erstellen. Die Entscheidung in menschlicher Hand behalten.
Beginnen Sie mit der KI-gestützten Telemetrieanalyse
Der risikoärmste Ansatz, um GenAI in das Störungsmanagement einzuführen, ist ganz einfach: Lassen Sie die KI Fragen zu Daten beantworten, die Ihnen bereits vorliegen.
Ein schreibgeschützter Agent kann Fragen zu Ihrem tatsächlichen Ereignisverlauf beantworten:
„Wie viele kritische Warnmeldungen hatten wir letzte Woche in der Produktion?“
„Wie wurde der Fehler ‚KubePodNotReady‘ beim letzten Mal behoben?“
„Welche Regel wurde diesen Monat am häufigsten angewendet?“
Hier beginnt das Vertrauen – und hier zeigt sich auch die erste Schwachstelle: ein Chatbot ohne fundierte Grundlage.
Wenn der Agent seine Antwort auf ein allgemeines Modell eines typischen Kubernetes-Clusters stützt, anstatt auf Ihren Prometheus, Ihren Alarmverlauf und Ihre Runbooks, merken die Entwickler schnell, dass er nur rät.
Der Test ist ganz einfach:
Kann es mithilfe der Daten, über die Sie bereits verfügen, eine Frage beantworten, die Ihre Dashboards nicht beantworten können?
Umstellung auf KI-gestützte Unfalluntersuchung
Fragen zu beantworten ist hilfreich, doch zur Behebung eines Vorfalls sind Untersuchungen erforderlich.
Der nächste Schritt besteht darin, dass der Mitarbeiter eine Warnmeldung wie ein guter Techniker untersucht: Er stellt konkrete Hypothesen auf, überprüft jede einzelne anhand von Echtzeit-Metriken, Protokollen und Ihren tatsächlichen Standardarbeitsanweisungen und legt seine Überlegungen dar.
Der Agent sollte nicht von einem Tool-Aufruf zum nächsten springen, bis er zufällig fündig wird. Er sollte eine Hypothese aufstellen, die relevanten Belege sammeln und erläutern, wie diese Belege seine Einschätzung beeinflussen.
Der Fehlermodus ist hier die plausible Geschichte.
Fragt man ein Sprachmodell: „Warum ist der Zahlungsdienst ausgefallen?“, liefert es eine überzeugende Erklärung – unabhängig davon, ob diese durch Fakten gestützt wird oder nicht.
„Plausibel“ und „richtig“ sind zwei verschiedene Dinge.
Zum jetzigen Zeitpunkt besteht das Ziel nicht darin, dass die KI die endgültige Entscheidung trifft. Vielmehr soll die Untersuchung schneller und strukturierter gestaltet werden, während die Beweise für den Techniker, der den Vorfall bearbeitet, weiterhin einsehbar bleiben.
Überprüfen Sie die von einer KI erstellte Ursachenanalyse, bevor Sie Maßnahmen ergreifen
Hier wird der Unterschied zwischen einer Demo und einem Tool, auf das Ingenieure vertrauen, deutlich.
Eine KI-generierte RCA muss überprüfbar sein.
Verwenden Sie zunächst einen Zitiervertrag: Jede Tatsachenbehauptung – ein Messwert, ein Pod-Name, ein Zeitstempel für die Bereitstellung – muss auf den konkreten Tool-Aufruf verweisen, durch den sie zustande gekommen ist. Alles, was der Agent annimmt, für das er jedoch keine Belege abgerufen hat, muss als unbestätigte Hypothese gekennzeichnet werden.
Eine selbstbewusste Erfindung ist gefährlicher als eine eingestandene Lücke, da ein Bereitschaftsingenieur darauf reagieren könnte.
Zweitens: Setzen Sie einen Prüfer ein, der keine Ermittlungen anstellen darf.
Ein zweiter Prüfer, der über keine Hilfsmittel verfügt, vergleicht jede Behauptung mit dem aufgezeichneten Ausführungsverlauf und stuft sie als belegt, unbegründet, widerlegt oder korrekt als Hypothese gekennzeichnet ein.
Ein Prüfer mit Hilfsmitteln ist eine zweite Meinung. Ein Prüfer ohne Hilfsmittel ist ein Wirtschaftsprüfer.
Das Ergebnis ist ein Gütesiegel auf dem RCA, das genau eines bedeutet:
Diese Behauptungen lassen sich anhand von Beweisen belegen.
Nicht „Diese Schlussfolgerung ist richtig.“ Das sind unterschiedliche Aussagen.
Einführung der „Governed AI Remediation“
Erst wenn das Ergebnis überprüfbar ist, macht es für den Agenten Sinn, etwas zu unternehmen.
Das Deaktivieren einer fehlerhaften Regel, das Neustarten einer Workload oder das Zurücksetzen einer Bereitstellung sollte als Vorschlag mit einer Dry-Run-Vorschau erfolgen, von einer Person genehmigt und mit einem lückenlosen Prüfpfad ausgeführt werden.
Die größten Risiken liegen hier auf der architektonischen Ebene.
Der Untersuchungsagent muss konstruktionsbedingt schreibgeschützt sein – mit separaten Anmeldedaten und einem separaten Toolset, das sich vom agierenden Agenten unterscheidet, anstatt eines Berechtigungsflags auf demselben Agenten.
Aktionen sollten aus einem festgelegten, geprüften Katalog stammen und nicht aus willkürlichen Skripten, die vom Modell generiert werden.
Seltene Ausnahmen, bei denen die Automatisierung nicht auf eine Genehmigung warten sollte – wie beispielsweise Maßnahmen im Zusammenhang mit behördlichen Verzögerungen, bei denen das Zögern selbst das Risiko darstellt –, sollten wohlüberlegt, dokumentiert und selten sein.
Je mehr Befugnisse man einem KI-System einräumt, desto strenger sollten diese Befugnisse geregelt werden.
Was macht den Einsatz von GenAI im Vorfallmanagement erfolgreich?
Ganz gleich, in welcher Phase Sie sich befinden – das sind die Fragen, die wir jedem Anbieter stellen würden – auch uns selbst.
Wohin werden die Inhalte von Warnmeldungen weitergeleitet, und werden sie als nicht vertrauenswürdig eingestuft?
Warn-Labels und Annotationen stammen aus Client-Clustern und gelangen unverändert in das Modell. Dadurch werden sie zu einer vom Angreifer steuerbaren Eingabe – eine Prompt-Injektion in einer Annotation stellt eine echte Angriffsfläche dar.
Eingabeschutzmaßnahmen sind wichtig, aber ebenso wichtig ist die Isolierung der Mandanten, die durch die Begrenzung der Zugriffsrechte pro Umgebung und nicht durch eine Anweisung in einer Eingabeaufforderung erzwungen wird.
Wie hoch sind die Kosten pro behobenem Vorfall?
Wenn man jede Warnmeldung an ein LLM weiterleitet, kann die Einführung von AIOps schnell zu einer bösen Überraschung bei der Cloud-Rechnung führen.
Die Lösung liegt in einer statistischen Vorauswahl, bevor das Modell zum Einsatz kommt – Dublettenabgleich, Entropie-Bewertung und bayessche Priorisierung –, sodass nur die Alarme, die eine Untersuchung rechtfertigen, KI-Ressourcen beanspruchen.
Eine bessere Triage ist ein messbarer Hebel zur Senkung der Kosten pro Vorfall.
Im nächsten Beitrag werden wir uns eingehender mit der KI-gestützten Alarm-Triage befassen.
Merkt es sich das?
Bei den meisten Implementierungen werden alle bisherigen RCA-Analysen gespeichert, ohne dass jemals auf eine davon zurückgegriffen wird. Jeder Vorfall beginnt bei Null.
Der Mehrwert von Persistent Memory kommt nur dann zum Tragen, wenn die Ergebnisse jeder Untersuchung – die Grundursache, die Belege und die tatsächlich ergriffenen Abhilfemaßnahmen – zusammen mit den bereits in Jira vorhandenen, themenbezogenen Tickets als Kontext für die nächste Untersuchung dienen.
Kannst du es einschalten, ohne dass sich dadurch etwas ändert?
Jede Funktion, die einen Alarm unterdrücken oder einen Vorfall ändern könnte, sollte zunächst im Schattenmodus ausgeführt werden können: klassifizieren, aufzeichnen, nichts ändern und Ihnen ermöglichen, die Ergebnisse mit den tatsächlichen Maßnahmen Ihrer Mitarbeiter zu vergleichen, bevor die Funktion aktiv wird.
Der aktuelle Stand unseres KI-SRE-Agenten
Unser Dialog-Agent auf Basis der tatsächlichen Ereignisverlaufsdaten sowie unsere hypothesengestützte RCA, die auf Prometheus-Metriken und SOPs basiert, sind bereits im Einsatz.
Der nächste Schritt ist die verifizierte, KI-generierte RCA. Der Zitiervertrag und das werkzeuglose Verifizierungs-Tool befinden sich derzeit in der Entwicklung und werden zunächst im Schattenmodus bereitgestellt, sodass wir die Ergebnisse anhand des Urteils der Ingenieure kalibrieren können, bevor wir Vertrauenssiegel einführen.
Außerdem entwickeln wir ein geregeltes Fehlerbehebungsverfahren, bei dem eine strikte Trennung von Lese- und Schreibzugriffen eine zwingende Voraussetzung ist. Das Ziel besteht darin, dass der Agent Maßnahmen vorschlägt, genau aufzeigt, was passieren wird, und diese erst nach entsprechender Genehmigung ausführt.
Das Langzeitgedächtnis – einschließlich des semantischen Abrufs vergangener RCA-Episoden und der Suche nach ähnlichen Problemen in Jira – ist ebenfalls in der Roadmap vorgesehen.
Wir möchten Ihnen lieber zeigen, wo wir tatsächlich stehen, als zu behaupten, das gesamte System sei bereits gelöst.
Erste Schritte mit GenAI zur Behebung von Vorfällen
Fang klein an.
Verbinden Sie Ihre bestehenden Systeme – Prometheus, Alertmanager und Ihre Runbooks – und prüfen Sie, ob der Agent Fragen beantworten kann, die Ihre Dashboards nicht beantworten können.
Gehen Sie dann zu einer fundierten Untersuchung über. Sobald die Untersuchung zuverlässige Ergebnisse liefert, führen Sie eine Überprüfung durch. Erst danach sollten Sie in Erwägung ziehen, dem System die Erlaubnis zum Handeln zu erteilen.
In jeder Phase:
Bitten Sie die KI nicht, eine Entscheidung zu treffen, bei der Sie ihr noch nicht genug Vertrauen entgegenbringen können.
So sollte GenAI unserer Meinung nach in die Störungsbehebung Einzug halten – nicht als Sprung von der Überwachung zur autonomen Behebung, sondern als schrittweiser Prozess, bei dem sich jede neue Funktion erst ihren Platz verdienen muss.
Behalten Sie die ITGix-Blogs im Auge, um das nächste Kapitel nicht zu verpassen.
