Bytt hosting: planlegg data og overgang sammen
Planlegg database, filer og skrivetilgang sammen. En gjennomarbeidet plan skiller forberedelse, overgang og retur etter nye endringer.
Et hostingbytte er fullført for teamet ditt når den avtalte arbeidsflyten fungerer på det nye stedet med riktig datatilstand. Bestem på forhånd når endringer skal tas imot, hvem som godkjenner overgangen, og under hvilke betingelser teamet kan gå tilbake.
Kartlegg arbeidsflyten og skriveveiene
I det tenkte eksemplet driver en bedrift kundeportalen P-65. En kunde oppretter forespørselen A-65 med vedlegget F-65. Database og fillager hører sammen. I tillegg til nettleseren kan et grensesnitt og en bakgrunnsprosess endre data. Alle disse skriveveiene må inngå i overgangsplanen.
Eksemplet har en varslet skrivepause. Det er et bevisst valg, ikke et krav ved enhver migrering. Teamet avslutter pågående endringer kontrollert og registrerer hvilke åpne oppgaver som kan fortsette på målstedet. Løpende overføring av nye endringer ville være en annen metode med egne synkroniserings- og konfliktkontroller.
Avtal overgangen som en arbeidsrekkefølge
AWS anbefaler å dokumentere og øve avhengigheter, oppgaverekkefølge, ansvarlige, kontroller og retur før byttet. Den utfylte planmalen inneholder planlagte trinn, ikke resultater fra en gjennomført migrering.
Fase | Avtale i eksemplet | Ansvarlig rolle | Betingelse for neste trinn |
|---|---|---|---|
Forberedelse | Kontroller målmiljøet med en konsistent database- og filkopi. | Applikasjonsteam | Innlogging og tillatt tilgang fungerer, uautorisert tilgang avvises, og den tilhørende filen kan åpnes i den isolerte testen. |
Skrivepause | Stans mottak og behandling av nye endringer på alle gamle skriveveier; overfør siste konsistente tilstand. | Drift og applikasjonsteam | Åpent arbeid er registrert; database og filer passer sammen. |
Godkjenning | Åpne den kontrollerte måltilgangen og ta bare imot endringer på det tiltenkte nye skrivemålet. | Forretnings- og driftsansvarlige | Den styrende datatilstanden, tilgangsveien og beslutningen om avbrudd er tydelige. |
Skill mellom avbrudd og retur på forhånd
Microsoft anbefaler å tilpasse avbruddskriterier og prøvde returtrinn til arbeidsbelastningen. I eksemplet hindrer allerede et manglende vedlegg godkjenningen. Så lenge målstedet ikke har tatt imot nye endringer, kan en forberedt retur til den uendrede gamle tilstanden passe.
Etter nye endringer på målstedet er det ikke nok å sette DNS-adressen tilbake. Endringene kan mangle i det gamle systemet. Returen krever da en fastlagt styrende datatilstand og en kontrollert metode for endringene som kom imellom. Ingen ukoordinerte parallelle skriveveier åpnes i mellomtiden. Hvis teamet ikke kan håndtere dette sikkert, må det endre planen før godkjenning.
Fullfør DNS og overgang sammen
DNS-TTL beskriver vanlig mellomlagring av et svar. Noen klienter kan derfor fortsatt bruke den gamle tilgangen. Virkemåten må passe til skrivepausen eller det nye styrende systemet; to uavhengig skrivbare kopier er ikke et fullført bytte.
Kontroller hele arbeidsflyten i et egnet testmiljø, inkludert ny forespørsel, vedlegg, roller og bakgrunnsarbeid. Eksterne handlinger begrenses der til testmål. Planlegg også overvåking og en ansvarlig kontakt etter godkjenningen. Den gamle tjenesten tas først ut av drift når avtalte sluttbetingelser og sikkerhetskopieringen er avklart.
Kilder
Les videre
Alle artikler
Sky og drift med ASES
Hosting, utrulling, vedlikehold og oppfølging