Hvem merker det først når tjenesten din er nede, du eller leverandøren?
Krev at driftsleverandøren oppdager feil med automatiske alarmer, ikke via klagende kunder. Grunnlaget er overvåking av oppetid, feilrater, responstider og de kritiske forretningsfunksjonene, en varslingskjede med tydelig plassert ansvar også utenfor kontortid, og en hendelsesprosess som gir deg status underveis og dokumentert læring etterpå.
Det finnes to måter å få vite at tjenesten din er nede på. Enten går det en alarm hos den som drifter den, eller så ringer en sint kunde til deg. Forskjellen mellom de to er hele poenget med profesjonell drift, og det er verdt å stille krav til dette før du signerer en avtale. Dette bør du be om.
Grunnovervåking: hva som skal måles
Overvåking begynner med fire ting som alltid skal måles, uansett hvordan tjenesten din ser ut.
- Oppetid. Svarer tjenesten i det hele tatt? Målt utenfra, slik en bruker opplever den, ikke bare om serveren er slått på.
- Feil. Hvor stor andel av kallene mislykkes? En stigende feilkurve er ofte det første signalet på at noe er i ferd med å gå i stykker.
- Responstider. Hvor raskt svarer tjenesten? En side som laster tregt, er for brukeren nesten like ille som en som ikke laster i det hele tatt.
- Kritiske funksjoner. De forretningshandlingene som aldri skal svikte: innlogging, bestilling, betaling. En server kan se sprek ut i statistikken mens akkurat kassen ikke fungerer.
Det siste punktet er det som oftest mangler. Teknisk grunnovervåking sier at serveren lever, men ikke at kundene kan handle. Krev at funksjonene der virksomheten din faktisk tjener penger, overvåkes som egne målepunkter.
Varslingskjeden: Hvem reagerer, og når?
Overvåking uten alarmer er bare grafer som ingen ser på klokken tre om natten. Det avgjørende er hva som skjer når en verdi passerer en grense.
En varslingskjede bestemmer hvem som kontaktes, i hvilken rekkefølge, og hva som skjer hvis ingen svarer. Den som har vakt, får alarmen først. Svarer vedkommende ikke innen en bestemt tid, eskaleres den videre til neste nivå. Kravet er enkelt å formulere, men lett å glemme: Det skal finnes et tydelig plassert, bemannet ansvar også utenfor kontortid. Kvelder, helger og helligdager er nettopp da en forstyrrelse som ingen følger med på, rekker å gjøre mest skade.
Vær på vakt mot drift som «fungerer fordi Anna alltid pleier å sjekke». Et ansvar som hviler på én hjelpsom enkeltperson, er ikke noe ansvar. Det er flaks, og flaksen tar slutt når Anna er på ferie.
Et scenario: natt til lørdag
Tenk deg at betalingen slutter å fungere ved midnatt, rett før en salgshelg. I den umodne varianten oppdages det først rundt klokken ni på mandag, når kundeservice fylles av e-post fra kunder som ikke fikk fullført kjøpet sitt. Rundt 57 timer med tapt salg, og et tillitstap som ikke vises i noen logg.
I den modne varianten går det en alarm i løpet av minutter: Feilkurven for betalingen har skutt i været. Vakthavende får en melding og ser at en tredjepartstjeneste svarer med feil. Betalingen kobles midlertidig om. Kundene merker en kort forstyrrelse i stedet for en hel helg. Samme feil, to helt ulike utfall, og det som skiller dem, er alarmer og en bemannet kjede.
Hendelsesprosessen: under og etter
Når noe først skjer, avgjøres kvaliteten av to ting: at du holdes informert underveis, og at feilen fører til læring etterpå.
| Del av prosessen | Hva du bør kreve |
|---|---|
| Statusinformasjon | Løpende beskjed om hva som skjer og når feilen forventes rettet, ikke taushet |
| Tiltak og eskalering | Tydelig hvem som eier hendelsen til den er løst |
| Post-mortem | En dokumentert gjennomgang etterpå: årsak og hva som endres |
Under en hendelse skal du ikke måtte jage etter svar. Krev at leverandøren aktivt informerer om situasjonen og gir et anslag på tid slik at du kan håndtere dine egne kunder. Taushet under en forstyrrelse er nesten like ille som selve forstyrrelsen.
Etterpå kommer det som skiller en moden leverandør fra en som bare slukker branner: en post-mortem, altså en saklig gjennomgang av hva som skjedde, hvorfor, og hva som skal endres, uten syndebukker. Uten den vanen kommer den samme feilen tilbake om og om igjen, og du betaler for den samme brannen flere ganger.
Slik bruker du dette
Du trenger ikke å kunne sette opp overvåking selv. Du må stille fire spørsmål før du signerer: Hva overvåkes, inkludert de kritiske funksjonene våre? Hvordan ser varslingskjeden ut utenfor kontortid? Hvordan blir vi informert under en hendelse? Og gjennomfører dere post-mortems? Svarene avslører raskt om driften er gjennomtenkt eller improvisert.
Vil du ha hjelp til å formulere driftskravene eller gå gjennom et opplegg, hjelper vi i Weapp gjerne med det som en del av systemarbeidet vårt. Ta kontakt, så går vi gjennom hva som er fornuftig for akkurat din tjeneste.
Ofte stilte spørsmål
Hva er forskjellen på overvåking og alarmer?
Overvåking er å måle hvordan tjenesten har det: oppetid, feil, responstider. En alarm er at noen eller noe reagerer når en måleverdi passerer en grense. Overvåking uten alarmer er bare pene grafer som ingen ser på når det trengs. Det er alarmene, med tydelige terskler og mottakere, som gjør at feil faktisk oppdages i tide.
Hva menes med en varslingskjede?
En forhåndsbestemt rekkefølge for hvem som kontaktes når en alarm går, og hva som skjer hvis den personen ikke svarer. Først den som har vakt, deretter eskalering til neste nivå etter en viss tid. Poenget er at ingen alarm skal kunne bli liggende hos noen som har fri uten at den går videre til noen som kan gripe inn.
Hva bør vi kreve når det gjelder driftsforstyrrelser utenfor kontortid?
At det finnes et tydelig plassert ansvar også på kvelder, i helger og på helligdager, ikke at alarmer hoper seg opp til neste arbeidsdag. Hvilken responstid som er passende, avhenger av hvor forretningskritisk tjenesten er, men ansvaret skal være bemannet og avtalt, ikke noe som tilfeldigvis fungerer fordi en enkelt utvikler er hjelpsom.
Hva er en post-mortem, og hvorfor er den viktig?
En gjennomgang etter en hendelse som beskriver hva som skjedde, hvorfor, og hva som skal endres for at det ikke skal gjenta seg, uten å peke ut syndebukker. Den gjør at den samme feilen ikke kommer tilbake gang på gang. En driftsleverandør som mangler den vanen, har en tendens til å slukke den samme brannen om og om igjen.
Hva er kritiske funksjoner, og hvorfor overvåkes de særskilt?
Handlingene der virksomheten din tjener penger eller leverer verdi: at kunder kan logge inn, legge inn en bestilling og gjennomføre en betaling. En server kan se frisk ut i statistikken samtidig som akkurat kassen ikke fungerer. Derfor holder ikke teknisk grunnovervåking. De forretningskritiske funksjonene må overvåkes som egne målepunkter.