Hvem opdager først at din tjeneste er nede: du eller leverandøren?
Kræv at driftsleverandøren opdager fejl med automatiske alarmer, ikke via klagende kunder. Grundlaget er overvågning af oppetid, fejlrater, svartider og de forretningskritiske flows, en alarmkæde med udpeget ansvar også uden for arbejdstiden og en incidentproces der giver dig status undervejs og dokumenteret læring bagefter.
Der er to måder at få at vide at din tjeneste er nede på. Enten går der en alarm hos dem der drifter den, eller også ringer en vred kunde til dig. Forskellen mellem de to er hele pointen med professionel drift, og den er værd at stille krav til før du skriver under på en aftale. Her er hvad du skal bede om.
Grundovervågning: hvad der skal måles
Overvågning begynder med fire ting der altid skal holdes øje med, uanset hvordan din tjeneste ser ud.
- Oppetid. Svarer tjenesten overhovedet? Målt udefra, sådan som en bruger oplever den, ikke bare om serveren er tændt.
- Fejl. Hvor stor en andel af kaldene fejler? En stigende fejlkurve er ofte det første tegn på at noget er ved at gå i stykker.
- Svartider. Hvor hurtigt svarer tjenesten? En side der indlæses langsomt, er for brugeren næsten lige så dårlig som en der slet ikke indlæses.
- Kritiske flows. De forretningshandlinger der ikke må svigte: login, ordre, betaling. En server kan se frisk ud i statistikken mens netop checkout er i stykker.
Det sidste punkt er det der oftest mangler. Teknisk grundovervågning fortæller at serveren lever, men ikke at kunderne kan handle. Kræv at de flows hvor din forretning faktisk tjener penge, overvåges som selvstændige målepunkter.
Alarmkæden: Hvem reagerer, og hvornår?
Overvågning uden alarmer er bare grafer som ingen kigger på klokken tre om natten. Det afgørende er hvad der sker når en værdi passerer en grænse.
En alarmkæde bestemmer hvem der kontaktes, i hvilken rækkefølge, og hvad der sker hvis ingen svarer. Den vagthavende får alarmen først; svarer vedkommende ikke inden for en fastsat tid, eskaleres den videre til næste niveau. Kravet er enkelt at formulere, men let at glemme: Der skal være et udpeget, bemandet ansvar også uden for arbejdstiden. Aftener, weekender og helligdage er netop de tidspunkter hvor en uovervåget driftsforstyrrelse når at gøre mest skade.
Vær på vagt over for drift der “fungerer fordi Anna altid plejer at tjekke”. Et ansvar der hviler på en enkelt hjælpsom person, er ikke et ansvar. Det er held, og heldet slipper op når Anna er på ferie.
Et scenarie: natten til lørdag
Forestil dig at betalingen holder op med at virke ved midnat op til en udsalgsweekend. I den umodne udgave bliver det først opdaget ved nitiden mandag når supporten fyldes med mails fra kunder der ikke kunne gennemføre deres køb. Ni timers tabt salg og et tab af tillid som ikke ses i nogen log.
I den modne udgave går en alarm inden for få minutter: Fejlkurven for betalingsflowet er skudt i vejret. Den vagthavende får en besked, ser at en tredjepartstjeneste svarer med fejl, og omlægger midlertidigt betalingen. Kunderne mærker en kort forstyrrelse i stedet for en hel weekend. Den samme fejl, to helt forskellige udfald, og det der skiller dem, er alarmer og en bemandet kæde.
Incidentprocessen: undervejs og bagefter
Når noget først sker, afgøres kvaliteten af to ting: at du holdes informeret undervejs, og at fejlen fører til læring bagefter.
| Del af processen | Hvad du skal kræve |
|---|---|
| Statusinformation | Løbende besked om hvad der sker, og forventet tid til udbedring, ikke tavshed |
| Udbedring og eskalering | Klart hvem der ejer incidenten indtil den er løst |
| Post-mortem | En dokumenteret gennemgang bagefter: årsag og hvad der ændres |
Under en incident vil du ikke jagte svar. Kræv at leverandøren aktivt informerer om situationen og en forventet tidshorisont så du kan håndtere dine egne kunder. Tavshed under en driftsforstyrrelse er næsten lige så slemt som selve forstyrrelsen.
Bagefter kommer det der skiller en moden leverandør fra en der bare slukker brande: en post-mortem. En saglig gennemgang af hvad der skete, hvorfor, og hvad der skal ændres, uden syndebukke. Uden den vane vender den samme fejl tilbage igen og igen, og du betaler for den samme brand flere gange.
Sådan bruger du det
Du behøver ikke selv at kunne sætte overvågning op. Du skal stille fire spørgsmål før du skriver under: Hvad overvåges, inklusive vores kritiske flows? Hvordan ser alarmkæden ud uden for arbejdstiden? Hvordan bliver vi informeret under en incident? Og laver I post-mortems? Svarene afslører hurtigt om driften er gennemtænkt eller improviseret.
Vil du have hjælp til at formulere kravene til driften eller til at gennemgå en opsætning, tager vi hos Weapp det gerne med i systemarbejdet. Kontakt os, så gennemgår vi hvad der er rimeligt for netop din tjeneste.
Ofte stillede spørgsmål
Hvad er forskellen på overvågning og alarmer?
Overvågning er at måle hvordan tjenesten har det: oppetid, fejl, svartider. Alarmer er at nogen eller noget reagerer når en måleværdi passerer en grænse. Overvågning uden alarmer er bare flotte grafer som ingen kigger på når det gælder. Det er alarmerne, med klare tærskler og modtagere, der gør at fejl faktisk bliver opdaget i tide.
Hvad menes der med en alarmkæde?
En fastlagt rækkefølge for hvem der kontaktes når en alarm går, og hvad der sker hvis den person ikke svarer. Først den vagthavende, derefter en eskalering til næste niveau efter et bestemt stykke tid. Pointen er at ingen alarm må kunne lande hos en der har fri uden at den går videre til en der kan handle.
Hvad skal vi kræve ved driftsforstyrrelser uden for arbejdstiden?
At der er et udpeget ansvar også om aftenen, i weekender og på helligdage, og ikke at alarmer hober sig op til næste arbejdsdag. Hvilken svartid der er rimelig, afhænger af hvor forretningskritisk tjenesten er, men ansvaret skal være bemandet og aftalt, ikke noget der tilfældigvis fungerer fordi en enkelt udvikler er hjælpsom.
Hvad er en post-mortem, og hvorfor betyder den noget?
En gennemgang efter en incident der beskriver hvad der skete, hvorfor, og hvad der skal ændres så det ikke gentager sig, og den gør det uden at udpege skyldige. Den gør at den samme fejl ikke vender tilbage gang på gang. En driftsleverandør der mangler den vane, har en tendens til at slukke den samme brand igen og igen.
Hvad er kritiske flows, og hvorfor overvåges de særskilt?
De handlinger hvor din forretning tjener penge eller leverer værdi: at kunder kan logge ind, afgive en ordre, gennemføre en betaling. En server kan se sund ud i statistikken samtidig med at netop checkout er i stykker. Derfor er teknisk grundovervågning ikke nok. De forretningskritiske flows skal overvåges som de selvstændige målepunkter de er.