Teststrategi for cloudmigrering: faser, testtyper og tjekliste
En teststrategi for cloudmigrering fastlægger, hvad du tester før, under og efter hver migreringsbølge, og de kriterier for bestået eller ikke bestået, der afgør, om en workload går i drift. Den dækker funktionalitet, dataintegritet, ydeevne, sikkerhed og rollback. Metoden er: mål en baseline på den gamle platform, kør en testmigrering, sammenlign, og skift først, når tallene stemmer.
Vigtigste pointer
- Registrér baselines, før du flytter noget: svartider, fejlrater, køretider for batchjobs og antal rækker.
- Aftal kriterier for bestået eller ikke bestået og udløsere for rollback før den første bølge og ikke under cutover.
- Brug migreringsværktøjernes egne testfunktioner: Testmigreringer i Azure Migrate og datavalidering i AWS DMS findes netop til det.
- Testtyperne skaleres med migreringsvejen. En lift-and-shift kræver mest kontrol af paritet, mens en refaktorering kræver fuld funktionel test og integrationstest.
- Kør testmigreringer i et isoleret netværk. Microsoft fraråder testmigreringer ind i et virtuelt produktionsnetværk.
- Bliv ved med at teste efter cutover: følg service level indicators (SLI'er) i mindst en hel forretningscyklus.
Hvad er test af cloudmigrering?
Test af cloudmigrering er de kontroller, der beviser, at en applikation, dens data og dens infrastruktur fungerer mindst lige så godt efter flytningen som før. Den kører gennem hele migreringen og ikke kun til sidst.
Den adskiller sig fra almindelig test af releases på tre måder:
- Platformen ændres, ikke koden. I en lift-and-shift er koden den samme, så du tester miljøet: netværk, identitet, lagerydelse, DNS og tidszoner.
- Data flytter sig. Du skal bevise, at hver række og fil nåede frem uændret, og at løbende ændringer blev synkroniseret helt frem til cutover.
- Cloud opfører sig anderledes. Autoskalering, grænser for managed services, regional latenstid og delt infrastruktur kan ændre ydeevnen, selv når intet andet er ændret.
Succeskriterierne er de samme som on-premises: Funktioner skal virke, data skal være komplette og korrekte, og brugerne må ikke mærke et fald i hastighed.
De fire faser i en teststrategi for migrering
Del testen op i fire faser, hver med sit eget bevis og sin egen godkendelse.
| Fase | Mål | Vigtigste kontroller | Dokumentation |
|---|---|---|---|
| 1. Plan og baseline | Vid, hvordan "godt" ser ud i dag | Afhængighedskort, kritiske brugerrejser, nuværende svartider, varighed af batchjobs, datamængder | Baselinerapport, aftalte kriterier for bestået |
| 2. Testmigrering | Bevis, at workloaden kører på målet | Opstart og forbindelser, funktionelle smoke tests, integrationer, datavalidering, ydeevne under belastning | Testresultater pr. workload, fejlliste |
| 3. Cutover | Skift sikkert, med en vej tilbage | Endelig datasynkronisering og validering, kontrol af DNS og certifikater, smoke tests, go/no-go | Runbook for cutover med tider, underskrevet go/no-go |
| 4. Efter migreringen | Bekræft stabilitet og finjustér | Overvågning af SLI'er, brugergodkendelse, test af backup og restore, kontrol af omkostninger | Hypercare-rapport, lukkede fejl |
Fase 1: plan og baseline
Begynd med en oversigt over applikationer, databaser, grænseflader og planlagte jobs, og rangér dem efter forretningsrisiko. For hver workload registrerer du de tal, du senere skal sammenligne med: p95-svartid for centrale transaktioner, fejlrate, varighed af natlige batchjobs, databasestørrelse og antal rækker.
Gør dem til kriterier. For eksempel: "p95 for ordresøgning inden for 10 % af baseline", "ingen afvigende rækker i økonomitabellerne", "natlig batch er færdig før kl. 06.00". Googles SRE-bog definerer en SLI som "et omhyggeligt defineret kvantitativt mål for et aspekt af serviceniveauet" og et SLO som en målværdi for den (Google SRE book). Når du formulerer kriterierne sådan, bliver go/no-go-beslutningen objektiv.
Fase 2: testmigrering
Migrér en kopi af workloaden til målet, og test den dér, mens kilden fortsat kører. Begge store platforme understøtter det:
- Azure Migrate tilbyder en testmigrering, der starter replikerede VM'er i et virtuelt netværk, du vælger. Microsofts vejledning siger, at det ikke anbefales at testmigrere ind i et virtuelt produktionsnetværk, fordi åbne forbindelser til on-premises kan give dublerede VM'er eller DNS-ændringer.
- AWS Application Migration Service (MGN) starter testinstanser fra løbende replikerede servere, og replikeringen fortsætter efter testen. AWS kalder det en bedste praksis at teste mindst to uger før den planlagte cutover, så der er tid til at rette det, du finder.
Brug fasen til at finde overraskelserne: hårdkodede IP-adresser, manglende firewallregler, licenstjek bundet til hardware og jobs, der kalder servere, du glemte at migrere.
Fase 3: cutover
Cutover er en indøvet runbook og ikke improvisation. Frys ændringer, kør den endelige datasynkronisering, validér data, skift DNS eller mål for load balanceren, og kør smoke tests. Hvert trin har en ejer, et planlagt tidspunkt og en rollback-handling.
Definér udløsere for rollback på forhånd, for eksempel: "hvis smoke tests fejler, eller datavalideringen viser afvigelser 60 minutter efter skiftet, sættes DNS tilbage til kilden". Øv rollback mindst én gang under testmigreringerne.
Fase 4: validering efter migreringen
Efter go-live sammenligner du SLI'er med baseline i mindst en hel forretningscyklus, helst med månedsafslutning eller spidsbelastningsdage. Kør brugergodkendelsestests, test en restore fra de nye backups, og sammenlign den første cloudregning med overslaget. Først derefter lukker du kilden ned.
Hvilke testtyper bør du køre?
Afstem testtyperne efter risikoen for hver workload. Ikke alle applikationer behøver alle tests.
| Testtype | Hvad den beviser | Typiske værktøjer |
|---|---|---|
| Funktionel test og regressionstest | Funktioner og brugerrejser virker stadig | Selenium, Playwright, eksisterende testsuiter |
| Integrationstest | API'er, beskedkøer, filoverførsler og tredjepartstjenester forbinder | Kontrakttests, værktøjer til API-test, syntetiske transaktioner |
| Datavalidering | Hver række og fil nåede frem og stemmer | Datavalidering i AWS DMS, checksums, antal rækker, værktøjer til sammenligning af databaser |
| Ydeevne og belastning | Svartider og gennemløb lever op til målene, og autoskalering virker | JMeter, k6, Gatling |
| Sikkerhed og compliance | Adgang, kryptering, netværksregler og logning er korrekte | Værktøjer til sikkerhedsposition i cloud, sårbarhedsscanninger, gennemgang af IAM |
| Robusthed og DR | Workloaden overlever fejl og kan genetableres | Failover-øvelser, restore af backup, AWS Fault Injection Service |
| Brugergodkendelse | Forretningsbrugerne bekræfter, at systemet er egnet til brug | Scriptet UAT med godkendelse |
Til realistiske belastningstests, der svarer til din spidsbelastning, kan du se vores tjeneste til belastningstest.
Hvordan validerer du data under en migrering?
Validér data på tre niveauer: optælling, checksums og sammenligning række for række for kritiske tabeller.
- Optælling: rækker pr. tabel, filer pr. bucket, samlet antal bytes. Hurtigt og fanger grove fejl.
- Checksums og aggregater: summer af beløb, hashes af nøglekolonner. Fanger afkortning og problemer med kodning.
- Sammenligning på rækkeniveau: for databaser sammenligner datavalidering i AWS DMS hver kilderække med den tilsvarende målrække og rapporterer afvigelser, også for ændringer, der er registreret under løbende replikering.
To praktiske begrænsninger i AWS-dokumentationen bør du planlægge efter: Validering kræver en primærnøgle eller et unikt indeks på hver tabel, og den giver ekstra forespørgselsbelastning på både kilde og mål. Planlæg tunge valideringskørsler uden for arbejdstid, eller kør dem som separate opgaver, der kun validerer.
Test også det, der ændres med vilje. Hvis du konverterer fra Oracle til PostgreSQL, er datatyper, collation og sorteringsrækkefølge forskellige, så sammenlign resultater af forespørgsler og ikke kun lagrede værdier. Vores tjeneste til databasemigrering dækker disse konverteringer.
Hvordan testen ændrer sig med migreringsvejen
- Rehost (lift and shift): fokusér på paritet i miljøet. Kontrollér netværk, DNS, identitet, gennemløb i lager, backupjobs og overvågningsagenter. Funktionel test kan være en smoke test plus de kritiske brugerrejser.
- Replatform: når du flytter en database til en managed service eller en app til containere, skal du tilføje datavalidering, ydeevnetests og kontrol af grænser i managed services, som antal forbindelser.
- Refactor: behandl det som ny software. Kør fuld funktionel test, integrationstest og ydeevnetest, og brug canary- eller blue/green-udgivelser med feature flags for at begrænse eksponeringen.
Tjekliste til test af cloudmigrering
- Oversigt og afhængighedskort er færdige for bølgen
- Baselines er registreret for kritiske brugerrejser, batchjobs og datamængder
- Kriterier for bestået og udløsere for rollback er godkendt af forretningsejeren
- Testmiljøet er isoleret fra produktionsnetværk
- Infrastruktur er defineret som kode, så test og produktion stemmer overens (se vores tjeneste inden for Terraform og infrastructure as code)
- Testdata er maskeret, hvor de indeholder personoplysninger
- Testmigrering er gennemført, fejl er rettet og gentestet
- Datavalidering er bestået for alle tabeller i omfanget
- Belastningstest ved forventet spidsbelastning er bestået
- Sikkerhedsgennemgang er udført: IAM, kryptering, security groups, logning
- Rollback er indøvet og tidsmålt
- Runbook for cutover med ejere og tidspunkter er godkendt
- Dashboards og alarmer til overvågning efter migreringen er i drift
- Restore af backup er testet på den nye platform
Sådan hjælper Opsio
Opsio planlægger og gennemfører cloudmigreringer med test indbygget i hver bølge. For SilverRail Technologies flyttede Opsio virksomhedens nordiske gren til AWS og sammenlagde den med den globale organisation. Mobilize-fasen omfattede en pilot med testmigrering af udvalgte workloads, og migreringsprocessen og AWS-tjenesterne blev justeret på baggrund af testen. Data blev flyttet med native PostgreSQL-værktøjer efter en detaljeret plan for cutover, og cutovers blev gennemført i stramme servicevinduer for at begrænse påvirkningen af kunderne. Læs casen om SilverRail.
Ofte stillede spørgsmål
Hvad er en teststrategi for cloudmigrering?
Det er en plan, der definerer, hvilke tests der køres før, under og efter hver migreringsbølge, kriterierne for bestået for hver enkelt, og hvem der godkender. Den dækker funktion, data, ydeevne, sikkerhed og rollback.
Hvad er faserne i test af cloudmigrering?
Plan og baseline, testmigrering, cutover og validering efter migreringen. Hver fase giver dokumentation, for eksempel baselinerapporter, testresultater, en underskrevet go/no-go og en hypercare-rapport.
Hvordan tester man data efter en cloudmigrering?
Sammenlign antal rækker og checksums for alle tabeller, og kør sammenligninger på rækkeniveau for kritiske data. På AWS sammenligner datavalidering i DMS kilde- og målrækker og rapporterer afvigelser. Den kræver en primærnøgle eller et unikt indeks på hver tabel.
Hvordan adskiller test af en lift-and-shift sig fra en refaktorering?
En lift-and-shift kræver mest kontrol af paritet i miljøet og de kritiske brugerrejser, fordi koden ikke ændres. En refaktorering kræver fuld funktionel test, integrationstest og ydeevnetest, fordi du reelt udgiver ny software.
Hvor længe bør man overvåge efter cutover?
I mindst en hel forretningscyklus, herunder spidsbelastningsdage som månedsafslutning, før du lukker kildesystemerne ned. Hold muligheden for rollback åben, indtil de aftalte kriterier er opfyldt.
Om forfatteren
Redaktionelle retningslinjer: Artiklen er skrevet af en certificeret fagperson, angivet i bylinen ovenfor. Vi opdaterer den, når den teknologi eller regulering, den handler om, ændrer sig; datoerne ovenfor viser den seneste opdatering. Opsio er redaktionelt uafhængig — vi anbefaler løsninger ud fra tekniske fordele, ikke kommercielle relationer.