Bereitschaftsdienst ist ein unverzichtbarer Bestandteil des modernen IT-Betriebs. Wer Produktivsysteme betreibt, muss auch nachts, an Wochenenden und Feiertagen erreichbar sein. Was auf dem Papier selbstverständlich klingt, hat in der Praxis eine dunkle Seite: Unkontrollierter On-Call-Betrieb zählt zu den Hauptgründen für Burnout, erhöhte Fluktuation und sinkende Qualität im Incident Response. Dieser Beitrag zeigt, wie Teams durch smarte Rotationsmodelle und KI-gestützte Alarmfilterung den Bereitschaftsdienst menschlicher gestalten können.
Das eigentliche Problem: Alert-Volumen ohne Intelligenz
Die meisten On-Call-Probleme entstehen nicht, weil Systeme häufiger ausfallen. Sie entstehen, weil zu viele Alarme ausgelöst werden, die keine echte menschliche Reaktion erfordern. Studien aus dem SRE-Umfeld zeigen, dass ein erheblicher Anteil aller Nacht-Alerts entweder selbstheilend ist, bereits bekannt war oder durch fehlerhafte Schwellenwerte ausgelöst wurde.
Das Ergebnis: Menschen werden um 2:30 Uhr geweckt, schauen fünf Minuten auf Dashboards, stellen fest, dass sich das Problem selbst gelöst hat – und versuchen, wieder einzuschlafen. Passiert das mehrfach pro Woche, akkumuliert sich ein Schlafdefizit, das Konzentration, Entscheidungsfähigkeit und langfristig die Gesundheit beeinträchtigt. Alert Fatigue ist kein individuelles Versagen, sondern eine systemische Fehlfunktion.
KI als Filter: Weniger Lärm, mehr Relevanz
Moderne KI-gestützte Alerting-Systeme setzen an genau diesem Punkt an. Anstatt jeden Alarm direkt an eine Person weiterzuleiten, analysieren sie Muster, Korrelationen und historische Daten, bevor ein Alert eskaliert wird. Konkrete Techniken umfassen:
- Deduplication und Grouping: Mehrere Alarme, die denselben Root Cause haben, werden zu einem einzigen Vorfall zusammengefasst. Statt zehn separater Alerts für fünf ausgefallene Pods erhält das On-Call-Team eine einzige, kontextualisierte Meldung.
- Dynamische Schwellenwerte: KI-Modelle erkennen, dass ein System nachts typischerweise unter geringerer Last läuft und passen Alarmgrenzen automatisch an. Ein Latenzanstieg, der tagsüber kritisch wäre, ist um 3 Uhr morgens bei einem Zehntel des normalen Traffics möglicherweise unbedeutend.
- Selbstheilende Alarme unterdrücken: Wenn ein Alert in den letzten 30 Minuten dreimal ausgelöst und automatisch aufgelöst wurde, ohne menschliche Intervention, kann das System lernen, ihn zunächst stumm zu schalten und nur bei Persistenz zu eskalieren.
- Kontext-Anreicherung: Bevor ein Alert eine Person erreicht, wird er mit relevanten Informationen angereichert: aktueller Status ähnlicher Systeme, jüngste Deployments, bekannte ähnliche Vorfälle aus der Vergangenheit. Das verkürzt die Diagnosephase erheblich.
Smarte Rotationsmodelle: Fairness als Grundprinzip
Neben der technischen Alert-Filterung ist das Rotationsmodell entscheidend für die nachhaltige Belastungsverteilung im Team. Klassische Modelle, bei denen eine Person eine Woche lang ununterbrochen Bereitschaft hat, sind für viele Systeme zu belastend. Besser bewährte Ansätze sind:
- Kürzere Rotationszyklen: Zwei bis drei Tage statt sieben reduzieren die maximale Belastung pro Zyklus erheblich. Kombiniert mit guten Runbooks, die den Wissenstransfer beim Wechsel sicherstellen, funktioniert das auch bei komplexen Systemen.
- Follow-the-Sun-Modelle: Teams, die über mehrere Zeitzonen verteilt sind, können Bereitschaft so aufteilen, dass jedes Mitglied nur während seiner normalen Wachzeit On-Call ist. Das setzt eine gewisse Teamgröße und internationale Verteilung voraus, ist aber für viele Unternehmen machbar.
- Shadow On-Call: Neue Teammitglieder werden zunächst einem erfahrenen On-Call-Mitglied zugeteilt, ohne selbst Alarmverantwortung zu tragen. Das baut Kompetenz auf und reduziert den Druck beim ersten echten Einsatz.
- Service-basierte Rotation: Statt alle Systeme auf eine einzige Bereitschaftsperson zu legen, werden Rotationen nach Servicezuständigkeit aufgeteilt. Wer das System am besten kennt, ist auch am besten geeignet, nachts dafür Bereitschaft zu leisten.
Schwellenwerte sorgfältig kalibrieren
Einer der häufigsten Fehler im Alerting ist die unreflektierte Übernahme von Standardkonfigurationen aus Monitoring-Templates. Ein CPU-Alert bei 80% mag für einen bestimmten Dienst sinnvoll sein, für einen anderen ist es ein vollkommen normaler Betriebszustand.
Sinnvoller ist ein regelmäßiger Review-Prozess, bei dem das Team nach jedem Bereitschaftszyklus auswertet: Welche Alarme haben tatsächlich menschliche Eingriffe erfordert? Welche waren falsch positiv? Welche haben zu spät ausgelöst? Dieser Feedback-Loop führt schrittweise zu einem Alerting-Setup, das zu den tatsächlichen Systemeigenschaften passt – und nicht zu einem generischen Monitoring-Template.
Postmortem-Kultur und strukturiertes Lernen
Burnout entsteht auch dann, wenn Teams das Gefühl haben, immer wieder dieselben Probleme zu lösen, ohne dass etwas verbessert wird. Eine konsequente Postmortem-Kultur, die nach jedem signifikanten Incident die Ursachen analysiert und konkrete Maßnahmen ableitet, wirkt dem entgegen.
Wichtig dabei: Postmortems ohne Schuldzuweisungen. Das Ziel ist nicht, verantwortliche Personen zu identifizieren, sondern Systemschwächen zu beheben. Teams, die dies ernst nehmen, beobachten mit der Zeit eine sinkende Incident-Häufigkeit – und damit auch eine sinkende On-Call-Belastung.
Kompensation und Wertschätzung
Technische Maßnahmen allein reichen nicht aus. On-Call-Belastung muss auch menschlich anerkannt werden. Das umfasst finanzielle Kompensation für geleistete Bereitschaft und nächtliche Einsätze, aber auch nicht-monetäre Maßnahmen wie Ausgleichszeit nach intensiven Nächten, klare Kommunikation über Erwartungen und offene Gespräche im Team über Belastungsgrenzen.
Teams, in denen On-Call als "selbstverständlich" gilt und keine besondere Wertschätzung erfährt, haben signifikant höhere Fluktuationsraten in diesem Bereich. Der Verlust erfahrener SREs oder Operations-Engineers ist langfristig kostspieliger als angemessene Kompensation.
Heartbeat-Monitoring als stille Sicherheitsnetz
Ein oft unterschätzter Baustein für ruhigere Nächte ist das Heartbeat-Monitoring für Hintergrundprozesse. Viele Cronjobs, ETL-Pipelines und asynchrone Tasks laufen im Hintergrund, ohne aktiv überwacht zu werden – bis sie ausfallen und die Konsequenzen Stunden später auffallen. Heartbeat-Checks, bei denen ein Prozess nach erfolgreichem Durchlauf ein Signal sendet, kehren die Überwachungslogik um: Ausbleiben des Signals ist der Alarm, nicht ein aktiv erkannter Fehler. Das reduziert die Reaktionszeit bei ausgefallenen Hintergrundprozessen und verhindert, dass stille Fehler erst bei manuellen Prüfungen entdeckt werden.
Fazit: On-Call kann menschenwürdig sein
Bereitschaftsdienst muss kein Synonym für schlechten Schlaf und ständige Anspannung sein. Mit sorgfältig kalibrierten Alarmen, klaren Rotationsmodellen, KI-gestützter Alarmfilterung und einer offenen Feedbackkultur lässt sich ein On-Call-System aufbauen, das Systeme zuverlässig überwacht, ohne die Menschen dahinter zu erschöpfen. Der Schlüssel liegt nicht in der Akzeptanz von Burnout als unvermeidbare Begleiterscheinung des IT-Betriebs, sondern in der systematischen Verbesserung der Bedingungen, unter denen Menschen Bereitschaft leisten.
Bildquelle: Pexels / fauxels
Quellen
- Google SRE Book – Kapitel zu On-Call und Alert Management (sre.google)
- PagerDuty – State of Digital Operations Report (pagerduty.com)
- The New Stack – Practical approaches to reducing on-call burden (thenewstack.io)
