MTTR (mean time to recovery, eller repair) er gjennomsnittlig tid fra en hendelse starter til tjenesten fungerer igjen. MTTA (mean time to acknowledge) er gjennomsnittlig tid fra et varsel går ut til noen bekrefter at de jobber med saken. MTBF (mean time between failures) er gjennomsnittlig tid en tjeneste går normalt mellom hendelser. Sammen beskriver de påliteligheten: MTBF sier hvor ofte ting går i stykker, MTTA hvor raskt dere reagerer og MTTR hvor lenge kundene blir berørt.
Denne guiden går gjennom definisjonene, formlene, et utregnet eksempel med tall, hvilke tidspunkter du bør samle inn og de praktiske endringene som forbedrer hver måleverdi.
Måleverdiene og hva de måler
MTTR: fire betydninger, én forkortelse
MTTR er den mest siterte hendelsesmålingen og den mest forvirrende, fordi R-en står for forskjellige ting avhengig av hvem som bruker den:
Mean time to repair: fra reparasjonsarbeidet starter til løsningen er på plass. Vanlig innen maskinvare og vedlikehold.
Mean time to recovery (eller restore): fra nedbruddet starter til tjenesten fungerer igjen for brukerne. Den mest nyttige varianten for nettsteder og API-er.
Mean time to respond: fra varselet går ut til teamet begynner å handle. Ligger nær MTTA.
Mean time to resolve: til hendelsen er helt avsluttet, inkludert oppfølgingen som hindrer at den skjer igjen.
Ingen av dem er feil. Det viktige er at du velger én, skriver ned definisjonen og bruker den konsekvent. Å sammenligne ditt «recovery»-tall med noen andres «repair»-tall sier deg ingenting. I denne artikkelen betyr MTTR mean time to recovery: fra tjenesten sluttet å fungere til den fungerte igjen.
MTTD og MTTA: responsen før reparasjonen
MTTD (mean time to detect) er tiden fra en hendelse starter til overvåkingen sender et varsel. MTTA er tiden fra det varselet til en person bekrefter det. Begge inngår i MTTR, og det er derfor de betyr så mye: ingen kan rette et problem de ikke har hørt om.
MTBF: hvor ofte ting går i stykker
MTBF er gjennomsnittlig oppetid mellom hendelser. Jo høyere tall, jo bedre. Søskenbegrepet MTTF (mean time to failure) brukes om ting som byttes ut i stedet for å repareres, for eksempel disker. For nettjenester er det MTBF du trenger.
Formlene
MTTD = total time from incident start to alert / number of incidents
MTTA = total time from alert to acknowledgement / number of incidents
MTTR = total time from incident start to recovery / number of incidents
MTBF = total operating time without incidents / number of incidents
Availability = MTBF / (MTBF + MTTR)
Den siste linjen viser hvorfor begge sider teller. Du kan øke tilgjengeligheten ved å ha færre hendelser (høyere MTBF) eller ved å gjøre dem kortere (lavere MTTR). Å gjøre dem kortere er ofte langt billigere.
Et utregnet eksempel
Her er en eksempelmåned for en nettbutikk med fire hendelser. Tallene er oppdiktet for å illustrere, men tidspunktene er av den typen ethvert overvåkingsverktøy gir deg.
HendelseStartetVarselBekreftetGjenopprettetOppdagetBekreftelseGjenopprettingKassen gir 50303:1203:1303:1603:191 min3 min7 minTidsavbrudd i API-et10:0510:0610:0810:411 min2 min36 minInnloggingsfeil14:3014:3114:4515:021 min14 min32 minSøket nede22:5022:5122:5623:151 min5 min25 min
Bruk så formlene:
MTTD = (1 + 1 + 1 + 1) / 4 = 1 minutt.
MTTA = (3 + 2 + 14 + 5) / 4 = 6 minutter.
MTTR = (7 + 36 + 32 + 25) / 4 = 25 minutter.
MTBF: en måned på 30 dager har 43 200 minutter. Minus 100 minutter nedetid gir 43 100. Delt på 4 hendelser blir MTBF 10 775 minutter, omtrent 7,5 dager.
Tilgjengelighet = 10 775 / (10 775 + 25) = 99,77 %.
To ting skiller seg ut. Bekreftelsen på 14 minutter ved innloggingshendelsen trekker MTTA opp fra rundt 3 minutter til 6, så det er verdt å spørre hvorfor ingen tok det varselet. Og med 99,77 % ligger butikken godt under et mål på 99,9 %, som bare tillater 43 minutter i måneden. Hvis du setter slike mål, kan du lese SLA vs. SLO vs. SLI om hvordan de henger sammen.
Tenk deg nå den samme måneden med sjekker hvert femte minutt og uten bekreftelsestrinn. Det kan da ta opptil fem minutter i stedet for ett å oppdage feilen, noe som legger opptil fire minutter til hver hendelse. MTTR stiger fra 25 til opptil 29 minutter uten at noen har gjort noe annerledes.
Hvilke tidspunkter du bør samle inn
Du trenger fire tidspunkter per hendelse. De fleste kommer rett fra overvåkingen:
Start: den første mislykkede sjekken. Ekstern overvåking registrerer den selv når serverne dine ikke logger noe.
Varsel: når feilen ble bekreftet og varselet gikk ut.
Bekreftet: når en person sa «jeg tar den». Har du ikke et vaktverktøy, fungerer et svar i hendelseskanalen; noter tidspunktet. I Uptimecheck bekrefter du hendelsen i appen eller, med Slack-appen, med en knapp i Slack, og tidspunktet blir registrert.
Gjenopprettet: den første vellykkede sjekken etter hendelsen, som også er når varselet om gjenoppretting går ut.
Med Uptimecheck har hver hendelse en tidslinje: når den startet, hvem som ble varslet og når, bekreftelser (også med en knapp i Slack når du bruker Slack-appen), notater og gjenopprettingen. MTTA og MTTR regnes ut for deg, og rapportens CSV-eksport gir hver monitors antall hendelser, nedetid og lengste hendelse til et regneark. Legg til det dere lærte i en postmortem.
En praktisk advarsel: gjennomsnitt skjuler avvik. Én hendelse på seks timer og ni små utfall på ett minutt gir et gjennomsnitt på rundt 37 minutter, som ikke beskriver noen av dem. Se på medianen og den lengste hendelsen ved siden av gjennomsnittet, og gå gjennom de tregeste hendelsene én etter én.
Slik kutter du tiden det tar å oppdage feil
Sjekk hvert minutt
Sjekkintervallet er den øvre grensen for hvor lang tid det tar å oppdage en feil. Sjekker hvert minutt på alt som tjener penger eller betjener kunder, er den aller billigste forbedringen av MTTR. Bruk oppetidsovervåking med 1 minutts intervall for alle kritiske sider og endepunkter.
Sjekk det som går i stykker, ikke bare det som laster
Hendelser som overvåkingen ikke ser, blir oppdaget av kundene, ofte timer senere. Valider innholdet på viktige sider, overvåk API-endepunktene appene er avhengige av, og legg til heartbeats på planlagte jobber. Hver hendelse som en kunde melder fra om først, er et hull i overvåkingen din.
Slik kutter du tiden til bekreftelse
Send bare bekreftede varsler
Treg bekreftelse er som regel et tillitsproblem. Hvis halvparten av varslene er falske, lærer folk seg å vente og se. Bekreft hver feil med en ny sjekk før du varsler, og fjern monitorer som varsler uten at noen trenger å gjøre noe. Guiden vår om å redusere falske varsler går gjennom detaljene.
Send varslene til riktig kanal
En e-post klokken 03:12 blir lest klokken 07:30. Send kritiske monitorer til en kanal som når mobilen til den som har vakt, og til en teamchat for alle andre, og la mindre hastende monitorer gå på e-post. I Uptimecheck velger du varslingskanaler per monitor: e-post, Slack, Microsoft Teams, Discord, Google Chat, Mattermost, Telegram, PagerDuty, ntfy, Pushover, webhooks og push-varsler på mobilen, på alle planer. Eskalering kan holde en kanal tilbake i 5 til 60 minutter og bare varsle hvis nedbruddet fortsatt pågår og ingen har bekreftet det.
Gjør ansvaret tydelig
Et varsel som sendes til fem personer, blir ofte ikke bekreftet av noen. Utpek én eier per tjeneste og én vakthavende per vakt. Alle andre får informasjonen, ikke ansvaret. Med vaktplaner i Uptimecheck bytter folk på å ha vakt, med unntak ved sykdom eller vaktbytte, og push-varsler når den som har vakt akkurat nå.
Slik kutter du reparasjonstiden
Skriv runbooks for kjente feil
De fleste hendelser gjentar seg. Disken blir full, en worker-pool går tom, en sertifikatfornyelse feiler. En kort runbook per monitor gjør en halvsøvnig feilsøking om til en sjekkliste:
Runbook: checkout returns 503
1. Check the server dashboard: CPU, memory, disk on web-01 and web-02.
2. Check PHP-FPM status: sudo systemctl status php8.3-fpm
3. If workers are exhausted: sudo systemctl restart php8.3-fpm
4. Check for long-running jobs: ps aux –sort=-%cpu | head
5. Still failing after 10 minutes? Escalate to the lead developer.
Ha lenken til runbooken der varselet kommer, for eksempel festet i hendelseskanalen, så den er ett trykk unna.
Se årsak og symptom side om side
Når en sjekk av nettstedet feiler, er det første spørsmålet som regel om serveren er tom for minne, CPU eller disk. Med servermålinger ved siden av oppetidssjekkene går det steget fra en SSH-økt til et raskt blikk.
Gjør det enkelt å rulle tilbake
Mange hendelser starter med en deploy. Er tilbakerulling én kommando, tar gjenopprettingen minutter. Krever det et møte, tar det en time.
Oppdater statussiden tidlig
En statusside gjør ikke selve nedbruddet kortere, men den forkorter den delen kundene opplever som verst: uvissheten. Den hindrer også at supporten blir oversvømt mens teamet retter problemet. En statusside koblet til monitorene dine viser den berørte komponenten så snart hendelsen åpnes. Legg til en kort melding om hva dere gjør, og når neste oppdatering kommer.
Slik forbedrer du MTBF
Færre hendelser får du ved å lære av dem du har hatt. Etter hver større hendelse skriver dere en postmortem uten skyldfordeling, blir enige om ett eller to tiltak og følger dem opp til de er gjennomført. I løpet av noen måneder slutter de samme feilene å komme tilbake, og MTBF stiger.
Begynn å måle med ekte tidspunkter. Prøv Uptimecheck gratis i 14 dager, uten kredittkort.