Overvåking som fører til handling: Slik lager dere en driftsplan for nettsiden

Kategori: Hosting og drift

Nettsiden kan svare med status «ok» og likevel være ubrukelig. Forsiden åpnes, men kontaktskjemaet sender ingenting. Produktsidene virker, mens kassen stopper. En cache viser gammelt innhold etter publisering, eller en feil hos CDN-leverandøren rammer bare enkelte besøkende.

Derfor bør profesjonell overvåking handle om mer enn å sjekke om serveren svarer. Målet er å oppdage feil som påvirker kundene, varsle riktig person og gi denne personen nok informasjon til å handle. Det krever en enkel, men gjennomtenkt driftsplan.

Start med tjenestene nettsiden faktisk leverer

Før dere velger måleverktøy og varslingskanaler, bør dere definere hva som må fungere. Ta utgangspunkt i brukerens oppgaver, ikke bare infrastrukturen.

For et vanlig bedriftsnettsted kan de viktigste tjenestene være:

• Forsiden og sentrale landingssider skal kunne åpnes.
• Kontaktskjemaet skal kunne sendes og leveres til riktig mottaker.
• Publisert innhold skal bli synlig uten feil i cache eller CDN.
• Innlogging og redigering skal fungere for redaktørene.
• Backup skal gjennomføres og kunne brukes ved gjenoppretting.

For en nettbutikk kommer blant annet produktsøk, lagerstatus, handlekurv, betaling og ordrebekreftelse i tillegg. Disse funksjonene bør ikke behandles som én samlet tjeneste. Det er fullt mulig at butikken ser normal ut samtidig som kundene ikke får betalt.

Lag derfor en kort liste over kritiske brukerreiser. Prioriter dem etter konsekvensen ved feil. En betalingsfeil bør normalt utløse raskere oppfølging enn en treg side i et gammelt artikkelarkiv.

Bygg overvåkingen i flere lag

Ingen enkelt måling gir et riktig bilde av driften. En robust løsning kombinerer flere typer kontroll, slik at dere både ser symptomet kunden møter og den tekniske årsaken bak.

1. Ekstern tilgjengelighet

En ekstern kontroll bør jevnlig åpne nettsiden fra utsiden av driftsmiljøet. Den kan avdekke feil i DNS, sertifikater, CDN, brannmur, server og applikasjon. Kontrollen bør ikke bare se etter en vellykket statuskode. Den bør også kontrollere at siden inneholder forventet innhold og svarer innenfor et akseptabelt tidsrom.

Bruk gjerne målinger fra flere geografiske steder dersom kundene befinner seg i ulike områder. Da blir det lettere å oppdage feil som bare påvirker enkelte nettverk eller deler av CDN-et.

2. Kritiske brukerreiser

Sett opp automatiske tester som etterligner viktige handlinger. En slik test kan åpne et skjema, fylle ut feltene og kontrollere at innsendingen blir registrert. For en nettbutikk kan testen legge et testprodukt i handlekurven og gå frem til betalingssteget uten å gjennomføre en reell betaling.

Testene bør være stabile og begrensede. Dersom de er for omfattende, kan små designendringer skape falske alarmer. Test det som viser at tjenesten virker, ikke hver eneste detalj i grensesnittet.

3. Applikasjon og server

Interne målinger kan vise belastning på prosessor, minne, lagring, database og bakgrunnsjobber. De kan også fange opp applikasjonsfeil, køer som stopper og uvanlig mange trege forespørsler.

Slike data er nyttige for feilsøking, men bør tolkes i sammenheng med brukeropplevelsen. Høy belastning er ikke nødvendigvis en hendelse dersom nettsiden fortsatt fungerer raskt og stabilt. Motsatt kan en alvorlig funksjonsfeil oppstå uten at serveren ser presset ut.

4. Caching og CDN

Cache og CDN kan gi raskere levering og avlaste serveren, men de legger også til flere feilkilder. Overvåkingen bør vise om forespørsler blir levert fra cache, om opprinnelsesserveren svarer, og om feil blir lagret eller spredd gjennom mellomlagringen.

Det bør finnes en dokumentert metode for å tømme relevant cache uten å fjerne mer enn nødvendig. Etter publisering eller vedlikehold kan en enkel kontroll sammenligne innholdet som vises eksternt, med innholdet applikasjonen faktisk leverer.

5. Backup og planlagte jobber

Det holder ikke å overvåke at en backupprosess startet. Kontroller at den ble fullført, at filen har forventet innhold, og at kopien finnes på riktig lagringssted. Feil i sikkerhetskopiering bør varsles før dere trenger kopien.

Det samme gjelder planlagte jobber som sender e-post, synkroniserer produkter, rydder data eller oppdaterer søkeindekser. En jobb som ikke kjører, kan skape store driftsproblemer uten at nettsiden går ned.

Varsle etter konsekvens, ikke etter hvert avvik

For mange varsler gjør overvåkingen mindre nyttig. Når mindre avvik, korte responstidstopper og kritiske feil havner i samme kanal, lærer mottakerne raskt å overse dem.

Lag en enkel varslingsmatrise med tre nivåer:

• Kritisk: En sentral brukerreise er utilgjengelig, betaling stopper, eller store deler av nettstedet er nede. Varslet må nå en person som kan starte håndtering med en gang.
• Haster: Feilen påvirker en viktig funksjon, men det finnes en midlertidig løsning eller begrenset påvirkning. Oppfølging bør skje innen avtalt arbeidstid eller beredskap.
• Bør undersøkes: Kapasiteten nærmer seg en grense, en planlagt jobb feiler, eller ytelsen utvikler seg negativt. Dette registreres som en oppgave før det blir en hendelse.

Definer hvem som mottar hvert nivå, hvor raskt det skal bekreftes, og hvem som overtar dersom første mottaker ikke svarer. Varsling uten tydelig eierskap er bare en teknisk beskjed.

Gi hvert kritisk varsel en handlingsplan

Når alarmen går, er det dårlig tid for å finne ut hvem som har tilgang til driftsmiljøet eller hvordan CDN-et settes i bypass. Lag korte handlingsplaner for de mest sannsynlige hendelsene.

En god handlingsplan bør svare på:

1. Hva har overvåkingen registrert?
2. Hvordan bekrefter vi om feilen er reell?
3. Hvilke systemer og leverandører kan være berørt?
4. Hvilke trygge strakstiltak kan gjennomføres?
5. Når skal saken eskaleres, og til hvem?
6. Hvordan informerer vi interne brukere eller kunder?
7. Hvordan dokumenterer vi hendelsen etterpå?

Planen bør være konkret. «Undersøk serveren» hjelper lite. «Kontroller ekstern test, applikasjonslogg, databaseforbindelse og status for CDN før omstart vurderes» gir en tydeligere start.

Unngå automatiske omstarter som standardløsning på alle problemer. De kan skjule årsaken, skape nye feil og fjerne informasjon som trengs i feilsøkingen.

Koble vedlikehold til overvåkingen

Oppdateringer, konfigurasjonsendringer og publiseringer bør merkes i driftsoversikten. Da kan dere se om en feil eller ytelsesendring oppstod rett etter et bestemt tiltak.

Før planlagt vedlikehold bør dere avklare hvilke varsler som skal dempes, og hvilke som fortsatt må være aktive. En vedlikeholdsperiode skal ikke gjøre overvåkingen blind. Tester av betaling, innlogging eller integrasjoner kan fortsatt avdekke feil som ikke var forventet.

Etter vedlikehold bør kritiske brukerreiser kontrolleres før arbeidet regnes som ferdig. Det er ikke nok at oppdateringen ble installert uten tekniske feilmeldinger.

Bruk behovene til å velge driftsmiljø

Overvåkingsplanen gjør det enklere å vurdere hosting. I stedet for å sammenligne lagringsplass og markedsførte kapasitetsnivåer kan dere stille konkrete driftskrav.

Undersøk blant annet om driftsmiljøet gir:

• Innsyn i logger, ressursbruk og applikasjonsfeil.
• Støtte for ekstern overvåking og automatiske helsesjekker.
• Kontroll over cache, CDN og nødvendige unntak.
• Separate miljøer for testing og produksjon.
• Automatisert backup med kopier adskilt fra produksjonsmiljøet.
• En tydelig prosess for eskalering ved alvorlige hendelser.
• Nok kapasitet til normal trafikk og forventede topper.

Et rimelig driftsmiljø kan bli kostbart dersom feilsøking krever manuell leting, tilgangene er uklare eller leverandørene peker på hverandre. Det riktige miljøet er det som støtter kravene til tjenesten og gjør den mulig å drifte på en kontrollert måte.

Gå gjennom planen jevnlig

Nettsider endrer seg. Nye skjemaer, integrasjoner, betalingsmetoder og innholdsprosesser kan gjøre gamle tester utilstrekkelige. Sett derfor av faste tidspunkt til å kontrollere at overvåkingen fortsatt dekker de viktigste brukerreisene.

Se også på varslene fra perioden. Hvilke var reelle? Hvilke skapte støy? Oppdaget kundene feil før dere gjorde det? Ble et varsel liggende fordi ansvaret var uklart? Svarene gir konkrete forbedringspunkter.

Profesjonell drift handler ikke om å love at feil aldri skjer. Den handler om å oppdage dem tidlig, begrense konsekvensene og gjenopprette normal drift på en forutsigbar måte. Overvåking får først verdi når den er koblet til prioriteringer, ansvar og handling.