Vem märker först när din tjänst ligger nere – du eller leverantören?
Kräv att driftleverantören upptäcker fel med automatiska larm, inte via klagande kunder. Grunden är övervakning av upptid, felnivåer, svarstider och de kritiska affärsflödena, en larmkedja med utpekat ansvar också utanför kontorstid, och en incidentprocess som ger dig status under tiden och ett dokumenterat lärande efteråt.
Det finns två sätt att få veta att din tjänst ligger nere. Antingen ringer ett larm hos den som driftar den, eller så ringer en arg kund hos dig. Skillnaden mellan de två är hela poängen med professionell drift, och den är värd att kravställa innan du skriver på ett avtal. Här är vad du ska begära.
Grundövervakning: vad som ska mätas
Övervakning börjar med fyra saker som alltid ska bevakas, oavsett hur din tjänst ser ut.
- Upptid. Svarar tjänsten över huvud taget? Mätt utifrån, som en användare upplever den – inte bara att servern är påslagen.
- Fel. Hur stor andel av anropen misslyckas? En stigande felkurva är ofta den första signalen på att något är på väg att gå sönder.
- Svarstider. Hur snabbt svarar tjänsten? En sida som laddar långsamt är för användaren nästan lika illa som en som inte laddar alls.
- Kritiska flöden. De affärshandgrepp som får inte fallera: inloggning, order, betalning. En server kan se pigg ut i statistiken medan just kassan är trasig.
Den sista punkten är den som oftast saknas. Teknisk grundövervakning säger att servern lever, men inte att kunderna kan handla. Kräv att de flöden där din verksamhet faktiskt tjänar pengar bevakas som egna mätpunkter.
Larmkedjan: vem reagerar, och när?
Övervakning utan larm är bara grafer som ingen tittar på klockan tre på natten. Det avgörande är vad som händer när ett värde passerar en gräns.
En larmkedja bestämmer vem som kontaktas, i vilken ordning, och vad som sker om ingen svarar. En jourhavande får larmet först; svarar den inte inom en bestämd tid eskaleras det vidare till nästa nivå. Kravet är enkelt att formulera men lätt att glömma: det ska finnas ett utpekat, bemannat ansvar även utanför kontorstid. Kvällar, helger och röda dagar är precis när en obevakad störning hinner göra mest skada.
Var vaksam på drift som “fungerar för att Anna alltid brukar kolla”. Ett ansvar som vilar på en enskild hjälpsam person är inget ansvar – det är tur, och turen tar slut när Anna är på semester.
Ett scenario: natten mot lördag
Föreställ dig att betalningen slutar fungera vid midnatt inför en försäljningshelg. I den omogna varianten upptäcks det först vid niotiden på måndag, när supporten fylls av mejl från kunder som inte kunde slutföra sitt köp. Nio timmars förlorad försäljning, och ett förtroendetapp som inte syns i någon logg.
I den mogna varianten går ett larm inom minuter: felkurvan för betalflödet sköt i höjden. Jouren får ett meddelande, ser att en tredjepartstjänst svarar med fel, och kopplar tillfälligt om betalningen. Kunderna märker en kort störning i stället för en hel helg. Samma fel, två helt olika utfall – och det som skiljer dem är larm och en bemannad kedja.
Incidentprocessen: under och efter
När något väl händer avgörs kvaliteten av två saker: att du hålls informerad under tiden, och att felet leder till lärande efteråt.
| Del av processen | Vad du ska kräva |
|---|---|
| Statusinformation | Löpande besked om vad som händer och förväntad åtgärdstid – inte tystnad |
| Åtgärd och eskalering | Tydligt vem som äger incidenten tills den är löst |
| Post-mortem | En dokumenterad genomgång efteråt: orsak och vad som ändras |
Under en incident vill du inte jaga svar. Kräv att leverantören informerar aktivt om läget och en uppskattad tid, så att du kan hantera dina egna kunder. Tystnad under en störning är nästan lika illa som störningen själv.
Efteråt kommer det som skiljer en mogen leverantör från en som bara släcker bränder: en post-mortem. En saklig genomgång av vad som hände, varför, och vad som ska ändras – utan syndabockar. Utan den vanan återkommer samma fel om och om igen, och du betalar för samma brand flera gånger.
Så använder du det här
Du behöver inte kunna sätta upp övervakning själv. Du behöver ställa fyra frågor innan du skriver på: Vad övervakas, inklusive våra kritiska flöden? Hur ser larmkedjan ut utanför kontorstid? Hur informeras vi under en incident? Och gör ni post-mortems? Svaren avslöjar snabbt om driften är genomtänkt eller improviserad.
Vill du ha hjälp att formulera driftkraven eller granska ett upplägg tar vi på Weapp gärna med det i systemarbetet. Hör av dig så går vi igenom vad som är rimligt för just din tjänst.
Vanliga frågor
Vad är skillnaden mellan övervakning och larm?
Övervakning är att mäta hur tjänsten mår – upptid, fel, svarstider. Larm är att någon eller något reagerar när en mätvärde passerar en gräns. Övervakning utan larm är bara vackra grafer som ingen tittar på när det behövs. Det är larmen, med tydliga trösklar och mottagare, som gör att fel faktiskt upptäcks i tid.
Vad menas med en larmkedja?
En förutbestämd ordning för vem som kontaktas när ett larm går, och vad som händer om den personen inte svarar. Först en jourhavande, sedan en eskalering till nästa nivå efter en viss tid. Poängen är att inget larm ska kunna landa hos någon som är ledig utan att det går vidare till någon som kan agera.
Vad ska vi kräva om driftstörningar utanför kontorstid?
Att det finns ett utpekat ansvar även på kvällar, helger och röda dagar – inte att larm samlas på hög till nästa arbetsdag. Vilken svarstid som är rimlig beror på hur affärskritisk tjänsten är, men ansvaret ska vara bemannat och avtalat, inte något som råkar fungera för att en enskild utvecklare är hjälpsam.
Vad är en post-mortem och varför spelar den roll?
En genomgång efter en incident som beskriver vad som hände, varför, och vad som ska ändras för att det inte ska upprepas – utan att peka ut skyldiga. Den gör att samma fel inte återkommer gång på gång. En driftleverantör som saknar den vanan tenderar att släcka samma brand om och om igen.
Vad är kritiska flöden och varför övervakas de särskilt?
De handgrepp där din verksamhet tjänar pengar eller levererar värde: att kunder kan logga in, lägga en order, genomföra en betalning. En server kan se frisk ut i statistiken samtidigt som just kassan är trasig. Därför räcker inte teknisk grundövervakning – de affärskritiska flödena behöver bevakas som de egna mätpunkter de är.