Du driver en webshop. Nogen er i gang med at betale lige nu. Kassen er gået i stykker. Kunden får en fejl. Kunden går. Du har lige mistet et salg.
Uden et dashboard til driften ville du først finde fejlen i morgen, når du gennemgår den daglige rapport.
Med et dashboard til driften opdager driftsteamet fejlen på få sekunder. Retter den med det samme. Kunden prøver igen. Salget går igennem.
Prisen for langsom opdagelse: hundredvis af dollar i timen pr. fejl.
Dashboards til driften fanger problemer i realtid og ikke timer eller dage senere.
Hvad dashboards til driften skal gøre
Dashboards til driften overvåger systemernes tilstand og den løbende drift.
Er hjemmesiden oppe? Virker forløbene i kassen? Svarer betalingsudbyderne? Bliver e-mails sendt? Lykkes kaldene til API'er?
Et dashboard til driften handler ikke om omsætning eller forretningens tal. Det handler om systemernes tilstand.
Kravet om data i realtid
Et dashboard til driften skal opdateres i realtid eller næsten i realtid (inden for et minut).
Forsinkede data er ubrugelige. Hvis dashboardet opdateres hver time, overser du nedbrud, der sker mellem opdateringerne.
Kravet om realtid betyder: et dashboard til driften er dyrt at bygge og holde i gang. Brug det kun til kritiske systemer.
Hvad du skal overvåge på dashboardet til driften
Oppetid
Svarer hjemmesiden? Grøn, hvis den er oppe, rød, hvis den er nede.
Svartid
Hvor hurtig er hjemmesiden? Grøn, hvis under to sekunder, gul, hvis to til fem sekunder, rød, hvis over fem sekunder.
Andel af fejl
Hvor stor en del af forespørgslerne giver fejl? Grøn, hvis under 0,1 %, gul, hvis 0,1 % til 0,5 %, rød, hvis over 0,5 %.
Aktive transaktioner
Hvor mange transaktioner sker lige nu? Til orientering. Hverken godt eller dårligt i sig selv.
Tragten for konvertering i gang
Hvor mange besøgende er på hvert trin i kassen lige nu? Frafald på et trin skal undersøges.
Ydelse for API'er
Svartider for eksterne integrationer. Betalingsudbyder, e-mailtjeneste, API til forsendelse.
Ydelse for databasen
Svartider for forespørgsler og tilstanden af forbindelserne til databasen.
Et rigtigt eksempel: dashboard til driften i en webshop
Øverste del (systemernes tilstand)
Status for hjemmesiden: OPPE (grøn). Svartid: 1,2 sekunder (grøn). Andel af fejl: 0,08 % (grøn). Aktive brugere: 423. Transaktioner i gang: 17.
Midterste del (tragten i kassen)
Visning af kurv: 127 brugere. Start på betaling: 89 brugere (70 % konvertering fra kurv). Oplysninger om forsendelse: 72 brugere (81 % konvertering). Oplysninger om betaling: 68 brugere (94 % konvertering). Bekræftelse af ordre: 64 brugere (94 % konvertering). Frafald ved oplysninger om forsendelse: 17 brugere (vent, det er højere end normalt, undersøg).
Nederste del (integrationer)
Betalingsudbyder: svarer på 800 ms (grøn). E-mailtjeneste: 99,8 % leveret (grøn). Beregning af forsendelse: svarer på 1200 ms (gul, lidt langsom).
Handling med det samme
Frafaldet ved oplysninger om forsendelse er højere end normalt. Undersøg, om det er den langsomme beregning af forsendelse, der får folk til at give op.
System med advarsler
Dashboardet til driften bør udløse advarsler, når tal bliver røde.
Advar driftsteamet med det samme. Ikke med en e-mail, der kan blive overset. Brug SMS, en chatbesked eller en personsøger, der afbryder.
Grænserne skal være stramme. Du vil ikke have falske alarmer. Men det er bedre at have én falsk alarm og fange ét rigtigt problem end at overse problemer.
Eksempler på grænser: hjemmesiden er nede i 30 sekunder = advarsel. Andel af fejl over 1 % i 5 minutter = advarsel. Svartid over 5 sekunder i 10 minutter = advarsel. Betalingsudbyderen svarer ikke = advarsel med det samme.
Vagtordning
Til systemer, der er så kritiske, at de har brug for et dashboard til driften, har du brug for en vagtordning.
Nogen har ansvaret for overvågningen hele døgnet. Hvis en advarsel udløses klokken tre om natten, vågner vagthaveren og løser problemet.
Vagt er dyrt. Men nedetid er dyrere.
Sæt kun kritiske systemer på dashboardet til driften med vagt.
Hvad du IKKE skal overvåge
Overvåg ikke forretningens tal på dashboardet til driften. Omsætning, konverteringer og udviklingen i trafik hører til på dashboards til forretningen og ikke til driften.
Hvis du blander forretning og drift, bliver formålet uklart. Drift handler om systemernes tilstand. Forretning handler om forretningens tilstand.
Forskellige dashboards til forskellige formål.
Dashboard eller advarsler
Med dashboardet til driften kan du overvåge i forvejen. Se på dashboardet, før problemet bliver kritisk.
Med advarsler kan du reagere bagefter. Problemet opstår, advarslen udløses, og du retter det.
Du har brug for begge dele. Dashboardet til overvågning i forvejen. Advarsler til at reagere, når ingen ser på dashboardet.
Drejebøger til håndtering af hændelser
Når en advarsel udløses, hvad sker der så? Driftsteamet bør have en drejebog for hver type advarsel.
Advarsel om, at hjemmesiden er nede: genstart webserveren. Hvis den stadig er nede, skift til reserven. Hvis den stadig er nede, eskalér til en erfaren udvikler. Advarsel om, at betalingsudbyderen er nede: skift til en reserve. Giv kunderne besked om mulig forsinkelse. Overvåg, til den primære udbyder er oppe igen. Advarsel om, at databasen er langsom: tjek forbindelserne. Hvis de er fyldt, så øg dem. Tjek loggen over forespørgsler. Stop langsomme forespørgsler. Overvåg.
Drejebøger forhindrer panik. Klare trin forhindrer fejl.
Ofte stillede spørgsmål
Hvor ofte skal vi se på dashboardet til driften?
Hele tiden i arbejdstiden. Én person ser på det hele tiden. Uden for arbejdstid ser vagthaveren på det. For systemer, der ikke er kritiske, så tjek hver time. For kritiske systemer (betalinger og kassen) skal du overvåge hele tiden. Bestem, hvilke systemer der er kritiske: systemer, hvor en times nedetid koster en betydelig omsætning. Alt andet kan tjekkes hver time. Med WEMASY's hjemmesidebygger kan du sætte det op direkte på din hjemmeside.
Hvilken svartid er acceptabel?
For kassen i en webshop: under to sekunder. For en hjemmeside til markedsføring: under tre sekunder. For interne værktøjer til administration: under fem sekunder. Er det langsommere, lider konverteringen eller brugeroplevelsen. Mål ud fra brugerens synsvinkel og ikke serverens. Hvis brugeren mærker en forsinkelse, er det for langsomt.
Hvordan undgår vi, at folk bliver trætte af advarsler?
Stramme grænser. Advar kun, når der er et rigtigt problem. Hvis du får ti advarsler om dagen, og ni er falske alarmer, holder folk op med at lægge mærke til dem. Det er bedre at have to advarsler om dagen, som alle er rigtige. Justér grænserne kraftigt. Hvis en advarsel udløses, og den ikke er hastende, så hæv grænsen. At blive træt af advarsler dræber evnen til at reagere.
Skal dashboardet til driften kunne bruges på mobilen?
Ja. Vagthaveren skal kunne tjekke det fra alle steder. Sørg for, at det virker på telefonen. Vagthaveren er måske væk fra skrivebordet. Optimér til mobil. Store felter til at trykke på. Enkelt layout. Hurtig indlæsning, selv på 4G.
Hvordan følger vi tilstanden i driften over tid?
Log alle tal. Selv om dashboardet til driften er i realtid, så gem historikken. Gennemgå hver uge: hvor ofte var vi nede, hvor langsomme var vi, og hvad var de hyppigste fejl. Brug historikken til at finde fejl i systemet som helhed. Eksempel: hvis du har tre tidsudløb hos betalingsudbyderen om ugen, så undersøg betalingsudbyderen. Ret ikke bare grænsen for advarslen.
Hvad hvis vagthaveren ikke ved, hvordan problemet løses?
Hav en vej til eskalering. Vagthaveren er første kontakt. Hvis vedkommende ikke kan løse det på fem minutter, så eskalér til en erfaren udvikler. Den erfarne udvikler er andet niveau. Hvis ingen af dem kan løse det, så eskalér til support hos leverandøren eller til direktøren. Drejebøgerne bør beskrive vejen til eskalering for hver type advarsel.