TReNDS DI agentas ieško klaidų priežasties: logai pagaliau kalba žmonių kalba
·
DI agentas klaidų analizei šiandien nėra teorinis žaislas. Tai jau darbas, pinigai, duomenys ir kartais labai žemiškas klausimas: kas prisiims atsakomybę, kai DI pradės veikti už žmogų?
DI agentas klaidų analizei skamba kaip nišinė programuotojų tema. Bet TReNDS rugpjūčio 7 d. aprašytas AWS sprendimas labai ūkiškai parodo, kur juda praktinis DI: sistema pamato klaidą loguose, pasiima kontekstą iš kodo ir komandai išsiunčia priežasties analizę.
Turiu prisipažinti, tokias naujienas skaitau ne kaip blizgančią vitriną. Skaitau kaip žmogus, kuris iš karto galvoja apie komandą pirmadienio rytą. Kas iš to bus naudinga? Kur bus painiava? Ir kur po mėnesio kas nors pasakys: „mes galvojom, kad čia automatiškai susitvarkys“.
KAS NUTIKO
TReNDS naudoja CloudWatch subscription filters, AWS Lambda, Strands Agents SDK ir Amazon Bedrock. Kai EKS loguose atsiranda ERROR, Exception, FATAL ar CRITICAL tipo signalas, Lambda paleidžia agentą, kuris tiria kontekstą ir per SNS informuoja komandą.
Kas yra naktį skaitęs logus, tas žino. Akys bėga per tekstą, smegenys sako „dar vieną eilutę“, o kažkur viduje jau tyliai prašai kavos aparato pasigailėjimo.
Čia svarbi detalė: kalbame ne apie dar vieną gražų demonstracinį video. Kalbame apie produktus, politiką, infrastruktūrą arba tyrimus, kurie keičia, kaip žmonės dirba su DI realiose organizacijose.
KODĖL TAI SVARBU
Klaidų analizė dažnai stringa ne todėl, kad žmonės nemoka. Stringa dėl triukšmo: logai vienur, kodas kitur, incidento kontekstas trečioje vietoje.
DI jau išlipo iš „parašyk tekstą“ dėžutės. Jis naršo, jungiasi prie įrankių, analizuoja duomenis, planuoja veiksmus, kartais tvarko dokumentus ar padeda priimti sprendimą. Trumpai: jis artėja prie darbo proceso, ne tik prie pokalbio lango.
Ir čia smegenys mėgsta paslysti. Norisi sakyti: „ai, čia dar užsienyje“. Bet tas pats modelis ar funkcija rytoj atsiras kliento kompiuteryje, darbuotojo naršyklėje arba partnerio pasiūlyme.
KĄ TAI REIŠKIA VERSLUI
Verslui tai reiškia mažiau laukimo tarp incidento ir pirmos hipotezės. Ne galutinio nuosprendžio, o pradžios taško, nuo kurio inžinierius gali judėti greičiau.
- rinkti klaidų signalus iš vienos vietos
- duoti agentui tik reikalingą kodo kontekstą
- siųsti analizę ten, kur komanda jau dirba
- palikti žmogų prie pataisymo sprendimo
Geras pirmas bandymas: ne leisti agentui taisyti produkciją, o paprašyti jo paruošti incidento santrauką su trimis tikėtinomis priežastimis.
Man patinka paprastas testas: ar po šios naujienos tavo komanda turi vieną aiškesnį sprendimą? Jei ne, vadinasi dar tik skaitome. Skaityti galima. Tik nereikia apsimesti, kad tai jau strategija.
KUR GALI SKAUDĖTI
Rizika – agento išvadą priimti kaip tiesą. Logų analizėje jis turi būti kaip antras žmogus prie monitoriaus, ne kaip teisėjas su plaktuku.
Dažniausia klaida labai ūkiška. Žmonės įsijungia įrankį, pabando, nustemba, pasidžiaugia ir tada palieka viską savieigai. Po kelių savaičių paaiškėja, kad vieni darbuotojai kelia jautrius failus, kiti matuoja naudą iš jausmo, o treti net nežino, kas leidžiama.
Ne tragedija. Bet tvarkos reikia.
KĄ PASIDARYTI ŠIĄ SAVAITĘ
Šią savaitę pasirinkite vieną dažną klaidos tipą ir susirašykite, kokių trijų informacijos šaltinių reikia pirmai analizei.
Šaltinis: AWS Machine Learning Blog.
DUK
Ką TReNDS automatizavo?
Klaidų aptikimą ir pirminę root-cause analizę, naudojant Amazon Bedrock, Lambda, CloudWatch ir Strands Agents.
Ar agentas pats taiso klaidas?
AWS aprašytame pavyzdyje agentas tiria klaidą ir siunčia analizę komandai, o žmogus priima sprendimą.
Kam tai aktualu?
Komandoms, kurios turi daug logų, dažnus incidentus ir nori greitesnio pirmo atsakymo.
Jei nori DI naudoti praktiškai, pradėk nuo vieno proceso. Vienas pasikartojantis darbas. Vienas atsakingas žmogus. Vienas matavimas. Daugiau praktikos rasi MasterSprint.
