Definition von MTTR

Mean Time to Repair (mittlere Reparaturzeit, MTTR) ist ein wichtiger Leistungsindikator und gibt an, wie lange die Wiederherstellung der Funktionsfähigkeit eines Systems nach einem Zwischenfall im Durchschnitt dauert. Die MTTR wird neben anderen Zwischenfallmetriken genutzt, um die Leistung der DevOps- und IT-Teams zu bewerten, die Effektivität von Sicherheitsprozessen und Sicherheitslösungen zu beurteilen sowie die Wartungsfreundlichkeit von Systemen einzuschätzen.
Service Level Agreements (SLAs) mit Drittanbietern enthalten meist Vorgaben für die MTTR, die jedoch nicht garantiert werden, da sich die Zwischenfälle in ihrer Komplexität unterscheiden. Gleichermaßen ist es nicht sinnvoll, die MTTRs verschiedener Unternehmen zu vergleichen, da die mittlere Reparaturzeit im hohen Maße von individuellen Faktoren wie Größe und Art der Infrastruktur sowie Umfang und Kompetenz der IT- und DevOps-Teams abhängt. Jedes Unternehmen muss selbst entscheiden, welche Metriken für seine Zwecke am besten geeignet sind, und wie diese in der eigenen Umgebung eingesetzt werden.

Unterschiede zwischen gängigen Fehlermetriken

Moderne Unternehmenssysteme sind äußerst komplex und Fehler können auf vielfältige Art und Weise auftreten. Deshalb gibt es keine Zwischenfallmetriken, die sich für alle Unternehmen gleichermaßen eignen. Es gibt jedoch eine große Auswahl von Metriken, die sich mitunter nur im Detail voneinander unterscheiden.

Mean Time to Detect (mittlere Erkennungszeit, MTTD)

Die mittlere Erkennungszeit ist die durchschnittliche Zeit zwischen dem Einsetzen eines Systemfehlers und dessen Erkennung. Die MTTD wird als wichtiger Leistungsindikator genutzt, der die Effektivität der vom DevOps-Team genutzten Tools und Prozesse bewertet.

Zur Berechnung der MTTD wird ein Zeitraum gewählt (z. B. ein Monat), in dem die Zeit zwischen dem Einsetzen von Systemausfällen und deren Erkennung gemessen wird. Um den Durchschnitt zu erhalten, wird die Gesamtzeit durch die Anzahl der Zwischenfälle geteilt. Die MTTD sollte möglichst niedrig sein. Wenn der Zeitraum bis zur Erkennung von Systemausfällen allmählich immer länger wird, sollten die vorhandenen Verwaltungstools und Prozesse zur Zwischenfallreaktion sofort einer Überprüfung unterzogen werden.

Mean Time to Identify (mittlere Identifizierungszeit, MTTI)

Diese Metrik misst die Zahl der Geschäftsstunden zwischen dem Auslösen einer Warnung und dem Zeitpunkt, an dem das Cybersicherheitsteam mit der Untersuchung der Warnung beginnt. Die MTTI gibt einen Überblick darüber, ob Warnsysteme wirksam sind und ob das Cybersicherheitsteam mit genügend Personal ausgestattet ist. Wenn der MTTI-Wert hoch ist oder sich in die falsche Richtung entwickelt, leidet das Cybersicherheitsteam möglicherweise unter Informationsüberlastung.

Mean Time to Recovery (mittlere Wiederherstellungszeit, MTTR)

Die mittlere Wiederherstellungszeit gibt an, wie viele Geschäftsstunden im Durchschnitt zwischen dem Beginn eines Zwischenfalls und der vollständigen Wiederherstellung der Geschäftsabläufe vergehen. Die Zwischenfallmetrik gibt Aufschluss über die Effektivität der DevOps- und IT-Teams und zeigt Optimierungsmöglichkeiten für Prozesse und Funktionen auf.

Mean Time to Resolve (mittlere Behebungszeit, MTTR)

Die mittlere Behebungszeit gibt an, wie viel Zeit im Mittel zwischen der ersten Warnung bis zur Analyse nach dem Zwischenfall vergeht – inklusive der Zeit, die aufgewendet wird, um sicherzustellen, dass der Fehler nicht erneut auftritt. Die MTTR wird in Geschäftsstunden gemessen.

Mean Time between Failures (mittlere Betriebsdauer zwischen Ausfällen, MTBF)

Die mittlere Betriebsdauer zwischen Ausfällen ist eine wichtige Leistungsmetrik, die die Zuverlässigkeit und Verfügbarkeit von Systemen misst. IT-Teams nutzen sie, um herauszufinden, welche Systeme oder Komponenten gut funktionieren und welche eventuell repariert oder ausgetauscht werden müssen. Die MTBF ermöglicht ihnen, vorbeugende Wartungsmaßnahmen durchzuführen und die Gesamtzahl der Ausfälle zu reduzieren. Außerdem können sie ihre Arbeit damit besser priorisieren und anhand historischer MTBF-Daten wartungsbedingte Ausfälle sowie Ressourcenzuweisungen besser planen.

Die MTBF ergibt sich aus dem Durchschnitt der Stunden, die zwischen Systemausfällen während des normalen Betriebs in einem bestimmten Zeitraum vergehen.

Mean Time to Failure (mittlere Betriebsdauer bis zum Ausfall, MTTF)

Die mittlere Betriebsdauer bis zum Ausfall gibt die Betriebsdauer im Vergleich zu Ausfällen an. Im Gegensatz zur MTBF, die auf die Reparaturfähigkeit ausgerichtet ist, geht es bei der MTTF um Ausfälle, die nicht repariert werden können. Sie wird genutzt, um die Lebensdauer von Systemen vorherzusagen. Die MTTF eignet sich jedoch nicht für jedes System. So sind beispielsweise Systeme mit langen Lebensdauern (z. B. zentrale Systeme von Banken oder viele industrielle Kontrollsysteme) für MTTF-Metriken ungeeignet, da sie eine derart lange Lebensdauer haben, dass sie aufgrund des technischen Fortschritts am Ende durch ein völlig anderes System ersetzt werden. In solchen Fällen ist die Erhebung der mittleren Betriebsdauer bis zum Ausfall überflüssig.

Im Gegenzug dazu stellt sie bei Systemen mit üblicheren Lebensspannen eine gute Methode dar, um herauszufinden, welche Marken am besten abschneiden und welche Umgebungsfaktoren die Lebensdauer eines Produkts am stärksten beeinflussen.

Vorteile der MTTR für DevOps- und IT-Teams

Die MTTR soll die Zahl ungeplanter Ausfälle verringern und die Breakout-Time verkürzen. Sie eignet sich jedoch auch, um die Kultur innerhalb des IT-Teams zu verbessern.

Wenn DevOps- und IT-Teams Zwischenfälle behoben können, bevor die Benutzer dadurch beeinträchtigt werden, werden sie als effizient und effektiv wahrgenommen. Dies fördert einen resilienten Systemaufbau, denn wenn das DevOps-Team weiß, dass seine Leistung an der MTTR gemessen wird, entwickelt es Anwendungen, die schneller repariert werden können. Dies sind beispielsweise Anwendungen, die mit separaten Web-Services ausgestattet werden, sodass der Ausfall eines einzelnen Services nicht zum Ausfall der gesamten Anwendung führt. Wird die MTTR richtig umgesetzt, berücksichtigt sie auch die Analyse nach einem Zwischenfall, die mittels einer Feedback-Schleife dazu genutzt werden sollte, künftige Software-Builds zu verbessern und Anreize für die frühzeitige Behebung von Fehlern im Software-Entwicklungsprozess zu setzen.

Berechnen der mittleren Reparaturzeit

Die Formel zur Berechnung der MTTR ist recht simpel: Addieren Sie einfach den gesamten Zeitaufwand für ungeplante Reparaturen, die in einem bestimmten Zeitraum für ein System anfielen, und teilen Sie das Ergebnis durch die Gesamtanzahl der relevanten Zwischenfälle.

Doch nicht alle Ausfälle sind gleichwertig. Die Zeit für die Reparatur einer defekten Komponente oder eines kundenseitigen Systems, das zu Spitzenzeiten ausfällt, ist in Bezug auf Umsatzeinbußen, Produktivität oder Markenschäden kostspieliger als die Reparaturzeit für einen unkritischen Ausfall mitten in der Nacht. Mit einem „Fehler-Budget“ können Unternehmen festlegen, dass jede Minute, die für die Reparatur der wichtigsten Systeme aufgewendet wird, genauso viel wert ist wie eine Stunde für die Reparatur sekundärer Systeme. Anhand dieser Unterscheidung lassen sich die wahren Kosten von Ausfällen besser ablesen und es wird klarer, welche Bedeutung die MTTR für das einzelne Unternehmen hat.

Reduzieren der MTTR

Zur Reduzierung der MTTR müssen drei Elemente zusammenkommen.

1. Das erste ist eine klare Strategie für den Behebungsprozess, der auch eine Analyse nach dem Zwischenfall enthalten sollte, um die gewonnenen Erkenntnisse zusammenzutragen.
2. Technologie spielt selbstverständlich eine unverzichtbare Rolle. Daher sollte eine gute Lösung Transparenz, Überwachung und korrigierende Wartungsmaßnahmen bieten, um Probleme zu beseitigen und Abwehrmaßnahmen für künftige Angriffe einzurichten.
3. Und schließlich müssen auch die Fähigkeiten zur Verfügung stehen, mit denen ein Zwischenfall behoben werden kann.

Die MTTR kann durch ein höheres Budget oder durch mehr Personal reduziert werden, doch das ist nicht immer realistisch. Stattdessen sollte der Reparaturprozess so weit wie möglich mithilfe von künstlicher Intelligenz (KI) und Machine Learning (ML) automatisiert werden. Dazu gehören Maßnahmen wie schnelle Erkennung, Minimierung von False Positives, intelligente Eskalation und automatisierte Behebungsmaßnahmen, um mithilfe von Workflows die MTTR zu verringern.

Es kann sinnvoll sein, sich an der MTTR zu orientieren, um Ausfälle zu minimieren und die DevOps- und IT-Teams zu optimieren. Dies sollte jedoch nicht das endgültige Ziel sein. Schließlich sind Metriken nicht dazu gedacht, einfach Zahlen zu verbessern. Vielmehr sollen sie dazu beitragen, die Systeme ganz praktisch am Laufen zu halten sowie das Unternehmen und seine Kunden zu schützen. Nutzen Sie die MTTR in einer Form, die Ihren Mitarbeitern hilft, die Kunden zu schützen und die Systembetriebszeit zu optimieren.

So verbessern Sie die MTTR mit einer modernen Log-Management-Lösung

Protokolle sind bei jeder Zwischenfallreaktion unbezahlbar. Falcon LogScale ermöglicht die vollständige Beobachtbarkeit für alle Streaming-Protokolle und Ereignisdaten, sodass IT-Abteilungen besser auf das Unbekannte vorbereitet sind und schnell die Ursache eines Zwischenfalls aufspüren können.

Falcon LogScale nutzt moderne Technologien wie Daten-Streaming, indexlose Architektur und hybride Bereitstellungen, um Computing-Ressourcen zu optimieren und Speicherkosten zu senken. Dadurch kann Falcon LogScale strukturierte und unstrukturierte Daten im Arbeitsspeicher erfassen sowie die Durchsuchung und Analyse von Datenmengen beliebiger Größe enorm beschleunigen.

Vollständige Protokollierung und Einblicke – kostenlos

Falcon LogScale Community Edition (ehemals Humio) ist eine kostenlose moderne Log-Management-Plattform für die Cloud. Durch die Erfassung von Streaming-Daten erhalten Sie einen sofortigen Überblick über verteilte Systeme und können Zwischenfälle verhindern bzw. beheben.

Falcon LogScale Community Edition ist sofort kostenlos verfügbar und bietet folgende Vorteile:

• Erfassung von bis zu 16 GB pro Tag
• Speicherung bis zu 7 Tage
• Keine Kreditkarte erforderlich
• Unbegrenzter Zugriff ohne Testzeitraum
• Indexlose Protokollierung, Echtzeit-Warnungen und Live-Dashboards
• Zugriff auf unseren Marktplatz und zugehörige Pakete, einschließlich Leitfäden zur Entwicklung neuer Pakete
• Lernen und Kooperation in einer aktiven Gemeinschaft

KOSTENLOS TESTEN