Bestill driftsnivået før serveren: Slik setter dere krav til profesjonell webhosting

Kategori: Hosting & drift

Valg av webhosting starter ofte med lagringsplass, prosessorkraft og pris. Det er sjelden der den viktigste forskjellen ligger. For en bedrift er det mer nyttig å avklare hvor kritisk nettsiden er, hvor raskt feil må håndteres, og hvor mye data virksomheten tåler å miste.

Først når disse behovene er tydelige, kan dere vurdere om driftsmiljøet, rutinene og leverandørens ansvar faktisk er godt nok. Målet er ikke å kjøpe mest mulig kapasitet, men å bestille et driftsnivå som passer virksomheten.

Start med konsekvensen av nedetid

En presentasjonsside, en nettbutikk og en innlogget kundeportal har ulike krav. Hvis alle behandles likt, ender virksomheten gjerne med enten unødvendig høye kostnader eller for svak beredskap.

Beskriv derfor hva som skjer dersom løsningen er utilgjengelig i fem minutter, én time og én arbeidsdag. Vurder blant annet:

• Om kunder mister muligheten til å bestille, betale eller kontakte bedriften.
• Om ansatte blir hindret i å gjøre jobben sin.
• Om nedetid påvirker aktive kampanjer eller viktige lanseringer.
• Om utilgjengelighet kan skade tillit eller skape ekstra arbeid for kundeservice.
• Om data kan gå tapt mens løsningen er nede.

Denne vurderingen gir et bedre beslutningsgrunnlag enn en generell formulering om at nettsiden må være stabil. Den gjør det også enklere å prioritere mellom oppetid, responstid, gjenoppretting og kostnad.

Gjør oppetid til et presist krav

Oppetid oppgis gjerne som en prosent, men prosenttallet alene sier lite. Dere må vite hva som måles, hvor det måles fra, og hvilke hendelser som holdes utenfor.

Avklar om tilgjengelighet betyr at serveren svarer, at forsiden kan åpnes, eller at en viktig funksjon faktisk virker. En nettbutikk kan levere en teknisk respons samtidig som handlekurven eller betalingen feiler. Da er serveren oppe, men tjenesten er ikke tilgjengelig for kunden.

Et nyttig tilgjengelighetskrav bør beskrive:

• Hvilke sider eller funksjoner som skal kontrolleres.
• Hvor ofte kontrollen skal gjennomføres.
• Hvordan planlagt vedlikehold behandles.
• Når et avvik regnes som startet og avsluttet.
• Hvem som mottar varsel og har ansvar for oppfølging.
• Hvordan oppetid og hendelser rapporteres.

Forretningskritiske brukerreiser bør overvåkes separat. Det kan være innsending av et skjema, innlogging eller et testkjøp frem til betalingssteget. Da måles det kundene faktisk er avhengige av.

Fastsett hvor raskt dere må være tilbake

To krav er særlig viktige når noe har gått galt: hvor lang tid gjenopprettingen kan ta, og hvor mye data virksomheten kan tåle å miste.

Gjenopprettingstid beskriver hvor lenge tjenesten kan være utilgjengelig før den må være tilbake i akseptabel drift. Gjenopprettingspunkt beskriver hvor langt tilbake i tid data kan hentes fra.

En enkel bedriftsnettside kan kanskje gjenopprettes fra nattens sikkerhetskopi. For en nettbutikk kan det innebære tap av bestillinger, kundedata eller lagerendringer. Da kan det være nødvendig med hyppigere kopiering av databasen eller en løsning som håndterer transaksjonsdata separat.

Sett kravene per løsning, ikke som én felles standard for hele virksomheten. Et praktisk eksempel kan være at en innholdsside tåler gjenoppretting neste arbeidsdag, mens en bestillingsløsning må prioriteres umiddelbart. Tallene må bestemmes ut fra reelle konsekvenser, ikke hva en standardpakke tilfeldigvis tilbyr.

Skill mellom backup og gjenoppretting

At en leverandør tar backup, betyr ikke automatisk at nettsiden kan gjenopprettes raskt. Sikkerhetskopien må være komplett, tilgjengelig og mulig å bruke når produksjonsmiljøet har problemer.

Be om tydelige svar på følgende:

• Hvor ofte filer og database sikkerhetskopieres.
• Hvor lenge kopiene beholdes.
• Om kopiene lagres adskilt fra produksjonsmiljøet.
• Om gjenoppretting av én fil, databasen eller hele løsningen er mulig.
• Hvem som kan bestille en gjenoppretting.
• Hvor lang tid en normal gjenoppretting forventes å ta.
• Om tilbakeføring testes regelmessig.

En ubrukt backupordning gir falsk trygghet. Gjennomfør derfor planlagte gjenopprettingstester. Testen bør dokumentere hvilken kopi som ble brukt, hvor lang tid arbeidet tok, og om nettsiden fungerte etterpå.

Definer hvordan caching skal styres

Caching kan redusere belastningen på serveren og gi raskere sider, men krever tydelige regler. Det gjelder særlig løsninger med innlogging, handlekurv, personlige priser eller innhold som endres ofte.

Driftsoppsettet kan ha flere lag med mellomlagring: i nettleseren, i en CDN-tjeneste, på webserveren og i selve publiseringsløsningen. Hvis ingen har oversikt over lagene, kan gammelt innhold bli liggende eller dynamiske sider bli lagret feil.

Avklar derfor:

• Hvilke sidetyper som kan mellomlagres.
• Hvilke informasjonskapsler eller innlogginger som skal omgå cache.
• Hvor lenge ulike ressurser skal beholdes.
• Hvordan cache tømmes ved publisering og feilretting.
• Hvem som kan endre reglene.
• Hvordan dere kontrollerer at sensitivt eller personlig innhold ikke mellomlagres.

Cache bør behandles som en del av applikasjonens funksjon, ikke bare som en bryter leverandøren slår på.

Bruk CDN når behovet er tydelig

Et CDN kan levere statiske ressurser fra flere geografiske plasseringer og redusere trafikken mot det primære driftsmiljøet. Det kan også bidra til å håndtere trafikktopper og filtrere enkelte typer uønsket trafikk.

Behovet avhenger av hvor brukerne befinner seg, hvor tunge ressursene er, og hvor sårbar løsningen er for belastning. En nettside med et lokalt publikum og få mediefiler har andre behov enn en internasjonal tjeneste med mye video, bilder eller nedlastbart innhold.

CDN-et må inngå i driftsansvaret. Noen må forvalte sertifikater, cache-regler, tilgang, feilsøking og tømming av innhold. Hvis leverandøren av driftsmiljøet og den som styrer CDN-et peker på hverandre ved feil, blir løsningen vanskeligere å drifte.

Velg miljø etter ansvar, ikke produktnavn

Begreper som sky, dedikert server og administrert hosting sier ikke nødvendigvis hvem som gjør hva. Det avgjørende er hvordan ansvaret er fordelt.

For hvert alternativ bør dere avklare hvem som håndterer:

• Operativsystem, webserver og database.
• Sikkerhetsoppdateringer og løpende feilretting.
• Publiseringsløsning, utvidelser og integrasjoner.
• Skalering av kapasitet.
• Sertifikater, domenekonfigurasjon og CDN.
• Overvåking, varsling og hendelseshåndtering.
• Backup, gjenoppretting og dokumentasjon.

Et administrert miljø kan være riktig når bedriften vil kjøpe både teknologi og operativt ansvar. Et mer selvbetjent miljø kan passe når virksomheten har intern kompetanse, gode rutiner og kapasitet til å følge opp hendelser. Lav serverpris er ikke nødvendigvis lav driftskostnad dersom mye arbeid må utføres internt.

Planlegg vedlikehold uten å gjøre produksjon til testmiljø

Profesjonell drift handler også om hvordan endringer gjennomføres. Oppdateringer bør testes i et eget miljø når de kan påvirke funksjonalitet, integrasjoner eller kundereiser.

En enkel vedlikeholdsrutine bør angi:

1. Hvilke oppdateringer som kan installeres automatisk.
2. Hvilke endringer som krever test og godkjenning.
3. Når vedlikehold normalt utføres.
4. Hvilke kontroller som gjøres etter endringen.
5. Hvordan løsningen tilbakeføres hvis noe feiler.
6. Hvordan berørte personer informeres.

Det bør også være mulig å håndtere kritiske feil uten å vente på neste ordinære vedlikeholdsvindu. Rutinen må derfor skille mellom planlagt vedlikehold og hasteendringer.

Samle kravene i en driftsmatrise

Før dere velger leverandør eller driftsplattform, kan kravene samles i en kort driftsmatrise. Lag én oppføring for hver nettside eller digitale tjeneste.

Matrisen bør minst inneholde:

• Tjenestens eier og tekniske kontakt.
• Viktigste brukerreiser.
• Konsekvens ved kort og langvarig nedetid.
• Krav til tilgjengelighet og responstid ved feil.
• Akseptabel gjenopprettingstid og datatap.
• Backupfrekvens og oppbevaring.
• Behov for caching, CDN og skalerbar kapasitet.
• Vedlikeholdsvindu og krav til testmiljø.
• Ansvar for overvåking, varsling og feilretting.

Bruk matrisen både ved innkjøp og i den løpende leverandøroppfølgingen. Da blir det mulig å sammenligne alternativer på faktisk leveranse, ikke bare tekniske spesifikasjoner.

Følg opp driftsnivået over tid

Behovene endrer seg når nettsiden får flere integrasjoner, mer trafikk eller større betydning for salget. Gjennomgå derfor driftskravene etter større endringer og med faste mellomrom.

Se på hendelser, gjenopprettingstester, ytelsesproblemer og planlagte aktiviteter. Kontroller også om kontaktpersoner, tilganger og ansvar fortsatt er riktige. En driftsavtale som ikke følger løsningen, mister gradvis verdi.

Profesjonell webhosting handler til slutt om forutsigbarhet. Virksomheten skal vite hva som overvåkes, hvem som reagerer, hvor raskt feil håndteres, og hvordan tjenesten kommer tilbake. Når dette er definert før serveren velges, blir driftsmiljøet et bevisst valg fremfor en tilfeldig teknisk pakke.