Das Problem: On-Call als Belastungstest für Teams
Bereitschaftsdienst ist in der modernen IT-Organisation unvermeidlich. Systeme fallen nicht zu Bürozeiten aus, und Produktionsprobleme warten nicht auf Montagmorgen. Doch die Art, wie On-Call-Rotationen in vielen Teams aufgebaut sind, erzeugt chronischen Stress, reduziert die Schlafqualität der Beteiligten und führt langfristig zu Burnout und Fluktuation.
2026 ist das Thema On-Call-Wohlbefinden in der SRE- und Platform-Engineering-Community fest angekommen. Teams beginnen zu verstehen: Wer auf Dauer unzuverlässige Alerting-Systeme, schlecht dokumentierte Runbooks und keine sinnvolle Rotation hat, zahlt dafür mit Mitarbeiterzufriedenheit und letztlich mit Systemstabilität.
Was schlechtes Alerting kostet
Alert Fatigue ist eines der häufigsten und folgenschwersten Probleme in On-Call-Teams. Wenn ein Monitoring-System hundert Alarme pro Nacht schickt, von denen neunzig automatisch oder irrelevant sind, lernen On-Call-Mitarbeiter, Alarme zu ignorieren. Das ist eine rationale Reaktion auf ein irrationales System – aber es bedeutet, dass der eine relevante Alarm in der Masse untergeht.
Gut motivierte Ingenieure beginnen nach mehreren schlaflosen Nächten mit falsch-positiven Alarmen, ihre Reaktionszeit zu erhöhen und Alarme weniger gründlich zu prüfen. Die Lösung liegt nicht in mehr Disziplin, sondern in besserem Alerting-Design.
Alert-Hygiene: Das Fundament gesunden On-Call-Betriebs
Alert-Hygiene bedeutet: jeder Alarm, der gefeuert wird, sollte einen handlungsnotwendigen Zustand beschreiben, der menschliches Eingreifen erfordert. Klingt banal, ist in der Praxis aber eine kontinuierliche Arbeit.
Konkrete Maßnahmen für bessere Alert-Hygiene:
- Alarm-Audit: Regelmäßig auswerten, welche Alarme in den letzten 30 Tagen ausgelöst haben und welchen davon tatsächlich eine menschliche Aktion folgte. Alarme ohne Aktion sind Kandidaten zur Überarbeitung oder Abschaltung.
- Schwellwerte an SLOs koppeln: Statt willkürliche CPU-Grenzen zu alarmieren, definieren erfolgreiche Teams Alarme, die SLO-Verletzungen oder deren drohende Unterschreitung signalisieren.
- Kontext im Alarm: Ein Alarm sollte nicht nur sagen, was passiert ist, sondern auch: Welches System ist betroffen? Wie kritisch ist es? Was ist der erste diagnostische Schritt?
- Stille Stunden schützen: Teams, die nachts alarmiert werden, sollten sicherstellen, dass nur P1-Alarme wirklich wecken. Alles andere kommt in eine Queue für den nächsten Morgen.
KI-gestützte Alert-Filterung 2026
KI-Unterstützung beim Alerting hat in den letzten zwei Jahren erhebliche Fortschritte gemacht. Moderne Alerting-Systeme nutzen ML-Modelle, die aus historischen Alert-Daten lernen, welche Muster zu echten Incidents geführt haben und welche sich nach kurzer Zeit selbst auflösten.
Der Ansatz: statt jeden Schwellwertverstoß sofort zu eskalieren, bewertet das System die Wahrscheinlichkeit, dass menschliches Eingreifen nötig ist. Alarme mit hoher Selbstauflösungswahrscheinlichkeit werden zunächst zurückgehalten und nur bei Persistenz weitergegeben.
Das funktioniert gut für klassische Muster wie transiente CPU-Spitzen, kurze Netzwerklatenzen oder bekannte periodische Prozesse. Weniger gut funktioniert es bei neuartigen Fehlermustern – die per Definition noch keine historischen Daten haben. Deshalb bleibt manuelle Alert-Review unverzichtbar, auch wenn KI-Filterung die Alarmlast deutlich reduziert.
Gesunde Rotationen: Was sich in der Praxis bewährt
Wie On-Call-Rotationen strukturiert sind, hat erheblichen Einfluss auf die Belastung. Folgende Prinzipien haben sich in wachsenden Engineering-Teams bewährt:
- Keine Solo-Rotation: Wer allein On-Call ist, trägt die volle Last. Paarweise Rotationen – mit einer Hauptperson und einer Backup-Person – reduzieren sowohl Druck als auch Ausfallrisiko.
- Planbare Rotationszyklen: Eine Woche On-Call bedeutet sieben Tage Anspannung. Teams, die auf klare, planbare Zyklen setzen, berichten über geringere Belastung, weil der Rhythmus vorhersehbarer wird.
- Kompensation für nächtliche Alarme: Teams, die ihre On-Call-Mitarbeiter für Alarmierungen außerhalb der Arbeitszeit kompensieren, haben deutlich bessere Retention-Raten.
- Gradueller Einstieg: On-Call-Dienst sollte mit Shadowing-Phasen eingeführt werden, bevor jemand eigenverantwortlich im Dienst ist.
Runbooks als psychologische Entlastung
Um drei Uhr nachts mit einem kritischen Alert konfrontiert zu sein ist stressig. Was diesen Stress reduziert: ein klares, aktuelles Runbook. Ein gutes Runbook beschreibt in einfachen Schritten, was zu tun ist – ohne dass man das System vollständig verstehen muss, um erste Maßnahmen einzuleiten.
KI-Assistenten werden 2026 in zunehmend mehr Teams eingesetzt, um Runbooks zu generieren und aktuell zu halten. Aus Postmortem-Daten und Incident-Logs lassen sich Muster extrahieren, die als strukturierte Runbook-Basis dienen. Die Qualität dieser automatisch generierten Runbooks ist noch nicht durchgehend zuverlässig, aber als erster Entwurf spart das Stunden an manueller Arbeit.
Notification-Handler und granulare Alarmsteuerung
Moderne Monitoring-Plattformen ermöglichen es, Notification-Handler für unterschiedliche Szenarien zu konfigurieren: Eskalationsketten, die sich nach Tageszeit oder Schweregrad unterscheiden, direkte Benachrichtigungen auf verschiedenen Kanälen oder stille Alarme, die nur geloggt werden. Mit FreshCore lassen sich solche Notification-Handler pro Monitor und Zeitfenster konfigurieren, sodass die Alarmierung genau dort landet, wo sie gebraucht wird – ohne alle zur gleichen Zeit aufzuwecken.
Teamkultur: Was Technologie nicht ersetzen kann
Alle Technologie hilft wenig, wenn die Teamkultur On-Call als persönliche Schwäche behandelt. Teams, die blameless Postmortems etabliert haben, offen über Überlastung sprechen können und Burnout-Signale frühzeitig ansprechen, haben deutlich geringere Fluktuation in technischen Rollen.
Blameless Postmortems nach Incidents – ohne Schuldzuweisungen, mit Fokus auf systemische Ursachen – sind dabei kein nettes Extra, sondern ein zentrales Werkzeug. Sie helfen Teams, aus Fehlern zu lernen, ohne Angst vor persönlichen Konsequenzen.
Fazit
On-Call-Burnout ist kein Schicksal. Er ist das Ergebnis schlecht designter Systeme, unklarer Prozesse und unzureichender Unterstützung. Teams, die Alert-Hygiene ernst nehmen, Rotationen sorgfältig strukturieren, KI zur Lärmreduzierung einsetzen und eine Kultur der Offenheit pflegen, haben deutlich zufriedenere On-Call-Mitarbeiter – und zuverlässigere Systeme.
Bildquelle: Pexels (Team-Meeting-Foto, lizenzfrei)
Quellen: Google SRE Book (sre.google/books), PagerDuty State of Digital Operations Report 2025 (pagerduty.com), Atlassian Incident Management Handbuch (atlassian.com)
