Ein KI-SRE-Agent, der mit Belegen arbeitet

Was ist ein KI-SRE-Agent?

Ein KI-SRE-Agent ist Software, die Teile der Arbeit übernimmt, die Site Reliability Engineers während eines Incidents leisten: Alerts lesen, Kontext sammeln, Hypothesen zur Ursache bilden und prüfen sowie nächste Schritte vorschlagen. Anders als ein Chatbot, der Fragen beantwortet, führt ein Agent selbstständig eine Folge von Schritten aus, etwa Daten abfragen, Zeiträume vergleichen und aktuelle Änderungen prüfen.

Ziel ist nicht, Bereitschaftsteams zu ersetzen. Es geht darum, die Zeit zwischen „ein Alert hat ausgelöst“ und „wir verstehen, was passiert“ zu verkürzen und denjenigen, die nachts geweckt werden, wiederkehrende Analyse- und Dokumentationsarbeit abzunehmen.

Warum KI für Incident Response

Moderne Systeme bestehen aus vielen Services, Clustern und Abhängigkeiten. Fällt etwas aus, verteilen sich die relevanten Hinweise auf Logs, Metriken, Traces, Deployment-Historie und Konfigurationsänderungen. Ein großer Teil eines Incidents vergeht damit, diesen Kontext zusammenzutragen, oft unter Zeitdruck und ohne genaue Kenntnis der Services anderer Teams.

Ein Agent kann diese ersten Schritte jedes Mal gleich gründlich ausführen. Er wird nicht müde, prüft dieselben Quellen in derselben Reihenfolge und kann viele Signale parallel auswerten, auch bei Services, die Ihr Team nur selten betreut. Wie nützlich er ist, hängt von zwei Dingen ab: dem Zugriff auf gut strukturierte Telemetrie mit Topologie und der Transparenz darüber, wie er zu seinen Schlüssen kommt.

So arbeitet der Obseria AI Agent

Der Obseria AI Agent ist Teil von Obseria Intelligence. Löst ein Alert oder ein SLO-Burn-Rate-Alert aus, beginnt er eine Untersuchung:

1. Triage: Er gruppiert zusammengehörige Alerts, ermittelt betroffene Services und schätzt die Auswirkung auf Nutzer anhand von SLOs und Request-Daten.
2. Kontext: Er nutzt TopoGraph, um vor- und nachgelagerte Abhängigkeiten zu finden, und prüft aktuelle Deployments, Konfigurationsänderungen und Automatisierungsläufe.
3. Analyse: Er fragt Logs, Metriken und Traces in Obseria Lake mit OQL, PromQL oder SQL ab, vergleicht das Incident-Fenster mit dem Normalverhalten und grenzt wahrscheinliche Ursachen ein.
4. Belege: Er stellt seine Befunde als Beweiskette dar, jeder Schritt verknüpft mit der Abfrage und den Daten dahinter.
5. Vorschlag: Er schlägt eine Maßnahme vor, etwa einen Rollback des letzten Deployments oder ein Runbook aus Obseria Automation.

Die Untersuchung erscheint direkt im Incident, sodass alle Beteiligten dieselben Informationen sehen. Sie können Rückfragen stellen, zusätzliche Prüfungen anfordern oder eine Hypothese verwerfen.

Leitplanken und menschliche Freigabe

Wenn Software Produktivsysteme verändern darf, braucht es klare Grenzen. Der Obseria AI Agent führt standardmäßig keine Aktionen eigenständig aus. Sie entscheiden, welche Aktionen er vorschlagen darf, welche eine ausdrückliche Freigabe durch eine Person erfordern und welche innerhalb festgelegter Grenzen automatisch laufen dürfen, zum Beispiel der Neustart eines einzelnen Pods in einem Nicht-Produktions-Namespace.

Die Berechtigungen folgen der rollenbasierten Zugriffskontrolle Ihrer Obseria-Organisation. Jeder Vorschlag, jede Freigabe und jede Aktion wird in der Incident-Zeitleiste und im Audit-Log festgehalten. So ist jederzeit nachvollziehbar, wer was wann freigegeben hat. Der Agent kann sich irren, und genau deshalb gibt es die Beweiskette: Sie können seine Schlüsse prüfen, bevor Sie handeln.

Incident-Zusammenfassungen und Postmortem-Entwürfe

Nach einem Incident dauert die Dokumentation oft länger als die Behebung. Der Agent entwirft eine Zusammenfassung mit Zeitleiste, betroffenen Services, Auswirkung, ergriffenen Maßnahmen und den gesammelten Belegen. Für ein Postmortem bereitet er einen Entwurf mit beitragenden Faktoren und offenen Fragen vor, den Ihr Team prüft, korrigiert und ergänzt. Der Entwurf ist ein Ausgangspunkt; Schlussfolgerungen und Folgemaßnahmen verantwortet weiterhin das Team.

So erzielen Sie gute Ergebnisse

• Einheitlich instrumentieren. Nutzen Sie die OpenTelemetry Semantic Conventions und konsistente Servicenamen, damit der Agent Signale verknüpfen kann.
• Deployments erfassen. Senden Sie Deployment- und Konfigurationsereignisse; viele Incidents beginnen mit einer Änderung.
• SLOs definieren. Sie geben dem Agenten ein klares Maß für Nutzerauswirkung und Priorität.
• Mit Freigabe für alles starten. Erweitern Sie automatische Aktionen schrittweise, sobald Sie einzelnen Abläufen vertrauen.
• Ergebnisse prüfen. Behandeln Sie Befunde als gut vorbereitete Hypothese und geben Sie Feedback, wenn sie falsch sind.