Wie du eine On-Call-Rotation über Zeitzonen hinweg gestaltest

Das Ziel ist Follow-the-Sun-Abdeckung: Vorfälle werden von denjenigen aufgegriffen, die wach sind, niemand wird regelmäßig um 3 Uhr morgens angepiepst, die 24-Stunden-Uhr wird aufgeteilt, ohne dass eine Person den Großteil der Last trägt.

Das Schwierige ist nicht das Konzept. Es sind die Übergaben.

Das Grundmodell

Die einfachste Struktur weist jedem regionalen Team ein zusammenhängendes UTC-Fenster während ihres normalen Arbeitstags zu:

24-Stunden-Abdeckung, niemand außerhalb der Arbeitszeit on-call. Das ist die saubere Version. Echte Teams haben nicht immer drei ausgewogene regionale Büros – dazu mehr unten.

Übergaben sind der Schwachpunkt

Die meisten Ausfälle bei On-Call-Rotationen passieren an Übergabegrenzen. Ein Vorfall tritt um 15:55 UTC auf – ist das APAC oder Europa? Wenn die Antwort unklar ist, werden Pages verpasst oder doppelt ausgelöst.

Definiere es explizit:

• Zuständigkeit wird dadurch bestimmt, wer on-call ist, wenn der Vorfall eintritt – nicht, wer ihn zuerst untersucht hat.
• An Schichtgrenzen schreibt der ausgehende Engineer eine kurze Statusübersicht; der eingehende Engineer bestätigt, bevor der ausgehende geht.
• Baue eine 15–30-minütige Überschneidung an jeder Übergabe ein, wo beide Teams verfügbar sind. Das kostet wenig und fängt alles ab, was an der Naht eintrifft.

DST verursacht Rotationsdrift

Wenn deine Engineers in DST-beobachtenden Regionen sind, müssen die UTC-Abdeckungsfenster sich verschieben, wenn die Uhren umgestellt werden – sonst passen die Fenster nicht mehr zu den tatsächlichen Arbeitstagen.

Beispiel: London deckt 08:00–16:00 UTC im Winter ab. Nach dem britischen Wechsel zu BST (UTC+1) ist 08:00 UTC 9 Uhr London – eine Stunde in ihren Tag, aber effektiv starten sie die On-Call-Zeit eine Stunde früher Ortszeit.

Die fehlerunanfälligste Lösung: Verankere Schichten in Ortszeit in deinem On-Call-Tool („8–16 Uhr Londoner Zeit”) und lass das Tool die UTC-Konvertierung übernehmen. Die meisten modernen Plattformen unterstützen das. Wenn deines das nicht tut, musst du UTC-Fenster zweimal im Jahr nach DST-Übergängen aktualisieren – was Leute konsequent vergessen zu tun.

Wenn du keine drei ausgewogenen Regionen hast

Drei Teams mit 8-Stunden-Fenstern, die die Uhr sauber aufteilen, ist der Idealfall. Die meisten Teams haben das nicht.

Zwei Regionen: Eine muss die Lücke abdecken. Rotiere wöchentlich – Woche A erweitert Americas auf Mitternacht UTC; Woche B beginnt Europa um 06:00 UTC. Verfolge es explizit, damit kein Team es dauerhaft trägt.

Ungleiche Teamgrößen: Passe Fenstergrenzen so an, dass die Stunden pro Engineer ungefähr gleich sind – nicht so, dass regionale Fenster gleich groß sind. Ein Team von 10, das 10 Stunden abdeckt, hat eine geringere Pro-Kopf-Last als ein Team von 2, das 8 Stunden abdeckt.

Wochenend-Abdeckung: Definiere das separat vom Wochentag. Viele Teams akzeptieren längere SLAs am Wochenende und weniger on-call Engineers. Formuliere es explizit – „implizite” Wochenend-Abdeckungserwartungen sind eine zuverlässige Quelle für Spannungen.

Nutze meetwhen, um zu überprüfen, dass deine UTC-Fenster in der Ortszeit jedes Engineers dort landen, wo du es erwartest – besonders nach DST-Wechseln oder wenn ein neues Team aus einer anderen Stadt hinzukommt.