On-Call-Rotationen, die dein Team nicht zerstören

Was ist Bereitschaftsplanung überhaupt?

Bereitschaftsplanung (On-Call Scheduling) ist ein System, das festlegt, welches Teammitglied zu welcher Zeit verantwortlich für einen Ausfall ist. Es geht nicht nur um einen Kalender mit Namen und Schichten, sondern um Eskalationspfade, Handoff-Prozesse und die Frage, was passiert, wenn die verantwortliche Person nicht antwortet.

In SRE- und DevOps-Teams bedeutet das konkret, folgende Fragen vor einem Incident zu beantworten:

• Wer reagiert, wenn das Monitoring einen kritischen Alert feuert?

• Wer wird zuerst angerufen? Wer ist Backup?

• Wann wird an die nächste Ebene eskaliert?

Warum Bereitschaft ohne klare Planung scheitert

Die häufigsten Probleme sind nicht technischer, sondern organisatorischer Natur. Teams, die Bereitschaft informell regeln, haben in der Praxis niemanden, der wirklich Verantwortung trägt. Alert-Benachrichtigungen werden ignoriert, weil alle davon ausgehen, dass jemand anderes reagiert. Oder es reagieren drei Leute gleichzeitig und überschreiben sich gegenseitig, wodurch das Chaos die Situation nur noch schlimmer macht.

Das andere Extrem ist genauso problematisch: ein oder zwei Seniors haben dauerhafte Bereitschaft, weil sie das System als Einzige gut genug kennen. Laut dem State of Engineering Management Report 2024 haben 65 % der Entwickler im vergangenen Jahr Burnout erlebt. On-Call-Stress ist einer der stärksten Treiber, besonders wenn Rotationen ungerecht verteilt sind.

Gute Bereitschaftsplanung löst beides: Sie verteilt die Last fair und stellt sicher, dass immer jemand klar verantwortlich ist.

Die wichtigsten Rotationsmodelle

Es gibt kein universell richtiges Modell. Die Wahl hängt von Teamgröße, Zeitzonen und Alert-Volumen ab. Hier sind die drei gängigsten Ansätze:

Wöchentliche Rotation (der sichere Einstieg)

Eine Person übernimmt für eine ganze Woche die primäre Bereitschaft. Wöchentliche Rotationen sind für die meisten Teams der optimale Einstieg: Jede Person bekommt genug ununterbrochene Off-Call-Zeit zur Erholung, bleibt aber häufig genug im Kontakt mit den Systemen, um sattelfest zu bleiben.

Für Teams mit drei bis acht Personen bedeutet das eine On-Call-Woche alle drei bis acht Wochen - ein Rhythmus, den die meisten als fair empfinden.

Follow-the-Sun (für verteilte Teams)

Bei Teams, die über mehrere Zeitzonen verteilt sind, übernimmt jede Region die Bereitschaft nur während ihrer normalen Arbeitszeiten. Die Verantwortung wandert also mit der Sonne, und keiner muss mitten in der Nacht raus, weil die Schichten mit den Arbeitszeiten zusammenfallen.

Das klingt elegant, hat aber einen echten Nachteil: Übergaben sind aufwendig. Wer Bereitschaft abgibt, muss den Nachfolger vollständig über offene Incidents und Instabilitäten briefen. Ohne strukturierte Handoffs gehen Kontext und Verantwortung verloren.

Primär/Sekundär-Modell (für höheres Alert-Volumen)

Zwei Personen teilen sich eine Schicht: Eine ist primär verantwortlich, die andere ist Backup und hilft zusätzlich im Notfall. Bei komplexen Incidents arbeiten beide zusammen, statt dass einer allein eskaliert. Dieses Modell reduziert den Druck auf Einzelpersonen und ist besonders sinnvoll, wenn Junior-Engineers in den On-Call-Betrieb eingeführt werden. So können sie neben einer erfahreneren Person lernen, bevor sie allein die Verantwortung tragen.

⚠️ Zur primären Bereitschaft gehört immer eine Backup-Ebene. Wenn die erste Person nicht antwortet, ruft das System nach fünf bis zehn Minuten die zweite Person an. Das reduziert den Druck auf den Hauptverantwortlichen erheblich.

Was den On-Call-Betrieb wirklich zerstört: Alert-Fatigue

Der gut durchdachte Rotationsplan nützt wenig, wenn um 2 Uhr nachts der fünfte Alert innerhalb einer Stunde feuert und wie die anderen keine Handlung erfordert.

Eine Splunk-Studie aus 2025 zeigte, dass 73 % der Organisationen Ausfälle durch ignorierte Alerts erlebt haben. Das passiert nicht aufgrund von Nachlässigkeit. Es passiert, weil Engineers konditioniert wurden, Alerts als Hintergrundrauschen zu behandeln, da zu viele von ihnen nicht actionable sind.

Die Empfehlung aus dem Google SRE Workbook: maximal zwei handlungsrelevante Incidents pro Schicht als nachhaltiger Richtwert. Alles darüber hinaus ist ein Zeichen, dass Alerts angepasst werden müssen, nicht dass das Team mehr aushalten soll.

Konkret bedeutet das, regelmäßige Alert-Reviews einzuplanen. Für jeden Alert, der in den letzten 30 Tagen mehr als dreimal gefeuert hat, ohne dass etwas zu tun war, gibt es drei Optionen: fixen, abstellen oder den Schwellenwert anpassen.

Runbooks: Das unterschätzte Werkzeug

Stell dir vor, ein Junior-Engineer hat gerade die erste Allein-Bereitschaft. Es ist 23 Uhr, die Datenbank verhält sich seltsam, und er weiß nicht genau, ob das ein echter Incident ist oder ein bekanntes Muster, das sich von selbst löst. Runbooks beantworten genau diese Frage: Was tue ich jetzt?

Ein gutes Runbook ist eine kompakte Checkliste: welches Dashboard öffnen, welche Commands ausführen, wen bei Eskalation kontaktieren. Nicht mehr und nicht weniger.

Für den Einstieg empfiehlt es sich, die fünf häufigsten Incident-Typen aus dem letzten Quartal zu identifizieren und für jeden ein Runbook zu schreiben. Das reduziert die kognitive Last und die Angst, die Burnout beschleunigt.

Faire Übergaben: Damit Kontext nicht verloren geht

Jede On-Call-Übergabe sollte ein strukturiertes Handoff-Dokument erzeugen:

• Was war in dieser Woche los?

• Welche Incidents gab es? Was ist noch offen?

• Wo gibt es bekannte Instabilitäten?

Dieses Dokument sollte in einem gemeinsamen Kommunikations-Kanal gepostet werden, der für das gesamte Team sichtbar ist. Das kostet zehn Minuten am Ende einer Schicht. Die Alternative ist, dass die nächste Person mit einem Incident konfrontiert wird, dessen Hintergrund sie nicht kennt - was die Lösungszeit verdreifacht.

Wann Bereitschaft zu viel wird — und was dann zu tun ist

Bereitschaftsplanung ist kein rein technisches Problem. Es ist auch eine Frage von Teamkultur und Transparenz. Wenn eine Rotation faire Schichten hat, aber Engineers trotzdem erschöpft wirken, lohnt es sich, drei Dinge zu messen:

Alert-Volumen pro Schicht: Wer trägt die Hauptlast? Wird das gleichmäßig verteilt oder haben manche Teams strukturell mehr Alerts?

Mean Time to Acknowledge (MTTA): Wenn Bestätigungen regelmäßig lange dauern, ist das entweder ein Zeichen von Alert-Fatigue oder davon, dass Personen Bereitschaft haben, die sich dabei nicht sicher fühlen.

Post-Incident Reviews: Rekapitulation nicht als Schuldzuweisung, sondern als Lernformat. Was hat die Reaktion verlangsamt? Wie kann das künftig behoben werden?