Du driver en e-handelssajt. Någon går till kassan just nu. Kassan är trasig. Kunden får ett felmeddelande. Kunden lämnar sajten. Du har just förlorat en försäljning.
Utan en driftdashboard hade du inte hittat felet förrän i morgon när du går igenom dagsrapporten.
Med en driftdashboard upptäcker driftteamet felet inom några sekunder. Åtgärdar det direkt. Kunden försöker igen. Köpet går igenom.
Kostnaden för långsam upptäckt: hundratals dollar per timme per fel.
Driftdashboards fångar problem i realtid, inte timmar eller dagar senare.
Driftdashboardens uppgift
Driftdashboards övervakar systemens hälsa och pågående verksamhet.
Är webbplatsen uppe? Fungerar kassaflödena? Svarar betalningsleverantörerna? Skickas e-post? Lyckas API-anropen?
En driftdashboard handlar inte om intäkter eller affärsmått. Den handlar om systemens hälsa.
Krav på data i realtid
En driftdashboard måste uppdateras i realtid eller nästan i realtid (inom en minut).
Fördröjd data är värdelös. Om dashboarden uppdateras varje timme missar du driftstopp som sker mellan uppdateringarna.
Kravet på realtid betyder att en driftdashboard är dyr att bygga och underhålla. Använd den bara för kritiska system.
Vad du ska övervaka på driftdashboarden
Drifttid
Svarar webbplatsen? Grönt om den är uppe, rött om den är nere.
Svarstid
Hur snabb är webbplatsen? Grönt om under två sekunder, gult om två till fem sekunder, rött om över fem sekunder.
Felfrekvens
Hur stor andel av anropen ger fel? Grönt om under 0,1 %, gult om 0,1 % till 0,5 %, rött om över 0,5 %.
Aktiva transaktioner
Hur många transaktioner pågår just nu? Som referens. Varken bra eller dåligt i sig.
Konverteringstratt som pågår
Hur många besökare finns i varje steg i kassan just nu? Avhopp i något steg utlöser en utredning.
API-prestanda
Svarstider för externa integrationer. Betalningsleverantör, e-posttjänst, API för frakt.
Databasprestanda
Svarstider för frågor och hälsa i anslutningspoolen.
Verkligt exempel: driftdashboard för e-handel
Övre delen (systemhälsa)
Webbplatsstatus: UPPE (grönt). Svarstid: 1,2 sekunder (grönt). Felfrekvens: 0,08 % (grönt). Aktiva användare: 423. Pågående transaktioner: 17.
Mittersta delen (kassatratten)
Visning av varukorg: 127 användare. Start av kassan: 89 användare (70 % konvertering från varukorgen). Leveransuppgifter: 72 användare (81 % konvertering). Betalningsuppgifter: 68 användare (94 % konvertering). Orderbekräftelse: 64 användare (94 % konvertering). Avhopp vid leveransuppgifter: 17 användare (vänta, det här är högre än normalt, utred).
Nedre delen (integrationer)
Betalningsleverantör: svarar på 800 ms (grönt). E-posttjänst: 99,8 % levererat (grönt). Fraktkalkylator: svarar på 1 200 ms (gult, något långsam).
Åtgärd direkt
Avhoppen vid leveransuppgifter är högre än normalt. Utred om fraktkalkylatorns långsamhet gör att kunder avbryter.
Larmsystem
En driftdashboard ska utlösa larm när mått blir röda.
Larma driftteamet direkt. Inte med e-post som kan missas. SMS, chatt eller personsökare som avbryter.
Tröskelvärdena ska vara strikta. Du vill inte ha falsklarm. Men det är bättre med ett falsklarm och ett fångat verkligt problem än att missa problem.
Exempel på tröskelvärden: webbplatsen nere i 30 sekunder = larm. Felfrekvens över 1 % i 5 minuter = larm. Svarstid över 5 sekunder i 10 minuter = larm. Betalningsleverantören svarar inte = larm direkt.
Jourschemat
För system som är så kritiska att de behöver en driftdashboard behöver du ett jourschema.
Någon ansvarar för övervakningen dygnet runt. Om ett larm går klockan 03 vaknar personen i jour och åtgärdar problemet.
Jour är dyrt. Men driftstopp är dyrare.
Lägg bara kritiska system på driftdashboarden med jour.
Vad du INTE ska övervaka
Övervaka inte affärsmått på driftdashboarden. Intäkter, konverteringar och trafiktrender hör till affärsdashboards, inte driftdashboards.
Att blanda affär och drift förvirrar syftet. Drift handlar om systemens hälsa. Affär handlar om affärens hälsa.
Separata dashboards för separata syften.
Dashboard eller larm
Driftdashboarden låter dig övervaka i förväg. Titta på dashboarden innan problemet blir kritiskt.
Larm låter dig reagera i efterhand. Problemet uppstår, larmet går, du åtgärdar det.
Båda behövs. Dashboard för övervakning i förväg. Larm för reaktion när ingen tittar på dashboarden.
Instruktioner för incidenthantering
När ett larm går, vad händer sedan? Driftteamet ska ha en instruktion för varje typ av larm.
Larm om att webbplatsen är nere: starta om webbservern. Om den fortfarande är nere, växla till reservsystemet. Om den fortfarande är nere, eskalera till en senior utvecklare. Larm om att betalningsleverantören är nere: byt till en reservleverantör. Informera kunder om möjlig försening. Övervaka tills huvudleverantören är tillbaka. Larm om långsam databas: kontrollera anslutningspoolen. Om den är full, utöka den. Kontrollera frågeloggen. Avsluta långsamma frågor. Övervaka.
Instruktioner förhindrar panik. Tydliga steg förhindrar misstag.
Vanliga frågor
Hur ofta ska vi titta på driftdashboarden?
Hela tiden under kontorstid. En person som tittar hela tiden. Utanför kontorstid tittar personen i jour. För icke-kritiska system, titta varje timme. För kritiska system (betalningar, kassa), kontinuerlig övervakning. Definiera vilka system som är kritiska: system där en timmes driftstopp kostar betydande intäkter. Allt annat kan kontrolleras varje timme. Med WEMASY webbplatsbyggare kan du ställa in det direkt på din webbplats.
Vilken svarstid är acceptabel?
För e-handelns kassa: under två sekunder. För marknadsföringssajt: under tre sekunder. För interna adminverktyg: under fem sekunder. Långsammare än så och konverteringen eller användarupplevelsen blir lidande. Mät ur användarens perspektiv, inte serverns. Om användaren märker en fördröjning är det för långsamt.
Hur undviker vi larmtrötthet?
Strikta tröskelvärden. Larma bara när det finns ett verkligt problem. Om du får tio larm per dag och nio är falsklarm slutar folk lyssna. Det är bättre med två larm per dag som alla är verkliga. Justera tröskelvärdena aggressivt. Om ett larm går och det inte är brådskande, höj tröskelvärdet. Larmtrötthet dödar snabbheten i responsen.
Ska driftdashboarden gå att använda i mobilen?
Ja. Personen i jour behöver kunna titta från var som helst. Se till att den fungerar på telefon. Personen i jour kanske inte sitter vid skrivbordet. Optimera för mobil. Stora knappar. Enkel layout. Snabb inladdning även på 4G.
Hur följer vi driftens hälsa över tid?
Logga alla mått. Även om driftdashboarden är i realtid ska du spara historik. Gå igenom varje vecka: hur ofta låg vi nere, hur långsamma var vi, vilka var de vanligaste felen. Använd historiken för att hitta systematiska problem. Exempel: om du har tre tidsgränsfel hos betalningsleverantören per vecka, utred betalningsleverantören. Justera inte bara tröskelvärdet för larmet.
Vad gör vi om personen i jour inte vet hur problemet ska åtgärdas?
Ha en eskaleringsväg. Personen i jour är första insatsen. Om hen inte kan åtgärda det på fem minuter, eskalera till en senior utvecklare. Den seniora utvecklaren är andra nivån. Om ingen av dem kan åtgärda det, eskalera till leverantörens support eller vd:n. Instruktionerna ska beskriva eskaleringsvägen för varje typ av larm.