MTTR senken: Der schnellste Weg vom Incident zum Fix

Kein System ist ausfallfrei, und das muss es auch nicht sein. Die ehrlichere Frage lautet: Wie schnell ist ein Ausfall wieder vorbei? Diese Zeit – die Mean Time To Recovery, kurz MTTR – ist eine der aussagekräftigsten Kennzahlen für die Reife eines Betriebs.

MTTR ist keine einzelne Zahl

Um MTTR zu senken, muss man sie zerlegen. Zwischen dem Moment, in dem etwas kaputtgeht, und dem Moment, in dem es wieder läuft, liegen drei sehr unterschiedliche Phasen:

1. 1Erkennen – wie lange dauert es, bis überhaupt jemand (oder etwas) den Fehler bemerkt?
2. 2Verstehen – wie lange, bis die Ursache klar ist?
3. 3Beheben – wie lange dauert die eigentliche Gegenmaßnahme?

In den allermeisten Teams steckt die verlorene Zeit nicht im Beheben, sondern im Verstehen. Der Fix selbst ist oft ein Neustart oder ein Rollback in Sekunden – aber davor liegen 40 Minuten Rätselraten.

Wo man ansetzt

• Erkennen verkürzen: aussagekräftige Alerts auf Symptome, die Nutzer wirklich spüren, statt auf jede Metrik.
• Verstehen verkürzen: korrelierte Observability, saubere Deploy-Marker und ein Änderungsprotokoll, das die Frage „Was hat sich zuletzt geändert?" in Sekunden beantwortet.
• Beheben verkürzen: reversible Standardmaßnahmen als Runbook oder Auto-Remediation, damit niemand unter Druck improvisieren muss.

Jede Minute, die du in ein gutes Post-Mortem steckst, holst du beim nächsten Incident vielfach zurück.

Das Post-Mortem als Investition

Ein schuldfreies Post-Mortem, das die Ursache und die konkreten Verbesserungen festhält, ist kein bürokratischer Nachklapp. Es ist der Mechanismus, mit dem ein Team dieselbe MTTR beim nächsten Mal strukturell unterbietet. Systeme werden nicht dadurch besser, dass man Incidents vermeidet, sondern dadurch, dass man aus jedem einzelnen lernt.