Wenn um 3 Uhr morgens das Telefon klingelt, ist die Qualität des On-Call-Setups sofort erkennbar. Teams ohne klare Prozesse kämpfen sich durch unvollständige Runbooks, raten bei Eskalationspfaden und versuchen halbschlafend zu verstehen, was ein Monitoring-Alarm eigentlich bedeutet. Teams mit durchdachtem Setup hingegen wissen innerhalb weniger Minuten, was zu tun ist – und schlafen danach wieder ruhig. Der Unterschied liegt nicht im Talent einzelner Personen, sondern in der Struktur des Systems.
Was On-Call bedeutet und wer es braucht
On-Call bezeichnet die Bereitschaft, außerhalb der regulären Arbeitszeiten auf Systemvorfälle zu reagieren. Jedes Team, das Dienste betreibt, die rund um die Uhr verfügbar sein sollen, braucht eine Form von Bereitschaftsabdeckung. Das gilt nicht nur für große Unternehmen – auch kleine Startups mit zahlenden Kunden haben die Verantwortung, auf kritische Ausfälle zeitnah zu reagieren. Die Form muss dabei nicht aufwändig sein, aber sie muss existieren und klar definiert sein.
Eine Rotation verteilt die Last auf mehrere Schultern: Niemand ist dauerhaft allein verantwortlich, alle wissen im Voraus, wann ihre Schicht beginnt und endet, und es gibt klare Regelungen für Vertretungen und Übergaben. Ohne Rotation tragen meistens die erfahrensten oder am stärksten involvierten Personen die gesamte Last – ein direkter Weg zu Burnout und Fluktuation.
Rotationsstruktur: Primär, Sekundär und Eskalation
Eine bewährte Grundstruktur besteht aus drei Ebenen. Die primäre On-Call-Person ist die erste Anlaufstelle und empfängt alle Alarme. Sie versucht, das Problem eigenständig zu lösen oder einzuschätzen, welche Eskalation nötig ist. Die sekundäre On-Call-Person fungiert als Backup: Sie wird gerufen, wenn der primäre On-Call nicht erreichbar ist oder Unterstützung benötigt. Die dritte Ebene umfasst Führungskräfte oder Fachspezialisten, die bei schwerwiegenden oder lang anhaltenden Vorfällen einbezogen werden.
Diese Hierarchie muss nicht formal kompliziert sein. Wichtig ist, dass jeder weiß, wen er anruft, wenn er selbst nicht weiterkommt. Eskalationspfade sollten schriftlich dokumentiert und im Monitoring-System hinterlegt sein – nicht ausschließlich in den Köpfen einzelner Personen.
Schichtlänge und Übergaben
Die übliche Schichtlänge beträgt eine Woche, bei kleinen Teams manchmal weniger. Längere Schichten erhöhen die Belastung, kürzere verursachen mehr Übergabeaufwand. Am Ende jeder Schicht sollte eine strukturierte Übergabe stattfinden: Was ist in dieser Woche passiert? Welche Alarme wurden ausgelöst und wie wurden sie behandelt? Gibt es offene Probleme oder laufende Untersuchungen? Diese Übergabe muss nicht aufwändig sein – ein kurzes schriftliches Protokoll reicht. Sie verhindert, dass Informationen zwischen Schichten verloren gehen.
Besonders wichtig: Die On-Call-Person sollte nicht gleichzeitig erwartet werden, ihre reguläre Entwicklungsarbeit im vollen Umfang zu erledigen. On-Call kostet mentale Kapazität – allein das Bewusstsein, jederzeit gerufen werden zu können, erzeugt Hintergrundstress. Teams, die das ignorieren und On-Call als läuft nebenbei behandeln, produzieren schlechtere Arbeit in beiden Bereichen.
Runbooks: Das Gedächtnis des Teams
Ein Runbook ist eine dokumentierte Handlungsanleitung für ein bekanntes Problem oder einen bekannten Alarmtyp. Gute Runbooks sind kurz, konkret und direkt aus dem Alarm verlinkt. Sie beschreiben das Problem in einem Satz, zeigen die relevanten Prüfschritte, listen hilfreiche Befehle und definieren, ab wann eskaliert wird. Was sie nicht sind: Essays, Erklärartikel oder Systemdokumentationen.
Das kritische Detail ist die direkte Verlinkung: Wenn ein Alarm um 2 Uhr nachts ausgelöst wird, sollte die On-Call-Person einen Link direkt zum passenden Runbook finden – nicht erst suchen müssen. Runbooks, die niemand findet, helfen nicht. Runbooks, die veraltet sind, können aktiv schaden. Jedes Team sollte deshalb einen Prozess haben, Runbooks nach Vorfällen zu aktualisieren.
Alarme richtig einordnen
Ein häufiger Fehler beim On-Call-Setup ist, alle Alarme auf den gleichen Kanal und mit der gleichen Dringlichkeit zu schicken. Das Ergebnis ist Alarmermüdung: Alle Benachrichtigungen werden gleich behandelt, weil sie gleich aussehen. Besser ist eine klare Unterteilung: Kritische Alarme, die sofortiges menschliches Eingreifen erfordern, kommen auf den On-Call-Kanal und wecken bei Bedarf. Warnungen, die wichtig aber nicht dringend sind, kommen in einen separaten Kanal ohne Nachtbenachrichtigung. Informative Meldungen landen ausschließlich in Logs oder Dashboards.
Jeder Alarm, der nachts ausgelöst wird und beim Prüfen keine Handlung erfordert, ist falsch konfiguriert. Solche Alarme untergraben das Vertrauen ins Monitoring-System und erhöhen die Wahrscheinlichkeit, dass auch echte kritische Alarme ignoriert werden.
Technische Voraussetzungen
Ein funktionierendes On-Call-Setup braucht verlässliches Monitoring als Fundament. HTTP-Monitore müssen zuverlässig die Erreichbarkeit von Diensten prüfen. Heartbeat-Checks überwachen Prozesse und Batch-Jobs, die regelmäßig ein Lebenszeichen senden sollten. Benachrichtigungskanäle müssen so konfiguriert sein, dass kritische Alarme tatsächlich ankommen – das bedeutet in der Regel mindestens zwei unabhängige Kanäle, etwa E-Mail und Push-Benachrichtigung oder SMS. Wenn ein Benachrichtigungskanal ausfällt, muss der andere einspringen.
Faire Bedingungen als Grundvoraussetzung
On-Call kann auf Dauer nur funktionieren, wenn die Bedingungen fair sind. Das bedeutet: genug Personen in der Rotation, damit keine Einzelperson dauerhaft überfordert wird; Ausgleich oder Anerkennung für belastende Nachtschichten; aktive Bemühung, die Alarmrate zu senken und Toil zu reduzieren. Teams, die On-Call als Selbstverständlichkeit behandeln und die Belastung nicht adressieren, verlieren über Zeit die Personen, die am meisten Systemkenntnis haben.
Fazit
On-Call ist keine Strafe und keine Notlösung – es ist eine professionelle Dienstleistung für Nutzer und das eigene System. Mit durchdachten Rotationen, klaren Eskalationspfaden, präzisen Alarmen und lebendigen Runbooks wird Bereitschaftsdienst zur routinierten Aufgabe, die das Team stärkt statt erschöpft. Der Schlüssel liegt in der Struktur – nicht im Heldenmut Einzelner. Wer einmal ein gut funktionierendes On-Call-Setup erlebt hat, möchte nicht mehr ohne. Ein weiterer wichtiger Aspekt ist die Vermeidung von personengebundenem Wissen. Systeme, die nur eine einzige Person vollständig versteht, sind ein Risiko für die On-Call-Qualität. Gute Rotation setzt deshalb voraus, dass Runbooks und Dokumentation so vollständig sind, dass jede Person in der Rotation kompetent reagieren kann – das ist ein direkter Anreiz für bessere Dokumentation und schützt das Team langfristig.
