Rufbereitschaft (On-Call) ist ein Dienstmodell, bei dem eine benannte Person für einen festgelegten Zeitraum erreichbar ist und innerhalb einer vereinbarten Reaktionszeit auf Alarme und Incidents in Produktion reagiert. Gute Rufbereitschaft verbindet eine faire Rotation, handlungsrelevante Alarme, klare Eskalationswege, Runbooks und eine tragbare Belastung.
Was ist Rufbereitschaft?
Rufbereitschaft, im Englischen On-Call, bedeutet: Eine bestimmte Person ist für ein definiertes Zeitfenster dafür verantwortlich, auf Probleme in Produktion zu reagieren. Löst ein Alarm aus, bestätigt die Person ihn, bewertet die Auswirkungen auf Nutzer, mildert das Problem ab oder eskaliert und übergibt am Ende der Schicht sauber an die nächste Person. Rufbereitschaft gibt es, weil Software rund um die Uhr läuft, die Menschen, die sie verstehen, aber nicht rund um die Uhr arbeiten.
Wer Rufbereitschaft hat, muss nicht alles allein reparieren. Die Person ist Ersthelfer und koordiniert die ersten Minuten. Ihr wichtigstes Ziel ist, die Auswirkungen auf Nutzer schnell zu begrenzen. Deshalb bestimmt die Qualität der Rufbereitschaft direkt die MTTR.
Gängige Rotationsmodelle
| Modell | Funktionsweise | Geeignet für |
|---|---|---|
| Wöchentliche Rotation | Eine primär zuständige Person pro Woche, Übergabe an einem festen Wochentag | Kleine Teams mit moderatem Alarmaufkommen |
| Primär / sekundär | Eine zweite Person übernimmt, wenn die erste nicht rechtzeitig bestätigt | Kritische Services, größere Teams |
| Follow-the-Sun | Schichten wandern über Zeitzonen, niemand wird nachts geweckt | Verteilte Organisationen mit Teams in mehreren Regionen |
| Kernzeit plus Eskalation | Reaktion während der Arbeitszeit, nachts nur bei schweren Incidents | Interne Tools und weniger kritische Services |
Welches Modell Sie auch wählen: Legen Sie es schriftlich fest. Wer hat Bereitschaft, wie schnell muss bestätigt werden, wer ist Eskalationskontakt, wie läuft die Übergabe? Unklarheit macht aus einem kleinen Alarm einen langen Incident.
Was darf einen Menschen wecken?
Die wichtigste Regel: Ein Page muss dringend, handlungsrelevant und an Nutzerauswirkungen gekoppelt sein. Muss niemand innerhalb von Minuten handeln, gehört die Meldung in ein Ticket, nicht aufs Telefon. Symptombasierte Alarme auf den Golden Signals und auf die Burn Rate eines SLO erfüllen diese Regel, Alarme auf jede CPU-Spitze nicht.
Das Google-SRE-Buch nennt konkrete Grenzen für nachhaltige Bereitschaft: SREs sollen höchstens 25 Prozent ihrer Zeit in Rufbereitschaft verbringen, und pro 12-Stunden-Schicht sollten im Schnitt nicht mehr als zwei Incidents anfallen, weil jeder Vorfall Zeit für Diagnose, Behebung und Nacharbeit braucht. Wer diese Werte dauerhaft überschreitet, landet bei Alert Fatigue, übersehenen Alarmen und Erschöpfung.
Beispiel: eine Eskalationsrichtlinie
Eine beispielhafte Richtlinie für einen Payment-Service:
- Ein Severity-1-Alarm geht per Push und Anruf an die primäre Rufbereitschaft.
- Keine Bestätigung nach 5 Minuten: Die sekundäre Person wird alarmiert.
- Keine Bestätigung nach 15 Minuten: Die diensthabende Führungskraft wird alarmiert.
- Nach der Bestätigung eröffnet die Person einen Incident, verknüpft Alarm, Dashboard und Runbook und veröffentlicht innerhalb von 15 Minuten ein erstes Status-Update.
Niedrigere Schweregrade erzeugen ein Ticket und eine Nachricht im Team-Channel, ohne jemanden zu wecken. Die genauen Zeiten hängen von Ihren SLOs ab. Entscheidend ist, dass sie dokumentiert und getestet sind.
Best Practices
- Jeder Alarm hat einen Owner und ein Runbook. Niemand soll um drei Uhr nachts raten müssen, was eine Meldung bedeutet.
- Alarme wöchentlich prüfen. Zählen Sie Pages pro Schicht, markieren Sie jeden als handlungsrelevant oder Rauschen und entfernen oder justieren Sie das Rauschen.
- Übergaben schützen. Eine kurze schriftliche Zusammenfassung offener Themen, aktueller Deployments und laufender Maßnahmen verhindert Kontextverlust.
- Vergütung und Erholung regeln. Zulagen oder Freizeitausgleich und Ruhezeit nach nächtlichen Einsätzen halten die Rotation tragfähig. In Deutschland sind dabei Arbeitszeitgesetz, Ruhezeiten und gegebenenfalls Betriebsvereinbarungen zu beachten; klären Sie die Details mit HR oder Rechtsabteilung.
- Vor der ersten Schicht trainieren. Shadow-Schichten und Game Days schaffen Sicherheit, bevor jemand allein Bereitschaft hat.
- Den Kreis schließen. Größere Incidents bekommen ein schuldfreies Postmortem mit Maßnahmen, die künftige Alarme verhindern.
Die Gesundheit der Rufbereitschaft messen
Betrachten Sie Rufbereitschaft als System, das Sie beobachten können. Aussagekräftige Kennzahlen sind Pages pro Schicht, der Anteil handlungsrelevanter Alarme, die Zeit bis zur Bestätigung, die Zahl nächtlicher Alarme und wie viele Incidents eskaliert werden mussten. Erfassen Sie diese Werte pro Team und pro Service und besprechen Sie den Trend in einem monatlichen Operations-Review. Steigen die nächtlichen Pages oder sinkt der handlungsrelevante Anteil, ist das ein Frühwarnsignal, lange bevor Kolleginnen und Kollegen kündigen. Fragen Sie nach jeder Schicht, was die Arbeit gebremst hat: Fehlende Dashboards, unklare Runbooks oder laute Alarme lassen sich meist mit wenig Aufwand beheben.
Typische Fehler
- Alarmierung auf Ursachen (hohe CPU, ein ausgefallener Pod) statt auf Symptome, die Nutzer bemerken.
- Rotationen mit zu wenigen Personen, sodass jede jede zweite Woche Bereitschaft hat.
- Eskalationswege, die nur im Kopf einzelner Personen existieren.
- Rufbereitschaft als reine Feuerwehr verstehen und nie in Fixes investieren, die wiederkehrende Alarme beseitigen.
Wie Obseria hilft
Obseria fasst zusammengehörige Alarme zu einem Problem mit betroffenen Services und wahrscheinlicher Ursache zusammen, sodass die Rufbereitschaft einen Page statt zwanzig erhält. Das Incident Management von Obseria dokumentiert Zeitachse, Beteiligte und Status-Updates, und Obseria Intelligence kann eine agentische Ursachenanalyse mit Beweiskette starten, während die Person noch den Laptop aufklappt. Workflows in Obseria Automation führen sichere Runbook-Schritte automatisch aus.