MTBF (Mean Time Between Failures) ist die durchschnittliche Betriebszeit, die ein reparierbares System zwischen einem Ausfall und dem nächsten fehlerfrei läuft. Sie wird als gesamte Betriebszeit geteilt durch die Anzahl der Ausfälle berechnet und bestimmt zusammen mit der MTTR die Verfügbarkeit. Eine höhere MTBF bedeutet seltenere Ausfälle.
Was ist MTBF (Mean Time Between Failures)?
MTBF (Mean Time Between Failures) ist die durchschnittliche Zeit, in der ein reparierbares System zwischen zwei Ausfällen korrekt arbeitet. Der Begriff stammt aus der Zuverlässigkeitstechnik für Hardware wie Festplatten, Netzteile und Netzwerkgeräte, für die Hersteller MTBF-Werte angeben. Im Softwarebetrieb beschreibt die MTBF, wie häufig ein Service, ein Cluster oder eine Abhängigkeit ausfällt, im Unterschied dazu, wie schnell er sich erholt.
Die MTBF beantwortet die Frage „wie oft?“, die MTTR die Frage „wie lange?“. Beide sind nötig: Ein Service, der selten ausfällt, dann aber einen Tag lang nicht erreichbar ist, kann für Nutzer schlimmer sein als einer, der wöchentlich ausfällt und sich in Sekunden erholt.
MTBF berechnen
Die MTBF ist die gesamte Betriebszeit in einem Zeitraum geteilt durch die Anzahl der Ausfälle in diesem Zeitraum. Ausfallzeit zählt nicht als Betriebszeit.
MTBF = gesamte_Betriebszeit / Anzahl_Ausfälle
Ein illustratives Beispiel: Ein Service wird 30 Tage (720 Stunden) beobachtet. Er fällt dreimal aus, die Ausfälle dauern 1, 2 und 3 Stunden. Die Betriebszeit beträgt 720 - 6 = 714 Stunden, die MTBF also 714 / 3 = 238 Stunden. Die MTTR im selben Zeitraum liegt bei 6 / 3 = 2 Stunden.
Aus beiden Werten lässt sich die stationäre Verfügbarkeit ableiten:
Verfügbarkeit = MTBF / (MTBF + MTTR)
= 238 / (238 + 2) = 0,9917 (etwa 99,17 %)
Die Formel zeigt die zwei Hebel für bessere Verfügbarkeit: seltener ausfallen (MTBF erhöhen) oder schneller wiederherstellen (MTTR senken).
In der Praxis stammen die Eingangswerte aus Ihren Incident-Daten, nicht aus Rohmetriken. Jeder Incident braucht einen verlässlichen Start- und Endzeitpunkt und eine eindeutige Zuordnung zum betroffenen Service. Werden Incidents uneinheitlich erfasst, etwa nur schwere mit Ticket, sieht die MTBF besser aus als die Realität. Legen Sie einen Mindest-Schweregrad fest, ab dem ein Ereignis als Ausfall zählt, und wenden Sie ihn auf alle verglichenen Services an.
MTBF vs. MTTF vs. MTTR
| Kennzahl | Bedeutung | Einsatz |
|---|---|---|
| MTBF | Mittlere Betriebszeit zwischen Ausfällen | Reparierbare Systeme: Services, Server, Cluster |
| MTTF (Mean Time to Failure) | Mittlere Zeit bis zum Ausfall, der die Lebensdauer beendet | Nicht reparierbare Teile, etwa eine einzelne SSD oder ein Lüfter |
| MTTR | Mittlere Zeit bis zur Reparatur, Wiederherstellung oder Lösung | Erholungsgeschwindigkeit nach einem Ausfall |
| MTTD | Mittlere Zeit bis zur Erkennung eines Ausfalls | Qualität von Monitoring und Alerting |
Manche Definitionen messen die MTBF vom Beginn eines Ausfalls bis zum Beginn des nächsten und schließen damit die Reparaturzeit ein. Dokumentieren Sie, welche Variante Sie verwenden, sonst sind die Werte nicht vergleichbar.
MTBF richtig interpretieren
Die MTBF ist ein Mittelwert, keine Garantie. Eine Komponente mit einer MTBF von 100.000 Stunden läuft nicht elf Jahre lang, bevor sie ausfällt. Unter der gängigen Annahme einer konstanten Ausfallrate überlebt eine einzelne Einheit ihre MTBF nur mit einer Wahrscheinlichkeit von etwa 37 Prozent. MTBF-Werte sind daher vor allem für große Bestände nützlich: Sie sagen voraus, wie viele Ausfälle pro Zeitraum zu erwarten sind und wie viele Ersatzteile oder Reserveknoten Sie einplanen sollten.
In Software sind Ausfälle selten zufällig. Sie häufen sich um Deployments, Konfigurationsänderungen, Lastspitzen und ablaufende Zertifikate. Eine MTBF, die sich nach einer Prozessänderung verbessert oder verschlechtert, ist ein aussagekräftiges Signal. Ein einzelner MTBF-Wert im Vergleich zwischen unabhängigen Services meist nicht.
So verbessern Sie die MTBF
- Beseitigen Sie Single Points of Failure. Redundanz und Hochverfügbarkeit machen viele Komponentenausfälle für Nutzer unsichtbar.
- Machen Sie Änderungen sicherer. Canary-Releases, Feature Flags und automatische Rollbacks reduzieren änderungsbedingte Ausfälle, eine häufige Ursache von Incidents.
- Lernen Sie aus jedem Incident. Maßnahmen aus Postmortems, die Ursachen beseitigen, erhöhen die MTBF langfristig.
- Testen Sie Ausfälle gezielt. Chaos Engineering deckt Schwachstellen auf, bevor sie echte Ausfälle verursachen.
- Beobachten Sie Frühindikatoren. Sättigung, wachsender Speicherverbrauch und ablaufende Zertifikate kündigen Ausfälle an.
Häufige Fehler
- Nicht festzulegen, was als Ausfall zählt. Totalausfall, degradierter Endpunkt und fehlgeschlagener Batch-Job brauchen eine klare, gemeinsame Definition.
- Kleine Störungen und große Ausfälle gleich zu zählen. Dann bleibt unsichtbar, ob schwere Incidents seltener werden.
- Die MTBF aus sehr wenigen Incidents zu berechnen und das Ergebnis als präzise zu behandeln.
- Nur die MTBF zu optimieren und die Wiederherstellung zu vernachlässigen. Für die meisten Online-Services ist schnelle Erholung mindestens so wertvoll wie seltene Ausfälle.
Wie Obseria hilft
Obseria erfasst Incidents mit Beginn, Erkennung und Lösung pro Service, sodass sich MTBF, MTTD und MTTR aus denselben Daten ableiten lassen. Deployment-Marker und Obseria Intelligence zeigen, welche Änderungen und Abhängigkeiten mit Ausfällen zusammenhängen. So setzen Sie Verbesserungen dort an, wo sie die MTBF erhöhen. Details finden Sie unter Incident Management.