Gantt-diagram til cloudmigrering med bølger og omstilling
Et redigerbart Gantt-diagram til cloudmigrering: kortlægning, afhængigheder, en landing zone bygget parallelt, migreringsbølger, generalprøve på omstilling, hypercare og nedlæggelse med afhængigheder og milepæle.
Hvad er gantt-diagram til cloudmigrering med bølger og omstilling?
En cloudmigrering er flere projekter, der deler én frist. Kortlægning og planlægning afgør, hvad der flyttes, og i hvilken rækkefølge. Landing zonen, altså netværk, identitet og logning, som workloads skal lande i, kan bygges samtidig. Bølgerne flytter derefter workloads i partier, og kildemiljøet kan ikke slukkes, før den sidste bølge har kørt i produktion et stykke tid. En plan, der opstiller dem som én rækkefølge, overdriver længden. En plan, der behandler dem som uafhængige, skjuler de punkter, hvor det ene venter på det andet.
Skabelonen har fire faser: Kortlæg og planlæg, Byg landing zone, Migrér i bølger samt Omstilling og nedlukning. “Kortlægning af applikationer og servere” er den eneste opgave, der kan starte først. “Kortlægning af afhængigheder” starter tre arbejdsdage efter, at kortlægningen er begyndt, fordi de første fund er nok til at begynde at spore forbindelser, og “Migreringsstrategi pr. workload” følger efter. Derfra deler planen sig. “Bølgeplan og omstillingsvinduer” fører til milepælen “Migreringsplan godkendt”, mens “Design af landing zone” starter, så snart strategien er kendt, og kører parallelt med bølgeplanen.
Inde i landing zonen følger “Bygning af netværk og forbindelser” (10 arbejdsdage) og “Opsætning af identitet, sikkerhed og logning” (8) begge efter designet, og den anden starter to arbejdsdage efter, at designet er begyndt. “Landing zone klar” venter på begge. “Bølge 1: pilotmigrering” kan ikke starte, før både “Migreringsplan godkendt” og “Landing zone klar” er nået, og det er der, planer af denne slags oftest skrider: papirarbejdet er færdigt, og målet er det ikke, eller omvendt. “Indarbejd erfaringer fra piloten i runbooks” ligger mellem piloten og “Bølge 2: kerneworkloads”, og “Bølge 3: resterende workloads” starter fem arbejdsdage efter, at bølge 2 er begyndt, så den sidste bølge overlapper kernebølgen.
Efter bølgerne skal “Ydelses- og failovertest” og bølge 3 begge være færdige før “Sidste generalprøve på omstilling”, derefter “Omstillingsvindue”, “Hypercare” (10 arbejdsdage) og “Nedlæg kildeservere”. “Kildemiljø nedlagt” er den afsluttende milepæl. Alle varigheder er eksempler. Et virkeligt it-landskab har workloads, der ikke kan flytte sammen, licenser med egne slutdatoer og ændringsstop, som diagrammet ikke kender, så erstat længderne og opdelingen i bølger med jeres egne. En tidsplan planlægger arbejdet. Den gør ikke en migrering sikker, tryg eller økonomisk fornuftig, og den erstatter ikke de runbooks, testresultater og godkendelser, som jeres ændringsproces kræver. Til procesdelen kan du se deploymentprocessen på /da/templates/software-deployment-proces, genopretningsprocessen på /da/templates/it-katastrofeberedskab og ændringsprocessen på /da/templates/it-aendringsstyring-workflow.
Hvad dette flowchart dækker
I denne skabelon
- Fire faser, Kortlæg og planlæg, Byg landing zone, Migrér i bølger samt Omstilling og nedlukning, med 19 opgaver og tre milepæle: “Migreringsplan godkendt”, “Landing zone klar” og “Kildemiljø nedlagt”.
- Et start-til-start-overlap i kortlægningen: “Kortlægning af afhængigheder” starter tre arbejdsdage efter, at “Kortlægning af applikationer og servere” starter, før kortlægningen er færdig.
- En landing zone bygget ved siden af planlægningen: “Design af landing zone” følger “Migreringsstrategi pr. workload” og kører parallelt med “Bølgeplan og omstillingsvinduer”, hvor “Opsætning af identitet, sikkerhed og logning” starter to arbejdsdage efter, at designet starter.
- En samling, der spærrer for den første bølge: “Bølge 1: pilotmigrering” venter på både “Migreringsplan godkendt” og “Landing zone klar”, og derefter kommer “Indarbejd erfaringer fra piloten i runbooks” før “Bølge 2: kerneworkloads”.
- Overlappende bølger og en sikker hale: “Bølge 3: resterende workloads” starter fem arbejdsdage efter, at bølge 2 starter, og “Nedlæg kildeservere” venter på den 10 dage lange “Hypercare”.
Hvornår du skal bruge skabelonen
- Du flytter servere eller applikationer til en cloududbyder og skal vise, hvornår planlægningen, landing zonen, hver bølge og omstillingen ligger.
- Du skal forklare en styregruppe eller applikationsejere, hvorfor bølge 1 ikke kan starte, før landing zonen er klar, uanset hvad planen siger.
- Du bliver spurgt, hvor længe kildemiljøet skal være tændt, fx på grund af en slutdato for et datacenter eller en hostingaftale.
- Du vil afprøve, hvad der sker med datoen for nedlæggelsen, hvis netværksbygningen eller en bølge tager længere end planlagt.
Planen, opgave for opgave
Alle opgaver i diagrammet med længde i arbejdsdage og det, de venter på. En afhængighed er et trinnummer; SS er start-til-start, FF er slut-til-slut, og +n er en forsinkelse i arbejdsdage.
| # | Opgave | Gruppe | Arbejdsdage | Afhænger af |
|---|---|---|---|---|
| 1 | Kortlægning af applikationer og servere | Kortlæg og planlæg | 8 | |
| 2 | Kortlægning af afhængigheder | Kortlæg og planlæg | 6 | 1SS+3 |
| 3 | Migreringsstrategi pr. workload | Kortlæg og planlæg | 4 | 2 |
| 4 | Bølgeplan og omstillingsvinduer | Kortlæg og planlæg | 4 | 3 |
| 5 | Migreringsplan godkendt | Kortlæg og planlæg | Milepæl | 4 |
| 6 | Design af landing zone | Byg landing zone | 6 | 3 |
| 7 | Bygning af netværk og forbindelser | Byg landing zone | 10 | 6 |
| 8 | Opsætning af identitet, sikkerhed og logning | Byg landing zone | 8 | 6SS+2 |
| 9 | Landing zone klar | Byg landing zone | Milepæl | 7, 8 |
| 10 | Bølge 1: pilotmigrering | Migrér i bølger | 8 | 5, 9 |
| 11 | Indarbejd erfaringer fra piloten i runbooks | Migrér i bølger | 3 | 10 |
| 12 | Bølge 2: kerneworkloads | Migrér i bølger | 15 | 11 |
| 13 | Bølge 3: resterende workloads | Migrér i bølger | 12 | 12SS+5 |
| 14 | Ydelses- og failovertest | Migrér i bølger | 6 | 12 |
| 15 | Sidste generalprøve på omstilling | Omstilling og nedlukning | 2 | 13, 14 |
| 16 | Omstillingsvindue | Omstilling og nedlukning | 2 | 15 |
| 17 | Hypercare | Omstilling og nedlukning | 10 | 16 |
| 18 | Nedlæg kildeservere | Omstilling og nedlukning | 8 | 17 |
| 19 | Kildemiljø nedlagt | Omstilling og nedlukning | Milepæl | 18 |
Sådan fungerer det
Erstat længderne for kortlægning og planlægning
Sæt længderne på “Kortlægning af applikationer og servere”, “Kortlægning af afhængigheder” og “Migreringsstrategi pr. workload” ud fra størrelsen på jeres it-landskab. Behold start-til-start-forbindelsen, hvis sporingen kan begynde, før kortlægningen er slut.
Byg landing zonen ved siden af planen
Behold “Design af landing zone” og “Bølgeplan og omstillingsvinduer” som parallelle opgaver. Tilføj opgaver til alt andet, målet kræver, fx fælles tjenester, og forbind dem til “Landing zone klar”.
Lad bølge 1 vente på begge sider
“Bølge 1: pilotmigrering” afhænger af “Migreringsplan godkendt” og “Landing zone klar”. Gør netværksbygningen længere, og se, hvilken af dem der fastlægger pilotens start.
Del bølgerne, så de passer til jeres workloads
Omdøb eller duplikér bølgeopgaverne til jeres egne grupper af workloads. Brug en forsinkelse på start-til-start-forbindelsen, hvor en senere bølge kan begynde, mens en tidligere stadig kører.
Tilføj omstilling, hypercare og nedlæggelse
Sæt “Hypercare” til, hvor længe du vil beholde kilden som fallback. Tjek den dato, “Kildemiljø nedlagt” giver dig, mod enhver kontrakts- eller licensslutdato, du skal overholde.
Tilføj ansvarlige, del og eksportér
Sæt det ansvarlige team ind i Personer, skriv fx henvisninger til runbooks i opgavernes noter, del diagrammet med applikationsejerne, og eksportér en PDF til ændringsregistret.
Ofte stillede spørgsmål
Vælger diagrammet en migreringsstrategi for mig?
Nej. Det planlægger arbejdet. Opgaven “Migreringsstrategi pr. workload” er der, hvor du for hver workload afgør, om den skal flyttes, som den er, ændres eller erstattes. Diagrammet viser kun, hvad der venter på den beslutning.
Kan jeg planlægge efter en slutdato for datacenteret?
Sammenlign slutdatoen for “Kildemiljø nedlagt” med den dato, du har brug for. Er den senere, så ret en længde eller en afhængighed, og se datoen rykke sig. En fast Start er til datoer, der virkelig er faste, som et ændringsstop, og diagrammet markerer en, der strider mod en afhængighed.
Er arbejdsdagene rigtige kalenderdage?
De er mandag til fredag. Diagrammet har ingen helligdagskalender, så tilføj en opgave eller gør en varighed længere, hvor en helligdag eller et ændringsstop ligger.
Hvordan adskiller det sig fra diagrammet til datamigrering?
Dette flytter workloads og miljøer. Diagrammet til datamigrering på /da/templates/gantt-diagram-til-datamigrering dækker profilering, mapping, prøveindlæsninger og afstemning af selve dataene. Et stort program kan bruge begge.
Hvor er flowchartet til samme arbejde?
Deploymentprocessen på /da/templates/software-deployment-proces og genopretningsprocessen på /da/templates/it-katastrofeberedskab tegner beslutningerne og overdragelserne. Til en bredere programplan kan du se /da/templates/gantt-diagram-til-implementeringsplan.
