Når nettsiden stopper: Slik kravsetter du hosting og drift før avtalen signeres
En god driftsavtale handler ikke bare om serverplass og oppetid. Den må beskrive hvordan feil oppdages, hvem som reagerer, og hvor raskt nettsiden og dataene kan gjenopprettes.
Profesjonell webhosting blir ofte vurdert ut fra pris, lagringsplass og en lovet oppetidsprosent. Det sier lite om hva som faktisk skjer når nettsiden blir treg, en oppdatering feiler eller data må gjenopprettes.
Den mest nyttige vinklingen er derfor ikke «Hvilken server skal vi kjøpe?», men «Hva må driftsopplegget tåle, og hvordan kommer vi tilbake etter en feil?» Svaret bør styre valg av driftsmiljø, backup, caching, CDN, overvåking og vedlikehold.
Start med konsekvensen av nedetid
To nettsider med like mange besøkende kan ha helt forskjellige driftsbehov. En rådgivningsbedrift kan kanskje leve med en kort driftsstans utenom arbeidstid. For en nettbutikk midt i en kampanje kan samme stans bety tapte bestillinger, merarbeid og svekket tillit.
Vurder derfor konsekvensene før dere diskuterer tekniske løsninger:
- Hva skjer hvis nettsiden er utilgjengelig i 15 minutter, to timer eller én arbeidsdag?
- Finnes det skjemaer, bestillinger eller kundehenvendelser som kan gå tapt?
- Har virksomheten perioder der tilgjengeligheten er særlig viktig?
- Hvilke personer må varsles ved en alvorlig feil?
- Finnes det en alternativ kanal kundene kan bruke?
Dette gir et bedre beslutningsgrunnlag enn trafikkmengde alene. En nettside med moderat trafikk kan være forretningskritisk dersom den håndterer søknader, reservasjoner eller kvalifiserte henvendelser.
Oppetid må oversettes til praktiske krav
En oppetid på 99,9 prosent høres nær perfekt ut, men tilsvarer omtrent 8 timer og 46 minutter mulig nedetid i løpet av et år. Ved 99,99 prosent er den tilsvarende tiden rundt 53 minutter. Prosenten må derfor vurderes sammen med måleperiode, unntak og responstid.
Be leverandøren avklare:
- Hva regnes som nedetid?
- Måles nettsiden fra utsiden, eller bare om serveren kjører?
- Er planlagt vedlikehold unntatt?
- Gjelder løftet hele løsningen eller bare infrastrukturen?
- Hva skjer dersom databasen fungerer, men kundene ikke får sendt inn skjemaet?
En server kan være «oppe» samtidig som nettsiden viser feilmeldinger eller sentrale funksjoner har stoppet. Ekstern overvåking av det brukeren faktisk møter, er derfor viktigere enn en grønn statuslampe hos hostingleverandøren.
Definer hvor raskt dere må være tilbake
To begreper gjør det enklere å formulere konkrete krav: RTO og RPO. RTO beskriver hvor lang tid virksomheten maksimalt kan akseptere at tjenesten er utilgjengelig. RPO beskriver hvor mye data det er akseptabelt å miste, målt som tid siden siste gjenopprettingspunkt. Slike mål bør bestemmes ut fra forretningskonsekvensene og deretter brukes til å velge teknisk løsning.
For en enkel bedriftsnettside kan det eksempelvis være akseptabelt å gjenopprette tjenesten innen noen timer og innholdet fra forrige natt. For en aktiv nettbutikk kan flere timers tap av ordredata være uakseptabelt. Da kreves hyppigere sikkerhetskopiering eller løpende replikering, kombinert med raskere beredskap.
Strengere mål gir normalt høyere kostnad og mer kompleksitet. Det er sjelden hensiktsmessig å kreve tilnærmet null nedetid og null datatap dersom den reelle forretningsrisikoen ikke forsvarer investeringen.
Backup er først verdifull når den kan gjenopprettes
«Daglig backup» er ikke en fullstendig beskrivelse. En profesjonell backupløsning må angi hva som kopieres, hvor ofte det skjer, hvor lenge kopiene beholdes, hvor de lagres og hvem som har tilgang.
NSM anbefaler at en plan for sikkerhetskopiering blant annet beskriver hvilke data som omfattes, hyppighet, ansvar, oppbevaring, sikring og krav til gjenopprettingstid. NSM peker også på behovet for kopier som ikke kan nås via virksomhetens vanlige nettverk.
For en nettside bør backupen normalt omfatte:
- database med innhold, brukere, ordre og innstillinger
- opplastede bilder og dokumenter
- tema, programkode og spesialtilpasninger
- konfigurasjon for server, DNS og tilknyttede tjenester
- nødvendige opplysninger for å bygge miljøet opp igjen
Kopien bør ikke bare ligge på samme server som produksjonsløsningen. Dersom serveren, kontoen eller leverandørmiljøet rammes, kan både nettsted og backup ellers bli utilgjengelige samtidig.
Be om dokumentasjon på gjenopprettingstesten
En vellykket backupjobb viser bare at noe ble kopiert. Den viser ikke at filene er komplette, at databasen kan leses eller at løsningen kan settes i drift innen avtalt tid. Regelmessig gjenoppretting til et separat testmiljø er nødvendig for å kontrollere både innholdet og tidsbruken. AWS anbefaler periodiske gjenopprettingstester for å bekrefte at backupen faktisk oppfyller fastsatte RTO- og RPO-mål.
Caching og CDN må konfigureres for løsningen
Caching reduserer behovet for å generere samme innhold på nytt for hver forespørsel. Et CDN kan i tillegg lagre kopier av statiske ressurser, som bilder, stilark og JavaScript, nærmere brukerne. Dette kan redusere belastningen på den opprinnelige serveren og gi raskere levering.
Men caching er ikke et universelt avkrysningsfelt. Innloggede sider, handlekurver, personlige priser, skjemaresultater og annet individuelt innhold må håndteres annerledes enn en offentlig artikkel. Feil cache-regler kan gi utdatert innhold eller i verste fall vise informasjon til feil bruker.
Driftsleverandøren bør derfor kunne forklare:
- hvilke sidetyper og filer som caches
- hvordan innloggede brukere og dynamiske funksjoner unntas
- hvordan cachen tømmes etter publisering og oppdateringer
- hva som skjer når CDN-et eller den opprinnelige serveren feiler
- hvordan cache-treff og feil overvåkes
Et CDN kan avlaste serveren, men erstatter ikke et stabilt produksjonsmiljø. Forespørsler som ikke ligger i cachen, må fortsatt behandles av den opprinnelige løsningen.
Overvåk brukerens opplevelse og systemets årsaker
God overvåking kombinerer utvendige tester med innsyn i driftsmiljøet. Google skiller mellom «black-box»-overvåking, som tester tjenesten slik brukeren møter den, og «white-box»-overvåking, som undersøker interne målinger, logger og komponenter. Den første oppdager symptomet. Den andre hjelper driftsteamet med å finne årsaken.
For en vanlig bedriftsnettside kan overvåkingen blant annet dekke:
- om viktige sider svarer korrekt
- om skjemaer, søk eller utsjekk fungerer
- responstid og økning i feilrater
- ressursbruk på server og database
- utløp av sertifikater og domener
- feil i backup, automatiske jobber og integrasjoner
Varsling må knyttes til ansvar. En alarm uten en navngitt mottaker og forventet reaksjonstid er bare en melding. Avtalen bør skille mellom kritiske hendelser som krever umiddelbar respons, og mindre avvik som kan behandles neste arbeidsdag.
Vedlikehold må være en kontrollert prosess
WordPress, programtillegg, temaer, PHP, databaser og serverkomponenter endrer seg over tid. Å utsette alle oppdateringer øker teknisk gjeld og risiko. Å installere alt direkte i produksjon uten kontroll kan samtidig skape kompatibilitetsproblemer.
WordPress anbefaler å holde programtillegg oppdatert og å ha en aktuell backup før oppdatering. En profesjonell vedlikeholdsprosess bør i tillegg omfatte risikovurdering, testing av større endringer, funksjonskontroll etter utrulling og en tydelig plan for tilbakeføring.
Avklar hvem som har ansvar for:
- løpende sikkerhets- og vedlikeholdsoppdateringer
- testing i et separat miljø
- feilretting dersom en oppdatering påvirker spesialutviklet funksjonalitet
- oppgradering av PHP, database og operativsystem
- utfasing av komponenter som ikke lenger vedlikeholdes
Velg driftsmiljø etter risiko og ansvar
Delt hosting kan være tilstrekkelig for en enkel nettside med begrensede krav. Administrert hosting passer når virksomheten vil at en leverandør skal håndtere mer av overvåking, oppdateringer, sikkerhet og feilretting. Dedikerte eller skalerbare skymiljøer kan være aktuelle når løsningen har høy belastning, spesielle integrasjoner eller strenge krav til tilgjengelighet og isolasjon.
Det avgjørende er ikke hva miljøet kalles, men hvilke garantier og arbeidsprosesser som følger med. «Cloud», «premium» og «managed» har liten verdi dersom ansvar, responstid og gjenoppretting ikke er konkretisert.
Sju spørsmål før dere inngår driftsavtalen
- Hva overvåkes? Be om både eksterne brukertester og interne systemmålinger.
- Hvem reagerer? Avklar ansvar, beredskapstid og eskaleringsvei.
- Hvor raskt skal tjenesten tilbake? Sett et realistisk RTO basert på forretningsbehov.
- Hvor mye data kan gå tapt? Fastsett RPO og tilpass backuphyppigheten.
- Når ble backup sist testet? Be om resultatet fra en reell gjenoppretting.
- Hvordan gjennomføres oppdateringer? Krev backup, kontroll, testing og mulighet for tilbakeføring.
- Hva inngår ikke? Dokumenter grensen mellom hosting, applikasjonsdrift, feilretting og videreutvikling.
En god driftsavtale fjerner ikke all risiko. Den gjør risikoen forståelig og håndterbar. Virksomheten vet hva som overvåkes, hvor raskt noen reagerer, og hvordan nettsiden kommer tilbake dersom noe går galt. Det er den praktiske forskjellen mellom å leie serverplass og å ha profesjonell drift.
