AWS gjør hendelseshåndtering agentstyrt

AWS flytter en av de mest krevende driftsoppgavene inn i agentløkken. AWS DevOps Agent er nå generelt tilgjengelig, og AWS peker samtidig på Datadog MCP Server som standard bro mellom observability-data og AI-agenter.

Det høres teknisk ut. Det er også en styringssak.

Hendelseshåndtering i store IT-miljøer er sjelden ett varsel og én feil. Det er logger, metrics, traces, dashboards, deploy-historikk, konfigurasjon, avhengigheter, Slack-tråder og mennesker som prøver å forstå hva som faktisk skjedde. AWS beskriver DevOps Agent som en alltid tilgjengelig operasjonell lagkamerat som kan triagere, undersøke, korrelere miljødata og foreslå eller drive systematiske forbedringer på tvers av AWS, multicloud og on-prem.

Det viktigste er ikke at en agent kan lese Datadog. Det viktige er at AWS og Datadog gjør observability til en maskinlesbar operasjonsflate. Datadog MCP Server oversetter agentforespørsler til relevante Datadog-ressurser og håndterer blant annet autentisering, ruting, valg av endpoint og responsformat. Den gir agenten tilgang til avgrensede verktøysett for logger, metrics, traces, dashboards, monitors, incidents, APM, sikkerhetsskanning, databaseovervåking og CI/CD-synlighet.

For en CIO eller CISO betyr dette at incident response ikke lenger bare handler om bedre varsler. Det handler om hvem som får lov til å handle når en modell har funnet sammenhengen.

Hvorfor dette betyr noe

AI i drift har lenge vært mye demo og lite ansvar. Denne lanseringen er mer konkret. AWS sier at agenten kan brukes i produksjonsløp, ikke bare som et skriveverktøy for runbooks. Den kan trekke sammen infrastruktur, telemetri, kode og deploy-data, og bruke det til å forklare en hendelse og foreslå tiltak.

Det angriper en reell flaskehals. Mange virksomheter har investert tungt i observability, men får fortsatt høy kognitiv belastning når noe feiler. Dataene finnes. Sammenhengen må bygges mens klokken går. Det er dyrt på nattvakt, og det blir fort personavhengig.

Agentmodellen lover kortere vei fra symptom til årsak. Den lover også mindre repetisjon når samme feilklasse kommer tilbake. Hvis agenten kan huske hvilke mønstre som faktisk løste forrige hendelse, kan den gjøre driftsorganisasjonen mer konsistent.

Men løftet kommer med en regning. En agent med tilgang til observability, deploy-data og SRE-verktøy får fort mer operativ innsikt enn mange ansatte. Feil tilgangsmodell blir et produksjonsproblem. Feil handlingsrom blir en endringsrisiko.

MCP gjør integrasjonen mer styrbar

MCP-delen er viktig fordi den flytter integrasjonen bort fra skreddersydde API-kall og inn i et mer standardisert mønster. Tradisjonelle API-er er laget for applikasjoner og scripts. Agenter trenger ofte en annen inngang: de må forstå hvilke verktøy som finnes, hva de kan brukes til, hvilke parametere som kreves, og hva svaret betyr.

Datadog MCP Server blir dermed et kontrollpunkt. Det er her virksomheten kan avgrense hvilke observability-data agenten får lese, hvilke domener den kan operere i, og hvilke typer handlinger som krever menneskelig godkjenning.

Det er også her mange norske virksomheter bør starte. Ikke med en agent som kan gjøre alt. Start med lesetilgang, forklaring og forslag. La agenten lage en tidslinje for hendelsen, peke på sannsynlig rotårsak, hente relevante deploys og lage et forslag til tiltak. Deretter kan mennesker godkjenne eller avvise.

Når det fungerer, kan handlingsrommet utvides. Men det bør skje etter risikoklasse, ikke etter entusiasme.

Hva ledelsen bør kreve

Før en slik agent får plass i produksjon, bør ledelsen be om fem konkrete svar.

For det første: Hvilke systemer kan agenten lese fra, og hvilke kan den skrive til? En vag formulering som «Datadog-integrasjon» holder ikke. Det må være en matrise over verktøy, datatyper, miljøer og rettigheter.

For det andre: Hvilke handlinger krever godkjenning? Restart av en ikke-kritisk testtjeneste er noe annet enn endring i produksjonsrouting, rollback av en betalingstjeneste eller justering av sikkerhetsregler.

For det tredje: Hvordan logges agentens arbeid? En hendelsesrapport må vise hvilke observasjoner agenten bygde på, hvilke verktøy den brukte, hvilke forslag den ga, og hvem som tok beslutningen. Uten dette blir revisjon og læring svakt.

For det fjerde: Hvordan måles effekten? Ikke mål bare antall agentkjøringer. Mål MTTR, falske hypoteser, feilaktige anbefalinger, antall manuelle eskaleringer, og om samme feilklasse faktisk blir sjeldnere.

For det femte: Hva er kill switch? En agent som oppfører seg feil under en produksjonshendelse må kunne kobles ut raskt uten at hele incident-prosessen stopper.

Norsk vinkel

Norske virksomheter har ofte mindre driftsteam enn de store amerikanske teknologiselskapene, men like komplekse avhengigheter. De har skytjenester, SaaS, integrasjoner, identitet, dataflyt og regulatoriske krav. Når en hendelse treffer, er det sjelden bare ett team som eier hele problemet.

Derfor er agentstyrt incident response interessant. Det kan gi mindre organisasjoner tilgang til en type operasjonell analyse som tidligere krevde svært erfarne SRE-miljøer.

Samtidig er fallhøyden høy i regulerte miljøer. Finans, helse, energi, offentlig sektor og transport bør behandle dette som en ny operasjonell kontrollflate. Agenten må inn i endringsstyring, tilgangsstyring, logging, beredskapsøvelser og leverandørvurdering.

Dette er ikke et argument for å vente. Det er et argument for å teste riktig.

Den beste piloten er smal. Velg én tjeneste, én observability-plattform, én incident-type og et klart mandat. La agenten forklare og foreslå, ikke utføre irreversible endringer. Kjør øvelser på kjente hendelser før den brukes live. Sammenlign agentens analyse med menneskenes. Deretter kan man avgjøre om den skal få mer ansvar.

AWS-lanseringen viser hvor enterprise-markedet går. AI-agenten blir ikke bare en assistent i IDE-en eller et skrivefelt i Slack. Den kobles til driftsplattformen. Da må styringen være like produksjonsklar som teknologien.

Kilder og medier

Primærkilde: AWS DevOps & Developer Productivity Blog, https://aws.amazon.com/blogs/devops/production-ready-autonomous-incident-resolution-with-aws-devops-agent-now-ga-and-datadog-mcp-server/

Kildekreditering: AWS og Datadog beskriver AWS DevOps Agent GA og Datadog MCP Server GA, inkludert bruk av MCP for observability-data, hendelser, APM, sikkerhet, databaseovervåking og CI/CD-synlighet.

Thumbnail: OpenAI Image 2 / hogby.ai