Teststrategi for skymigrering: faser, testtyper og sjekkliste
En teststrategi for skymigrering definerer hva du tester før, under og etter hver migreringsbølge, og de bestått/ikke bestått-kriteriene som avgjør om en arbeidsbelastning går i produksjon. Den dekker funksjonalitet, dataintegritet, ytelse, sikkerhet og tilbakerulling. Metoden: mål en baseline på den gamle plattformen, kjør en testmigrering, sammenlign, og gå først over når tallene stemmer.
Viktigste punkter
- Registrer baselines før du flytter noe: responstider, feilrater, kjøretider for batchjobber og antall rader.
- Avtal kriterier for bestått/ikke bestått og utløsere for tilbakerulling før første bølge, ikke under overgangen.
- Bruk migreringsverktøyenes egne testfunksjoner: testmigreringer i Azure Migrate og datavalidering i AWS DMS finnes til akkurat dette.
- Testtypene skalerer med migreringsstien. En lift-and-shift trenger hovedsakelig paritetskontroller, mens en refaktorering trenger full funksjons- og integrasjonstesting.
- Kjør testmigreringer i et isolert nettverk. Microsoft advarer mot å testmigrere inn i et virtuelt produksjonsnettverk.
- Fortsett å teste etter overgangen: følg servicenivåindikatorene (SLI-er) i minst én full forretningssyklus.
Hva er testing av skymigrering?
Testing av skymigrering er samlingen av kontroller som viser at en applikasjon, dataene den bruker og infrastrukturen virker minst like godt etter flyttingen som før. Den løper gjennom hele migreringen, ikke bare på slutten.
Den skiller seg fra vanlig releasetesting på tre måter:
- Plattformen endres, ikke koden. I en lift-and-shift er koden den samme, så du tester miljøet: nettverk, identitet, lagringsytelse, DNS og tidssoner.
- Data flyttes. Du må bevise at hver rad og fil kom frem uendret, og at løpende endringer ble synkronisert helt til overgangen.
- Skyen oppfører seg annerledes. Autoskalering, grenser i administrerte tjenester, regional latens og delt infrastruktur kan endre ytelsen selv om ingenting annet er endret.
Suksesskriteriene er de samme som i eget datasenter: funksjonene må virke, dataene må være komplette og korrekte, og brukerne må ikke merke at det går tregere.
De fire fasene i en teststrategi for migrering
Del testingen i fire faser, hver med egne bevis og godkjenning.
| Fase | Mål | Hovedkontroller | Bevis |
|---|---|---|---|
| 1. Planlegg og sett baseline | Vit hvordan «bra» ser ut i dag | Avhengighetskart, kritiske brukerreiser, dagens responstider, batchvarigheter, datamengder | Baselinerapport, avtalte kriterier for bestått/ikke bestått |
| 2. Testmigrering | Bevis at arbeidsbelastningen kjører på målplattformen | Oppstart og tilkobling, funksjonelle røyktester, integrasjoner, datavalidering, ytelse under last | Testresultater per arbeidsbelastning, feillogg |
| 3. Overgang | Bytt trygt, med en vei tilbake | Endelig datasynkronisering og validering, kontroll av DNS og sertifikater, røyktester, go/no-go | Driftsrutine for overgangen med tidsangivelser, signert go/no-go |
| 4. Etter migreringen | Bekreft stabilitet og finjuster | Overvåking av SLI-er, brukerakseptanse, test av sikkerhetskopi og gjenoppretting, kostnadskontroll | Hypercare-rapport, lukkede feil |
Fase 1: planlegg og sett baseline
Start med en oversikt over applikasjoner, databaser, grensesnitt og planlagte jobber, og rangér dem etter forretningsrisiko. For hver arbeidsbelastning noterer du tallene du senere skal sammenligne mot: p95-responstid for sentrale transaksjoner, feilrate, varighet på nattlig batch, databasestørrelse og antall rader.
Gjør dem om til kriterier. For eksempel: «p95 for ordresøk innenfor 10 % av baseline», «ingen avvik i rader i økonomitabellene», «nattlig batch er ferdig før 06:00». Googles SRE-bok definerer en SLI som «et nøye definert kvantitativt mål på et aspekt av servicenivået» og et SLO som en målverdi for den (Google SRE book, oversatt av oss). Når kriteriene skrives på den måten, blir go/no-go-beslutningen objektiv.
Fase 2: testmigrering
Migrer en kopi av arbeidsbelastningen til målplattformen og test den der mens kilden fortsetter å kjøre. Begge de store plattformene støtter dette:
- Azure Migrate tilbyr en testmigrering som starter replikerte VM-er i et virtuelt nettverk du velger. Microsofts veiledning sier at det ikke anbefales å testmigrere inn i et virtuelt produksjonsnettverk, fordi åpne forbindelser til eget datasenter kan gi dupliserte VM-er eller DNS-endringer.
- AWS Application Migration Service (MGN) starter testinstanser fra kontinuerlig replikerte servere, og replikeringen fortsetter etter testen. AWS kaller det en beste praksis å teste minst to uker før planlagt overgang, slik at det er tid til å rette det du finner.
Bruk denne fasen til å finne overraskelsene: hardkodede IP-adresser, manglende brannmurregler, lisenssjekker knyttet til maskinvare og jobber som kaller servere du glemte å migrere.
Fase 3: overgang
Overgangen er en innøvd driftsrutine, ikke noe man improviserer. Frys endringer, kjør den endelige datasynkroniseringen, valider dataene, bytt DNS eller mål i lastbalanseren og kjør røyktester. Hvert steg har en eier, et planlagt tidspunkt og en tilbakerullingshandling.
Definer utløsere for tilbakerulling på forhånd, for eksempel: «hvis røyktestene feiler eller datavalideringen viser avvik 60 minutter etter byttet, sett DNS tilbake til kilden». Øv på tilbakerullingen minst én gang under testmigreringene.
Fase 4: validering etter migreringen
Etter at systemet er i produksjon, sammenligner du SLI-ene mot baseline i minst én full forretningssyklus, om mulig inkludert månedsslutt eller andre toppdager. Kjør brukerakseptansetester, test en gjenoppretting fra de nye sikkerhetskopiene og sammenlign den første skyfakturaen med estimatet. Først da tar du kilden ut av drift.
Hvilke testtyper bør du kjøre?
Tilpass testtypene til risikoen for hver arbeidsbelastning. Ikke alle applikasjoner trenger alle tester.
| Testtype | Hva den beviser | Typiske verktøy |
|---|---|---|
| Funksjonell og regresjon | Funksjoner og brukerreiser virker fortsatt | Selenium, Playwright, eksisterende testsuiter |
| Integrasjon | API-er, meldingskøer, filoverføringer og tredjepartstjenester kobler seg til | Kontraktstester, API-testverktøy, syntetiske transaksjoner |
| Datavalidering | Hver rad og fil kom frem og stemmer | AWS DMS data validation, sjekksummer, radtellinger, verktøy for databasediff |
| Ytelse og last | Responstider og gjennomstrømning når målene, autoskalering virker | JMeter, k6, Gatling |
| Sikkerhet og etterlevelse | Tilgang, kryptering, nettverksregler og logging er riktige | Verktøy for sikkerhetsstatus i sky, sårbarhetsskanning, gjennomgang av IAM |
| Robusthet og DR | Arbeidsbelastningen tåler feil og kan gjenopprettes | Failover-øvelser, gjenoppretting fra sikkerhetskopi, AWS Fault Injection Service |
| Brukerakseptanse | Forretningsbrukerne bekrefter at systemet er egnet til bruk | Manusbasert UAT med godkjenning |
For realistiske lasttester som svarer til toppbelastningen din, se vår lasttesttjeneste.
Hvordan validerer du data under en migrering?
Valider data på tre nivåer: tellinger, sjekksummer og sammenligning rad for rad for kritiske tabeller.
- Tellinger: rader per tabell, filer per bucket, totalt antall byte. Raskt, og fanger grove feil.
- Sjekksummer og aggregater: summer av beløp, hasher av nøkkelkolonner. Fanger avkortning og problemer med tegnkoding.
- Sammenligning på radnivå: for databaser sammenligner AWS DMS data validation hver kilderad med målraden og rapporterer avvik, også for endringer som fanges opp under løpende replikering.
To praktiske begrensninger fra AWS-dokumentasjonen bør du planlegge for: valideringen krever en primærnøkkel eller unik indeks på hver tabell, og den gir ekstra spørringslast på både kilde og mål. Legg tunge valideringskjøringer utenfor arbeidstid, eller kjør dem som egne oppgaver som bare validerer.
Test også det som endres med vilje. Hvis du konverterer fra Oracle til PostgreSQL, er datatyper, collation og sorteringsrekkefølge forskjellige, så sammenlign spørringsresultater og ikke bare lagrede verdier. Vår databasemigreringstjeneste dekker slike konverteringer.
Slik endres testingen med migreringsstien
- Rehost (lift and shift): fokuser på paritet i miljøet. Kontroller nettverk, DNS, identitet, lagringsgjennomstrømning, backupjobber og overvåkingsagenter. Funksjonell testing kan være en røyktest pluss de kritiske brukerreisene.
- Replatform: når du flytter en database til en administrert tjeneste eller en app til containere, legger du til datavalidering, ytelsestester og kontroll av grenser i den administrerte tjenesten, som antall tilkoblinger.
- Refactor: behandle det som ny programvare. Kjør full funksjons-, integrasjons- og ytelsestesting, og bruk canary- eller blue/green-utrulling med feature flags for å begrense eksponeringen.
Sjekkliste for testing av skymigrering
- Oversikt og avhengighetskart er ferdig for bølgen
- Baselines registrert for kritiske brukerreiser, batchjobber og datamengder
- Kriterier for bestått/ikke bestått og utløsere for tilbakerulling er godkjent av forretningseier
- Testmiljøet er isolert fra produksjonsnettverk
- Infrastrukturen er definert som kode slik at test og produksjon er like (se vår Terraform-tjeneste for infrastruktur som kode)
- Testdata er maskert der de inneholder personopplysninger
- Testmigrering gjennomført, feil rettet og testet på nytt
- Datavalidering bestått for alle tabeller i omfanget
- Lasttest ved forventet topp bestått
- Sikkerhetsgjennomgang gjort: IAM, kryptering, sikkerhetsgrupper, logging
- Tilbakerulling innøvd og tidsmålt
- Driftsrutine for overgangen med eiere og tidspunkter er godkjent
- Dashbord og varsler for overvåking etter migreringen er i drift
- Gjenoppretting fra sikkerhetskopi er testet på den nye plattformen
Slik hjelper Opsio
Opsio planlegger og gjennomfører skymigreringer med testing innebygd i hver bølge. For SilverRail Technologies flyttet Opsio selskapets nordiske enhet over på AWS og slo den sammen med den globale organisasjonen. Mobilize-fasen inkluderte en pilot med testmigrering av utvalgte arbeidsbelastninger, og migreringsprosessen og AWS-tjenestene ble justert på grunnlag av testingen. Data ble flyttet med PostgreSQLs egne verktøy etter en detaljert plan for overgangen, og overgangene ble gjort i trange servicevinduer for å begrense påvirkningen på kundene. Les kundecaset om SilverRail.
Ofte stilte spørsmål
Hva er en teststrategi for skymigrering?
Det er en plan som definerer hvilke tester som kjøres før, under og etter hver migreringsbølge, kriteriene for bestått/ikke bestått for hver og hvem som godkjenner. Den dekker funksjon, data, ytelse, sikkerhet og tilbakerulling.
Hva er fasene i testing av skymigrering?
Planlegging og baseline, testmigrering, overgang og validering etter migreringen. Hver fase gir bevis, som baselinerapporter, testresultater, en signert go/no-go og en hypercare-rapport.
Hvordan tester du data etter en skymigrering?
Sammenlign antall rader og sjekksummer for alle tabeller, og kjør sammenligning på radnivå for kritiske data. På AWS sammenligner DMS data validation kilde- og målrader og rapporterer avvik. Den krever en primærnøkkel eller unik indeks på hver tabell.
Hvordan er testing av en lift-and-shift forskjellig fra en refaktorering?
En lift-and-shift trenger hovedsakelig paritetskontroller av miljøet og de kritiske brukerreisene, fordi koden ikke endres. En refaktorering trenger full funksjons-, integrasjons- og ytelsestesting, siden du i praksis slipper ny programvare.
Hvor lenge bør du overvåke etter overgangen?
I minst én full forretningssyklus, inkludert toppdager som månedsslutt, før du tar kildesystemene ut av drift. Hold muligheten for tilbakerulling åpen til de avtalte kriteriene er oppfylt.
Les også: Hva er en migrasjonsstrategi.
Om forfatteren
Redaksjonelle retningslinjer: Artikkelen er skrevet av en sertifisert fagperson, oppgitt i bylinen over. Vi oppdaterer den når teknologien eller regelverket den omhandler endres; datoene over viser siste oppdatering. Opsio er redaksjonelt uavhengig — vi anbefaler løsninger ut fra tekniske fortrinn, ikke kommersielle relasjoner.