MTTR kan betyde Mean Time to Repair, Recovery eller Restore afhængigt af konteksten. Derfor bør organisationen altid dokumentere den konkrete definition.
Begreb
MTTR
MTTR er en forkortelse, der typisk bruges om Mean Time to Repair, Mean Time to Recovery eller Mean Time to Restore. Fælles for varianterne er, at målingen beskriver den gennemsnitlige tid, det tager at få en berørt tjeneste eller komponent tilbage til normal drift efter en fejl eller hændelse.
Hvorfor er begrebet vigtigt?
MTTR er vigtigt, fordi det giver et konkret mål for, hvor effektivt en organisation håndterer driftsproblemer. En lavere MTTR kan betyde, at fejl opdages, diagnosticeres og afhjælpes hurtigere, så påvirkningen for brugerne bliver mindre.
For virksomheder kan udviklingen i MTTR bruges til at vurdere, om processer, værktøjer, dokumentation og beredskab forbedrer evnen til at genoprette tjenester.
Typisk misforståelse
Den mest almindelige fejl er at bruge MTTR uden at definere, hvad tiden måles fra og til. Resultatet kan være misvisende, hvis ét team måler fra første fejl til fuld genopretning, mens et andet måler fra alarmen bliver modtaget til en teknisk reparation er gennemført.
Eksempel
En tjeneste har tre hændelser på en måned, hvor genopretningen tager henholdsvis 20, 40 og 60 minutter. Hvis alle hændelser måles efter samme definition, er den gennemsnitlige MTTR 40 minutter.
Best practice
Definér præcist, hvad MTTR betyder i organisationen.
Fastlæg tydelige start- og sluttidspunkter for målingen.
Brug samme definition på tværs af sammenlignelige tjenester.
Kombinér MTTR med andre mål som MTTD og antal hændelser.
Undersøg årsagerne bag ændringer i MTTR frem for kun selve tallet.
Brug postmortems og runbooks til løbende at forbedre genopretningstiden.
Frequently asked questions
En lav MTTR er normalt positiv, men tallet skal vurderes sammen med hændelsernes alvor, kvaliteten af genopretningen og andre driftsmål. Hurtige midlertidige løsninger kan ellers give et misvisende billede.
Typiske forbedringer omfatter bedre monitoring, tydeligere alarmer, dokumenterede runbooks, klare eskaleringsveje, automatisering og læring fra tidligere hændelser.