AWS pagalbos agentas: kai incidento tyrimas nebeturi prasidėti nuo 6 atidarytų langų

·


AWS pagalbos agentas su Amazon Bedrock AgentCore incidentų tyrimui

AWS pagalbos agentas skamba kaip techninis terminas. Bet kai pažiūri praktiškai, čia yra labai žemiškas klausimas: kiek darbo darome rankomis tik todėl, kad niekas neprisėdo sutvarkyti proceso?

AWS liepos 7 d. aprašė pagalbos agentą, kuris tiria infrastruktūros incidentus su Amazon Bedrock AgentCore. Idėja paprasta: vietoj šokinėjimo tarp konsolės, CloudWatch, dokumentacijos, re:Post ir support formos, žmogus kalbasi su vienu agentu.

Man tokiose naujienose visada įsijungia mažas vidinis buhalteris. Ne tas, kuris skaičiuoja sąskaitas, o tas, kuris klausia: kiek tai kainuos, kas prižiūrės ir kur gali lūžti?

KAS NUTIKO

AWS rašo, kad įprastas incidento tyrimas gali suvalgyti 30-45 minutes dar prieš realų taisymą. Pavyzdinis agentas analizuoja CloudWatch logus, ieško AWS dokumentacijoje, tikrina bendruomenės žinias ir gali paruošti support case su surinktu kontekstu.

Kas yra dirbęs su incidentais, žino tą jausmą: ekranų daug, adrenalino daug, o galvoje sukasi vienas klausimas – nuo ko pradėti? Ir tada dar kas nors parašo Slacke: „ar jau aišku?“ Aišku, kad neaišku.

KODĖL TAI SVARBU

AWS pagalbos agentas svarbus todėl, kad incidentuose brangiausias dažnai yra ne vien pats gedimas, o blaškymasis. DI gali surinkti kontekstą, parodyti tikėtinus kelius ir sumažinti rankinį perjunginėjimą.

DI jau nebe vien langelis, į kurį įmetame tekstą. Jis jungiasi prie įrankių, moka kviesti servisus, gali veikti keliais žingsniais ir pradeda liesti tikrus verslo pinigus. Čia romantika baigiasi. Prasideda tvarka.

KĄ TAI REIŠKIA VERSLUI

Verslui čia pamoka platesnė nei AWS. Kiekvienoje įmonėje yra procesų, kur žmogus per vieną užduotį atsidaro penkis įrankius ir viską nešioja galvoje. Tai puiki vieta agentui.

  • susirašyti incidento tyrimo žingsnius
  • atskirti skaitymo veiksmus nuo veiksmų, kurie keičia sistemą
  • pirmiausia automatizuoti konteksto surinkimą
  • support case ar pakeitimus palikti žmogaus patvirtinimui

Pirmas praktinis bandymas galėtų būti agentas, kuris iš logų, dokumentacijos ir ankstesnių ticketų paruošia tyrimo santrauką. Ne iš karto taiso. Pirma padeda žmogui greičiau suprasti.

KUR PASISLĖPUSI RIZIKA

Rizika – duoti agentui per daug veiksmų per anksti. Incidento metu visi nori greičio, bet būtent tada klaida kainuoja brangiausiai.

Blogiausia DI klaida dažnai neatrodo kaip klaida. Ji ateina gražiai parašytu sakiniu, mandagiu tonu ir labai užtikrintu veidu. Todėl verslui reikia ne tik įrankių, bet ir įpročio tikrinti.

KĄ PASIDARYTI ŠIĄ SAVAITĘ

Paimkite paskutinį rimtesnį incidentą ir suskaičiuokite, kiek įrankių reikėjo vien informacijai surinkti.

Šaltinis: Amazon Web Services.

DUK

Kas yra AWS pagalbos agentas?

Tai DI agentas, kuris padeda tirti AWS incidentus, rinkdamas informaciją iš logų, dokumentacijos ir support kanalų.

Kokia praktinė nauda?

Mažiau rankinio perjunginėjimo ir greitesnis pradinis incidento supratimas.

Ar agentas turėtų pats taisyti problemas?

Pradžioje geriau ne. Pirmas etapas – konteksto surinkimas ir žmogaus sprendimo palaikymas.

Jei norite DI naudoti ne dėl mados, pradėkite nuo vieno proceso. Paimkite užduotį, kuri kartojasi kas savaitę, susirašykite žingsnius ir tik tada junkite įrankį. Daugiau praktinių DI taikymo pavyzdžių rasite MasterSprint.