Resiliency Agent i Azure Copilot: sonefeilfri arkitektur i praksis

Azure Copilot har fått en ny navngitt agent, og jeg har brukt den siste uken på å teste den. Resiliency Agent er nå i public preview, og den gjør noe jeg har etterlyst lenge: den snakker samme språk som arkitekten, ikke bare portalen.

Resiliency Agent er én av flere navngitte agenter i Azure Copilot, ved siden av Troubleshooting, Deployment og Optimization, og bygger videre på samme agent-arkitektur jeg beskrev i Copilot og Azure AI-veiledningen. Agenten dekker to arbeidsflyter. Start Resilient hjelper deg designe en applikasjon med sonefeilfrihet innebygget fra første deploy. Get Resilient tar for seg det du allerede har kjørende i Azure, og forteller deg konkret hva som mangler. Jeg har sett nok migreringsprosjekter til å vite at det andre scenarioet, opprydding i eksisterende arbeidslaster, er der de fleste norske virksomheter faktisk befinner seg.

Start Resilient: design fra dag én

Du beskriver applikasjonen din i naturlig språk, og agenten analyserer topologien og foreslår tiltak. Jeg synes eksemplet i dokumentasjonen er treffende enkelt: «Min app har en VM, en PostgreSQL-database og en lastbalanserer. Hjelp meg i gang med sonefeilfrihet.» Agenten svarer med en resiliensrapport og genererer ferdige Bicep-maler, delt opp i main.bicep, parameters.json og filer per ressurs.

Jeg testet dette på et lite oppsett med en lagringskonto og fikk ut noe i denne retningen (forenklet for lesbarhet, med Standard_ZRS som anbefalt SKU). Zone-redundant storage lover 99,9999999999 % holdbarhet (12 ni-tall) over et år, og det er et tall jeg gjerne fremhever for Microsoft kunder som lurer på om ekstra soner faktisk monner:

@allowed([
  'Standard_LRS'
  'Standard_ZRS'
])
param storageAccountType string = 'Standard_ZRS'

resource stg 'Microsoft.Storage/storageAccounts@2025-06-01' = {
  name: 'stresilient${uniqueString(resourceGroup().id)}'
  location: resourceGroup().location
  sku: {
    name: storageAccountType
  }
  kind: 'StorageV2'
}

Ikke banebrytende Bicep i seg selv, men poenget er at agenten velger sonefeilfri redundans som standard i stedet for at en utvikler må vite at valget finnes. Det er akkurat den typen kunnskapsoverføring jeg mener Azure Bicep MCP også løser godt: strukturert tilgang til beste praksis, ikke gjetting basert på gammel treningsdata.

Det samme mønsteret skalerer til større arkitekturer. Ber du agenten om hjelp med en applikasjon som består av AKS, Redis, lagring og Cosmos DB, samler den anbefalingene i én konsolidert resiliensoppsummering i stedet for fire separate rapporter, noe jeg setter pris på når jeg skal presentere funnene videre til en kunde som ikke er dypt teknisk.

Get Resilient: fra oversikt til utbedring

Den andre modusen er der jeg tror agenten virkelig sparer timer. Du samler ressursene dine i en Service Group, setter et sonefeilfrihetsmål, og agenten viser deg hvilke ressurser som oppfyller målet og hvilke som ikke gjør det.

Før dette fungerer, må Service Group-en meldes inn i en bruksplan. Basic-planen gir mål og resiliensoversikt med anbefalinger, mens Standard-planen legger til gjenopprettingsplaner og simulerte utfallsøvelser. Begge er gratis under preview, men jeg regner med at det endrer seg til GA, så jeg ville ikke bygget en langsiktig driftsprosess rundt akkurat det prisløftet. En Service Group tåler opptil 500 ressurser, og du kan ekskludere ressurser som ikke trenger sonefeilfrihet, for eksempel en lagringskonto som bare brukes til telemetri, eller manuelt attestere ressurser agenten ikke klarer å vurdere automatisk, som enkeltinstans-VM-er med applikasjonsstyrt redundans.

For ressurser som støtter direkte konvertering, som flere databasetjenester, kan agenten gjøre endringen. For virtuelle maskiner, som krever omutplassering, får du i stedet skript i PowerShell, Azure CLI, Bicep, Terraform eller ARM. Etter min erfaring er akkurat dette skillet, mellom «fiks direkte» og «fiks med redeploy», det som stopper de fleste opprydningsprosjekter i praksis. Nå får du begge veiene dokumentert i samme samtale.

Zone-down drill: test svikten før den skjer

Med Standard-planen kan du gå et steg videre og kjøre en zone-down drill: en simulert soneutfall bygget på Azure Chaos Studio, som validerer om Service Group-en din faktisk overlever at én sone forsvinner, ikke bare om konfigurasjonen ser riktig ut på papiret. Jeg liker denne tilnærmingen bedre enn en ren sjekkliste, siden den tvinger fram et ærlig svar: tåler applikasjonen bortfallet, eller stopper den likevel opp et sted ingen hadde tenkt på? Drillen krever egen RBAC-tilgang og en gjenopprettingsplan for ressurser som må håndteres manuelt, som VM-er med Azure Site Recovery, så sett av tid til oppsettet før du planlegger å bruke den i en produksjonsnær test.

Det som overrasker meg minst, er kostnadsdelen. Agenten viser indikativ kostnads- og nedetidspåvirkning før du bestemmer deg, samme tankegang jeg beskrev i FinOps og AI-transformasjon: la KI regne på konsekvensene før du bruker budsjett på dem, ikke etterpå.

Tiltak	Type endring	Typisk kostnadseffekt	Nedetid
Lagringskonto til ZRS	Konvertering i portalen	Lite påslag per GB	Ingen
Database til sonefeilfri SKU	Ofte direkte konvertering	Moderat, avhenger av SKU	Minimal, sekunder til minutter
VM til sonefeilfritt oppsett	Krever redeploy	Ingen ekstra kostnad for selve sonen	Planlagt vedlikeholdsvindu

Tallene i tabellen er typiske mønstre jeg har sett i egne prosjekter, ikke agentens faktiske output. De faktiske estimatene varierer med region, SKU og eksisterende arkitektur.

Ingen automatikk uten at du sier ja

Noe jeg satte pris på med en gang: agenten gjør ingen endringer automatisk. Alle tiltak krever din bekreftelse og manuell utførelse. Det er en fornuftig avgrensning i en preview, og jeg anbefaler at det forblir sånn også etter GA for produksjonsmiljøer med endringskontroll.

Agenten bruker on-behalf-of-token for å utføre handlinger innenfor din egen tilgang, og tokenene slettes automatisk innen 28 dager. For en sikkerhetsbevisst leser er det verdt å vite, selv om jeg fortsatt anbefaler at dere vurderer datahåndteringen opp mot egne interne krav før dere ruller ut agenten bredt i organisasjonen.

Norge-vinkelen: Norway East støtter allerede soner

Norway East støtter tilgjengelighetssoner, og det er et poeng jeg synes får for lite oppmerksomhet i norske IT-miljøer. Latensen mellom sonene i en region ligger typisk under 2 millisekunder, og Azure fakturerer ikke for datatrafikk mellom soner i samme region. For norske virksomheter som er bundet til Norway East av datasuverenitet eller GDPR-hensyn, betyr det at soneredundans er den mest realistiske veien til høyere oppetid, uten å måtte flytte data ut av landet.

Jeg kjenner at flere norske virksomheter utsette sonefeilfrihet fordi de trodde det krevde en sekundær region. Det gjør det ikke. En ren flersone-konfigurasjon i Norway East dekker de fleste driftsscenarioene der kravet er å tåle at én sone faller ut, ikke et fullt regionbortfall.

Sjekkliste: kom i gang med Resiliency Agent

Sjekk at Agents (Preview) er slått på i Azure Copilot admin center under Access management
Be om tilgang via allowlist-skjemaet hvis agenten ikke dukker opp i agentvelgeren
Start med Get Resilient på én produksjonsnær arbeidslast, ikke hele porteføljen samtidig
Be agenten lage en Service Group og et sonefeilfrihetsmål før du ber om utbedringsskript
Kjør en sonefeilfrihetsvurdering, og be om skript kun for ressursene som faktisk feiler
Test skriptene i et testmiljø før de kjøres mot produksjon, agenten fjerner ikke behovet for endringskontroll

Begrensninger å kjenne til i preview

Agenten er i dag optimalisert for sonefeilfrihet. Regional resiliens og andre resiliensdimensjoner kommer i senere versjoner, og Start Resilient genererer foreløpig kun Bicep, ikke Terraform eller ARM. Jeg savner Terraform-støtte allerede nå, siden flere virksomheter har Terraform som primærverktøy for infrastruktur. Se gjerne Azure MCP-server for hvordan du kan bygge bro mellom KI-agenter og eksisterende IaC-verktøykjeder i mellomtiden.

Min anbefaling

Jeg tror ikke Resiliency Agent erstatter en arkitekts vurdering, og det er heller ikke poenget. Den flytter derimot samtalen fra «vet vi om dette er sonefeilfritt» til «her er nøyaktig hva som mangler og hva det koster å fikse det». For et IT-miljø som mitt er det tid vunnet på hver eneste kundeengasjement.

Reliability-pilaren i Well-Architected Framework har lenge anbefalt flersone-arkitektur som førstevalg for produksjonsarbeidslaster i regioner som støtter det. Forskjellen nå er at anbefalingen kommer med et konkret handlingspunkt i samme samtale, ikke som et eget dokument du må lese og oversette selv. Jeg vil si det er nettopp den oversettelsen, fra prinsipp til kjørbar kode, som har manglet i norske arkitekturprosesser til nå.

Har du testet Resiliency Agent selv? Del gjerne erfaringene dine, gode eller dårlige, med meg på kontakt@jas-azure.com. Jeg samler tilbakemeldinger fra norske Azure-brukere og videreformidler dem til produktteamet i Microsoft, slik at neste versjon faktisk reflekterer hvordan vi jobber her hjemme.