Was ist Mean-Time-To-Repair (MTTR)?

Die Mean Time To Repair beginnt in dem Moment, in dem ein Ausfall erkannt wird, und umfasst die Diagnose- und Reparaturzeit, das Testen sowie alle weiteren Aktivitäten bis zur erneuten Bereitstellung des Services für Endbenutzer. Eine kurze MTTR zeigt an, dass eine Komponente bzw. ein Service schnell repariert werden kann und damit einhergehende IT-Probleme wahrscheinlich nur geringfügige geschäftliche Auswirkungen haben. Eine lange MTTR weist darauf hin, dass der Ausfall eines Geräts eine erhebliche Serviceunterbrechung zur Folge haben und sich daher stärker auf das Geschäft auswirken könnte.

Laut ZK Research wird 90 Prozent der MTTR nur dafür aufgewendet, herauszufinden, dass es tatsächlich ein Problem gibt. Falsche Diagnosen und unzulängliche Reparaturen können die Mean Time To Repair ebenfalls verlängern. Eine lange MTTR sollte IT-Administratoren also dazu veranlassen, ihre Troubleshooting-Methode neu zu bewerten, um potenzielle Ausfallzeiten zu reduzieren. Dabei gilt es, den gesamten Lebenszyklus einzubeziehen – vom Monitoring und der Erkennung bis hin zur Diagnose und Problemlösung.

Die meisten SLAs (Service Level Agreements) enthalten die Mean Time To Repair in irgendeiner Form. Dabei ist zu beachten, dass die MTTR keine garantierte, sondern eine durchschnittliche Reparaturzeit angibt. Ein Anbieter, der mit einer MTTR von 24 Stunden wirbt, gibt damit an, wie lange die Ausführung einer Reparatur in der Regel dauert. Bei einzelnen Incidents kann diese Zeitangabe jedoch über- oder unterschritten werden. Je nach Kontext kann die für Mean Time to Repair häufig verwendete Abkürzung “MTTR” auch für Mean Time To Recovery, Mean Time To Resolve oder Mean Time To Resolution stehen. In allen Varianten meint der Begriff „Mean Time To Repair" jedoch die Zeitspanne, die das Troubleshooting und die Behebung eines Problems durchschnittlich in Anspruch nehmen.

Ausfallmetriken sind Leistungsindikatoren, mit denen Unternehmen die Zuverlässigkeit ihrer Geräte und Systeme nachverfolgen können. Die Bandbreite reicht von gängigen Desktop-Serviceanfragen wie der grundlegenden Fehlerbehebung bei einem Laptop oder Konnektivitätsproblemen bis hin zu Serverausfällen und anderen fehlerhaft arbeitenden Komponenten, die erhebliche Auswirkungen haben können.

Wie werden Ausfallmetriken wie MTTR, MTBF, MTTF, etc. definiert?

Der Begriff „Ausfall“ bezieht sich in diesem Fall nicht ausschließlich auf nicht funktionierende Geräte oder Systeme (wie einen abgestürzten Datei-Server), sondern kann auch Systeme bezeichnen, die zwar funktionieren, jedoch aufgrund eines Leistungsabfalls absichtlich offline genommen wurden. Jedes System, das die Zielvorgaben nicht erfüllt, kann als „Ausfall“ deklariert werden.

Zu den gängigen Ausfallmetriken gehören:

• Mean-Time-To-Repair (MTTR): Die durchschnittlich für die Reparatur und Wiederherstellung eines ausgefallenen Systems benötigte Zeit. Bei Mean Time To Repair handelt sich um eine Messgröße für die Wartbarkeit von reparierbaren Komponenten oder Services. Je nach Komplexität des Geräts und des zugehörigen Problems kann die MTTR in Minuten, Stunden oder Tagen gemessen werden. Die Abkürzung der MTTR kann dabei auch für Mean-Time-To-Recovery, Mean-Time-To-Resolve oder Mean-Time-To-Resolution stehen.
• Mean-Time-Between-Failure (MTTF): Die durchschnittliche Betriebsdauer zwischen einem Geräteausfall oder Systemabsturz und dem nächsten. In Unternehmen wird die MTBF herangezogen, um die Zuverlässigkeit und Verfügbarkeit von Systemen und Komponenten vorherzusagen. Diese Kennzahl wird durch Nachverfolgung der Zeitspanne zwischen System-/Komponentenausfällen während des normalen Betriebs berechnet.
• Mean-Time-To-Failure (MTTF): Die durchschnittliche Betriebsdauer eines Geräts oder Systems bis zum Ausfall. In der Regel erfassen IT-Teams die entsprechenden Daten, indem sie Systemkomponenten über mehrere Tage oder Wochen beobachten. Diese Kennzahl ähnelt zwar der MTBF, wird jedoch normalerweise verwendet, um Elemente zu beschreiben, die ausgetauscht werden müssen, z. B. ein Bandlaufwerk in einem Backup-Array, während die MTBF für Elemente verwendet wird, die entweder repariert oder ersetzt werden können.
• Mean-Time-To-Detect (MTTD): Die durchschnittliche Zeitspanne zwischen dem Eintreten eines Problems und dessen Erkennung. Die MTTD bezeichnet die Zeit, die vergeht, bevor die IT-Abteilung ein Service-Ticket erhält und die Stoppuhr für die MTTR startet.
• Mean-Time-To-Investigate (MTTI): Die durchschnittliche Zeitdauer zwischen der Erkennung eines IT-Incidents und dem Beginn der Untersuchung seiner Ursache mit Blick auf die Lösungsfindung. Mit anderen Worten, die Zeitspanne zwischen MTTD und dem Beginn der MTTR.
• Mean-Time-To-Restore-Service (MTRS): Die durchschnittliche Zeitspanne von der Erkennung eines Incidents bis zur erneuten Bereitstellung des betreffenden Systems oder der Komponente für die Benutzer. Die MTRS unterscheidet sich folgendermaßen von der MTTR: Während die MTTR angibt, wie lange es dauert, ein Element zu reparieren, bezieht sich die MTRS darauf, wie lange es dauert, den Service wiederherzustellen, nachdem das Element repariert wurde.
• Mean-Time-Between-System-Incidents (MTBSI): Die durchschnittliche Zeitspanne zwischen der Erkennung zweier aufeinanderfolgender Incidents. Die MTBSI wird durch Addition von MTBF und MTRS berechnet (MTBSI = MTBF + MTRS).
• Ausfallrate (Failure Rate): Eine weitere Metrik für die Zuverlässigkeit, mit der die Häufigkeit des Ausfalls einer Komponente oder eines Systems gemessen wird. Die Ausfallrate wird als Anzahl der Ausfälle pro Zeiteinheit angegeben.

Ausfallmetriken wie bspw. die Mean Time To Repair spielen eine entscheidende Rolle beim Umgang mit Ausfallzeiten und beim Management der potenziell negativen Auswirkungen auf das Unternehmen. Sie bieten der IT-Abteilung all jene quantitativen und qualitativen Daten, die sie benötigt, um besser für unvermeidliche Systemausfälle planen und die Reaktion darauf optimieren zu können.

Ausfallmetriken wie die MTTR können allerdings nur dann wirksam eingesetzt werden, wenn eine große Menge relevanter, genauer Daten erfasst wird. Manuell wäre dies eine mühsame und zeitintensive Angelegenheit, doch mit moderner Unternehmenssoftware lassen sich die erforderlichen Daten problemlos mit wenigen Klicks aus einer Vielzahl von Quellen sammeln und die entsprechenden Metriken berechnen.

Was versteht man unter Zuverlässigkeit, Verfügbarkeit und Wartbarkeit (RAM)?

Zuverlässigkeit, Verfügbarkeit und Wartbarkeit sind Merkmale des Systemdesigns, die Einfluss auf die Lebenszykluskosten eines Systems sowie auf dessen Fähigkeit haben, seine Aufgaben zu erfüllen. Im englischen Sprachraum werden die Begriffe Reliability, Availability und Maintainability oftmals auch als RAM abgekürzt. Dementsprechend kann RAM also auch als Messgröße verstanden werden, mit der das Vertrauen eines Unternehmens in seine Hardware, Software und Netzwerke beziffert wird.

Jedes dieser Merkmale kann Auskunft über die Stärken und Schwächen eines Systems und deren Auswirkungen auf die Produktivität, Kundenzufriedenheit und Unternehmensbilanz geben.

• Zuverlässigkeit (Reliability) bezieht sich auf die Wahrscheinlichkeit, dass ein System seine vorgesehene Funktion über einen bestimmten Zeitraum hinweg ausfallfrei erfüllt. Da die Zuverlässigkeit bis zu einem gewissen Grad von der Qualität eines Produkts abhängt, ist sie ein inhärentes Merkmal der unterschiedlichen Komponenten eines Systems (und des Systemdesigns). Da Hard- und Software jedoch nie ganz vor Ausfällen gefeit sind, werden häufig Ausfallmetriken wie MTBF, MTTF und die Ausfallrate herangezogen, um die Zuverlässigkeit von Systemen und Komponenten zu messen und zu prognostizieren.
• Verfügbarkeit (Availability) ist die Wahrscheinlichkeit, dass ein System wie vorgesehen funktioniert, wenn es eingesetzt werden muss. Die Verfügbarkeit ist daher eine Funktion der Zuverlässigkeit und Wartbarkeit und wird durch Dividieren der MTBF durch die Summe aus MTBF und MTTR berechnet (A = MTBF / (MTBF + MTTR)).
• Wartbarkeit (Maintainability) beschreibt, wie problemlos und wie schnell ein System und seine Komponenten repariert oder ausgetauscht und nach einem Ausfall wieder vollständig in Betrieb genommen werden können. Die Wartbarkeit eines Systems hängt von einer Fülle von Faktoren ab, unter anderem von der Qualität der Geräte und der Installation, der Qualifikation und Verfügbarkeit des IT-Personals sowie von der Funktionalität und Effizienz von Wartungs- und Reparaturverfahren. Die Mean Time To Repair gehört zu den Benchmark-Metriken, die für die Bestimmung der Wartbarkeit einer Komponente oder eines Systems herangezogen werden, wobei eine kurze MTTR auf eine gute Wartbarkeit hinweist.

Zusammengenommen können die RAM-Merkmale verwendet werden, um die Muster für Uptime (Zuverlässigkeit bzw. Reliability) und Downtime (Wartbarkeit bzw. Maintainability) eines Systems sowie den Prozentsatz der Uptime in einer bestimmten Zeitspanne (Verfügbarkeit bzw. Availability) zu ermitteln.

Im Wesentlichen gibt die Mean Time Between Failures (MTBF) an, wie oft die Geräte und Anlagen eines Unternehmens ausfallen. Demgegenüber ist die Mean Time To Repair (MTTR) eine Messgröße dafür, wie schnell sie wieder zum Laufen gebracht werden können. Mit einer Kombination aus beiden Metriken lässt sich die Uptime bzw. die technische Verfügbarkeit (Availability) eines Systems berechnen. Unternehmen sollten darauf abzielen, die MTTR zu senken und die MTBF zu erhöhen, um ungeplante Ausfallzeiten zu vermeiden bzw. auf ein Minimum zu reduzieren.

Mit Hilfe der Mean Time To Repair lässt sich die Anlagenverfügbarkeit berechnen. Die MTTR lässt sich ermitteln, indem die Gesamtausfallzeit innerhalb einer bestimmten Laufzeit durch die Gesamtanzahl der Ausfälle innerhalb dieses Zeitraums dividiert wird. Wenn ein System beispielsweise innerhalb eines Monats dreimal ausgefallen ist und diese Ausfälle zu einer Ausfallzeit von insgesamt sechs Stunden geführt haben, dann betrüge die MTTR zwei Stunden.

MTTR = 6 Stunden / 3 Ausfälle = 2 Stunden

Reparaturen können zwar je nach Schwere des Fehlers Minuten oder Tage in Anspruch nehmen, die MTTR von IT-Systemen wird jedoch in der Regel in Stunden gemessen.

Die Mean Time To Repair (MTTR) ist eine wichtige Metrik, die in einer ITIL (Information Technology Infrastructure Library) enthalten ist. Dabei handelt es sich um eine strukturierte Sammlung von Best Practices für eine bessere Ausrichtung des IT-Servicemanagements (ITSM) an geschäftlichen Anforderungen. Diese umfasst derzeit fünf Kernpublikationen, die laut Axelos, dem aktuellen Inhaber der Lizenz für die Bibliothek, den ITIL-Service-Lebenszyklus abbilden – von der „Identifizierung der Kundenbedürfnisse und den Triebfedern der IT-Anforderungen über das Design und die Implementierung eines Service bis hin zur Monitoring- und Verbesserungsphase des Services.“

Welche Bedeutung hat die MTTR im ITIL-Framework?

ITIL gliedert die IT-Funktionen in mehrere, messbare Prozesse, darunter Servicekatalogmanagement, Service Level Management, Risikomanagement, Kapazitätsmanagement, Verfügbarkeitsmanagement, IT Service Continuity Management, Compliance-Management, IT-Architekturmanagement und Lieferantenmanagement. Die Mean Time To Repair ist ein Bestandteil des Verfügbarkeitsmanagement-Prozesses, mit dem sichergestellt werden soll, dass „die gesamte IT-Infrastruktur, Prozesse, Tools, Rollen usw. für die vereinbarten Verfügbarkeitsziele geeignet sind.“ Ebenso wie die MTBF, MTBSI und MTRS wird die MTTR als Messgröße für das Incident- und Problemmanagement genannt, die in SLAs (Service Level Agreements) aufgenommen werden kann.

Welche Bedeutung hat die MTTR für DevOps?

Bei DevOps, wo die Mean Time To Repair in der Regel für Mean-Time-To-Recovery steht, wird damit die Zeitspanne gemessen, die das DevOps-Team für die Wiederherstellung nach einem Produktionsausfall benötigt. Üblich ist hier die Berechnung der durchschnittlichen Produktionsausfallzeit der letzten zehn Downtime-Incidents.

Metriken spielen grundsätzlich eine wichtige Rolle, um den Erfolg von DevOps sicherzustellen und zu beziffern. Die Mean Time To Repair kann zwar durch das Volumen neuer Funktionen, die einer App hinzugefügt werden, die Komplexität des Codes und weitere Produktionsvariablen verzerrt werden. Im Allgemeinen lassen sich die Fähigkeiten eines Teams mit der MTTR jedoch genau quantifizieren. Im Idealfall sinkt die Mean Time To Repair mit zunehmender Reife der DevOps-Implementierung im Unternehmen.

Die MTTR Berechnung kann auch hilfreich dabei sein, um Führungskräften und Entscheidern die positiven geschäftlichen Auswirkungen des DevOps-Ansatzes zu vermitteln. Das ist beispielsweise der Fall, wenn die Mean Time To Repair eine Steigerung der Produktivität oder einen Rückgang der Ausfallzeit belegt und so in finanzielle Einsparungen übersetzt werden kann.

Welche Bedeutung hat die Mean Time To Repair für die kontinuierliche Software-Entwicklung?

Die MTTR ist eine Messgröße für die Stabilität des kontinuierlichen Entwicklungsprozesses in einem Unternehmen. Eine schnelle Softwareentwicklung und -bereitstellung ist für die meisten Unternehmen ein wichtiger Erfolgsfaktor. Ein zuverlässiger Continuous Delivery-Prozess beinhaltet eine Feedbackschleife („entwickeln (build), messen (measure), lernen (learn)“) um stetige Verbesserungen zu erzielen und geschäftliche Zielvorgaben einzuhalten.

Da Schnelligkeit und Stabilität die Grundlage kontinuierlicher Entwicklung bilden, sind Metriken wie bspw. die Mean Time To Repair ausgesprochen wichtig, um solche Aspekte besser bewerten und optimieren zu können. Es gibt keine standardisierten Metriken für das Monitoring der kontinuierlichen Entwicklung und letztendlich liegt die Entscheidung darüber, welche Metriken zielführend sind, bei den einzelnen Unternehmen. Die Mean Time To Repair ist jedoch eine gängige Messgröße, um zu bewerten, wie schnell die Teams bei der Behebung von Ausfällen in der Continuous Delivery-Pipeline sind. Darüber hinaus kann die MTTR auch als Richtwert für die Verbesserung der Stabilität dienen.

Viele Probleme, die zu einer längeren Mean Time To Repair beitragen, sind unternehmensspezifisch und machen mitunter eine gezielte Bewertung der jeweiligen IT-Prozesse und -verfahren erforderlich. Es gibt jedoch sechs generelle Schritte zur Verkürzung der MTTR, von denen wahrscheinlich jedes Unternehmen profitieren kann.

1. Incidents eingehend analysieren: Um die Mean Time To Repair zu verkürzen, müssen Sie Incidents und Ausfälle zunächst besser verstehen. Moderne Unternehmenssoftware hilft bei der automatisierten Zusammenführung Ihrer in verteilten Silos gespeicherten Daten und ermöglicht die zuverlässige Berechnung der MTTR. So gewinnen Sie wertvolle Erkenntnisse über die ursächlichen Faktoren der Mean Time To Repair als erfolgskritischen Metrik.
2. Mit Monitoring den Überblick behalten: Bevor Sie ein Problem beheben können, müssen Sie es erst einmal erkennen – und je früher das gelingt, desto besser. Eine gute Monitoring-Lösung bietet einen kontinuierlichen Strom von Echtzeitdaten über die Performance Ihres Systems. Und zwar in der Regel auf einer zentralen, benutzerfreundlichen Dashboard-Oberfläche. So werden Sie schon in einem frühen Stadium auf Probleme aufmerksam gemacht.
3. Maßnahmenplan bereithalten: Bei kleineren Unternehmen mit knappen Ressourcen sind Ad-hoc-Reaktionen häufig nicht zu vermeiden. Größere Unternehmen sollten jedoch durchstrukturierten Verfahren und Protokollen folgen. In vielen Unternehmen ist dazu ein konventioneller ITSM-Ansatz mit klar abgegrenzten Rollen und Reaktionen erforderlich. Unternehmen, bei denen die Digitalisierung bereits abgeschlossen ist, können eine flexiblere Methode mit funktionsübergreifenden Tools für die Zusammenarbeit wählen und für jeden Incident maßgeschneiderte Reaktionen entwickeln. Wie auch immer Ihr Plan aussieht, er sollte klar umreißen, wer im Falle eines Incidents zu benachrichtigen ist, wie ein Incident dokumentiert werden muss und welche Schritte zu unternehmen sind, wenn Ihr Team mit der Lösung des Problems beginnt.
4. Incident Management-System automatisieren: Eine schnelle Reaktion beginnt damit, dass die richtigen Mitarbeiter rasch genaue Informationen über das Problem erhalten. Die Benachrichtigung eines Teammitglieds per Telefon mag für Incidents mit niedriger Priorität während der Geschäftszeiten in Ordnung sein. Doch was geschieht, wenn Ihre Website durch einen Serverausfall am Freitagabend um 20:00 Uhr plötzlich offline ist? Ein automatisiertes Incident Management-System kann gleichzeitig Warnmeldungen über mehrere Kanäle (Telefonanruf, SMS, E-Mail) an alle Mitarbeiter in Bereitschaft senden. So lässt sich der Vorgang erheblich beschleunigen, da die zuständigen Mitarbeiter nicht mehr aufwendig lokalisiert und einzeln manuell kontaktiert werden müssen.
5. Incident Response-Teams und Rollen benennen: Klar definierte Rollen und Verantwortungsbereiche sind entscheidend für eine effektive Abwicklung der Incident Response und eine Verkürzung der Mean Time To Repair (MTTR). Die Struktur einer Support-Organisation hängt natürlich von den Anforderungen Ihres Unternehmens ab, doch ITIL bietet ein geeignetes Framework, das aus den folgenden Rollen besteht.
   • Incident Manager (IM): Wer diese Rolle übernimmt, ist die treibende Kraft des Incident Management-Prozesses, passt ihn bei Bedarf an und optimiert ihn. Laut ITIL kommt diese Funktion in kleinen und mittelständischen Unternehmen in der Regel dem Service Desk Manager zu, kann in größeren Unternehmen aber auch eine separate Funktion sein. Der Incident Manager ist vor allem für die Verwaltung des Incident Management Systems und die Durchsetzung des Incident Management-Prozesses zuständig. Darüber hinaus leitet der IM das Incident Response-Team, meldet wichtige Leistungsindikatoren (KPIs) an die Führungsebene und leitet außerdem den First- und Second-Line-Support.
   • First-Line-Support (Level 1): Die Mitarbeiter des First-Line-Supports sind die zentrale Anlaufstelle für Endbenutzer, die Serviceunterbrechungen melden. Sie sind für die Klassifizierung von Incidents zuständig und versuchen, den ausgefallenen Service so schnell wie möglich wiederherzustellen. Wenn der First-Line-Support den Incident nicht beheben kann, muss er ihn an das Personal des Second-Line-Supports weiterleiten, die Reparaturmaßnahmen überwachen und die Benutzer über den Incident-Status auf dem Laufenden halten.
   • Second-Line-Support (Level 2): Die Techniker des Second-Line-Supports sind in der Regel höher qualifiziert als ihre Kollegen aus dem First-Line-Support. Daher können sie zur Behebung von Incidents herangezogen werden, die der First-Line-Support nicht in den Griff bekommt. Die Responder des Second-Line-Supports können auch für die Interaktion mit Drittanbietern von Software oder Hardware verantwortlich sein, um den normalen Servicebetrieb schnellstmöglich wiederherzustellen. In sehr großen, komplexen oder sensiblen Umgebungen kann auch ein Third-Line-Support (Level 3) erforderlich sein, dessen Mitarbeiter noch höher qualifiziert sind.
   Ihr Incident Response-Team muss nicht genau diese Struktur aufweisen. Wichtig ist jedoch, dass ein Leiter bestimmt wird, der die Incident Response steuert und eine gute Kommunikation mit den verantwortlichen Akteuren innerhalb und außerhalb des Teams sicherstellt. Außerdem sollten die Aufgabenbereiche aller Teammitglieder klar definiert sein.
6. Mitarbeiter für unterschiedliche Rollen ausbilden: Spezialisten mit Fokuswissen sind von unschätzbarem Wert für Ihr Incident Response-Team. Wenn Sie sich jedoch auch bei relativ unbedeutenden Problemen ausschließlich auf diese Spezialisten verlassen, besteht das Risiko, dass Sie sie überlasten. Darunter kann die Ausführung der Aufgaben leiden, für die sie eigentlich da sind, und am Ende steht das Risiko der Überforderung. Darüber hinaus ist ihr Response-Team machtlos, wenn der Spezialist beim Auftreten eines Incidents gerade nicht zur Stelle ist.

Diese Probleme können Sie entschärfen – und letztendlich auch Ihre Mean Time To Repair senken – indem Sie dafür sorgen, dass sich alle Mitarbeiter gut mit Ihrem System auskennen und in mehreren Funktionen und Incident Response-Rollen geschult sind. Dadurch wird Ihr Team in die Lage versetzt, wirksamer zu reagieren, und zwar unabhängig davon, wer beim Auftreten eines Problems gerade Bereitschaftsdienst hat.

MTTR kann zudem umfassende Einblicke in Ihre Infrastruktur ermöglichen, um eine raschere und genauere Diagnose von Problemen sicherzustellen. Wenn Ihnen zum Beispiel Echtzeitdaten zum Volumen der eingehenden Anfragen eines Servers vorliegen und Sie wissen, wie schnell der Server darauf reagiert, gestaltet sich die Fehlerbehebung im Falle eines Serverausfalls deutlich einfacher. Anhand der Daten können Sie auch sehen, wie bestimmte Maßnahmen zur Reparatur von Systemkomponenten die System-Performance beeinträchtigen, sodass Sie schneller eine geeignete Lösung entwickeln können.

IT-Abteilungen von Unternehmen stehen zunehmend unter dem Druck, ihren Service zu verbessern und gleichzeitig Kosten zu senken. Daher werden die Reaktionszeiten bei Incidents immer wichtiger für den Erfolg. Die sogenannte Mean Time To Repair – kurz MTTR – ist zwar keine magische Zahl. Sehr wohl ist die Mean Time To Repair aber ein aussagekräftiger Indikator für die Fähigkeit eines Unternehmens, schnell eine Antwort auf potenziell kostspielige Probleme zu finden und diese zu lösen. Angesichts der direkten Auswirkungen von Systemausfallzeiten auf die Produktivität, Rentabilität und das Vertrauen der Kunden sind fundierte Kenntnisse der MTTR und ihrer Funktionen für jede tech-zentrierte Organisation unerlässlich.