Die Wiederanlaufzeit bezeichnet die Zeitspanne zwischen dem Eintreten eines Systemausfalls und dem vollständigen Wiederherstellungszeitpunkt, an dem das System seinen regulären Betrieb wieder aufgenommen hat. Sie ist die messsbare, reale Ausfallzeit aus Nutzerperspektive – von dem Moment, in dem das System nicht mehr verfügbar ist, bis zu dem Moment, in dem es wieder vollständig funktionsfähig ist.
Im Kontext automatisierter Prozesse ist die Wiederanlaufzeit eine kritische Betriebskennzahl: Jede Minute, in der Automatisierungsworkflows nicht laufen, akkumulieren sich Warteschlangen, verzögern sich Prozesse und entstehen manuelle Nacharbeiten. Eine kurze Wiederanlaufzeit ist kein reines IT-Thema – sie ist eine direkte Determinante der Prozessqualität.
Die Phasen bis zur Wiederherstellung
Ausfall
Komponente fällt aus
Erkennung
Monitoring schlägt an
Reaktion
Failover / Neustart
Normalbetrieb
System wieder verfügbar
Wiederanlaufzeit verkürzen
- Erkennungszeit minimieren: Kurze Health-Check-Intervalle (10–30 Sekunden statt 5 Minuten) reduzieren die Zeit von Ausfall bis Alert massiv
- Automatischer Neustart: Kubernetes und Docker starten ausgefallene Container automatisch neu – ohne manuelle Eingriffe
- Vorbereitete Failover-Systeme: Hot-Standby-Systeme übernehmen in Sekunden; Cold-Standby-Systeme brauchen Minuten bis Stunden zum Hochfahren
- Dokumentiertes Runbook: Wenn manuelle Eingriffe nötig sind, reduziert ein klares Runbook die Zeit für Diagnose und Entscheidung erheblich
- MTTR tracken: Mean Time to Recovery (MTTR) als regelmäßig gemessene Betriebskennzahl – was nicht gemessen wird, wird nicht verbessert
Wiederanlaufzeit vs. RTO
Der RTO (Recovery Time Objective) ist die Zielvorgabe – die maximal akzeptable Wiederanlaufzeit, die das Business vorgibt: „Wir können maximal 2 Stunden Ausfall tolerieren.“ Die Wiederanlaufzeit ist die tatsächlich gemessene Realität: „Beim letzten Ausfall haben wir 38 Minuten gebraucht.“ RTO ist Planung und Anforderung; Wiederanlaufzeit ist Messung und Realität. Ein gutes Betriebskonzept stellt sicher, dass die gemessene Wiederanlaufzeit dauerhaft unter dem RTO-Ziel liegt.
Praxisbeispiel
Ein Automationsdienstleister analysiert die Wiederanlaufzeiten der letzten 12 Monate: 8 Ausfälle insgesamt. Ursachen: 3× Container-Absturz (automatischer Kubernetes-Neustart: 25–45 Sekunden), 2× Datenbankverbindungsproblem (automatischer Reconnect: 90 Sekunden), 1× Hardware-Node-Ausfall (Kubernetes-Reschedule auf anderen Node: 4 Minuten), 1× Netzwerkausfall beim Hosting-Provider (kein Failover: 47 Minuten), 1× Fehlkonfiguration nach Update (manuelle Intervention: 2 Stunden 12 Minuten). Erkenntnis: Die 6 automatisch behobenen Ausfälle haben zusammen 9 Minuten Downtime verursacht. Die 2 manuellen Ausfälle: 159 Minuten. Investition: Monitoring für Netzwerkprobleme ausgebaut und automatischer Netzwerk-Failover konfiguriert.
