Velg webhosting etter konsekvens, ikke kapasitet

Kategori: Hosting og drift

Mange velger webhosting ved å sammenligne lagringsplass, prosessorkraft og månedspris. Det er enkelt å måle, men sier lite om hvor godt driftsmiljøet støtter virksomheten når noe faktisk skjer.

Et bedre utgangspunkt er konsekvens: Hva koster det hvis nettsiden er utilgjengelig, treg eller viser feil innhold? Hvor mye data kan dere miste? Hvor raskt må normal drift gjenopprettes? Svarene gir grunnlaget for en konkret driftsprofil.

Driftsprofilen er et kort beslutningsdokument som beskriver kravene til oppetid, ytelse, caching, CDN, backup, overvåking, vedlikehold og ansvar. Den gjør det lettere å velge riktig hosting og reduserer risikoen for at viktige behov oppdages først etter en hendelse.

Start med nettsidens faktiske rolle

To nettsteder med omtrent samme trafikk kan ha helt ulike driftsbehov. En informasjonsside som hovedsakelig viser åpningstider og kontaktinformasjon tåler ofte et kort avbrudd. En nettbutikk, innlogget kundeportal eller bestillingsløsning kan tape omsetning og skape manuelt etterarbeid i samme tidsrom.

Før dere vurderer tekniske løsninger, bør dere svare på disse spørsmålene:

• Hvilke oppgaver utfører kunder og ansatte på nettsiden?
• Hva skjer i virksomheten hvis oppgavene ikke kan gjennomføres?
• Finnes det alternative kanaler mens nettsiden er nede?
• Når på døgnet og i hvilke perioder er tilgjengelighet viktigst?
• Hvilke data oppstår på nettsiden, for eksempel ordre, skjemaer eller brukerinnhold?
• Hvem skal ta beslutninger og kommunisere ved en driftsfeil?

Beskriv konsekvensene konkret. «Nettsiden er viktig» er ikke et driftskrav. «Kunder kan ikke bestille, og kundeservice må registrere bestillinger manuelt» gir derimot et tydelig grunnlag for prioritering.

Del løsningen inn etter kritikalitet

Det er sjelden nødvendig å stille samme krav til alle deler av nettstedet. En kampanjeside, nettbutikkens kasse og et internt rapporteringsområde kan ha forskjellige behov selv om de ligger i samme løsning.

En enkel inndeling kan være:

Ordinær publisering

Dette gjelder innhold som tåler kortere avbrudd og der endringer skjer relativt sjelden. Her kan et standardisert, administrert driftsmiljø være tilstrekkelig, så lenge backup, oppdateringer og grunnleggende overvåking er på plass.

Forretningsviktig tjeneste

Dette omfatter blant annet aktive salgssider, skjemaer som skaper kundehenvendelser og løsninger ansatte er avhengige av. Her bør kravene til responstid, gjenoppretting, ytelsesovervåking og leverandøransvar være tydeligere.

Virksomhetskritisk funksjon

Dette er funksjoner der avbrudd raskt påvirker omsetning, leveranser, kundedata eller sentrale arbeidsprosesser. Slike løsninger kan kreve mer robust infrastruktur, hyppigere sikkerhetskopiering, redundans og beredskap utenfor vanlig arbeidstid.

Poenget er ikke å gjøre hele nettsiden mest mulig avansert. Poenget er å bruke ressursene der konsekvensene er størst.

Definer oppetid som mer enn et prosenttall

Et løfte om høy oppetid kan se betryggende ut, men må avgrenses. Dere bør vite hva som måles, hvor det måles fra, hvilke deler av tjenesten som inngår, og hvilke avbrudd som er unntatt.

En nettside kan svare teknisk selv om innloggingen feiler, produktsøk ikke virker eller kassen ikke kan ta imot betaling. Driftsprofilen bør derfor beskrive hvilke funksjoner som må fungere for at løsningen skal regnes som tilgjengelig.

Avklar også:

• Om planlagt vedlikehold regnes som nedetid.
• Når vedlikehold normalt gjennomføres.
• Hvor raskt kritiske feil skal vurderes.
• Hvilke kontaktkanaler som gjelder utenfor arbeidstid.
• Hvem som har ansvar når feilen ligger i kode, integrasjoner eller eksterne tjenester.

Dette skiller et reelt driftsopplegg fra et generelt hostingprodukt.

Bestem hva som kan caches

Caching reduserer belastningen på serveren ved å gjenbruke ferdig generert innhold. Det kan gi raskere sider og bedre kapasitet ved trafikktopper. Feil caching kan samtidig føre til at brukere ser utdatert eller personlig innhold som ikke er ment for dem.

Driftsprofilen bør skille mellom offentlig innhold og dynamiske funksjoner. Artikler, bilder og produktsider kan ofte caches effektivt. Handlekurv, kasse, innloggede områder og personlige priser må vanligvis behandles annerledes.

Avklar hvordan cachen tømmes når innhold publiseres, produkter endres eller en kritisk rettelse legges ut. Det bør også finnes en kontrollert måte å koble caching fra under feilsøking. Ellers kan gamle versjoner skjule om en rettelse faktisk virker.

Bruk CDN når det løser et konkret behov

Et CDN distribuerer statiske filer og eventuelt cachet innhold nærmere brukerne. Det kan være nyttig når målgruppen er geografisk spredt, nettstedet har mange tunge filer eller trafikken varierer kraftig.

CDN er likevel ikke en erstatning for et godt driftsmiljø. Langsom databasebruk, tunge utvidelser og ineffektiv applikasjonskode blir ikke automatisk løst. Definer derfor hva CDN-et skal forbedre: levering av bilder, håndtering av trafikktopper, geografisk responstid eller avlastning av opprinnelsesserveren.

Dere bør også vite hvem som styrer innstillingene, hvordan endringer testes, og hva som skjer hvis CDN-tjenesten får problemer. Flere tekniske lag gir verdi først når ansvar og feilsøking er avklart.

Sett krav til gjenoppretting før backupfrekvens

«Daglig backup» er ikke et komplett krav. For en nettside som mottar ordre gjennom hele dagen, kan ett døgn med datatap være alvorlig. For en statisk informasjonsside kan det være akseptabelt.

Definer to forhold:

• Akseptabelt datatap: Hvor langt tilbake kan dere gå uten at konsekvensene blir uakseptable?
• Akseptabel gjenopprettingstid: Hvor lenge kan tjenesten være utilgjengelig mens den gjenopprettes?

Deretter kan dere velge backupfrekvens, lagringstid og gjenopprettingsmetode. Backup bør oppbevares adskilt fra miljøet den beskytter. Det må også være tydelig om leverandøren gjenoppretter hele løsningen, enkeltfiler eller databasen, og hvem som kontrollerer resultatet etterpå.

Overvåk det brukeren er avhengig av

Serverovervåking kan vise at maskinen kjører, men ikke nødvendigvis at nettsiden fungerer. En profesjonell driftsprofil bør kombinere flere nivåer:

• Tilgjengelighet for sentrale sider og funksjoner.
• Responstid og tydelige avvik fra normal ytelse.
• Feil i applikasjon, database og integrasjoner.
• Ressursbruk som lagringsplass, minne og prosessorkapasitet.
• Utløp eller feil knyttet til sertifikater og domeneoppsett.
• Gjennomføring av planlagte backuper og vedlikeholdsjobber.

Ikke alt skal utløse en alarm til ledelsen. Driftsleverandøren bør filtrere tekniske signaler, undersøke årsaken og eskalere når hendelsen krever en beslutning eller påvirker virksomheten.

Avklar vedlikehold som en løpende tjeneste

Hosting holder infrastrukturen i gang. Vedlikehold sørger for at selve nettløsningen fortsatt fungerer når programvare, integrasjoner og behov endres. Disse oppgavene kan ligge hos samme leverandør, men det bør ikke tas for gitt.

Driftsprofilen bør beskrive hvem som håndterer oppdateringer, kompatibilitetstesting, feilretting, opprydding og kapasitetsvurdering. Angi også hvilke endringer som kan gjennomføres som rutine, og hvilke som krever godkjenning.

For viktige løsninger bør endringer først prøves i et separat testmiljø. Testmiljøet må ligne produksjonsmiljøet nok til at resultatene er relevante, men det bør ikke bruke reelle personopplysninger ukritisk eller sende faktiske e-poster og ordre.

Velg driftsmiljø etter ansvar og behov

Delt hosting, virtuelle servere, administrerte plattformer og skalerbare skymiljøer kan alle være riktige valg. Forskjellen ligger ikke bare i kapasitet, men i hvor mye ansvar virksomheten selv må bære.

Et miljø med mange valgmuligheter kan bli en belastning dersom ingen har ansvar for konfigurasjon, sikkerhet og feilretting. Et mer standardisert miljø kan være bedre når leverandøren kjenner publiseringsløsningen og håndterer hele driftskjeden.

Vurder derfor følgende ved valg av miljø:

• Om løsningen har jevn eller sterkt varierende trafikk.
• Om applikasjonen krever spesielle serverinnstillinger.
• Hvor mye kontroll utviklerne faktisk trenger.
• Om leverandøren tar ansvar for operativsystem og plattform.
• Hvordan test, produksjon og eventuell reserve er skilt.
• Hvor enkelt løsningen kan flyttes eller skaleres senere.

Samle kravene på én side

En nyttig driftsprofil trenger ikke være omfattende. Den kan oppsummeres med følgende punkter:

1. Nettsidens viktigste funksjoner og konsekvensen av avbrudd.
2. Kritiske tidsperioder og forventede trafikktopper.
3. Krav til tilgjengelighet og respons ved feil.
4. Regler for caching og bruk av CDN.
5. Akseptabelt datatap og gjenopprettingstid.
6. Funksjoner og tekniske forhold som skal overvåkes.
7. Ansvar for oppdateringer, testing og vedlikehold.
8. Kontaktpersoner og beslutningsmyndighet ved hendelser.

Gå gjennom profilen når nettsiden får nye funksjoner, integrasjoner eller større trafikk. En enkel nettside kan gradvis bli en sentral arbeidsflate uten at driftsavtalen endres tilsvarende.

Profesjonell webhosting handler derfor mindre om å kjøpe mest mulig kapasitet og mer om å gjøre bevisste valg. Når kravene bygger på virksomhetens reelle konsekvenser, blir det enklere å velge riktig miljø, fordele ansvar og betale for det driftsnivået nettsiden faktisk trenger.