Flytt nettsiden uten unødvendig nedetid: En praktisk plan for bytte av driftsmiljø
Et hostingskifte bør behandles som en kontrollert produksjonsendring. Denne planen reduserer risikoen for nedetid, datatap og feil etter flytting.
Kategori: Hosting & drift
Å flytte en nettside til et nytt driftsmiljø handler ikke bare om å kopiere filer og endre DNS. Nettsiden kan ha skjemaer, nettbutikk, integrasjoner, planlagte oppgaver, cache, e-postutsending og sikkerhetsregler som må fungere på samme måte etter flyttingen. Hvis én avhengighet blir glemt, kan nettstedet se riktig ut samtidig som viktige funksjoner har sluttet å virke.
Derfor bør et hostingskifte behandles som en kontrollert produksjonsendring. Målet er ikke bare kortest mulig nedetid. Målet er en flytting der dere vet hva som skal skje, hvordan resultatet skal kontrolleres, og når dere skal gå tilbake til det gamle miljøet.
Start med å kartlegge hva som faktisk skal flyttes
Før dere velger metode og tidspunkt, må dere forstå løsningen. En enkel bedriftsnettside kan ofte flyttes i ett samlet løp. En nettbutikk eller medlemstjeneste krever gjerne en plan for data som endres mens flyttingen pågår.
Kartleggingen bør minst omfatte:
- nettsidens filer, database og opplastede medier
- domener, underdomener og DNS-poster
- SSL-sertifikater og videresendinger
- cachelag, CDN og eventuelle brannmurregler
- skjemaer, e-postutsending og eksterne integrasjoner
- planlagte oppgaver og automatiske importer eller eksporter
- tilgang til databaser, filsystem og administrasjon
- krav til PHP, database, servermoduler og lagringsplass
Kartleggingen avdekker også hvem som må delta. Det kan være webbyrå, intern IT, DNS-ansvarlig, hostingleverandør og leverandører av integrasjoner. Navngitte personer og tydelige tidspunkter er bedre enn å oppdage under flyttingen at bare én medarbeider kan godkjenne en nødvendig endring.
Bygg det nye miljøet før dere endrer trafikken
Det nye driftsmiljøet bør settes opp og testes mens det gamle fortsatt er i produksjon. Da kan dere undersøke feil uten at besøkende blir berørt.
Miljøet bør ligne produksjonen dere faktisk trenger, ikke bare klare å vise forsiden. Kontroller blant annet programvarekrav, databaseinnstillinger, filrettigheter, lagringskapasitet, tidsinnstillinger, e-postoppsett og planlagte oppgaver. Dersom løsningen bruker serverspesifikk cache eller bildebehandling, må dette også verifiseres.
Nettsiden kan testes i det nye miljøet ved å styre trafikken lokalt fra en testmaskin. Da kan testeren åpne det vanlige domenet mot den nye serveren uten å endre offentlig DNS. Dette er ofte mer pålitelig enn å teste på en midlertidig adresse, fordi enkelte løsninger oppfører seg annerledes når domenet endres.
Test mer enn det visuelle
En rask gjennomgang av sidene er nødvendig, men ikke tilstrekkelig. Test konkrete brukeroppgaver:
- send inn alle viktige skjemaer og kontroller mottak
- logg inn med relevante brukerroller
- gjennomfør et testkjøp dersom nettstedet har nettbutikk
- kontroller søk, filtrering og nedlasting av filer
- utløs relevante e-poster og varsler
- test integrasjoner mot økonomi-, CRM- eller fagsystemer
- kontroller at videresendinger og feilsider fungerer
Se også i logger etter feil som ikke er synlige i nettleseren. En side kan bli vist selv om bakgrunnsjobber, API-kall eller e-postutsending feiler.
Bestem hvordan ferske data skal håndteres
Den vanskeligste delen av en flytting er ofte data som oppstår etter at den første kopien er tatt. Nye bestillinger, skjemaer, kommentarer, brukerregistreringer og redaksjonelle endringer kan havne i det gamle miljøet mens det nye klargjøres.
For en nettside med få endringer kan dere avtale en kort innholdsfrys. Redaktører lar være å publisere, og den endelige databasen kopieres rett før trafikken flyttes. For løsninger med løpende transaksjoner må dere vurdere en kort vedlikeholdsperiode eller en kontrollert sluttsynkronisering.
Ikke baser dere på å slå sammen to databaser manuelt etterpå. Det kan oppstå konflikter mellom identifikatorer, relasjoner og tidsstempler. Velg på forhånd hvilket miljø som er autoritativt i hver fase, og avtal et tydelig tidspunkt for når skriving i det gamle miljøet skal stoppe.
Forbered DNS, CDN og sertifikater
DNS-endringen avgjør hvor trafikken sendes, men den flytter ikke nettsiden i seg selv. Før byttet bør relevante DNS-poster og deres mellomlagringstid gjennomgås. En kortere levetid kan bidra til at endringen slår raskere gjennom, men den må justeres i god tid før flyttingen for å ha ønsket effekt.
Kontroller samtidig hvordan CDN-et er satt opp. Hvis CDN-et fortsatt henter innhold fra gammel server, kan brukerne få en blanding av gammelt og nytt innhold. Opprinnelsesserver, cache-regler og tømming av cache må derfor inngå i kjøreplanen.
SSL må være klart i det nye miljøet før trafikken kommer. Test både hoveddomene og andre vertsnavn som skal være tilgjengelige. Videresending fra ukryptert til kryptert trafikk bør også kontrolleres, sammen med eventuelle sikkerhetsregler som begrenser hvilke tjenester som kan nå serveren.
Lag en kjøreplan med stoppunkter
På flyttedagen bør teamet følge en skriftlig og tidfestet kjøreplan. Den trenger ikke være omfattende, men hvert punkt bør ha ansvarlig person, forventet resultat og en måte å kontrollere resultatet på.
En typisk rekkefølge kan være:
- Bekreft at backup er fullført og at nødvendig tilgang fungerer.
- Stans publisering og andre skriveoperasjoner i gammelt miljø.
- Ta en endelig kopi av database og nye filer.
- Importer data og kjør nødvendige tekniske tilpasninger.
- Utfør en kort funksjonstest direkte mot nytt miljø.
- Endre DNS og oppdater CDN dersom det er nødvendig.
- Tøm relevante cacher i riktig rekkefølge.
- Kontroller nettstedet fra flere nettverk og enheter.
- Aktiver overvåking og følg logger, responstid og feil.
- Åpne igjen for redigering og transaksjoner.
Legg inn stoppunkter før irreversible eller risikofylte steg. Dersom sluttsynkroniseringen feiler, skal dere ikke endre DNS bare fordi tidspunktet i kalenderen er passert.
Definer tilbakeføring før flyttingen starter
En tilbakeføringsplan må beskrive mer enn at dere kan peke DNS tilbake. Hvis nye bestillinger eller henvendelser allerede er registrert i det nye miljøet, kan en retur til det gamle føre til datatap.
Avtal derfor hvilke feil som utløser tilbakeføring, hvem som tar beslutningen, og hvor lenge det er praktisk mulig å gå tilbake. Kritiske feil kan være utilgjengelig betaling, manglende innlogging, omfattende serverfeil eller tap av nye data. Mindre visuelle avvik kan ofte rettes etter at flyttingen er gjennomført.
Det gamle miljøet bør beholdes uendret i en avtalt periode, men beskyttes mot nye skriveoperasjoner når det ikke lenger er produksjonsmiljø. Da har dere et sammenligningsgrunnlag uten å skape to aktive versjoner av samme løsning.
Overvåk hele brukerreisen etter byttet
En enkel oppetidskontroll kan bekrefte at serveren svarer, men ikke at nettsiden fungerer. Etter flyttingen bør overvåkingen dekke sentrale sider og handlinger. Følg med på responstid, serverfeil, databasefeil, mislykkede bakgrunnsjobber og avvik i trafikk eller konverteringer.
De første timene krever tettere oppfølging. Deretter bør kontroller gjentas neste arbeidsdag og etter at planlagte døgn- eller ukesjobber har kjørt. Det er vanlig at feil først blir synlige når en import starter, et sertifikat skal fornyes, eller en e-postkø behandles.
Kontroller også backupjobber i det nye miljøet. En melding om at backup er konfigurert er ikke det samme som at riktige filer og databaser faktisk blir lagret. Se etter fullførte kjøringer, forventet datamengde og riktig lagringsmål.
Avslutt med opprydding og ny driftsbaseline
Når flyttingen er bekreftet stabil, bør gamle tilganger, midlertidige testadresser og unødvendige DNS-poster fjernes. Oppdater driftsdokumentasjonen med serverinformasjon, kontaktpunkter, backupoppsett, overvåking, vedlikeholdsrutiner og ansvar.
Bruk samtidig flyttingen til å etablere en ny baseline. Noter normal responstid, ressursbruk, cachetreff, lagringsforbruk og forventet trafikk. Da blir det enklere å oppdage senere avvik og vurdere om driftsmiljøet har riktig kapasitet.
En vellykket hostingflytting kjennetegnes ikke bare av at forsiden åpner. Skjemaer blir levert, transaksjoner blir lagret, integrasjoner kjører, cache og CDN viser riktig innhold, overvåkingen varsler som planlagt, og driftsansvaret er tydelig etter at prosjektet er avsluttet.
