Bevor Sie einen AI-SRE bewerten, geben Sie Ihrem vorhandenen Agenten Kontext
🇬🇧 Read in English~4 min read
devopscloud-nativekubernetessreai-agentsmcpobservability
GPU-Teams stehen vor einem schlechten Kompromiss: ein Control Plane pro Team oder schwache Isolation in einem gemeinsamen Cluster. Dieses reproduzierbare Labor kombiniert Kamaji (Control Planes als Pods) und HAMi (fraktionierte GPUs) auf einer einzigen Maschine ohne GPU, unter Verwendung von HAMis Mock-Device-Plugin.
Wenn Sie AI-SRE-Produkte evaluieren, besitzen Sie wahrscheinlich bereits einen Großteil davon. Der Coding-Agent, den Ihre Entwickler nutzen – Claude Code, Codex oder Cursor – kann bereits einen Kubernetes-Cluster untersuchen. Was ihm meist fehlt, ist Kontext: Was fällt gerade aus, und was hat sich geändert, bevor es kaputtging.
Wir haben gemessen, wie viel dieser Unterschied ausmacht. Derselbe Agent und dasselbe Modell arbeiteten zweimal 50 kaputte Cluster durch: einmal mit einer Shell und rohem kubectl, einmal mit Read-only-MCP-Tools, die diesen Kontext liefern.
| Metrik | Shell + kubectl | Read-only-Clusterkontext |
|---|---|---|
| Korrekte Diagnosen (von 50) | 45 | 46 |
| Mittlere Bewertung (0–1) | 0.905 | 0.936 |
| Innerhalb von 2 Minuten korrekt | 60 % | 86 % |
| Innerhalb von 5 Minuten korrekt | 78 % | 90 % |
| Mittlere Zeit bis zur Diagnose-Einreichung (richtig oder falsch) | 191 s | 64 s |
| Median | 87 s | 44 s |
| 90. Perzentil | 632 s | 94 s |
| Mittlere Tool-Aufrufe pro Fehler | 16.3 | 9.8 |
Der Genauigkeitsgewinn war moderat – 46 gegenüber 45, wobei beide Arme bei 44 derselben Fehler richtig lagen. Der große Unterschied war Zeit, und die zählt bei einem aktiven Ausfall: Niemand möchte fünfzehn Minuten auf eine KI-Untersuchung warten, während Nutzer Fehlermeldungen erhalten.
Mit Kontext hatte der Agent bei 86 % der Fehler innerhalb von zwei Minuten eine korrekte Diagnose, gegenüber 60 % mit einer Shell. Mit einer Shell dauerte einer von zehn Fehlern mehr als zehn Minuten. Die größte Lücke zeigte sich bei den 14 Fehlern, bei denen alle Pods „Ready“ meldeten, die Anwendung aber defekt war: durchschnittlich 326 Sekunden mit Shell, 79 mit Kontext. Weniger Tool-Aufrufe bedeuten auch weniger Modell-Schleifen – in der Regel geringere Token-Kosten.
50 Fehler aus SREGym (dem offenen Kubernetes-Fehler-Benchmark von Microsoft und UIUC) auf einem Live-3-Knoten-Amazon-EKS-Cluster. Beide Arme nutzten Claude Code auf Claude Sonnet 5 über Bedrock. Ein Arm erhielt eine Shell und rohes kubectl; der andere Read-only-MCP-Tools von Radar (Open-Source-Kubernetes-UI + MCP-Server), wobei kubectl blockiert war, sodass kein Rückgriff auf eine Shell möglich war. SREGyms Bewertungsinstanz – Claude Opus 5 bei Temperatur 0 – bewertete die erste Diagnose, die jeder Lauf einreichte.
Ehrliche Einschränkungen der Autoren: Kontext behob nicht das Urteilsvermögen des Modells. Beide Arme verfehlten dieselben drei Fehler (ein mutierender Webhook, der Speicherlimits bei der Zulassung umschreibt, eine PriorityClass, die fälschlich als globaler Standard skaliert ist, und eine echte, aber unzusammenhängende Fehlkonfiguration, die statt des DNS-Fehlers gemeldet wurde). Die beiden Arme hatten zudem unterschiedliche Berechtigungen – nur die Shell konnte schreiben –, sodass der Lauf nicht exakt isoliert, was die Arbeit erledigt hat.
Radars Read-only-MCP-Tools ergänzen vier Dinge über das hinaus, was kubectl zurückgibt:
--event-ttl, und viele Änderungen erzeugen nie eines).Bevor Sie für ein dediziertes AI-SRE-Produkt ausgeben, geben Sie dem Agenten, den Sie bereits haben, diesen Kontext und messen Sie ihn. Das liefert Ihnen eine Baseline dafür, was das Produkt hinzufügt. Der größte Teil des Werts eines SRE während eines Vorfalls ist nicht Urteilsvermögen – es ist Orientierung: zu wissen, was sich geändert hat und was gerade ausfällt. Das ist günstig bereitzustellen und ist der größte Hebel auf die Zeit bis zur Diagnose, den diese Daten zeigen.