Øv på gjenoppretting
En backup som ikke er testet er verdiløs. Det samme gjelder en disaster recovery-plan som aldri har blitt testet.
Hvis teamet har gjort grunnarbeidet godt, har dere en plan for gjenoppretting som beskriver hvordan infrastruktur, applikasjon og data gjenopprettes til normal drift.
Årsakene til gjenoppretting varierer: menneskelige feil, feil i leveranser, svikt hos leverandør, utilgjengelig infrastruktur eller ondsinnede hendelser. Målet er alltid det samme: redusere nedetid og datatap med forutsigbare prosesser.
Minimumskrav til gjenoppretting
Teamet bør som minimum ha kontroll på:
- dokumenterte mål for gjenoppretting (RTO) og akseptabelt datatap (RPO)
- verifiserte backups av data, konfigurasjon og avhengige artefakter
- en konkret, stegvis recovery-oppskrift som kan følges av flere enn én person
- nødvendige tilganger, roller og tilgangspakker for de som skal gjenopprette
- et testmiljø der recovery-planen kan øves uten å påvirke produksjon
- tydelige kriterier for når systemet kan åpnes for brukere igjen
Øving og verifisering
Recovery må testes jevnlig. Teamet bør planlegge øvelser som dekker både enkle feil og mer komplekse scenarioer.
Eksempler på øvelser:
- gjenoppretting av enkeltkomponent (f.eks. database eller apptjeneste)
- full gjenoppretting av kritisk tjeneste i alternativt miljø
- validering av backup-kjede fra backup til verifisert restore
- øvelse der nøkkelpersoner ikke er tilgjengelige
Etter hver øvelse bør dere dokumentere hva som fungerte, hva som feilet og hvilke tiltak som må inn i backloggen.
En tenkt oppskrift for løsningen tegnet opp i artikkelen om systemskisser kan være som under. Premisset for planen under er at vi har kildekode og pipelines tilgjengelig i eksempelvis Azure DevOps, og at applikasjon og ressurser på mystisk vis er fjernet fra Azure:
- Sjekk at nye subscriptions er på plass i Azure
- Konfigurer Azure Pipelines slik at de deployer til disse
- Verifiser at alle Entra-grupper er tilgjengelige
- Deploy infrastruktur-som-kode
- Konfigurer NSG’er og brannmurer (dersom dette ikke gjøres som kode)
- Skru av aksess utenfor leveranseteamet for å unngå at brukere forstyrrer restoreprosessen
- Verifiser at ressursene har tilgang til dataplatformen
- Verifiser tilganger til database
- Restore applikasjon og data:
- Restore data til database fra siste backup
- Deploy backend
- Deploy frontend
- Verifiser at applikasjon fungerer
- Publiser PowerBI-rapport
- Verifiser at den kan lese data fra backend
- Skru på aksess for sluttbrukere slik at de kan bruke applikasjonen igjen.
Det er verdt å nevne at hvert punkt ofte trenger utfyllende informasjon, med henvisninger til tilgangspakker eller gruppemedlemskap for at den som gjenoppretter skal få nødvendig tilgang.
Recovery for løsninger med AI-komponenter
Hvis løsningen har AI-komponenter, må recovery-planen også dekke:
- gjenoppretting av modellartefakter og versjoner
- gjenoppretting av konfigurasjon for model routing, prompts og sikkerhetsgrenser
- gjenoppretting av vektorindeks/feature store der dette brukes
- verifisering av modellkvalitet etter restore (ikke bare at tjenesten svarer)
- kontroll av AI-relaterte logger slik at hendelsesforløp fortsatt er sporbart
Dette støtter kontrollområder som “AI system operation and monitoring” og “AI system recording of event logs” i en operativ recovery-kontekst.