On-Call
Organisierte Bereitschaft von Teams zur Reaktion auf Vorfälle und Betriebsstörungen außerhalb regulärer Arbeitszeiten. Zweck sind schnelle Wiederherstellung, Minimierung von Ausfallzeiten und klare Eskalationspfade.
Klassifikation
- KomplexitätMittel
- AuswirkungOrganisatorisch
- EntscheidungstypOrganisation
- OrganisationsreifeFortgeschritten
Technischer Kontext
Prinzipien & Ziele
Use Cases & Szenarien
Kompromisse
- Burnout durch dauerhaft hohe Bereitschaftsbelastung.
- Unklare Eskalationspfade führen zu verzögerten Reaktionen.
- Unzureichende Dokumentation verschlechtert Problemlösungszeiten.
- Rufbereitschaft so planen, dass Belastung fair verteilt ist.
- Automatisiere Routine-Reaktionen und reduziere manuelle Schritte.
- Führe regelmäßige Post-Incident-Reviews mit konkreten Verbesserungen durch.
I/O & Ressourcen
- Monitoring- und Alerting-Konfiguration
- On-Call-Dienstplan und Eskalationsmatrix
- Runbooks, Playbooks und Kontaktdaten
- Erkannte und bearbeitete Vorfälle mit Timeline
- Post-Incident-Reports und action items
- Verbesserte Runbooks und reduzierte Alarmflut
Beschreibung
On-Call beschreibt die strukturierte Rotation von Verantwortlichkeiten für Betriebsteams, um Störungen schnell zu erkennen, zu eskalieren und zu beheben. Es umfasst Bereitschaftspläne, Alarmierung, Runbooks und Nachbesprechungen zur kontinuierlichen Verbesserung. Gut gestaltete On-Call-Prozesse reduzieren Ausfallzeiten und verteilen Wissen nachhaltig in der Organisation.
✔Vorteile
- Schnellere Wiederherstellung und geringere Ausfallzeiten.
- Wissen wird im Team verteilt und nicht bei Einzelpersonen gebunden.
- Bessere Messbarkeit von Betriebseffekten und Verbesserungszyklen.
✖Limitationen
- Erhöhter Stress für beteiligte Personen, insbesondere bei schlechter Planung.
- Aufwand für Schichtplanung und Verwaltung kann signifikant sein.
- Ohne gute Automatisierung entsteht hoher Lärm durch nicht relevante Alerts.
Trade-offs
Metriken
- Mean Time to Acknowledge (MTTA)
Mittlere Zeit bis zur Bestätigung eines Alarms durch On-Call.
- Mean Time to Resolve (MTTR)
Mittlere Zeit bis zur Wiederherstellung des normalen Betriebs nach einem Vorfall.
- Alert-Noise-Ratio
Anteil irrelevanter oder falsch positiver Alarme an der Gesamtzahl.
Beispiele & Implementierungen
Etablierte SRE-On-Call-Rotation
Ein SRE-Team führt rotierende Bereitschaft ein, kombiniert Alarmpriorisierung und Skrivens zur Fehlerbehebung.
Kleinteam mit geteilten Bereitschaftszeiten
Ein kleines Produktteam teilt Rufbereitschaft über wenige Personen und nutzt klare Eskalationspfade.
Extern unterstützte Bereitschaft durch Pager-Service
Ein Team nutzt einen Pager-/Incident-Service für Alarmierung, ergänzt durch automatisierte Playbooks.
Implementierungsschritte
Definieren von Zielen, SLAs und Kompensationsregeln für On-Call.
Einführen eines rotierenden Dienstplans und klarer Eskalationspfade.
Erstellen und Testen von Runbooks; Messgrößen einführen und überwachen.
⚠️ Technische Schulden & Engpässe
Tech Debt
- Fehlende Automatisierung bei häufigen Recovery-Schritten.
- Veraltete oder nicht getestete Runbooks und Playbooks.
- Unzureichende Integration zwischen Monitoring und Pager-Systemen.
Bekannte Engpässe
Beispiele für Missbrauch
- Ständige Heimarbeit der Entwickler als Ersatz für strukturierte On-Call-Prozesse.
- Eskalationen direkt an Management statt an technische Experten.
- On-Call ohne Zugang zu Logs/Runbooks und ohne Handlungsanweisungen.
Typische Fallen
- Unzureichende Transition zwischen Schichten führt zu Informationsverlust.
- Mangelnde Messung verhindert Verbesserung der Bereitschaftsqualität.
- Zu enge Rotation ohne Erholungszeit erhöht Fehlerrisiko.
Erforderliche Fähigkeiten
Drivers (Architectural Drivers)
Constraints
- • Arbeitszeitgesetzliche Regelungen und Kompensationspflichten
- • Verfügbarkeit von qualifiziertem Personal zur Rotation
- • Integration in bestehende Alarmierungs- und Monitoring-Systeme