MTTR (mean time to recovery, eller repair) är den genomsnittliga tiden från att en incident börjar tills tjänsten fungerar igen. MTTA (mean time to acknowledge) är den genomsnittliga tiden från ett larm tills någon bekräftar att hen jobbar med det. MTBF (mean time between failures) är den genomsnittliga tiden som en tjänst går normalt mellan incidenterna. Tillsammans beskriver de driftsäkerheten: MTBF visar hur ofta saker går sönder, MTTA hur snabbt ni reagerar och MTTR hur länge kunderna drabbas.
Den här guiden går igenom definitionerna, formlerna, ett räkneexempel med siffror, vilka tidsstämplar du ska samla in och de praktiska förändringar som förbättrar varje mått.
Måtten och vad de mäter
MTTR: fyra betydelser, en förkortning
MTTR är det mest citerade incidentmåttet och det mest förvirrande, eftersom R står för olika saker beroende på vem som använder det:
Mean time to repair: från att reparationsarbetet börjar tills åtgärden är på plats. Vanligt inom hårdvara och underhåll.
Mean time to recovery (eller restore): från att avbrottet börjar tills tjänsten fungerar igen för användarna. Den mest användbara varianten för webbplatser och API:er.
Mean time to respond: från larmet tills teamet börjar agera. Ligger nära MTTA.
Mean time to resolve: tills incidenten är helt avslutad, inklusive uppföljningen som hindrar att den händer igen.
Ingen av dem är fel. Det viktiga är att du väljer en, skriver ner definitionen och använder den konsekvent. Att jämföra din siffra för ”recovery” med någon annans siffra för ”repair” säger ingenting. I den här artikeln betyder MTTR mean time to recovery: från att tjänsten gick sönder tills den fungerade igen.
MTTD och MTTA: reaktionen före reparationen
MTTD (mean time to detect) är tiden från att en incident börjar tills övervakningen larmar. MTTA är tiden från det larmet tills en person bekräftar det. Båda ingår i MTTR, och därför betyder de så mycket: ingen kan åtgärda ett problem som de inte har hört talas om.
MTBF: hur ofta saker går sönder
MTBF är den genomsnittliga upptiden mellan incidenter. Ju högre, desto bättre. Släktingen MTTF (mean time to failure) används för sådant som byts ut i stället för att repareras, till exempel diskar; för onlinetjänster är det MTBF du behöver.
Formlerna
MTTD = total tid från incidentstart till larm / antal incidenter
MTTA = total tid från larm till bekräftelse / antal incidenter
MTTR = total tid från incidentstart till återställning / antal incidenter
MTBF = total drifttid utan incidenter / antal incidenter
Tillgänglighet = MTBF / (MTBF + MTTR)
Den sista raden visar varför båda sidorna spelar roll. Du kan förbättra tillgängligheten genom att ha färre incidenter (högre MTBF) eller genom att göra dem kortare (lägre MTTR). Att korta dem är ofta betydligt billigare.
Ett räkneexempel
Här är en exempelmånad för en webbutik, med fyra incidenter. Siffrorna är påhittade för att illustrera, men tidsstämplarna är av det slag som alla övervakningsverktyg ger dig.
IncidentBörjadeLarmBekräftadÅterställdUpptäcktBekräftelseÅterställningKassan ger 50303:1203:1303:1603:191 min3 min7 minTimeouts i API:et10:0510:0610:0810:411 min2 min36 minInloggningsfel14:3014:3114:4515:021 min14 min32 minSökningen nere22:5022:5122:5623:151 min5 min25 min
Använd nu formlerna:
MTTD = (1 + 1 + 1 + 1) / 4 = 1 minut.
MTTA = (3 + 2 + 14 + 5) / 4 = 6 minuter.
MTTR = (7 + 36 + 32 + 25) / 4 = 25 minuter.
MTBF: en månad på 30 dagar har 43 200 minuter. Minus 100 minuters nertid blir det 43 100. Delat med 4 incidenter blir MTBF 10 775 minuter, ungefär 7,5 dagar.
Tillgänglighet = 10 775 / (10 775 + 25) = 99,77 %.
Två saker sticker ut. Bekräftelsen på 14 minuter vid inloggningsincidenten drar upp MTTA från ungefär 3 minuter till 6, så det är värt att fråga sig varför ingen tog det larmet. Och med 99,77 % ligger butiken en bra bit under ett mål på 99,9 %, som bara tillåter 43 minuter i månaden. Om du sätter sådana mål kan du läsa SLA, SLO och SLI om hur de hänger ihop.
Tänk dig nu samma månad med kontroller var femte minut och utan bekräftelsesteg. Upptäckten kan då ta upp till fem minuter i stället för en, vilket lägger till upp till fyra minuter på varje incident. MTTR stiger från 25 till upp till 29 minuter innan någon har gjort något annorlunda.
Vilka tidsstämplar du ska samla in
Du behöver fyra tidsstämplar per incident. De flesta kommer direkt från övervakningen:
Start: den första misslyckade kontrollen. Extern övervakning registrerar den även när dina servrar inte loggar något.
Larm: när felet bekräftades och notisen skickades.
Bekräftad: när en person sa ”jag tar det”. Har du inget jourverktyg fungerar ett svar i incidentkanalen; notera tiden. I Uptimecheck bekräftar du incidenten i appen eller, med Slack-appen, med en knapp i Slack, och tiden registreras.
Återställd: den första godkända kontrollen efter incidenten, som också är när meddelandet om återställning skickas.
Med Uptimecheck har varje incident en tidslinje: när den började, vem som larmades och när, bekräftelser (även med en knapp i Slack när du använder Slack-appen), anteckningar och återställningen. MTTA och MTTR räknas ut åt dig, och rapportens CSV-export ger varje monitors antal incidenter, nertid och längsta incident för ett kalkylark. Lägg till lärdomarna i en postmortem.
En praktisk varning: medelvärden döljer avvikare. En incident på sex timmar och nio små blippar på en minut ger i snitt ungefär 37 minuter, vilket beskriver ingen av dem. Titta på medianen och den längsta incidenten vid sidan av medelvärdet, och gå igenom de långsammaste incidenterna en och en.
Så kortar du tiden till upptäckt
Kontrollera varje minut
Kontrollintervallet är den övre gränsen för din tid till upptäckt. Kontroller varje minut på allt som drar in pengar eller betjänar kunder är den enskilt billigaste förbättringen av MTTR. Använd upptidsövervakning med 1-minutersintervall för varje kritisk sida och endpoint.
Kontrollera det som går sönder, inte bara det som laddas
Incidenter som övervakningen inte ser upptäcks av kunderna, ofta timmar senare. Validera innehållet på viktiga sidor, övervaka de API-endpoints som appar är beroende av och lägg till heartbeats på schemalagda jobb. Varje incident som en kund rapporterar först är en lucka i din övervakning.
Så kortar du tiden till bekräftelse
Skicka bara bekräftade larm
Långsam bekräftelse är oftast ett förtroendeproblem. Om hälften av larmen är falska lär sig folk att avvakta. Bekräfta varje fel med en andra kontroll innan larmet går, och ta bort monitorer som larmar utan att någon behöver göra något. Vår guide om att minska falsklarm går igenom detaljerna.
Skicka larmen till rätt kanal
Ett mejl klockan 03:12 blir läst klockan 07:30. Skicka larm från kritiska monitorer till en kanal som når jourhavandes mobil och till en teamchatt för alla andra, och låt mindre brådskande monitorer larma via e-post. I Uptimecheck väljer du larmkanaler per monitor: e-post, Slack, Microsoft Teams, Discord, Google Chat, Mattermost, Telegram, PagerDuty, ntfy, Pushover, webhooks och pushnotiser i mobilen, på alla planer. Eskalering kan hålla tillbaka en kanal i 5 till 60 minuter och larma bara om avbrottet fortfarande pågår och ingen har bekräftat det.
Gör ansvaret tydligt
Ett larm som skickas till fem personer bekräftas ofta av ingen. Utse en ansvarig per tjänst och en jourhavande per pass. Alla andra får informationen, inte ansvaret. Med jourscheman i Uptimecheck turas folk om, med undantag för en sjukdag eller ett byte, och pushlarm når den som har jour just nu.
Så kortar du tiden till åtgärd
Skriv runbooks för kända fel
De flesta incidenter upprepas. Disken blir full, en pool av workers tar slut, en certifikatförnyelse misslyckas. En kort runbook per monitor gör en halvsovande felsökning till en checklista:
Runbook: kassan svarar 503
1. Kolla serverdashboarden: CPU, minne, disk på web-01 och web-02.
2. Kolla PHP-FPM-status: sudo systemctl status php8.3-fpm
3. Om alla workers är upptagna: sudo systemctl restart php8.3-fpm
4. Leta efter jobb som kör länge: ps aux –sort=-%cpu | head
5. Fungerar det fortfarande inte efter 10 minuter? Eskalera till ansvarig utvecklare.
Ha länken till runbooken där larmet landar, till exempel fäst i incidentkanalen, så att den bara är ett tryck bort.
Se orsak och symptom sida vid sida
När en webbplatskontroll misslyckas är den första frågan oftast om servern har slut på minne, CPU eller disk. Med servermått bredvid upptidskontrollerna krymper det steget från en SSH-session till en snabb blick.
Gör det enkelt att rulla tillbaka
Många incidenter börjar med en deploy. Om det räcker med ett kommando för att rulla tillbaka tar återställningen minuter. Om det kräver ett möte tar den en timme.
Uppdatera statussidan tidigt
En statussida kortar inte själva avbrottet, men den kortar det som kunderna upplever som värst: att inte veta. Den hindrar också att supporten översvämmas medan teamet åtgärdar problemet. En statussida som är kopplad till dina monitorer visar den drabbade komponenten så fort incidenten öppnas; lägg till en kort notis om vad ni gör och när ni uppdaterar nästa gång.
Så förbättrar du MTBF
Färre incidenter får du genom att lära dig av dem du har haft. Skriv en skuldfri postmortem efter varje större incident, kom överens om en eller två åtgärdspunkter och följ upp dem tills de är klara. Efter några månader slutar samma fel att komma tillbaka och MTBF stiger.
Börja mäta med riktiga tidsstämplar. Prova Uptimecheck gratis i 14 dagar, inget kreditkort krävs.