TReNDS nasadil AI agenta na analýzu produkčných chýb, výsledky však zatiaľ hodnotil interne

Od upozornenia k automatickému vyšetrovaniu

Center for Translational Research in Neuroimaging and Data Science, skrátene TReNDS, nasadil do produkcie agenta, ktorý po zachytení chyby automaticky zhromaždí prevádzkové stopy a pripraví analýzu pravdepodobnej príčiny. Centrum funguje ako spoločné pracovisko Georgia State University, Georgia Institute of Technology a Emory University a prevádzkuje výskumné aplikácie a API na Amazon EKS. Podľa prípadovej štúdie napísanej spoločne pracovníkom TReNDS a architektmi AWS trvalo manuálne vyšetrovanie priamočiarejších chýb približne 15 až 30 minút. Nový systém má pri takýchto prípadoch doručiť prvú štruktúrovanú diagnózu za menej než 60 sekúnd.

Architektúra sa začína pri logoch odosielaných cez Fluent Bit do Amazon CloudWatch. Subscription filter sleduje výrazy ako ERROR, Exception, FATAL alebo CRITICAL a pri zhode aktivuje funkciu AWS Lambda. Tá rozbalí udalosť, odovzdá ju agentovi vytvorenému pomocou Strands Agents SDK a model dostupný cez Amazon Bedrock rozhodne, ktoré nástroje potrebuje použiť. Hotová analýza smeruje cez Amazon SNS k vývojárom. Systém teda nenahrádza monitoring: nadväzuje na existujúce upozornenie a automatizuje časť práce medzi zaznamenaním chyby a začiatkom opravy.

Podstatným detailom, ktorý v pôvodnom krátkom súhrne chýbal, je spôsob získavania dôkazov. Jeden nástroj vyhľadá v rovnakom logovom streame udalosti z časového okna okolo chyby, aby agent získal celý stack trace a predchádzajúce varovania bez miešania záznamov z iných kontajnerov. Ďalší nástroj načíta z GitHubu konkrétny súbor uvedený v stack trace. Model tak môže sledovať volania medzi súbormi alebo dohľadať spoločnú pomocnú funkciu. Ide o užitočnejší vzor než jednoduché odoslanie jedného chybového riadka do chatbota, stále však závisí od úplnosti telemetrie a správneho priradenia nasadeného kódu.

TReNDS testoval viacero modelov a ako primárny zvolil Claude Sonnet, pretože podľa interného hodnotenia najlepšie zvládal nástroje a uvažovanie nad viacerými súbormi. Jednoduchšie prípady by v budúcnosti mohli smerovať k lacnejšiemu modelu a zložité incidenty k výkonnejšiemu. Systém zároveň používa DynamoDB na deduplikáciu opakovaných chýb po rovnakom vydaní, aby každá kópia udalosti nespúšťala ďalšiu platenú analýzu. To je prakticky dôležité: bez obmedzenia duplicít by porucha produkujúca tisíce rovnakých záznamov mohla zahltiť tím aj rozpočet na modelové volania.

Kde môže vzniknúť reálna úspora

Najväčšou hodnotou nie je tvrdenie, že model autonómne opravuje produkciu. V opísanom nasadení zhromažďuje kontext a vytvára východisko pre človeka, ktorý diagnózu preverí a rozhodne o zásahu. Vývojár nemusí ručne otvárať viacero obrazoviek, hľadať správny kontajner, kopírovať stack trace a následne prechádzať repozitár. Takýto pomocník môže byť prínosný najmä počas pohotovosti alebo pri službe, ktorú rieši menej skúsený člen tímu. Konzistentná prvá analýza tiež uľahčuje porovnávanie opakujúcich sa incidentov.

Údaj o čase kratšom než minúta však nemožno čítať ako všeobecný benchmark. AWS ani TReNDS nezverejnili počet hodnotených incidentov, ich rozdelenie podľa náročnosti, úspešnosť určenia skutočnej príčiny, mieru falošných diagnóz ani celkové náklady. Porovnávanie navyše spája čas manuálneho vyšetrovania s časom vytvorenia prvého automatického návrhu, nie nevyhnutne s časom do overenej opravy. Organizácia, ktorá chce podobný systém nasadiť, by preto mala merať aspoň presnosť diagnóz, podiel užitočných odporúčaní, latenciu, cenu na incident a zmenu času obnovy služby.

Logy a kód sú citlivé vstupy

Prepojenie modelu s produkčnými logmi a súkromným repozitárom rozširuje bezpečnostnú hranicu. Log môže obsahovať osobné údaje, prihlasovací údaj omylom vypísaný aplikáciou alebo text ovplyvnený používateľom. Takýto text sa nesmie stať dôveryhodným pokynom pre agenta. OWASP medzi rizikami systémov založených na LLM uvádza prompt injection, únik citlivých informácií, nebezpečné spracovanie výstupu, nadmerné oprávnenia a prílišnú dôveru v odpoveď modelu. Nástroje agenta by preto mali mať minimálne oprávnenia, prístup iba k potrebným logovým skupinám a repozitárom, obmedzený objem načítaných dát a audit každého volania.

TReNDS pracuje aj s výskumom súvisiacim so zdravím, preto autori zdôrazňujú dátové hranice a možné požiadavky HIPAA. Pre slovenské a európske organizácie bude dôležitý najmä GDPR režim spracovania osobných údajov v logoch, zmluvné nastavenie cloudových služieb, retenčné lehoty a umiestnenie spracovania. Samotné použitie služby v európskom regióne neodstraňuje potrebu dátovej inventúry a posúdenia prístupov. AI Act používa rizikový prístup a pri vybraných vysokorizikových systémoch zdôrazňuje logovanie, dokumentáciu, ľudský dohľad, robustnosť a kybernetickú bezpečnosť. Bežný interný nástroj pre DevOps nemusí automaticky patriť medzi vysokorizikové systémy, tieto zásady sú však vhodným prevádzkovým minimom.

Čo ešte treba preukázať

Otvorenou otázkou zostáva kvalita pri zložitých incidentoch. Chyby spôsobené súbehom procesov, výpadkom externej služby, zmenou konfigurácie alebo nedostatočnou telemetriou nemusia byť vysvetliteľné zo stack trace a niekoľkých súborov. Model tiež môže zameniť koreláciu za príčinu alebo načítať inú revíziu kódu, než aká reálne beží. Pred rozšírením právomocí by preto mal tím vytvoriť súbor historických incidentov so známou príčinou, hodnotiť odpovede naslepo a sledovať, či sa kvalita nemení pri výmene modelu, promptu alebo nástrojov.

TReNDS plánuje pripojiť interné runbooky, rozdeliť incidenty medzi lacnejšie a výkonnejšie modely a neskôr automaticky vytvárať GitHub issues či návrhy pull requestov. Každý takýto krok zvyšuje užitočnosť, ale aj možný dosah chyby. Rozumnou hranicou je ponechať agentovi čítanie a prípravu návrhov, zatiaľ čo zápis do repozitára, nasadenie alebo zásah do klastra vyžaduje schválenie človekom. Prípad TReNDS je presvedčivou ukážkou úzko vymedzeného agenta napojeného na overiteľné nástroje, nie dôkazom, že autonómna analýza už spoľahlivo nahrádza skúseného prevádzkového inžiniera.