Grønt statuslys er ikke nok: Overvåk nettsiden slik kundene bruker den

Kategori: Hosting og drift

Oppetid blir ofte målt ved å kontrollere om forsiden svarer. Det er nyttig, men gir et ufullstendig bilde. Nettsiden kan være tilgjengelig samtidig som kontaktskjemaet feiler, produktdata ikke oppdateres, innloggingen stopper eller en betalingsfunksjon er utilgjengelig.

Profesjonell webdrift bør derfor overvåke tjenesten slik kundene faktisk bruker den. Det krever mer enn et grønt statuslys for webserveren. Dere må følge hele leveransekjeden fra DNS, CDN og cache til applikasjon, database og eksterne integrasjoner.

Oppetid må knyttes til en konkret funksjon

Spørsmålet «Er nettsiden oppe?» er for upresist. En bedre start er å spørre hvilke funksjoner som må virke for at nettstedet skal gjøre jobben sin.

For en konsulentbedrift kan dette være at tjenestesider lastes, kontaktskjemaet tar imot henvendelser og kvitteringen vises. For en nettbutikk kan det være produktsøk, lagerstatus, handlekurv og betaling. For en medlemsportal kan innlogging og tilgang til beskyttet innhold være avgjørende.

Lag en kort liste over virksomhetskritiske kundereiser. Prioriter dem etter konsekvensen av feil:

• Kritisk: Feilen stopper salg, henvendelser eller tilgang til en betalt tjeneste.
• Alvorlig: En viktig funksjon er svekket, men kunden har en alternativ vei.
• Begrenset: Feilen påvirker innhold eller funksjoner som kan vente til ordinær arbeidstid.

Denne prioriteringen bør styre både overvåking, varsling og responstid. Det er liten verdi i å vekke noen om natten fordi et lite brukt bilde mangler, mens et ødelagt bestillingsskjema blir liggende uoppdaget til neste dag.

Overvåk leveransen i flere lag

God overvåking består av flere kontroller som utfyller hverandre. Hvert lag svarer på ulike spørsmål og gjør det lettere å finne årsaken når noe går galt.

1. Ekstern tilgjengelighet

En ekstern kontroll besøker nettsiden utenfra og måler om den svarer, hvor lang tid svaret tar, og om riktig innhold kommer tilbake. Kontrollen bør ikke bare se etter en vellykket statuskode. En feilside kan også returneres som et tilsynelatende vellykket svar.

La derfor kontrollen se etter et bestemt tekstelement eller en annen forventet del av siden. Da oppdager dere flere tilfeller der serveren svarer, men applikasjonen leverer feil innhold.

2. Applikasjon og database

En cachet forside kan fungere selv om WordPress, databasen eller en annen publiseringsløsning har stoppet. Overvåkingen bør derfor også teste en kontroll som går til selve applikasjonen.

En slik helsesjekk kan blant annet kontrollere at applikasjonen starter, at databasen svarer, og at nødvendige lagringsområder er tilgjengelige. Den bør være rask og begrenset, slik at overvåkingen ikke skaper unødig belastning.

3. Kritiske kundereiser

En syntetisk test etterligner handlingene til en bruker. Den kan åpne en landingsside, fylle ut et kontrollert testskjema og kontrollere at riktig bekreftelse vises. I en nettbutikk kan den legge et testprodukt i handlekurven og kontrollere at kassen åpnes, uten å gjennomføre et reelt kjøp.

Testene må utformes slik at de ikke sender falske henvendelser, påvirker lageret eller forstyrrer rapporteringen. Bruk egne testdata og avklar hvordan de skal filtreres bort fra ordinære arbeidsprosesser.

4. Eksterne avhengigheter

Mange nettsteder er avhengige av tjenester utenfor selve driftsmiljøet. Det kan være betaling, søk, kart, video, CRM, nyhetsbrev eller produktdata. Nettsiden kan være teknisk tilgjengelig mens en slik integrasjon har sluttet å virke.

Kartlegg hvilke eksterne tjenester hver kritiske kundereise trenger. Overvåk deretter resultatet av integrasjonen, ikke bare om en ekstern server svarer. For et skjema er det for eksempel viktigere å kontrollere at henvendelsen blir registrert på riktig sted enn at integrasjonen returnerer et teknisk svar.

CDN og caching kan både hjelpe og skjule

CDN og caching reduserer lastetid og belastning på opprinnelsesserveren. De kan også holde deler av nettstedet tilgjengelig under korte driftsproblemer. Samtidig kan de skjule feil.

Hvis overvåkingen bare besøker en cachet side, kan alt se normalt ut mens den underliggende applikasjonen er nede. Dere trenger derfor kontroller av både det kundene mottar gjennom CDN-et og det opprinnelige driftsmiljøet.

Følg også med på om feil innhold blir mellomlagret. En midlertidig feilside, gammel pris eller utdatert produktstatus kan bli liggende i cache lenger enn ønsket. Rutinen for hendelser bør derfor beskrive når cache skal tømmes, hvem som kan gjøre det, og hvordan resultatet kontrolleres etterpå.

Unngå å slå av all caching som første reaksjon. Det kan øke belastningen på en allerede presset server. Avgrens heller problemet til bestemte sider, innholdstyper eller cachelag.

Varsler skal føre til handling

For mange varsler gjør det vanskeligere å oppdage de viktige. Overvåkingen bør redusere støy, ikke produsere en kontinuerlig strøm av tekniske meldinger.

Et nyttig varsel bør fortelle:

• Hvilken funksjon som feiler.
• Om feilen påvirker kunder eller bare en intern kontroll.
• Når feilen startet og om den er gjentatt.
• Hvilke tekniske lag som fortsatt fungerer.
• Hvem som har ansvar for å undersøke saken.
• Hva som bør kontrolleres først.

Legg inn en kort forsinkelse eller krav om gjentatte feil der det er forsvarlig. Et enkelt tregt svar behøver ikke å utløse full beredskap. For en kritisk betalings- eller innloggingsfunksjon kan terskelen derimot være lavere.

Lag en enkel feilmatrise

En feilmatrise gjør det lettere å gå fra symptom til sannsynlig årsak. Den trenger ikke være omfattende. Start med de vanligste kombinasjonene.

• Forsiden virker, men dynamiske sider feiler: Kontroller applikasjon, database og cache.
• Nettsiden virker internt, men ikke eksternt: Kontroller DNS, CDN, sertifikat og nettverkstilgang.
• Sidene lastes, men skjemaet feiler: Kontroller validering, e-postlevering, CRM-integrasjon og feillogger.
• Bare enkelte besøkende opplever feil: Kontroller geografiske CDN-noder, enheter, nettlesere og personvernvalg.
• Alt blir gradvis tregere: Kontroller ressursbruk, databaseforespørsler, køer, lagringsplass og eksterne tjenester.

Matrisen bør ligge sammen med kontaktinformasjon, tilgangsrutiner og beslutningsmyndighet. Når driften svikter, er det feil tidspunkt å lete etter hvem som kan tømme cache eller starte en tjeneste på nytt.

Backup må kobles til hendelsestypen

Backup løser ikke alle driftsfeil. En treg integrasjon, feil CDN-konfigurasjon eller utløpt tilgang blir sjelden reparert ved å gjenopprette hele nettstedet. Ukritisk tilbakeføring kan dessuten overskrive nye bestillinger, brukere eller redaksjonelle endringer.

Beskriv derfor hva som skal gjenopprettes i ulike situasjoner. Det kan være en enkelt fil, en database, opplastet innhold, konfigurasjon eller hele miljøet. Avklar også hvilke data som kan gå tapt ved tilbakeføring, og hvem som kan godkjenne dette.

Før større vedlikehold bør dere kontrollere at relevant backup er fullført og tilgjengelig. Etter en tilbakeføring må de kritiske kundereisene testes, ikke bare forsiden.

Vedlikehold må vises i overvåkingen

Oppdateringer, databasearbeid og endringer i infrastrukturen kan utløse varsler. Ikke løs dette ved å slå av all overvåking. Registrer heller et avgrenset vedlikeholdsvindu og behold kontrollene som kan avsløre uventede konsekvenser.

Etter vedlikehold bør ansvarlig person kontrollere applikasjonen, cache, CDN og de viktigste kundereisene. Følg også med en periode etterpå. Enkelte feil oppstår først når cache skal bygges opp igjen, trafikken øker eller en planlagt jobb starter.

Velg driftsmiljø etter hvor godt det kan observeres

Kapasitet og pris er viktige når dere velger hosting, men driftsmiljøet må også gi nødvendig innsikt. Dere bør kunne undersøke ressursbruk, responstid, feil, planlagte jobber og endringer i infrastrukturen.

Et administrert miljø kan være riktig når virksomheten ønsker at leverandøren håndterer operativ drift og plattformvedlikehold. Et mer fleksibelt miljø kan passe når løsningen har spesielle krav og dere har kompetanse til å forvalte det. Uansett modell må ansvarsdelingen være tydelig.

Avklar hvem som følger opp varsler, hvem som kan endre CDN og cache, hvem som vedlikeholder applikasjonen, og hvem som kontakter eksterne leverandører. Overvåking uten tydelig eierskap registrerer bare at problemet varer.

Start med de tre viktigste kontrollene

Dere trenger ikke overvåke alt fra første dag. Begynn med én ekstern tilgjengelighetskontroll, én kontroll av applikasjonen utenom cache og én syntetisk test av den viktigste kundereisen.

Test deretter varslingskjeden ved å fremprovosere en ufarlig feil i et kontrollert miljø. Bekreft at riktig person mottar et forståelig varsel og vet hva som skal gjøres. Gjenta øvelsen når kundereiser, integrasjoner eller ansvar endres.

Målet er ikke flest mulig målepunkter. Målet er å oppdage reelle problemer tidlig, forstå hvor de oppstår og få riktig person til å handle før feilen utvikler seg til tapt salg eller tapte henvendelser.