MTTR (mean time to recovery eller repair) er den gennemsnitlige tid fra en hændelse begynder, til tjenesten virker igen. MTTA (mean time to acknowledge) er den gennemsnitlige tid fra en alarm, til nogen bekræfter, at de arbejder på den. MTBF (mean time between failures) er den gennemsnitlige tid, en tjeneste kører normalt mellem hændelser. Tilsammen beskriver de pålidelighed: MTBF siger, hvor ofte noget går i stykker, MTTA hvor hurtigt I reagerer, og MTTR hvor længe kunderne er ramt.
Denne guide gennemgår definitionerne, formlerne, et regneeksempel med tal, hvilke tidsstempler du skal indsamle, og de praktiske ændringer, der forbedrer hver måling.
Målingerne og hvad de måler
MTTR: fire betydninger, én forkortelse
MTTR er den mest citerede hændelsesmåling og den mest forvirrende, fordi R’et står for noget forskelligt, alt efter hvem der bruger den:
Mean time to repair: fra reparationsarbejdet begynder, til rettelsen er på plads. Udbredt inden for hardware og vedligeholdelse.
Mean time to recovery (eller restore): fra nedbruddet begynder, til tjenesten virker igen for brugerne. Den mest brugbare udgave for websites og API’er.
Mean time to respond: fra alarmen, til teamet begynder at handle. Tæt på MTTA.
Mean time to resolve: indtil hændelsen er helt afsluttet, inklusive den opfølgning, der forhindrer, at den sker igen.
Ingen af dem er forkert. Det vigtige er, at du vælger én, skriver definitionen ned og bruger den konsekvent. At sammenligne dit “recovery”-tal med en andens “repair”-tal fortæller dig ingenting. I denne artikel betyder MTTR mean time to recovery: fra tjenesten gik ned, til den virkede igen.
MTTD og MTTA: reaktionen før reparationen
MTTD (mean time to detect) er tiden fra en hændelse begynder, til overvågningen slår alarm. MTTA er tiden fra den alarm, til en person kvitterer for den. Begge ligger inden i MTTR, og derfor betyder de så meget: Ingen kan løse et problem, de ikke har hørt om.
MTBF: hvor ofte noget går i stykker
MTBF er den gennemsnitlige oppetid mellem hændelser. Jo højere tal, jo bedre. Søskendemålingen MTTF (mean time to failure) bruges til ting, der udskiftes i stedet for at blive repareret, f.eks. diske; for onlinetjenester er det MTBF, du har brug for.
Formlerne
MTTD = samlet tid fra hændelsens start til alarm / antal hændelser
MTTA = samlet tid fra alarm til kvittering / antal hændelser
MTTR = samlet tid fra hændelsens start til genopretning / antal hændelser
MTBF = samlet driftstid uden hændelser / antal hændelser
Tilgængelighed = MTBF / (MTBF + MTTR)
Den sidste linje viser, hvorfor begge sider tæller. Du kan forbedre tilgængeligheden ved at have færre hændelser (højere MTBF) eller ved at gøre dem kortere (lavere MTTR). At gøre dem kortere er ofte langt billigere.
Et regneeksempel
Her er en eksempelmåned for en webshop med fire hændelser. Tallene er opfundet til illustration, men tidsstemplerne er af den slags, ethvert overvågningsværktøj giver dig.
HændelseStartetAlarmKvitteretGenoprettetOpdageKvittereGenopretteKasse 50303:1203:1303:1603:191 min3 min7 minAPI-timeouts10:0510:0610:0810:411 min2 min36 minLogin-fejl14:3014:3114:4515:021 min14 min32 minSøgning nede22:5022:5122:5623:151 min5 min25 min
Brug nu formlerne:
MTTD = (1 + 1 + 1 + 1) / 4 = 1 minut.
MTTA = (3 + 2 + 14 + 5) / 4 = 6 minutter.
MTTR = (7 + 36 + 32 + 25) / 4 = 25 minutter.
MTBF: en måned på 30 dage har 43.200 minutter. Minus 100 minutters nedetid giver 43.100. Delt med 4 hændelser er MTBF 10.775 minutter, cirka 7,5 dage.
Tilgængelighed = 10.775 / (10.775 + 25) = 99,77 %.
To ting springer i øjnene. De 14 minutter, det tog at kvittere for login-hændelsen, trækker MTTA op fra cirka 3 minutter til 6, så det er værd at spørge, hvorfor ingen tog den alarm. Og med 99,77 % ligger webshoppen et godt stykke under et mål på 99,9 %, som kun tillader 43 minutter om måneden. Hvis du sætter den slags mål, kan du læse SLA vs. SLO vs. SLI om, hvordan de hænger sammen.
Forestil dig nu den samme måned med tjek hvert femte minut og uden bekræftelsestrin. Det kunne tage op til fem minutter at opdage en fejl i stedet for ét, hvilket lægger op til fire minutter oven i hver hændelse. MTTR stiger fra 25 til op til 29 minutter, før nogen har gjort noget anderledes.
Hvilke tidsstempler du skal indsamle
Du skal bruge fire tidsstempler pr. hændelse. De fleste kommer direkte fra overvågningen:
Start: det første fejlede tjek. Ekstern overvågning registrerer det, selv når dine servere ikke logger noget.
Alarm: da fejlen blev bekræftet, og notifikationen blev sendt.
Kvitteret: da en person sagde “Jeg tager den”. Har du intet vagtværktøj, kan et svar i hændelseskanalen gøre det; notér tidspunktet. I Uptimecheck kvitterer du for hændelsen i appen eller, med Slack-appen, med en knap i Slack, og tidspunktet bliver registreret.
Genoprettet: det første beståede tjek efter hændelsen, som også er tidspunktet, hvor besked om genoprettelse bliver sendt.
Med Uptimecheck har hver hændelse en tidslinje: hvornår den startede, hvem der fik en alarm og hvornår, kvitteringer (også med en knap i Slack, når du bruger Slack-appen), noter og genoprettelsen. MTTA og MTTR bliver beregnet for dig, og rapportens CSV-eksport giver hver monitors antal hændelser, nedetid og længste hændelse til et regneark. Saml det, I har lært, i en postmortem.
En praktisk advarsel: Gennemsnit skjuler afvigere. Én hændelse på seks timer og ni små udfald på et minut giver et gennemsnit på cirka 37 minutter, som ikke beskriver nogen af dem. Se på medianen og den længste hændelse ved siden af gennemsnittet, og gennemgå de langsomste hændelser én for én.
Sådan forkorter du tiden til opdagelse
Tjek hvert minut
Tjekintervallet er den øvre grænse for, hvor lang tid det tager at opdage en fejl. Tjek hvert minut på alt, der tjener penge eller betjener kunder, er den enkleste og billigste forbedring af MTTR. Brug oppetidsovervågning hvert minut på alle kritiske sider og endpoints.
Tjek det, der går i stykker, ikke kun det, der indlæses
Hændelser, som overvågningen ikke ser, bliver opdaget af kunderne, ofte timer senere. Validér indholdet på vigtige sider, overvåg de API-endpoints, apps er afhængige af, og tilføj heartbeats til planlagte jobs. Hver hændelse, som en kunde melder først, er et hul i din overvågning.
Sådan forkorter du tiden til kvittering
Send kun bekræftede alarmer
Langsom kvittering er som regel et tillidsproblem. Hvis halvdelen af alarmerne er falske, lærer folk at vente og se. Bekræft hver fejl med et ekstra tjek, før der sendes en alarm, og fjern monitorer, der sender alarmer, uden at nogen behøver at handle. Vores guide til at reducere falske alarmer går i detaljer.
Send alarmer til den rigtige kanal
En e-mail kl. 03:12 bliver læst kl. 07:30. Send kritiske monitorer til en kanal, der når vagthavendes telefon, og til en teamchat for alle andre, og lad mindre presserende monitorer blive på e-mail. I Uptimecheck vælger du alarmkanaler pr. monitor: e-mail, Slack, Microsoft Teams, Discord, Google Chat, Mattermost, Telegram, PagerDuty, ntfy, Pushover, webhooks og push-notifikationer på telefonen, på alle planer. Eskalering kan holde en kanal tilbage i 5 til 60 minutter og kun sende en alarm, hvis nedbruddet stadig står på, og ingen har kvitteret for det.
Gør ansvaret tydeligt
En alarm, der sendes til fem personer, bliver ofte ikke kvitteret af nogen. Udpeg én ejer pr. tjeneste og én vagthavende pr. vagt. Alle andre får informationen, ikke ansvaret. Med Uptimechecks vagtplaner skiftes folk til at have vagten, med undtagelser ved en sygedag eller et bytte, og push-alarmer når den, der har vagten lige nu.
Sådan forkorter du reparationstiden
Skriv runbooks til kendte fejl
De fleste hændelser gentager sig. Disken bliver fuld, en worker-pulje løber tør, en certifikatfornyelse fejler. En kort runbook pr. monitor gør en halvsøvnig fejlsøgning til en tjekliste:
Runbook: kassen returnerer 503
1. Tjek serverens dashboard: CPU, hukommelse, disk på web-01 og web-02.
2. Tjek PHP-FPM-status: sudo systemctl status php8.3-fpm
3. Hvis alle workers er optaget: sudo systemctl restart php8.3-fpm
4. Tjek for langvarige jobs: ps aux –sort=-%cpu | head
5. Fejler det stadig efter 10 minutter? Eskalér til den ledende udvikler.
Hav linket til runbooken der, hvor alarmen lander, f.eks. fastgjort i hændelseskanalen, så den er ét tryk væk.
Sæt årsag og symptom side om side
Når et tjek af et website fejler, er det første spørgsmål som regel, om serveren er løbet tør for hukommelse, CPU eller disk. Når servermålinger ligger ved siden af oppetidstjekkene, bliver det trin forkortet fra en SSH-session til et hurtigt blik.
Gør det let at rulle tilbage
Mange hændelser begynder med et deploy. Hvis tilbagerulning er én kommando, tager genopretningen minutter. Hvis det kræver et møde, tager den en time.
Opdatér statussiden tidligt
En statusside gør ikke selve nedbruddet kortere, men den forkorter den del, kunderne oplever som værst: uvisheden. Den forhindrer også, at supporten bliver oversvømmet, mens teamet løser problemet. En statusside, der er forbundet med dine monitorer, viser den berørte komponent, så snart hændelsen åbnes; tilføj en kort note om, hvad I gør, og hvornår I opdaterer næste gang.
Sådan forbedrer du MTBF
Færre hændelser kommer af at lære af dem, I har haft. Skriv efter hver væsentlig hændelse en postmortem uden skyld, aftal et eller to handlingspunkter, og følg dem, til de er gennemført. I løbet af nogle måneder holder de samme fejl op med at vende tilbage, og MTBF stiger.
Begynd at måle med rigtige tidsstempler. Prøv Uptimecheck gratis i 14 dage, uden kreditkort.