Published Date: August 1, 2019
Die Mean-Time-To-Repair ist die mittlere Reparaturzeit bzw. Wiederherstellungszeit und ist eine wichtige Ausfallmetrik. Sie gibt die Zeitspanne an, die durchschnittlich für die Reparatur und Wiederherstellung der Funktionsfähigkeit einer Komponente oder eines Systems benötigt wird. Damit ist die MTTR eine primäre Messgröße für die Wartbarkeit der Systeme, Geräte, Anwendungen und Infrastruktur eines Unternehmens sowie für die Effizienz bei der Instandsetzung dieser Geräte nach dem Auftreten eines IT-Incidents.
Die MTTR 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 MTTR ebenfalls verlängern. Eine lange MTTR sollte IT-Administratoren 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 MTTR 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 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 jedoch die Zeitspanne, die das Troubleshooting und die Behebung eines Problems durchschnittlich in Anspruch nehmen.
Was sind Ausfallmetriken?
Ausfallmetriken sind Leistungsindikatoren, mit denen Unternehmen die Zuverlässigkeit ihrer Geräte und Systeme verfolgen 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. Der Begriff „Ausfall“ bezieht sich in diesem Fall nicht ausschließlich auf nicht funktionierende Geräte oder Systeme (wie einen abgestürzten Dateiserver), 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. Es 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 kann auch für Mean-Time-To-Recovery, Mean-Team-To-Resolve oder Mean-Time-To-Resolution stehen).
- Mean-Time-Between-Failures (MTBF): 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 spielen eine entscheidende Rolle beim Umgang mit Ausfallzeiten und beim Management der potenziell negativen Auswirkungen auf das Unternehmen. Sie bieten der IT-Abteilung die 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 können 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?
Zuverlässigkeit, Verfügbarkeit und Wartbarkeit, nach dem englischen Äquivalent (Reliability, Availability und Maintainability) oftmals mit RAM abgekürzt, sind Merkmale des Systemdesigns, die Einfluss auf die Lebenszykluskosten eines Systems sowie auf dessen Fähigkeit haben, seine Aufgaben zu erfüllen. RAM kann also eine Messgröße für das Vertrauen eines Unternehmens in seine Hardware, Software und Netzwerke sein.
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 MTTR 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.
Warum ist die MTTR so wichtig?
Da mit der MTTR vor allem gemessen wird, wie lange geschäftskritische Systeme außer Betrieb sind, ist sie ein aussagekräftiger Indikator für die Auswirkungen, die ein IT-Incident auf den Gewinn des Unternehmens haben wird. Je länger die MTTR eines IT-Teams ist, desto größer ist das Risiko, dass das Unternehmen beim Auftreten von IT-Incidents erhebliche Ausfallzeiten hinnehmen muss, die zu Geschäftsunterbrechungen, unzufriedenen Kunden und Umsatzeinbußen führen können.
Technische Ausfälle sind unvermeidlich. Unternehmen, die ihre MTTR kennen, haben eine Vorstellung davon, wie schnell und wirksam sie auf Ausfälle reagieren und den normalen Geschäftsbetrieb wiederherstellen können. Im Großen und Ganzen sind niedrige MTTR-Werte ein Zeichen für eine gesunde Computing-Umgebung und ein gutes Funktionieren der IT-Organisation.
Im Wesentlichen gibt die MTBF an, wie oft die Geräte und Anlagen eines Unternehmens ausfallen, während die MTTR eine Messgröße dafür ist, wie schnell sie wieder zum Laufen gebracht werden können. Mit einer Kombination aus beiden Metriken lässt sich die Uptime bzw. 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.
Wie wird die MTTR berechnet?
Die MTTR wird berechnet, 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.
Welche Bedeutung hat die MTTR im ITIL-Framework?
Die MTTR ist eine wichtige Metrik, die in einer ITIL (Information Technology Infrastructure Library) enthalten ist, einer strukturierten Sammlung von Best Practices für eine bessere Ausrichtung des IT-Servicemanagements (ITSM) an geschäftlichen Anforderungen. Sie 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 Services bis hin zur Monitoring- und Verbesserungsphase des Services.“
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 MTTR 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.“ Die MTTR wird ebenso wie die MTBF, MTBSI und MTRS als Messgröße für das Incident- und Problemmanagement genannt, die in SLAs (Service Level Agreements) aufgenommen werden kann.
Bei DevOps, wo die MTTR 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 MTTR 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 damit jedoch genau quantifizieren. Im Idealfall sinkt die MTTR mit zunehmender Reife der DevOps-Implementierung im Unternehmen.
Die Berechnung der MTTR kann auch hilfreich sein, um Führungskräften und Entscheidern die positiven geschäftlichen Auswirkungen des DevOps-Ansatzes zu vermitteln. Das ist beispielsweise der Fall, wenn die MTTR eine Steigerung der Produktivität oder einen Rückgang der Ausfallzeit belegt und so in finanzielle Einsparungen übersetzt werden kann.
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 zur Bewertung und Optimierung dieser Aspekte ausgesprochen wichtig. 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 MTTR 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 als Richtwert für die Verbesserung der Stabilität dienen.
Wie lässt sich die MTTR verkürzen?
Viele Probleme, die zu einer längeren MTTR beitragen, sind unternehmensspezifisch (und erfordern eine gezielte Bewertung der jeweiligen IT-Prozesse und -verfahren). Es gibt jedoch sechs generelle Schritte zur Verkürzung der MTTR, von denen wahrscheinlich jedes Unternehmen profitieren kann.
- Incidents eingehend analysieren: Um die MTTR 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 dieser erfolgskritischen Metrik.
- 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.
- 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.
- 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.
- 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 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.
- 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 MTTR 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.
Umfassende Einblicke in Ihre Infrastruktur ermöglichen eine raschere und genauere Diagnose von Problemen. 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 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.
MTTR – Eine Metrik mit erheblichen Auswirkungen auf den Geschäftserfolg
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 MTTR ist zwar keine magische Zahl, sehr wohl 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.
