Gjør webdriften målbar: Kravene som bør stå i driftsavtalen

Kategori: Hosting og drift

En hostingpakke forteller gjerne hvor mye lagring og kapasitet du får. Den sier ofte mindre om hva som faktisk skjer når nettsiden blir treg, en oppdatering feiler eller kundene ikke kommer gjennom kassen. Det er først i slike situasjoner forskjellen mellom serverplass og profesjonell drift blir tydelig.

For virksomheten bør målet være en driftsavtale som gjør leveransen forståelig og kontrollerbar. Den må beskrive hva som overvåkes, hvem som reagerer, hvor raskt feil håndteres, og hvordan nettsiden gjenopprettes. Uten dette kan både kunde og leverandør tro at den andre parten har ansvaret.

Start med nettsidens faktiske betydning

Driftskravene bør ta utgangspunkt i konsekvensene av nedetid og dårlig ytelse. En enkel informasjonsside har andre behov enn en nettbutikk, en bestillingsløsning eller et nettsted som mottar viktige henvendelser.

Avklar blant annet hvilke funksjoner som er forretningskritiske:

• Kan kunder fortsatt kontakte virksomheten hvis et skjema slutter å virke?
• Stopper omsetningen dersom betalingsløsningen er utilgjengelig?
• Er nettsiden avgjørende under kampanjer, arrangementer eller bestemte sesonger?
• Behandles det data som krever særskilt kontroll med lagring og tilgang?
• Finnes det integrasjoner mot økonomi, lager, medlemsregister eller andre systemer?

Svarene gir et bedre grunnlag for valg av driftsmiljø enn generelle merkelapper som standard, premium eller bedriftsløsning.

Definer oppetid før dere diskuterer prosent

Oppetid virker enkelt, men målingen kan være uklar. Det bør stå hva som måles, hvorfra det måles, og hvilke feil som regnes som nedetid. En server kan svare samtidig som forsiden viser en feilmelding, kontaktskjemaet er ødelagt eller nettbutikken ikke kan fullføre kjøp.

En nyttig avtale beskriver derfor tilgjengelighet på flere nivåer. Serveren skal svare, nettsiden skal levere gyldig innhold, og kritiske funksjoner skal fungere. For en nettbutikk kan det bety overvåking av produktsider, handlekurv og kasse. For et bedriftsnettsted kan det være forsiden, en sentral tjenesteside og innsending av skjema.

Planlagt vedlikehold må også avklares. Hvilke tidsrom kan brukes, hvor tidlig skal kunden varsles, og hvilke arbeider kan gjennomføres uten forhåndsgodkjenning? Hvis slike forhold ikke er definert, blir oppetidstallet vanskelig å tolke.

Overvåking må føre til handling

Overvåking har liten verdi hvis varsler bare samles i et system ingen følger med på. Driftsavtalen bør angi hvem som mottar varsler, når de skal undersøkes, og hvordan saken eskaleres hvis første tiltak ikke løser problemet.

God overvåking dekker mer enn om serveren er på. Aktuelle kontrollpunkter er:

• Responstid og tilgjengelighet fra utsiden av driftsmiljøet.
• Feilkoder og tomme eller ufullstendige svar.
• Ressursbruk som prosessor, minne og lagringsplass.
• Utløp eller feil knyttet til sertifikater.
• Bakgrunnsjobber som ikke blir kjørt.
• Kritiske brukerflyter som skjema, innlogging eller betaling.

Det bør også finnes terskler for gradvis forverring. En nettside kan bli stadig tregere uten å være helt nede. Overvåking av utviklingen gjør det mulig å rydde opp før kundene møter en full driftsstans.

Beskriv caching som en del av løsningen

Caching reduserer belastningen ved å gjenbruke ferdig generert innhold. Det kan gi raskere sider og gjøre nettstedet mer robust under trafikktopper. Samtidig kan feil caching vise gammelt innhold, feil priser eller informasjon beregnet på en annen bruker.

Avtalen bør beskrive hvilke deler av nettstedet som kan mellomlagres, hvor lenge innholdet beholdes, og hva som tømmer cachen. Publisering, produktendringer og kampanjer må slå gjennom på en forutsigbar måte.

Dynamiske områder krever særskilt kontroll. Handlekurv, kasse, innloggede sider og personlige visninger skal normalt ikke behandles som offentlige innholdssider. Ved feilsøking må leverandøren også kunne skille mellom problemer i applikasjonen og gammelt innhold i ett av flere cachelag.

Avklar hva CDN-et skal løse

Et CDN distribuerer statiske filer gjennom et nettverk av leveringspunkter. Det kan redusere lastetid for geografisk spredte brukere og avlaste det primære driftsmiljøet. Det kan også bidra til å håndtere enkelte typer uønsket trafikk.

CDN bør likevel ikke brukes som et plaster på en treg eller feilkonfigurert nettside. Hvis opprinnelsesserveren bruker lang tid på å lage sidene, vil ikke alle forespørsler kunne løses i distribusjonslaget.

Driftsavtalen bør angi hvem som administrerer oppsettet, cache-reglene og eventuelle sikkerhetsfunksjoner. Det må også være klart hvordan CDN-et kobles forbi under feilsøking, og hvordan innhold tømmes ved hasteendringer. Uklart eierskap kan gjøre en enkel feil unødvendig langvarig.

Still krav til backup og tilbakeføring

At det tas backup er ikke nok. Virksomheten må vite hva som sikkerhetskopieres, hvor ofte det skjer, hvor lenge kopiene beholdes, og om de lagres adskilt fra produksjonsmiljøet. En kopi på samme system beskytter dårlig dersom hele miljøet blir utilgjengelig.

Det er nyttig å skille mellom hvor mye data virksomheten kan tåle å miste, og hvor raskt tjenesten må være tilbake. En nettbutikk med løpende ordre kan trenge hyppigere kopier enn et nettsted som oppdateres noen ganger i måneden.

Avtalen bør også svare på praktiske spørsmål:

• Inngår tilbakeføring i driftsprisen, eller faktureres den separat?
• Hvem kan bestille en gjenoppretting?
• Kan enkeltfiler eller databasedata hentes tilbake uten å overskrive alt?
• Hvordan kontrolleres det at kopiene faktisk kan brukes?
• Hvor ofte testes en full tilbakeføring?

En gjennomført gjenopprettingstest gir langt større trygghet enn en statusmelding om at backupjobben er fullført.

Skill mellom serverdrift og vedlikehold av nettsiden

Mange konflikter oppstår fordi ordet drift brukes om forskjellige tjenester. Leverandøren kan mene vedlikehold av serveren, mens kunden forventer oppdatering og feilretting i publiseringsløsningen.

Avtalen bør skille tydelig mellom driftsmiljø, applikasjon og innhold. Serverdrift omfatter typisk kapasitet, operativsystem, nettverk og grunnleggende sikkerhetsoppdateringer. Applikasjonsvedlikehold kan omfatte publiseringsløsning, utvidelser, tema, integrasjoner og kompatibilitetstesting. Innholdsarbeid er vanligvis en egen leveranse.

Oppdateringer bør først prøves i et separat testmiljø når konsekvensen av feil er betydelig. Det må være mulig å kontrollere sentrale funksjoner før endringen går til produksjon, og det bør finnes en plan for å rulle tilbake.

Velg driftsmiljø etter risiko og arbeidsform

Delt hosting kan være tilstrekkelig for en enkel nettside med jevn og moderat trafikk. Et mer isolert eller skalerbart miljø kan være riktig når nettstedet har store trafikktopper, tunge integrasjoner, nettbutikkfunksjoner eller krav til strengere tilgangskontroll.

Valget handler ikke bare om kapasitet. Vurder også hvor lett miljøet kan kopieres til testing, hvordan endringer flyttes mellom miljøer, hvilke logger som er tilgjengelige, og hvor mye leverandøren faktisk forvalter. En teknisk fleksibel løsning kan bli krevende hvis virksomheten selv må håndtere alle oppdateringer, varsler og feil.

Be om en konkret forklaring på hva som skjer ved økt belastning. Skalerer løsningen automatisk, må kapasitet bestilles, eller vil nettstedet bare bli tregere? Svaret bør være forståelig for den som har driftsansvaret, ikke bare for serverteknikeren.

Avtal håndteringen av feil

Når noe går galt, trenger virksomheten en kjent kontaktvei. Det bør fremgå hvordan kritiske hendelser meldes utenfor vanlig arbeidstid, hvilke alvorlighetsgrader som brukes, og når kunden kan forvente første tilbakemelding.

Første tilbakemelding er ikke det samme som ferdig løsning. Derfor bør avtalen skille mellom bekreftelse, påbegynt feilsøking, midlertidig tiltak og permanent retting. For alvorlige hendelser bør kunden få korte statusoppdateringer underveis, også når årsaken ennå ikke er kjent.

Etter en større feil er det nyttig med en enkel gjennomgang av årsak, konsekvens og tiltak. Målet er ikke å plassere skyld, men å hindre gjentakelse og forbedre rutiner, overvåking eller teknisk oppsett.

En praktisk kontroll før avtalen signeres

1. Kartlegg kritiske funksjoner: Beskriv hva kundene må kunne gjøre på nettsiden.
2. Definer målingen: Avklar hvordan tilgjengelighet, responstid og funksjoner overvåkes.
3. Fordel ansvaret: Skill mellom hosting, serverdrift, applikasjonsvedlikehold og innhold.
4. Kontroller backupen: Be om rutiner for oppbevaring, tilgang og testet tilbakeføring.
5. Beskriv feilflyten: Avtal kontaktpunkt, alvorlighetsgrader, respons og statusoppdateringer.
6. Planlegg endringer: Fastsett hvordan oppdateringer testes, godkjennes og kan rulles tilbake.
7. Vurder behovet jevnlig: Oppdater driftskravene når nettstedet får nye funksjoner eller større forretningsverdi.

Profesjonell webdrift kjennetegnes ikke av flest mulig tekniske begreper. Den kjennetegnes av tydelig ansvar, relevante målinger og rutiner som fungerer når noe avviker. En god driftsavtale gjør forventningene konkrete før problemet oppstår.