AI SRE Agent: Die ersten 20 Minuten eines Vorfalls automatisieren
Es ist 3 Uhr morgens. Ein Alarm wird ausgelöst.
Du klappst deinen Laptop auf, und die nächsten zwanzig Minuten verlaufen wie bei jedem anderen Vorfall: Du vergleichst die Daten im Dashboard, verfolgst die Protokolle in einem zweiten Tab und versuchst dich zu erinnern, ob das schon einmal passiert ist und wie das Problem damals behoben wurde.
Wenn Sie den zeitlichen Ablauf erst einmal rekonstruiert haben, ist die Lösung schon fast in greifbarer Nähe. Die Untersuchung war der zeitaufwändige Teil, nicht die Entscheidung.
Auf diese zwanzig Minuten konzentrieren wir derzeit unsere technischen Anstrengungen.
Basierend auf jahrelanger Produktionserfahrung, nun für den Makler niedergeschrieben
Bevor daraus ein Produkt wurde, war es unser Hauptberuf.
Die SRE- und DevOps-Teams von ITGix haben für zahlreiche Kunden Produktionsinfrastrukturen konzipiert, betrieben und Fehler behoben – von Kubernetes-Clustern und Kafka-Pipelines bis hin zu PostgreSQL-Flotten, sowohl in Cloud- als auch in On-Premise-Umgebungen. Wir sind diejenigen, die um 3 Uhr morgens per Pager benachrichtigt werden.
Diese Erfahrung hat eine bestimmte Form, und sie ist selten so einfach wie „die Protokolle überprüfen“.
Man muss wissen, dass eine Verzögerung beim Kafka-Consumer unmittelbar nach einer Bereitstellung oft auf eine Rebalance-Flut hindeutet und nicht auf einen langsamen Consumer. Man muss wissen, dass ein OOMKilled Ein JVM-Pod mit einem flachen Heap-Diagramm kann auf den nativen Speicher statt auf den Heap verweisen. Wenn die P99-Latenz von PostgreSQL ansteigt, während die CPU-Auslastung konstant bleibt, sollte man zunächst die Lock-Wartezeiten und die Verbindungsauslastung überprüfen, bevor man auch nur eine einzige Abfrage umschreibt.
Jeder leitende Ingenieur hat Hunderte dieser Muster im Kopf.
Das Problem ist, dass die meisten davon nur in den Köpfen der Menschen existieren und ein universelles Modell sie nicht kennt. Es weiß zwar, was Kafka ist, aber es weiß nicht unbedingt, was bei diesem Programm um 3 Uhr morgens häufig schiefgeht.
Deshalb halten wir diese Erfahrung in zwei Formen fest, die der Agent direkt nutzen kann.
Standardverfahren von Canonical
Für jede von uns überwachte Technologie stellen wir von ITGix erstellte Runbooks bereit, die direkt mit den Alarmregeln verknüpft sind.
Jede SOP erläutert, was die Warnmeldung bedeutet, was zuerst überprüft werden sollte, womit sich das Problem in der Regel beheben lässt und was nicht verändert werden darf.
Wenn ein Alarm ausgelöst wird, ruft der RCA-Agent das entsprechende SOP ab und fügt es in den Untersuchungsverlauf ein, sodass Sie sehen können, welchem Teil des Playbooks es gefolgt ist.
Ihr Team kann außerdem eigene Standardarbeitsanweisungen (SOPs) für Ihre Dienstleistungen hinzufügen, und die Mitarbeiter können beide nutzen.
Fähigkeiten
Eine SOP gibt dem Mitarbeiter vor, was er überprüfen muss.
Eine Kompetenz umfasst die Vorgehensweise, nach der ein erfahrener Ingenieur die Überprüfung durchführt: die konkreten Abfragen, die ausgeführt werden müssen, die Hypothesen, die zuerst zu überprüfen sind, die maßgeblichen Schwellenwerte und die falschen Fährten, die ausgeschlossen werden müssen.
Wir bauen diese Kompetenzen Schritt für Schritt auf, beginnend mit Vorfällen, die unsere eigenen Teams bereits bewältigt haben.
Ein Modellanbieter kann zwar das Modell bereitstellen, aber nicht diesen betrieblichen Kontext.
Was den Unterschied ausmacht, ist nicht einfach nur ein intelligenteres Modell. Es ist das ingenieurwissenschaftliche Urteilsvermögen, das dem Modell vorgibt, wo es suchen, was es testen und welche Belege von Bedeutung sind.
Und da SOPs und Fähigkeiten klare, überprüfbare Dokumente sind und kein in einem Modell verborgenes Wissen, können Sie genau sehen, was der Agent weiß, es korrigieren und eigene Inhalte hinzufügen.
Das Problem ist nicht mangelnde Überwachung, sondern mangelnde Ermittlungen.
Die meisten Teams sind nicht blind. Sie verfügen über Dashboards, Warnmeldungen, Protokolle und Traces.
Das Problem ist, dass jeder Vorfall immer wieder bei Null anfängt.
Die Plattform weiß, dass ein Alarm ausgelöst wurde. Sie weiß jedoch nicht, dass dasselbe Fehlermuster bereits vor vier Monaten aufgetreten ist, was der Bereitschaftstechniker als Erstes überprüft hat oder wodurch das Problem tatsächlich behoben wurde. Dieses Wissen ist nur noch im Gedächtnis einer Person oder in einem Slack-Thread gespeichert, den niemand mehr finden wird.
Genau hier sehen wir eine praktische Aufgabe für einen KI-SRE-Agenten.
Seine Aufgabe ist eng gefasst und spezifisch: die ersten zwanzig Minuten der Ermittlungsarbeit zu übernehmen, bevor ein Mensch eingreifen muss.
Ersetze nicht die Ermessensentscheidung. Leiste die Vorarbeit, auf der diese Ermessensentscheidung beruht.
Wir sind nicht die Einzigen, die auf KI-SRE setzen – und das ist ein gutes Zeichen
Das ist keine spekulative Wette.
Jeder große Anbieter von Observability- und Cloud-Lösungen hat bereits etwas in diesem Bereich auf den Markt gebracht oder ist dabei, dies zu tun, und die gemeldeten Ergebnisse sind konsistent genug, um ernst genommen zu werden: Der Azure SRE Agent von Microsoft hat Diagnosedaten zu mehr als 18.000 Vorfällen gesammelt und berichtet von einer Einsparung von über 10.000 Ingenieursstunden. Datadogs „Bits AI SRE“ meldet eine Verkürzung der Zeit bis zur Lösung um bis zu 95 %, indem Hypothesen anhand von Live-Telemetriedaten überprüft werden, anstatt einem Techniker Rohdaten zu überhäufen. PagerDuty hat seine Lösung speziell auf persistenten Speicher ausgerichtet, da das Erinnern daran, was beim letzten Mal funktioniert hat, mit jedem bearbeiteten Vorfall an Wert gewinnt.
Es gibt jedoch einen wichtigen Vorbehalt – und den nehmen wir ernst.
Eine gründliche Auswertung von ClickHouse aus dem Jahr 2025 ergab, dass die heutigen LLMs bei einer unkritischen Anwendung bei der Diagnose noch nicht besser abschneiden als erfahrene SREs. Menschliche SREs sind in puncto reiner Genauigkeit nach wie vor überlegen.
Ein Bereich, in dem KI eindeutig punkten kann, ist die Geschwindigkeit der Zusammenfassung: Sie wandelt unübersichtliche Protokolle und Metriken in eine schlüssige Zeitleiste um, erstellt einen Entwurf für die Nachbetrachtung und gibt Hinweise darauf, wo man zuerst nachsehen sollte.
Das ist der tatsächliche Anwendungsbereich, in dem diese Technologie derzeit ihre Stärken ausspielt. Und genau darauf haben wir sie ausgelegt: einen KI-Agenten, der die Untersuchung von Vorfällen beschleunigt und einen Analyseentwurf erstellt, wobei die endgültige Entscheidung weiterhin beim Menschen liegt.
Kein eigenständiger Ersatz dafür.
Warum wir einen KI-SRE-Agenten entwickeln, anstatt einfach nur einen Chatbot einzusetzen
Drei Entscheidungen prägen alles, was wir aufgebaut haben.
Es denkt offen, nicht in einer „Black Box“.
Anstatt das Modell einfach umherirren zu lassen – ein Tool aufrufen, sehen, was zurückkommt, ein anderes Tool aufrufen, wiederholen, bis es aufgibt oder Glück hat –, bildet unser Agent zunächst explizite Hypothesen, untersucht nur das, was für die jeweilige Hypothese relevant ist, und legt seine Argumentation offen.
Man sieht, warum es zu einer Schlussfolgerung kam – und nicht nur zu dieser einen Schlussfolgerung.
Wir reduzieren das Rauschen mithilfe statistischer Verfahren, bevor wir überhaupt einen Modellaufruf zur Untersuchung durchführen.
Nicht jede Warnmeldung verdient eine umfassende Analyse.
Bevor etwas den RCA-Mitarbeiter erreicht, durchläuft es eine Bewertungs-Pipeline, die auf veröffentlichten Verfahren basiert – Entropie-Bewertung, bayessche Signalfusion, Überlebensanalyse zur Eskalationsgeschwindigkeit –, die entscheidet, wie dringend (oder ob überhaupt) es Beachtung verdient.
Die Funktion ist anpassbar, und Sie können eine Konfigurationsänderung anhand Ihres eigenen Alarmverlaufs simulieren, bevor Sie sie aktivieren. Das bedeutet, dass Sie nicht raten müssen, ob eine Änderung tatsächlich hilfreich ist.
Es baut auf dem auf, was Sie bereits nutzen – es handelt sich nicht um ein Migrationsprojekt.
Der Agent liest Ihre tatsächlichen Prometheus-Metriken, Ihre tatsächlichen SOPs und Ihren tatsächlichen Alarmverlauf aus – und nicht ein generisches Modell einer typischen Umgebung.
Onboarding bedeutet, das, was man bereits hat, zu verknüpfen, und nicht, es zu ersetzen.
Ein Mensch billigt alles, was etwas verändert.
Der Ermittler kann ungehindert ermitteln.
Jede Aktion – sei es das De aktivieren einer lautstarken Regel, das Neustarten einer Arbeitslast oder das Anpassen eines Schwellenwerts – führt zu einem Vorschlag mit einer Vorschau, den eine Person genehmigen muss, bevor er ausgeführt wird.
Jedes Mal ein lückenloser Prüfpfad.
Die wenigen Ausnahmen von dieser Regel – Maßnahmen bei regulatorischer Verzögerung, bei denen das Zögern selbst das Risiko darstellt – sind bewusst gewählt, dokumentiert und selten. Sie sind nicht die Regel.
Was der KI-SRE-Agent heute tatsächlich leistet
Die derzeitigen Kompetenzen konzentrieren sich auf Untersuchung, Analyse und Empfehlungen:
- Stellen Sie Fragen in einfacher Sprache. „Wie viele kritische Warnmeldungen gab es letzte Woche in der Produktionsumgebung?“ „Wie wurde diese Warnmeldung beim letzten Mal behoben?“ – Die Antworten basieren auf Ihrem tatsächlichen Ereignisverlauf und sind keine vorgefertigten Standardantworten.
- Eine auf Ihren Runbooks basierende Ursachenanalyse. Wenn ein Alarm ausgelöst wird, führt der Agent die Untersuchung anhand Ihrer tatsächlichen Standardarbeitsanweisungen (SOPs) und unter Berücksichtigung des jeweiligen Umgebungskontexts durch – und nicht anhand einer generischen Vorlage.
- Vorschläge für Regeln und Schwellenwerte, die auf Ihren tatsächlichen historischen Messwerten basieren. Keine Vermutungen auf der Grundlage von Best Practices – sondern eine statistische Auswertung der letzten 30 Tage, die Ihnen genau aufzeigt, welche Warnmeldungen zu schwach oder zu stark eingestellt sind und warum.
Was steht als Nächstes für den KI-SRE-Agenten an?
Wir arbeiten aktiv daran, dass der Agent nicht nur recherchieren, sondern auch handeln kann – indem er eine Lösung vorschlägt, eine Vorschau anzeigt und diese nach Ihrer Zustimmung umsetzt.
Darüber hinaus arbeiten wir an folgenden Projekten:
- ein Agent zur Kostenoptimierung, der nachverfolgt, ob sich seine eigenen Einsparungsvorschläge tatsächlich ausgezahlt haben;
- ein Agent zur Erfassung des Sicherheitsstatus, der auf demselben Vertrauensmodell basiert wie der SRE-Agent; und
- Langzeitgedächtnis, sodass jeder nachfolgende Vorfall von allen vorherigen Vorfällen profitiert, einschließlich der zugehörigen Tickets, die bereits in Ihrem Jira vorliegen.
Behalten Sie die ITGix-Blogs im Auge, um das nächste Kapitel nicht zu verpassen.
