Wer On-Call-Schichten kennt, kennt auch das Problem: Ein geplantes Deployment läuft durch, mehrere Dienste werden kurz neugestartet, und sofort prasseln Dutzende von Alerts ein – allesamt erwartet, allesamt harmlos, allesamt unnötige Unterbrechungen für die diensthabende Person. Dieses Szenario lässt sich mit sauberem Maintenance-Window- und Silence-Management komplett vermeiden.
Alert-Stummschaltung während geplanter Wartungsarbeiten ist keine Hintertür, die Probleme verdeckt – im Gegenteil. Sie ist ein wichtiges Steuerungselement, das sicherstellt, dass On-Call-Teams nur auf wirklich unerwartete Ereignisse reagieren müssen.
Was Maintenance Windows und Silences sind – und was nicht
Ein Maintenance Window ist ein klar definierter Zeitraum, in dem geplante Änderungen an der Infrastruktur durchgeführt werden. Typische Szenarien: Deployments neuer Softwareversionen, Datenbankmigrationen, Kernel-Updates auf Servern, Zertifikaterneuungen oder Netzwerkumkonfigurationen.
Eine Silence (auch: Alert-Stummschaltung, Mute oder Downtime) ist die technische Umsetzung davon im Alerting-System: Für den Zeitraum des Maintenance Windows werden bestimmte Monitore oder Alert-Regeln temporär deaktiviert, sodass erwartete Alarme nicht als Benachrichtigungen ausgelöst werden.
Was Silences ausdrücklich nicht sind:
- Eine dauerhafte Deaktivierung von Monitoren
- Ein Weg, unbequeme Alerts zu verstecken
- Ein Ersatz für die Behebung echter Probleme
Gut eingesetzte Silences sind zeitlich begrenzt, klar begründet und auf den minimalen Umfang beschränkt.
Warum ungeplante oder zu breite Silences gefährlich sind
In der Praxis entstehen Probleme häufig durch falsch konfigurierte Stummschaltungen:
Eine Silence, die versehentlich zu breit konfiguriert ist und auch produktionskritische Services umfasst, kann echte Ausfälle verbergen – genau dann, wenn das Deployment selbst eine unvorhergesehene Störung verursacht hat.
Typische Fehler:
- Zu lange Silences: Das Deployment dauerte 30 Minuten, aber die Silence läuft noch 6 Stunden. Ein echter Ausfall danach bleibt unbemerkt.
- Zu breite Silences: Statt nur den betroffenen Service zu stummschalten, werden alle Monitore eines ganzen Servers oder Clusters deaktiviert.
- Vergessene Silences: Niemand hebt die Silence nach dem Maintenance Window auf. Sie läuft weiter, bis jemand es bemerkt – oder eben nicht.
- Undokumentierte Silences: Es ist nicht mehr nachvollziehbar, wer eine Silence wann und warum gesetzt hat.
Best Practices für Maintenance Windows im On-Call-Betrieb
Silences immer zeitlich begrenzen
Jede Silence sollte ein festes Enddatum haben. Viele Alerting-Plattformen erzwingen das bereits technisch. Wenn ein Maintenance Window länger dauert als geplant, sollte die Silence manuell verlängert werden – mit bewusster Entscheidung, nicht automatisch.
Minimalen Scope definieren
Stummschalten sollte auf den kleinstmöglichen Umfang beschränkt sein: nur die betroffenen Monitore, nur den betroffenen Service, nicht pauschal den ganzen Stack. Ein Deploy des Payment-Services rechtfertigt keine Silence für den Checkout-Monitoring-Monitor des Gesamtsystems.
Begründung und Verantwortlichen dokumentieren
Jede Silence sollte kommentiert sein: Wer hat sie gesetzt? Für welches Deployment oder welche Wartung? Wann wurde entschieden, sie zu verlängern? Diese Dokumentation ist entscheidend für die Nachvollziehbarkeit – sowohl für das On-Call-Team als auch für spätere Postmortems.
Automatisches Aufheben nach Maintenance Window
Moderne Monitoring-Plattformen ermöglichen es, Silences direkt an Maintenance Windows zu koppeln. Sobald das Wartungsfenster schließt, wird auch die Stummschaltung automatisch aufgehoben. Das eliminiert eine häufige Fehlerquelle.
On-Call-Person informieren
Die Person im Bereitschaftsdienst sollte aktiv informiert werden, welche Silences aktiv sind – idealerweise über eine Dashboard-Ansicht oder automatische Benachrichtigung zu Beginn der Schicht. Niemand sollte ahnungslos in eine Schicht einsteigen, ohne zu wissen, welche Monitore gerade stummgeschaltet sind.
Koordination zwischen Deployment-Team und On-Call
Ein häufig unterschätzter Punkt ist die Kommunikation zwischen dem deployenden Team und der Person im On-Call-Dienst. Folgendes Vorgehen hat sich bewährt:
- Deployment ankündigen: Vor dem Start kurz im Team-Kanal posten – was wird deployed, welche Services sind betroffen, wann beginnt und endet das Maintenance Window?
- Silence setzen und kommunizieren: Wer setzt die Silence, und ist das mit der On-Call-Person abgestimmt?
- Status nach Deployment: Sobald das Deployment abgeschlossen und alles stabil ist, kurze Meldung – und explizites Aufheben der Silence, falls nicht automatisiert.
Dieses Muster reduziert Rückfragen, verhindert Überraschungsanrufe und stellt sicher, dass die On-Call-Person stets im Bild ist.
Monitoring-Integration: FreshCore und Maintenance Windows
Plattformen wie FreshCore ermöglichen es, für einzelne Monitore – ob HTTP-Checks, Heartbeats, DNS-Monitore oder Server-Monitoring – gezielt Wartungsfenster einzurichten. Während dieser Fenster werden Alert-Benachrichtigungen unterdrückt, ohne dass der Monitor selbst deaktiviert wird.
Das ist ein wichtiger Unterschied: Der Monitor läuft weiterhin und protokolliert den Zustand. Nur die Benachrichtigung wird zurückgehalten. Dadurch kann nach dem Maintenance Window sofort nachvollzogen werden, was während der Wartung passiert ist – und ob es Auffälligkeiten gab, die im Nachgang untersucht werden sollten.
Silences als Teil der On-Call-Kultur
Gut eingesetzte Stummschaltungen sind nicht ein Zeichen von Gleichgültigkeit, sondern von Reife im On-Call-Betrieb. Sie zeigen, dass ein Team
- Deployments und Wartungen proaktiv plant und kommuniziert,
- Alert-Fatigue aktiv bekämpft, indem es vermeidbare Benachrichtigungen verhindert,
- Vertrauen in seine eigenen Prozesse hat – und diese Prozesse dokumentiert.
Teams ohne strukturiertes Silence-Management neigen dazu, Alerts generell zu ignorieren oder zu "lärmblind" zu werden. Wer jeden Alert ernstgenommen haben will, muss dafür sorgen, dass nur sinnvolle Alerts ankommen.
Typische Tooling-Anforderungen
Ein gutes Silence-Management braucht folgende Funktionen im Alerting-Stack:
- Zeitlich begrenzte Silences mit automatischem Ablauf
- Granulare Scope-Definition (einzelner Monitor, Service, Tag, Cluster)
- Pflichtkommentar bei Silence-Erstellung
- Audit-Log mit allen Silence-Ereignissen (Erstellt, Verlängert, Beendet)
- Dashboard-Ansicht aktiver Silences für die On-Call-Person
- Integration mit Deployment-Pipelines oder ITSM-Tools zur automatischen Silence-Erstellung
Fazit
Maintenance Windows und Alert-Stummschaltungen sind ein wesentliches Werkzeug für einen funktionierenden On-Call-Betrieb. Richtig eingesetzt verhindern sie Alert-Fatigue, schützen die diensthabende Person vor unnötigen Unterbrechungen und erhalten gleichzeitig die Sichtbarkeit auf echte Probleme. Falsch eingesetzt – zu breit, zu lang, undokumentiert – können sie kritische Ausfälle verbergen.
Die Lösung liegt in klaren Prozessen: minimaler Scope, feste Laufzeiten, Dokumentationspflicht und enge Abstimmung zwischen dem Team, das deployed, und dem Team, das On-Call ist. Diese Disziplin zahlt sich direkt in weniger Nachtanrufen und mehr Vertrauen in die eigenen Alerts aus.
Bildquelle: Pexels (https://www.pexels.com/photo/669615/)
Weiterführende Quellen
- Google SRE Book – Kapitel zu On-Call und Alerting Philosophy
- PagerDuty: Best Practices for Maintenance Windows
