Sådan planlægger du bølger og omstilling i cloudmigrering
Planlæg en cloudmigrering i et Gantt-diagram: kortlæg afhængigheder, del workloads i bølger, byg landing zonen parallelt, hold generalprøve på omstillingen, og planlæg nedlæggelsen efter hypercare.
Det svære ved en tidsplan for cloudmigrering er at afgøre, hvad der flytter sammen, og hvad hver bølge venter på. Guiden viser, hvordan du gør en oversigt over workloads til bølger, en landing zone, en indøvet omstilling og en dato for nedlæggelse.
Kort fortalt
- Spor afhængigheder, mens kortlægningen kører, så workloads der skal flytte sammen, er kendt, før bølgerne fastlægges.
- Behandl landing zonen som et eget spor med en milepæl for klarhed, som den første bølge venter på.
- Kør en pilotbølge først, og sæt en opgave for erfaringer mellem den og de større bølger.
- Lad senere bølger overlappe med en start-til-start-forbindelse, men start aldrig en bølge, før dens input til generalprøven findes.
- Nedlæg kilden efter en hypercare-periode, og tjek datoen for nedlæggelsen mod jeres kontraktdatoer.
Fra en liste over workloads til en bølgeplan
En oversigt over workloads er en liste. En migreringsplan er en rækkefølge. Forskellen er afhængigheder: en applikation kan ikke flytte før den database, den kalder, et batchjob kan ikke flytte før det fildrev, det skriver til, og intet flytter, før stedet, det skal hen, findes. Teams, der springer det trin over, ender med bølger, der ser pæne ud på et slide og fejler den første weekend, fordi halvdelen af en bølges forbindelser blev efterladt.
Metoden her har tre greb. For det første: spor afhængigheder, mens kortlægningen stadig kører, så grupper af workloads, der skal flytte sammen, dukker op tidligt. For det andet: gør landing zonen til et særskilt arbejdsspor med egne opgaver og en milepæl for klarhed i stedet for en linje øverst i planen. For det tredje: sæt kildemiljøets nedlæggelse bag en hypercare-periode, så spørgsmålet om, hvornår det kan slukkes, har et synligt svar.
Et Gantt-diagram hjælper med det, en liste ikke kan vise: hvilken dato der rykker, når en anden gør det. Tager netværksbygningen fire dage længere, rykker pilotbølgen, derefter hver bølge efter den, derefter datoen for nedlæggelsen. Finder kortlægningen en sammenfiltret applikation, ændres bølgeplanen før landing zonen. Diagrammet fortæller ikke, hvilken strategi der passer til en workload, eller om målet er sikkert. Det planlægger det arbejde, du har besluttet.
Eksemplet bygger skabelonen til cloudmigrering i etaper. Varighederne er eksempler. Til processen frem for tidsplanen kan du se deploymentprocessen på /da/templates/software-deployment-proces og genopretningsprocessen på /da/templates/it-katastrofeberedskab.
En plan for cloudmigrering, bygget i etaper
Nitten opgaver i fire faser. Varighederne er eksempler; sæt dine egne. Åbn regnearkspanelet for at se rækkerne bag hver etape.
Kortlægning, afhængigheder og bølgeplanen
“Kortlægning af applikationer og servere” tager 8 arbejdsdage. “Kortlægning af afhængigheder” starter tre arbejdsdage efter, at den starter, så sporingen begynder på de første fund. “Migreringsstrategi pr. workload” og “Bølgeplan og omstillingsvinduer” følger og slutter ved milepælen “Migreringsplan godkendt”.
Landing zonen, bygget ved siden af planen
“Design af landing zone” starter, når strategien er kendt, ikke når planen er godkendt. “Bygning af netværk og forbindelser” tager 10 arbejdsdage og “Opsætning af identitet, sikkerhed og logning” 8, startende to arbejdsdage efter, at designet starter. “Landing zone klar” venter på begge.
Pilot først, derefter de større bølger
“Bølge 1: pilotmigrering” (8 arbejdsdage) venter på “Migreringsplan godkendt” og “Landing zone klar”. “Indarbejd erfaringer fra piloten i runbooks” følger, derefter “Bølge 2: kerneworkloads” (15). “Bølge 3: resterende workloads” starter fem arbejdsdage efter, at bølge 2 starter, og “Ydelses- og failovertest” følger bølge 2.
Generalprøve, omstilling, så nedlæggelse
“Sidste generalprøve på omstilling” venter på bølge 3 og på testen. “Omstillingsvindue” er 2 arbejdsdage, “Hypercare” er 10, og “Nedlæg kildeservere” (8) følger efter og slutter ved milepælen “Kildemiljø nedlagt”.
Sådan fungerer det
Start kortlægningen af afhængigheder, før kortlægningen slutter
Tilføj “Kortlægning af afhængigheder” som en egen opgave, og forbind den start-til-start med kortlægningen, fx 1SS+3. De første fund er nok til at begynde, og grupperne, der skal flytte sammen, dukker op uger tidligere.
Gør landing zonen til et spor med en milepæl
Giv designet af landing zonen, netværket og identitetsarbejdet hver sin opgave, saml dem i en milepæl med længden 0, og lad den første bølge afhænge af den såvel som af den godkendte plan.
Dimensionér bølger efter afhængighedsgrupper
Sæt workloads, der afhænger af hinanden, i samme bølge. Giv hver bølge en opgave, og brug feltet Gruppe til at holde bølgerne, landing zonen og omstillingen i adskilte bånd.
Kør en pilot, og planlæg, hvad du ændrer
Gør bølge 1 lille, og tilføj en opgave efter den til ændringer af runbooks og værktøj. Senere bølger afhænger af den opgave, så den tid, den tager, viser sig i datoerne.
Lad bølger overlappe med en forsinkelse
Hvor en senere bølge kan begynde, mens en tidligere kører, så brug en start-til-start-forbindelse med forsinkelse, fx 12SS+5. Tjek, at folkene og målets kapacitet er der, for diagrammet tjekker dem ikke.
Sæt nedlæggelsen bag hypercare
Tilføj hypercare som en opgave med en længde, der svarer til, hvor længe du vil beholde kilden som fallback, og lad nedlæggelsen følge efter. Sammenlign slutdatoen med den dato, du har brug for.
Faldgruber du skal undgå
At starte piloten, når papirarbejdet er klart
En underskrevet plan er ikke et klart mål. Afhænger bølge 1 kun af godkendelsen, overrasker en forsinket netværksbygning alle. Lad den første bølge vente på både planen og landing zonen.
Bølger delt efter team i stedet for efter afhængighed
At flytte alt, ét team ejer, samme dag, skiller ofte en applikation fra dens database. Del efter, hvad der taler med hvad, og tjek grupperne mod kortlægningen af afhængigheder.
At slukke kilden ved omstillingen
Starter nedlæggelsen ved omstillingen, slutter fallbacken, før problemerne er dukket op. Behold hypercare imellem, og giv den en reel længde.
At behandle planen som en beslutningsjournal
Diagrammet viser, hvornår arbejdet skal ske. Valg af strategi, sikkerhedsgennemgange og testresultater hører til i jeres egne optegnelser og ændringsproces, med en henvisning i opgavernes noter.
Åbn Gantt-diagrammet til cloudmigrering
Åbn skabelonen til cloudmigrering, ret bølgernes længder til dine egne, og se datoen for nedlæggelsen rykke sig.
Relaterede guides
Ofte stillede spørgsmål
Hvor mange bølger skal en migrering have?
Det afhænger af antallet af workloads og af, hvor tæt de hænger sammen. Skabelonen bruger tre som eksempel. Tilføj eller fjern bølgeopgaver, så de passer til jeres grupper.
Kan jeg planlægge efter en udflytningsdato for datacenteret?
Sammenlign slutdatoen for nedlæggelsesmilepælen med den dato, du har brug for. Er den senere, så ret en længde eller en afhængighed. Brug en fast Start kun til datoer, der virkelig er faste, som et ændringsstop; diagrammet markerer en fast start, der strider mod en afhængighed.
Følger diagrammet omkostninger eller kapacitet?
Nej. QueryChart planlægger opgaver, afhængigheder og fremdrift. Det følger ikke omkostninger, indsats eller ressourcebelastning, så hold dem i det værktøj, du allerede bruger.
Kan jeg indsætte min liste over workloads i diagrammet?
Ja. Kopiér rækker fra Excel, Sheets eller en CSV, og indsæt dem i arket. Navngiver den første linje kolonner som Opgave (Task), Varighed (Duration) og Afhænger af (Depends on), bliver hver kolonne genkendt på navnet.
Hvor ser jeg, hvilke opgaver der fastlægger slutdatoen?
Slå Vis og derefter Kritisk vej til for at fremhæve den kæde af opgaver, der fastlægger slutdatoen. Se /da/guides/kritisk-vej-i-gantt-diagram for, hvordan du læser den.
