Mean Time to Repair (MTTR)

Allgemeine Infos

MTTR ist eine Kennzahl für die durchschnittliche Dauer, die vergeht, bis ein ausgefallenes System, eine Komponente oder ein Service wieder funktioniert. Sie stammt aus der Instandhaltung und Zuverlässigkeitstechnik und wird in der IT im Incident Management, im Availability Management und im Betrieb von Cloud-Workloads genutzt.

Das Kürzel ist mehrdeutig: Mean Time to Repair zählt im engeren Sinn nur die aktive Reparaturzeit, Mean Time to Recovery bzw. Restore die gesamte Zeit vom Ausfall bis zum wiederhergestellten Betrieb inklusive Erkennung und Reaktion, Mean Time to Resolve in der IT oft die Zeit vom Ticket bis zum Abschluss. Microsoft definiert MTTR im Azure Well-Architected Framework als Zeit bis zur Wiederherstellung einer Komponente, nachdem ein Ausfall erkannt wurde. Wer MTTR vergleicht, muss deshalb dieselbe Definition verwenden.

Im DevOps-Umfeld hat DORA die frühere MTTR-Kennzahl in seinem aktuellen Modell mit fünf Metriken durch Failed Deployment Recovery Time ersetzt, also die Zeit zur Wiederherstellung nach einem fehlgeschlagenen Deployment.

Abgrenzung: Die MTBF (Mean Time Between Failures) misst die Zeit zwischen Ausfällen, MTTR die Dauer eines Ausfalls. RPO und RTO sind Zielvorgaben für den Notfall, MTTR ist ein gemessener Durchschnitt. Availability Management nutzt MTTR und MTBF zur Berechnung der Verfügbarkeit, ein Service Level Agreement legt die vertraglich zugesagte Wiederherstellungszeit fest.

Funktionsweise & Details

Die Berechnung folgt einem einfachen Prinzip:

  1. Für jeden Ausfall im Betrachtungszeitraum werden Beginn und Ende erfasst, Beginn je nach Definition als Ausfallzeitpunkt, Erkennung oder Ticketerstellung, Ende als wiederhergestellter Betrieb.
  2. MTTR = Summe der Ausfall- bzw. Reparaturzeiten geteilt durch die Anzahl der Ausfälle.
  3. Mit der MTBF ergibt sich die stationäre Verfügbarkeit: Verfügbarkeit = MTBF / (MTBF + MTTR). Beispiel: Bei einer MTBF von 500 Stunden und einer MTTR von 2 Stunden liegt die Verfügbarkeit bei rund 99,6 Prozent.
  4. Für eine aussagekräftige Verfügbarkeit müssen MTBF und MTTR dieselbe Zeiterfassung nutzen. Wer nur die reine Reparaturzeit ansetzt und Wartezeiten auf Ersatzteile oder Techniker weglässt, rechnet die Verfügbarkeit zu hoch.

Praktisch liefern Ticket-System (Zeitstempel von Erstellung, Zuweisung, Lösung) und IT-Monitoring (Alarm- und Entwarnungszeitpunkt) die Daten. Hilfreich ist die Zerlegung in Teilzeiten wie Erkennen, Reagieren, Beheben und Bestätigen, weil sich so zeigt, wo die Zeit verloren geht.

Vorteile & Nutzen

  • Messbare Betriebsqualität: MTTR zeigt, wie schnell Dein Team Ausfälle tatsächlich behebt, unabhängig vom Gefühl im Tagesgeschäft.
  • Ansatzpunkte für Verbesserung: Die Zerlegung in Erkennungs-, Reaktions- und Behebungszeit zeigt, ob Monitoring, Bereitschaft oder Dokumentation der Engpass ist.
  • Grundlage für Verfügbarkeitsziele: Zusammen mit der MTBF lässt sich berechnen, welche Verfügbarkeit realistisch zusagbar ist.
  • Argumente für Investitionen: Eine hohe MTTR durch fehlende Ersatzteile oder Herstellersupport begründet Wartungsverträge, Ersatzhardware oder Redundanz.

Praxisbeispiel

Ein Logistikdienstleister mit 250 Mitarbeitenden misst die MTTR seiner Lagerverwaltungs-Server über das Ticket-System und stellt fest, dass ein großer Teil der Ausfallzeit auf das Warten auf den Hardware-Techniker entfällt. Die IT zerlegt die MTTR in Erkennung, Reaktion und Behebung und sieht, dass Monitoring und Bereitschaft gut funktionieren. Daraufhin schließt das Unternehmen für die kritischen Hosts einen Wartungsvertrag mit kürzerer Reaktionszeit ab und legt eine Ersatz-Netzwerkkarte ins Lager. Bei den folgenden Hardware-Ausfällen sinkt die MTTR deutlich, und die Verfügbarkeitszusage gegenüber den Kunden lässt sich mit Daten belegen.

Worauf sollte man achten?

  • Lege schriftlich fest, welche MTTR-Variante Du misst und wo Start- und Endzeitpunkt liegen, sonst sind Berichte zwischen Teams oder Dienstleistern nicht vergleichbar.
  • Betrachte neben dem Durchschnitt auch Median und Ausreißer, ein einzelner Großausfall verzerrt die MTTR stark.
  • Setze MTTR nicht als alleiniges Ziel für Admins, sonst werden Tickets vorschnell geschlossen. Kombiniere sie mit Wiederöffnungsquote und Problem Management.
  • Definiere MTBF-Ziele nur für Komponenten unter Deiner Kontrolle, denn bei SaaS- und PaaS-Diensten fallen Komponenten aus und erholen sich, ohne dass der Anbieter das meldet, darauf weist auch Microsoft im Well-Architected Framework hin.

Fazit

MTTR ist eine einfache, aber aussagekräftige Betriebskennzahl, wenn die Definition klar ist und die Daten aus Ticket-System und Monitoring stammen. Nutze sie zusammen mit der MTBF, um Verfügbarkeitsziele realistisch zu planen.