🤖 AI

SREGym: A Live Benchmark for AI SRE Agents with High-Fidelity Failure Scenarios

Dit artikel introduceert SREGym, een modulaire, open-source, high-fidelity live-benchmark gebaseerd op cloud-native stacks uit de praktijk die complexe storingsscenario's simuleert om de prestaties van AI-agenten in Site Reliability Engineering (SRE) grondig te evalueren.

Oorspronkelijke auteurs: Jackson Clark, Yiming Su, Saad Mohammad Rafid Pial, Yifang Tian, Lily Gniedziejko, Hans-Arno Jacobsen, Yinfang Chen, Tianyin Xu

Gepubliceerd 2026-05-11

📖 5 min leestijd🧠 Diepgaand

CC BY 4.0

Oorspronkelijke auteurs: Jackson Clark, Yiming Su, Saad Mohammad Rafid Pial, Yifang Tian, Lily Gniedziejko, Hans-Arno Jacobsen, Yinfang Chen, Tianyin Xu

Oorspronkelijk artikel gelicentieerd onder CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dit is een AI-gegenereerde uitleg van het onderstaande artikel. Het is niet geschreven of goedgekeurd door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer

Stel je voor dat je een team hebt van zeer slimme, door AI aangedreven monteurs. Hun taak is het repareren van een gigantisch, complex, vliegend ruimteschip (een modern cloudcomputingsysteem) terwijl het nog in de lucht is. Deze AI-monteurs worden steeds beter in het schrijven van code om het schip te bouwen, maar de echte test is: kunnen ze het schip daadwerkelijk repareren als het midden in de vlucht begint te breken?

Dit artikel introduceert SREGYM, een nieuwe, hoog-risico trainingsomgeving die specifiek is ontworpen om deze AI-monteurs te testen.

Hier is de uiteenzetting van wat het artikel zegt, met gebruikmaking van eenvoudige analogieën:

1. Het Probleem: De "Te Makkelijke" Test

Vroeger waren tests voor deze AI-monteurs als het geven van een statische foto van een kapotte motor en het vragen: "Wat is er mis?"

De Tekortkoming: Het echte leven is geen statische foto. In de echte wereld kan de motor een vreemd geluid maken (een afleiding), kan de brandstofmeter flitsen (een leugen), en kan het probleem een mix zijn van een gebroken draad en een verstopt filter die tegelijkertijd optreden.
Het Resultaat: De oude tests waren te simpel. Ze hebben de AI niet voorbereid op de chaos van een echt productiesysteem.

2. De Oplossing: SREGYM (De "Live Vuur" Simulator)

De auteurs hebben SREGYM gebouwd, wat lijkt op een vliegsimulator voor IT-rampen.

Het is Live: In plaats van een statische foto moet de AI interageren met een echt, draaiend systeem.
Het is Rommelig: De simulator injecteert "ruis". Stel je voor dat de AI probeert een lek in een pijp te vinden, maar iemand slaat ook tegen de muren, laat gereedschap vallen en flitst met lichten in de buurt. De AI moet uitzoeken welke ruis het echte probleem is en welke slechts een afleiding is.
Het is Diepgaand: De problemen zijn niet alleen "de app crashte". De simulator kan dingen diep in het systeem kapotmaken, zoals het besturingssysteem, de hardware (schijfdrives) of het netwerk, en niet alleen de softwarecode.

3. De Drie Soorten "Vallen"

Het artikel benadrukt drie specifieke manieren waarop ze de simulator lastig maken, vergelijkbaar met hoe een echte noodsituatie verwarrend kan zijn:

Het "Geest"-Probleem (Metastabiele Storing): Stel je een auto voor die prima rijdt totdat je een bepaalde snelheid bereikt, waarna het begint te trillen, en zelfs als je vertraagt, blijft het trillen. De AI moet beseffen dat het trillen niet zomaar een willekeurige storing is; het is een zichzelf in stand houdende lus veroorzaakt door een specifieke instelling.
De "Dubbele Moeilijkheid" (Gelijktijdige Storingen): Twee dingen breken tegelijk. Het ene is een klein probleem (een waarschuwingslampje) en het andere is een groot probleem (een lekke band). De AI moet het waarschuwingslampje negeren en eerst de lekke band repareren.
De "Kettingreactie" (Gecorreleerde Storingen): Een gebroken onderdeel zorgt ervoor dat vijf andere onderdelen falen. De AI moet de keten terug traceren naar het enkele gebroken schakel, in plaats van te proberen alle vijf de symptomen te repareren.

4. De Testresultaten: De AI Worstelt

De onderzoekers hebben drie verschillende AI-"monteurs" door deze simulator getest (90 verschillende scenario's). Hier is wat er gebeurde:

Ze zijn goed in simpele dingen: Als het probleem een simpele typfout in de software is, doen de AI's het redelijk.
Ze raken verdwaald in de ruis: Wanneer er afleidingen zijn (zoals een crashende computer die niet de echte oorzaak is), laten de AI's zich vaak afleiden en proberen ze het verkeerde ding te repareren.
Ze missen het diepe materiaal: Wanneer het probleem diep in de hardware zit (zoals een slechte schijfdrive) of een complexe interactie tussen lagen, gokken de AI's vaak verkeerd. Ze neigen naar de softwareapplicatie de schuld te geven in plaats van de hardware.
De "Gierige" Fout: De AI's gedragen zich vaak als een hond die een bal achterna zit. Ze zien het eerste vreemde ding (een symptoom), gaan ervan uit dat dat het probleem is, en proberen het direct te repareren, zonder dieper te kijken of het misschien slechts een neveneffect van iets anders is.

5. Het Oordeel

Het artikel concludeert dat hoewel AI geweldig is in het schrijven van code, het nog niet klaar is om de primaire monteur te zijn voor het repareren van complexe, realistische systeemstoringen op zichzelf.

De huidige AI-modellen krijgen de diagnose slechts ongeveer 39% tot 73% van de tijd goed.
Ze krijgen de reparatie ongeveer 57% tot 78% van de tijd goed.
Wanneer je beide stappen combineert (diagnose en reparatie), daalt het slagingspercentage aanzienlijk, vooral in de "rommelige" scenario's.

Samenvatting

SREGYM is een nieuwe, realistische sportschool waar AI-agenten kunnen oefenen met het repareren van gebroken systemen. Het artikel toont aan dat hoewel deze AI-agenten slim zijn, ze momenteel gemakkelijk worden afgeleid door ruis, moeite hebben met diepe hardwareproblemen en vaak het verkeerde ding repareren. De sportschool is nu open voor andere onderzoekers om te gebruiken voor het trainen van betere AI-monteurs voor de toekomst.

Technische Samenvatting: SREGym – Een Live Benchmark voor AI SRE-agenten

1. Probleemstelling

Het artikel behandelt de kritieke kloof in de evaluatie van AI-agenten voor Site Reliability Engineering (SRE). Hoewel AI-agenten steeds vaker worden ingezet om productiefouten te diagnosticeren en te mitigeren, zijn bestaande benchmarks onvoldoende om drie hoofdredenen:

Vereenvoudiging: Huidige benchmarks (bijvoorbeeld statische Q&A-datasets, taken voor anomaliedetectie) slagen er niet in de dynamische, meerstaps aard van incidentrespons in de echte wereld te vangen. Ze evalueren agenten vaak op statische data of geïsoleerde symptomen in plaats van op oplossing van begin tot eind.
Gebrek aan Fideliteit: Bestaande live benchmarks (bijvoorbeeld AIOpsLab, ITBench) simuleren fouten maar missen de complexiteit van productieomgevingen. Ze richten zich typisch op problemen op applicatieniveau, negeren "omgevingsruis" (niet-gerelateerde voorbijgaande gebeurtenissen) en slagen er niet in complexe faalmodi te modelleren, zoals metastabiele toestanden of gecorreleerde fouten.
Extensibiliteitsproblemen: Veel benchmarks vertrouwen op maatgemaakte, hard-coded scripts (bijvoorbeeld Ansible) die het moeilijk maken om nieuwe scenario's samen te stellen, gedistribueerde gebeurtenissen te coördineren of de probleemruimte te schalen.

Bovendien introduceert de opkomst van door AI gegenereerde code nieuwe betrouwbaarheidsuitdagingen, met rapporten die aangeven dat AI-code aanzienlijk meer defecten introduceert en vaker aan testen ontsnapt dan door mensen geschreven code. Dit vereist robuuste agente SRE-capaciteiten die verder gaan dan codering en real-time mitigatie omvatten.

2. Methodologie: Het SREGym-framework

De auteurs presenteren SREGym, een hoge-fideliteit, live benchmark gebouwd op echte cloud-native systeemstapels (Kubernetes). In tegenstelling tot statische datasets biedt SREGym een live omgeving waar agenten via een gestandaardiseerde interface met draaiende systemen interageren.

Kernarchitectuur

Systeemomgeving: SREGym implementeert een catalogus van cloud-native applicaties (bijvoorbeeld DeathStarBench, TrainTicket, Astronomy Shop) en backendsystemen (MongoDB, TiDB, Kafka) beheerd door Kubernetes-operators.
Agentinterface: Agenten interageren via het Model Context Protocol (MCP), met toegang tot tools voor metrics (Prometheus), logs (Loki), traces (Jaeger) en clusterbesturing (kubectl).
Injectie van Fouten en Ruis: Het framework gebruikt een modulaire set injectoren om te simuleren:
- Fouten: Oorzaken over de hele stapel, inclusief hardwarefouten (via eBPF), OS-kernfouten, misconfiguraties, codebugs en operatorfouten.
- Ruis: Voorbijgaande, zelfherstellende verstoringen (bijvoorbeeld pod-crashes, verloren pakketten) die niet gerelateerd zijn aan de doelstoring, ontworpen om het vermogen van een agent te testen om signaal van ruis te onderscheiden.
Probleemdefinitie: Een probleem wordt gedefinieerd als een tuple $P = (E, I, F, O)$ , bestaande uit de omgeving, agentinterface, fouten/ruis en orakels.
Evaluatieorakels:
- Diagnoseorakel: Gebruikt een LLM-as-a-Judge-benadering met een gestructureerde checklist (9 Ja/Nee-vragen over drie dimensies: Foutlocatie, Foutkarakterisering en Faalbereik) om natuurlijke taal-diagnoses te evalueren. Dit vermijdt breekbare string-matching en staat een genuanceerde evaluatie toe.
- Mitigatieorakel: Verifieert programmatisch of de doelstoring is opgelost en het systeem is teruggekeerd naar een gezonde staat, met gebruik van zowel client-side (succespercentages van verzoeken) als system-side observabiliteit.

Belangrijke Ontwerpprincipes

Simuleren van Oorzaken, niet Symptomen: Het systeem injecteert oorzaken (bijvoorbeeld een ontbrekende omgevingsvariabele) in plaats van alleen symptomen (bijvoorbeeld een gecrashte pod), waardoor agenten moeten redeneren over het onderliggende defect.
Composabiliteit: Een Python-gebaseerde runtime orkestreert fout- en ruisinjectoren, waardoor complexe scenario's mogelijk zijn zoals metastabiele fouten (zelfonderhoudende degradatie) en gelijktijdige/gecorreleerde fouten.
Extensibiliteit: Het framework is ontworpen om "push-button" te zijn voor probleemcreatie, waardoor onderzoekers bestaande scenario's kunnen muteren of nieuwe kunnen maken via API's.

3. Belangrijkste Bijdragen

SREGym Benchmark: Een live, open-source benchmark met 90 realistische, uitdagende SRE-problemen die hardware, OS en applicatielagen bestrijken.
Hoge-fideliteit Faalmodellering: Introductie van complexe faalmodi die eerder niet in benchmarks werden aangepakt, waaronder:
- Metastabiele Fouten: Systemen die degraderen als reactie op voorbijgaande gebeurtenissen en niet herstellen zonder specifieke interventie.
- Gelijktijdige Fouten: Meerdere onafhankelijke fouten die gelijktijdig optreden.
- Gecorreleerde Fouten: Meerdere componenten die falen door een gedeelde oorzaak.
Simulatie van Omgevingsruis: Het vermogen om voorbijgaande, laag-impact verstoringen in te brengen die agenten uitdagen om irrelevante data te filteren.
Robuust Evaluatieprotocol: Een op checklist gebaseerde LLM-evaluatiemethode die hoge overeenkomst met menselijke experts bereikt ( $\kappa = 0,90$ ) terwijl het schaalt naar grote datasets.

4. Experimentele Resultaten

De auteurs evalueerden drie agenten: Stratus (een gespecialiseerde SRE-agent), Claude Code en OpenAI Codex, aangedreven door frontier-modellen (Sonnet-4.6, GPT-5.4, Kimi K2.5).

Algemene Prestaties

Succespercentages: Succespercentages voor diagnose varieerden van 38,9% tot 72,6%, en voor mitigatie van 57,3% tot 78,5%.
End-to-End (E2E) Prestaties: Het E2E-succespercentage (correcte diagnose + correcte mitigatie) varieerde aanzienlijk, met verschillen van maximaal 40% tussen agent-modelparen.
Invloed van Ruis: De aanwezigheid van ruis verlaagde consistent de succespercentages voor diagnose bij alle agenten. Mitigatie was robuuster maar werd toch beïnvloed.

Belangrijkste Bevindingen

Laagspecifieke Zwaktes: Agenten presteerden goed bij problemen op applicatieniveau, maar hadden aanzienlijke moeite met fouten die geworteld waren in lagere lagen (OS, hardware) of complexe patronen. Bijvoorbeeld, in hardwarefoutscenario's (schijfsectorfouten) slaagden agenten er niet in de hardware-oorzaak te identificeren en schreven deze vaak ten onrechte toe aan applicatielogica.
Uitdagingen bij Metastabiele Fouten: Agenten konden triggers op applicatieniveau identificeren, maar slaagden er vaak niet in deze te verbinden met infrastructuurbeperkingen (bijvoorbeeld resourcequota's) die nodig waren om de metastabiele toestand op te lossen.
Gierige Diagnose: Een terugkerende faalmodus was de " gierige aanpak", waarbij agenten vasthingen aan de eerste plausibele anomalie (vaak ruis of een niet-gerelateerd probleem) en niet verder onderzochten, wat leidde tot onjuiste toewijzing van de oorzaak.
Token-efficiëntie: Gespecialiseerde SRE-agenten (Stratus) waren aanzienlijk efficiënter in tokens (ongeveer 3x minder tokens gebruikt) dan coderingsagenten (Claude Code, Codex) door observabiliteitsdata voor te verwerken, zonder in te leveren op E2E-succespercentages.
Correlatie Diagnose-Mitigatie: Correcte diagnose correleerde sterk met succesvolle mitigatie ( $P(M|D) \approx 0,69\text{--}0,88$ ). Agenten konden fouten echter soms mitigeren, zelfs met onjuiste diagnoses, door iteratief het systeem te observeren en af te stemmen, hoewel dit minder efficiënt was.

5. Betekenis en Claims

Het artikel positioneert SREGym als een fundamentele stap richting productieklaar agente SRE.

Realisme: Door de "ruisende" en "gebeurtenisrijke" aard van productieomgevingen te simuleren, biedt SREGym een nauwkeurigere maatstaf voor de bereidheid van een agent voor implementatie in de echte wereld dan statische benchmarks.
Communityhulpbron: Als open-source, uitbreidbaar framework streeft het ernaar onderzoek te versnellen door een gemeenschappelijke basis te bieden voor het evalueren van diverse agentarchitecturen en modellen.
Beperkingen: De auteurs erkennen nederig beperkingen, waaronder de kleinere schaal van ingezette applicaties vergeleken met hyperschaalproductiesystemen, vereenvoudigde ruismodellen en de huidige evaluatie van slechts enkele agent-modelparen. Ze benadrukken dat hoge scores op SREGym een noodzakelijke maar niet voldoende voorwaarde zijn voor productieveiligheid.

Concluderend toont SREGym aan dat hoewel frontier-AI-agenten veelbelovend zijn in SRE-taken, er aanzienlijke gaten blijven in het hanteren van hoge-fideliteit, meerlagige en ruisende faalscenario's, wat de noodzaak onderstreept van verdere ontwikkeling in agente reliability engineering.