Belangrijkste punten
- MTTR is een gemiddelde hersteltijd: MTTR is de gemiddelde tijd om een dienst of functionaliteit na een incident te herstellen, op basis van vastgelegde start- en eindpunten.
- Leg de betekenis van MTTR vast: MTTR wordt uitgelegd als repareren, herstellen of oplossen. Teams moeten dus benoemen wat de start- en eindtijdstempels voorstellen om misleidende vergelijkingen te voorkomen.
- De berekening van MTTR is eenvoudig maar afhankelijk van definities: MTTR is de totale reparatietijd gedeeld door het aantal reparaties of incidenten. Inconsistente incidentgrenzen zorgen voor ruis.
- Volg de verdeling, niet alleen het gemiddelde: de mediaan en percentielen (p75/p90) beperken de vertekening door uitschieters en maken trendanalyse betrouwbaarder dan alleen gemiddelden.
- MTTR verschilt van betrouwbaarheids- en detectiegegevens: MTBF meet de tijd tussen storingen, MTTD meet de detectiesnelheid en sommige teams gebruiken MTTR als “opgelost”, waardoor de meting iets anders vastlegt.
MTTR (Mean Time To Repair) is een belangrijke meting die de gemiddelde tijd aangeeft om een systeem of onderdeel te repareren. Het is een van de meest aangehaalde gegevens in IT-operations. Maar pas als u begrijpt wat de cijfers werkelijk voorstellen, kunnen uw technici zich blijven verbeteren in plaats van hun toevlucht te nemen tot oppervlakkige (en vaak kostbare) oplossingen.
MTTR weerspiegelt de operationele efficiëntie
Om MTTR te begrijpen, kijken we naar het doel, de berekening en de unieke inzichten die deze meting oplevert.
Wat MTTR meet
Atlassian definieert MTTR als de gemiddelde tijd om te herstellen van een storing, waarbij de tijd tussen de uitval en de volledig werkende situatie wordt gemeten. Eenvoudig gezegd: het is de tijd die uw troubleshootingteam nodig had om een systeem of tool weer werkend te krijgen.
De MTTR-meting legt de tijd vast tussen de storing of het “begin van het incident” en de volledig herstelde systeemprestaties. Daarmee is het een waardevol hulpmiddel om trends te volgen en prestaties van tools vóór en na een wijziging te vergelijken, zeker wanneer u naast het gemiddelde ook de mediaan en de percentielen (p75/p90) bijhoudt.
Hoe MTTR wordt berekend
MTTR is een eenvoudig gemiddelde van de duur van incidenten. IBM geeft de standaardformule voor MTTR als volgt weer:
MTTR = totale reparatietijd ÷ aantal reparaties
Om MTTR nauwkeurig te meten, moet u de tijd voor detectie, diagnose en reparatie bijhouden. Leg start en einde consistent vast in uw metingen, anders loopt uw MTTR het risico ruis toe te voegen aan uw rapportages.
Zo berekent u MTTR in Excel:
- Exporteer incidentgegevens uit uw ITSM of RMM (bijvoorbeeld incident-ID, starttijdstempel, hersteltijdstempel of tijdstempel van oplossing).
- Open Microsoft Excel.
- Open het tabblad Gegevens en klik op Van tekst/CSV > uw exportbestand > Laden.
- Voeg een kolom toe (bijvoorbeeld DurationMinutes).
- Gebruik deze formule om de duur bij te houden:
=(EndTime-StartTime)*1440
- Gebruik deze formule om MTTR te berekenen:
=AVERAGE(DurationMinutesRange)
- Leg uw definitie vast in het werkblad (notitie in de bovenste rij):
- “Start = tijdstip van de storing” of “Start = tijdstip van detectie”
- “Einde = dienst hersteld” of “Einde = incident opgelost”
MTTR tegenover verwante metingen
Verschillende metingen in IT-operations leggen elk een eigen aspect van de operationele betrouwbaarheid vast. Het is essentieel om MTTR daarvan te onderscheiden, zodat businessreviews soepel verlopen en verwarring uitblijft.
Dit zijn de belangrijkste verschillen die u moet kennen:
- Mean Time Between Failures (MTBF): de gemiddelde tijd tussen de ene systeemstoring en de volgende.
- Mean Time To Detect (MTTD): de gemiddelde tijd die nodig is om vast te stellen dat er een storing, beveiligingslek of incident heeft plaatsgevonden.
- Mean Time To Resolve: sommige organisaties hanteren deze definitie voor MTTR en voegen er preventieve maatregelen aan toe om herhaling te voorkomen.
Veelvoorkomende valkuilen bij MTTR
Het Site Reliability Engineering (SRE)-platform van Google waarschuwt voor simplistische “MTTx”-cijfers en hoe die eerder misleiden dan richting geven. Zorgvuldige analyse en goede datakwaliteit wegen zwaar mee om MTTR correct te berekenen.
Dit zijn de meest voorkomende valkuilen bij MTTR in IT-operations:
- Detectie- of diagnosetijd buiten de meting laten
- Incidenten afsluiten voordat de dienst volledig is hersteld
- Focussen op symptomen in plaats van op onderliggende oorzaken
- MTTR vergelijken tussen systemen of omgevingen die niets met elkaar te maken hebben
MTTR als indicator van volwassenheid
Mits juist geïnterpreteerd kan MTTR laten zien waar operationele verbetering mogelijk is. Dat is nuttig bij het beoordelen van gehardende systemen en het volgen van trends, wat iets zegt over de volwassenheid van uw organisatie.
🥷🏻| Door de tools waarmee uw organisatie beveiligingslekken en systeemstoringen opspoort en vastlegt te centraliseren, krijgt u eenvoudiger en beter inzicht.
Lees hoe de functies van NinjaOne de operationele efficiëntie op peil houden.
Belangrijke aandachtspunten
Herstelsnelheid alleen bepaalt niet de betrouwbaarheid. Een systeem dat snel hersteld is maar vaak uitvalt, leidt tot een slechte klantervaring en meer overhead op termijn. Daarom benadrukt DevOps Research and Assessment (DORA) dat u MTTR samen met andere metingen moet interpreteren in plaats van als “losstaande score”.
Het is ook belangrijk om te weten waar het incident plaatsvond: een lage MTTR op een ondersteunende tool weegt minder zwaar dan een snelle hersteltijd op risicovolle systemen. Bij MTTR draait het om kadering. Geef dus altijd context om misleidende conclusies te voorkomen.
Daarnaast is het belangrijk om een set metingen bij te houden in plaats van alleen MTTR, zodat u complete rapportages krijgt, uitkomsten vooropstelt en de cijfers zorgvuldig interpreteert.
Veelvoorkomende problemen om te beoordelen
MTTR verbetert maar incidenten blijven
Het kan voorkomen dat uw MTTR laag blijft terwijl het aantal incidenten blijft stijgen. Voor troubleshooting op de lange termijn bekijkt u de onderliggende oorzaken van elk probleem en elke systeemstoring voordat u definitieve oplossingen doorvoert.
MTTR schommelt sterk
Als uw MTTR-grafiek grillig verloopt, kan dat liggen aan een inconsistente afbakening, door elkaar lopende prioriteiten, slechte definities of alle vier. Splits uw aanpak op om die problemen aan te pakken (bijvoorbeeld aparte teams voor verschillende prioriteiten) voor een consistente indeling en betere resultaten bij troubleshooting.
MTTR lijkt onrealistisch laag
Als uw MTTR te mooi lijkt om waar te zijn, komt dat meestal door te vroeg afgesloten incidenten. Met andere woorden: bestempelt u een melding te snel als “opgelost”, dan vertekent dat uw MTTR aanzienlijk. Haast u dus niet en definieer en verzamel uw metingen in elk scenario zorgvuldig.
Teams willen MTTR niet bijhouden
Cultureel gezien verzetten teams zich alleen tegen metingen wanneer die worden gebruikt om hen in verlegenheid te brengen of hun werk te bagatelliseren. Maak duidelijkere definities en interpreteer die naast andere indicatoren (zoals impact, herhaling en storingsfrequentie) om besluitvorming op de lange termijn te ondersteunen.
De integratie met NinjaOne vergroot het inzicht op schaal
De unified endpoint manager van NinjaOne geeft u meer inzicht in notificaties, incidenten en herstelgebeurtenissen die uw metingen beïnvloeden. Wie MTTR begrijpt, interpreteert deze gegevens correct en richt verbeteringen op de detectie-, respons- en herstelworkflows die er het meest toe doen.
MTTR is een belangrijk onderdeel van uw IT-operationsmetingen
MTTR staat voor de gemiddelde tijd waarin een systeemfout of storing wordt verholpen en dient als instrument om uw troubleshootingvaardigheid over de tijd te meten. Volwassen IT-teams die deze meting samen met andere gegevens gebruiken om workflows continu te verfijnen, boeken het meeste succes.
Gerelateerde onderwerpen:
