Det finns ett tyst ögonblick varje byrå känner igen: telefonen surrar med ännu ett ”SITE DOWN”-larm, och någon i teamet suckar och sveper bort det utan att titta. Sajten var uppe. Larmet var fel, precis som de tre senaste. Det är larmtrötthet – och det är farligare än det låter, för det är exakt så här ett verkligt avbrott slinker förbi obemärkt.
Varför övervakning börjar ropa varg
Larmtrötthet är sällan ett slumpfel. Det är resultatet av några konkreta designval som var för sig verkar rimliga men tillsammans dränker teamet i brus.
Larm på en enda check
Den vanligaste orsaken. Ett enda misslyckat anrop från en enda mätpunkt utlöser ett kritiskt larm. Men internet är stökigt – paket tappas, en mellanliggande router hickar, en mätpunkt får en sekunds timeout. Sajten var aldrig nere. Ändå ringde telefonen.
Ingen bekräftelse
Nära besläktat: systemet kontrollerar aldrig sin egen slutsats. Det ser ett misslyckande och agerar direkt istället för att fråga ”stämmer det här verkligen?” En andra kontroll hade avslöjat att det var en blipp – men den kontrollen görs aldrig.
Inga underhållsfönster
Du vet att kunden kör uppdateringar tisdagar klockan två på natten. Övervakningen vet det inte. Så varje planerat underhåll blir en skur av larm om något som inte är ett problem. Efter några veckor lär sig teamet att ignorera larm på tisdagsnätter – och där försvann värdet.
Allt till alla
När varje larm går till hela teamet blir ingen ansvarig, och alla antar att någon annan tittar. Bruset blir dessutom dubbelt så irriterande eftersom det stör folk som inte ens har med den kunden att göra. Resultatet: alla stänger av notiserna.
Hur du bygger bort det
Den goda nyheten är att varje orsak har en direkt motåtgärd. Poängen är inte färre larm för sakens skull – det är att varje larm som når en människa ska vara värt att agera på.
Bekräfta innan du larmar
Det enskilt mest effektiva greppet. När den första mätningen misslyckas, kontrollera igen från en annan plats innan något larm går ut. Först när två oberoende mätpunkter är överens om att sajten inte svarar räknas det som ett verkligt avbrott. Det tar bort merparten av falsklarmen som beror på nätverksglitchar, eftersom en glitch sällan drabbar två platser samtidigt.
Eskalera i steg
Alla larm förtjänar inte att väcka någon. Bygg en eskaleringstrappa: först en tyst notis i en kanal, och om felet kvarstår efter några minuter höjs allvaret och en person pingas. Ett litet hack som självläker på nittio sekunder ska aldrig ha nått en människa. Ett avbrott som består i tio minuter ska definitivt göra det.
Tysta tider och underhållsfönster
Sätt tider då icke-kritiska larm hålls tillbaka, och lägg in underhållsfönster för planerat arbete. En broschyrsajt behöver ingen som väcks klockan tre. Ett känt uppdateringsfönster ska inte generera larm alls. Detta ensamt återställer teamets förtroende för larmen som faktiskt kommer fram.
Dirigera per sajt
Skicka varje larm till den som äger den kunden, i den kanal de bevakar. När larmet är riktat blir det ägt, och ägda larm blir åtgärdade. Olika sajter kan dessutom ha olika policyer – en shop med SLA larmar hårdare och bredare än en enkel landningssida.
Var ärlig om orsaken
En sista, ofta förbisedd punkt: språket i larmet. Ett larm som säger ”SITE DOWN – CAUSED BY PLUGIN X” ljuger om det inte vet det säkert. Det ärliga är att beskriva vad som är känt: sajten svarar inte, bekräftat från två platser, och en uppdatering kördes strax innan. Det är korrelerat, det ändrades precis innan – inte ett bevisat orsakssamband. Den nyansen bygger förtroende, och förtroende är exakt det larmtrötthet förstör. Ett bra sätt att hålla koll är att då och då mäta din egen larmkvalitet: hur stor andel av larmen ledde faktiskt till en åtgärd? Om siffran är låg ropar systemet fortfarande varg, och det är dags att strama åt bekräftelse, eskalering eller dirigering tills varje larm är värt uppmärksamheten.
Så gör Ravnsight
Ravnsight är byggt kring den här filosofin. Ett misslyckande bekräftas från ett andra land innan det når dig, så nätverksglitchar aldrig blir larm. Systemet stödjer eskalering i steg, tysta tider och policyer per sajt, så att rätt person larmas i rätt kanal vid rätt tidpunkt. Och när ett larm väl går ut håller det sig till vad som faktiskt är känt – inklusive vad som ändrades precis innan – utan att låtsas veta orsaken. Färre larm, men de du kan lita på.
