Overvåk det som faktisk må virke: Bygg driften rundt kritiske brukerreiser
En nettside kan svare på overvåkingen og samtidig svikte kundene. Slik kobler dere oppetid, caching, CDN, backup og vedlikehold til funksjonene virksomheten er avhengig av.
En grønn status på serveren betyr ikke nødvendigvis at nettsiden fungerer. Forsiden kan være tilgjengelig fra cache mens kontaktskjemaet feiler. Nettbutikken kan laste raskt, men stoppe i kassen. En innlogget tjeneste kan svare normalt for eksisterende brukere, samtidig som nye brukere ikke får opprettet konto.
Profesjonell drift bør derfor ikke bare måle om serveren er oppe. Den må kontrollere om de viktigste brukerreisene faktisk kan gjennomføres. Det krever at virksomheten definerer hva som er kritisk, overvåker flere lag og avtaler hvem som skal reagere når noe går galt.
Start med konsekvensen, ikke infrastrukturen
Det er lett å begynne med tekniske målinger som prosessorbruk, minne, diskplass og responstid. Slike data er nyttige, men de sier lite om hvilken konsekvens en feil har for virksomheten.
Start heller med å liste opp handlingene nettsiden må støtte. For en bedriftsnettside kan det være å sende inn et kontaktskjema, finne kontaktinformasjon og laste ned produktdokumentasjon. For en nettbutikk kan det være å søke etter et produkt, legge det i handlekurven og fullføre betaling. For en medlemsportal kan innlogging og tilgang til riktig innhold være avgjørende.
Velg deretter et begrenset antall kritiske brukerreiser. Hver reise bør ha en tydelig definisjon av hva som regnes som vellykket. «Nettbutikken virker» er for upresist. «En testbruker kan legge et tilgjengelig produkt i handlekurven og komme frem til betalingssteget» kan kontrolleres.
En enkel prioritering
- Kritisk: Feilen stopper salg, henvendelser, innlogging eller levering av en sentral tjeneste.
- Viktig: Feilen påvirker mange brukere, men det finnes en midlertidig omvei.
- Ordinær: Feilen er synlig eller upraktisk, men stopper ikke en sentral handling.
Denne prioriteringen bør styre både overvåkingen, varslene og forventet reaksjonstid. Hvis alt merkes som kritisk, blir driftsvakten raskt oversvømt av varsler som ikke krever umiddelbar handling.
Overvåk flere lag av samme brukerreise
God overvåking består av flere kontroller som utfyller hverandre. En enkel oppetidsmåling er fortsatt nyttig, men den må ikke stå alene.
1. Kontroller at tjenesten svarer
En ekstern kontroll bør regelmessig hente utvalgte sider fra et sted utenfor driftsmiljøet. Det avdekker blant annet utilgjengelig server, feil i navneoppslag, utløpte sertifikater og problemer i nettverket.
Kontrollen bør ikke bare se etter en vellykket statuskode. Den bør også sjekke at siden inneholder forventet innhold, og at svartiden holder seg innenfor en avtalt grense. En feilmelding kan ellers bli levert med en teknisk vellykket respons.
2. Test selve handlingen
For kritiske funksjoner bør overvåkingen simulere en enkel brukerreise. Det kan være å åpne et skjema, fylle inn testdata og kontrollere at innsendingen blir registrert. I en nettbutikk kan en test legge et produkt i handlekurven og bekrefte at kassen åpnes med riktig innhold.
Testene må utformes slik at de ikke oppretter falske kundehenvendelser, påvirker lagerbeholdningen eller gjennomfører reelle betalinger. Bruk egne testprodukter, testkontoer og tydelig merkede data der det er mulig.
3. Følg med på infrastrukturen
Målinger av kapasitet og feilrater gir nødvendig sammenheng når en brukerreise svikter. Høy belastning på databasen, full disk eller kø i bakgrunnsjobber kan forklare hvorfor en funksjon har blitt treg eller ustabil.
Sett varsler på utvikling over tid, ikke bare absolutte grenser. Diskplassen kan for eksempel vokse jevnt på grunn av logger eller sikkerhetskopier. Da er det bedre å gripe inn før lagringen er full enn å vente på et driftsavbrudd.
Unngå at cache og CDN skjuler feilen
Caching og CDN reduserer lastetid og avlaster serveren. Samtidig kan de gjøre overvåkingen misvisende. En lagret kopi av forsiden kan leveres raskt selv om applikasjonen eller databasen bak ikke fungerer.
Overvåk derfor både den offentlige leveransen og opphavet bak mellomlagringen. Den offentlige kontrollen viser hva brukeren får. En separat kontroll mot applikasjonen viser om systemet fortsatt klarer å generere innhold og behandle dynamiske forespørsler.
Det er særlig viktig å skille mellom statiske og dynamiske deler:
- Produktsider og artikler kan ofte leveres fra cache.
- Handlekurv, kasse, innlogging og personlige sider må normalt håndteres dynamisk.
- Skjemaer kan vises fra cache, mens selve innsendingen er avhengig av applikasjon, database og e-post- eller integrasjonstjenester.
Overvåkingen bør også kontrollere at hurtigbufferen kan tømmes og bygges opp igjen uten feil. Etter en publisering eller teknisk endring kan gamle og nye ressurser ellers bli blandet, slik at brukerne får ødelagte sider selv om serveren er tilgjengelig.
Gjør varsler handlingsrettede
Et varsel som bare sier «nettsiden er nede», sender mottakeren ut på unødvendig leting. Et godt varsel bør opplyse hvilken kontroll som feilet, når feilen startet, om den er bekreftet fra flere steder, og hvilken brukerreise som er berørt.
Varslet bør også peke mot en avtalt første handling. Ved feil i kontaktskjemaet kan det være å kontrollere registrerte innsendinger og sette opp en alternativ kontaktkanal. Ved feil i kassen kan det være å undersøke betalingsintegrasjonen og midlertidig stoppe betalt annonsering.
Lag en enkel varslingsplan med følgende punkter:
- Hvem mottar varslet i og utenfor arbeidstid?
- Hvem avgjør alvorlighetsgrad?
- Hvem kan gjøre endringer i driftsmiljøet?
- Hvem informerer ledelse, kundeservice eller markedsavdeling?
- Når skal en leverandør eller integrasjonspartner kobles inn?
Det bør være mulig å svare på disse spørsmålene uten å lete i gamle e-poster eller være avhengig av én bestemt medarbeider.
Koble backup til overvåkingen
Backup er en viktig del av driften, men en melding om at en jobb er fullført, er ikke nok. Overvåkingen bør kontrollere at nye sikkerhetskopier faktisk blir opprettet, at størrelsen er rimelig, og at kopiene lagres adskilt fra produksjonsmiljøet.
En plutselig svært liten kopi kan tyde på at filer eller databasedata mangler. En uventet stor kopi kan skyldes voksende logger, midlertidige filer eller at gamle sikkerhetskopier blir inkludert på nytt.
Behovet for hyppighet må bestemmes av hvor mye data virksomheten tåler å miste. En innholdsside som endres ukentlig har et annet behov enn en nettbutikk med løpende ordre. Databasen, filene og eventuelle eksterne data må vurderes samlet. Det hjelper lite å gjenopprette databasen hvis nødvendige produktbilder, dokumenter eller konfigurasjoner mangler.
Bruk vedlikehold som forebyggende drift
Vedlikehold bør være en fast arbeidsprosess, ikke en opprydding som gjennomføres når noe allerede har sluttet å virke. Planen bør omfatte oppdateringer, kontroll av logger, opprydding i lagring, gjennomgang av sertifikater, test av varsler og kontroll av kritiske brukerreiser.
Etter hver større endring bør de viktigste testene kjøres på nytt. Det gjelder ikke bare endringer i nettsiden. Nye regler i CDN, justert caching, oppdatering av serverprogramvare eller endret sikkerhetsoppsett kan påvirke funksjoner uten at det er synlig i administrasjonen.
Planlegg også jevnlige gjennomganger av overvåkingen. En test av et gammelt skjema har liten verdi hvis virksomheten nå bruker en ny bestillingsløsning. Overvåkingen må utvikle seg sammen med nettsiden.
Velg driftsmiljø ut fra hva dere kan følge opp
Valget mellom delt hosting, administrert drift, virtuell server, dedikert miljø eller en mer sammensatt skyløsning handler ikke bare om ytelse. Det handler også om ansvarsdeling og operativ kapasitet.
Et fleksibelt miljø gir liten verdi hvis ingen har ansvar for operativsystem, sikkerhetsoppdateringer, database, logger og hendelseshåndtering. Tilsvarende kan en standardisert plattform være et godt valg når virksomheten ønsker tydelig ansvar, forutsigbart vedlikehold og færre komponenter å forvalte selv.
Be om konkrete svar før dere velger løsning:
- Hvilke deler overvåkes hele døgnet?
- Hvem reagerer på feil i applikasjonen, ikke bare på serveren?
- Hvordan håndteres belastningstopper og kapasitetsøkning?
- Hvor lagres sikkerhetskopier, og hvor lenge beholdes de?
- Hvem vedlikeholder cache, CDN, database og serverprogramvare?
- Hvordan varsles virksomheten ved hendelser som påvirker brukerne?
Det viktigste skillet går mellom hva leverandøren teknisk kan levere, og hva som faktisk inngår i den løpende driften. Sørg for at ansvaret er skriftlig avklart.
Lag et lite driftskart
Dere trenger ikke et omfattende styringssystem for å komme i gang. Lag et driftskart med de viktigste brukerreisene i venstre kolonne og avhengighetene deres i høyre: webserver, database, CDN, cache, betalingsløsning, e-post, søk eller andre integrasjoner.
Definer én eller flere kontroller for hver kritiske reise. Angi deretter hvem som mottar varsel, hva første tiltak er, og hvor raskt situasjonen skal vurderes. Gå gjennom kartet etter større endringer og minst når ansvar, leverandører eller sentrale funksjoner endres.
Resultatet er en drift som ser mer enn om serveren svarer. Den følger med på det nettsiden er satt til å gjøre, oppdager feil nærmere brukeren og gir ansvarlige et bedre utgangspunkt for å handle før problemet blir langvarig.
