Ferienbetrieb: Monitoring und Alerting bei reduzierter Besetzung

Der Sommer trifft die IT-Abteilung im Mittelstand immer nach demselben Muster: Ende Juli sind vier von sieben Kolleginnen und Kollegen im Urlaub, die Produktion in der Fertigung läuft aber weiter, die Fakturierung ebenfalls, und das Backup-Fenster hat sich nicht verschoben. Wer die verbleibende Rufbereitschaft schützen möchte, ohne kritische Ausfälle zu riskieren, kommt an einer temporären Neubewertung seiner Monitoring- und Alerting-Regeln nicht vorbei. Genau darum geht es in diesem Beitrag.

Wir beschreiben in den folgenden Abschnitten ein pragmatisches Vorgehen, das sich in unseren Kundenprojekten bewährt hat: Severity-Tuning, On-Call-Rotation über Grafana OnCall oder PagerDuty, automatisches Ticketing an einen definierten Primärkontakt, Eskalationsketten mit klaren Timeouts und eine bewusste Priorisierung, was in den Ferienwochen laufen muss und was sich verschieben lässt.

Severity-Tuning: Alert-Rauschen für vier Wochen unterdrücken

Der wichtigste Hebel ist die temporäre Neubewertung der Alert-Severities. Ein voller Log-Volume-Alert um zwei Uhr nachts ist im Regelbetrieb ein “warning” — in der Ferienzeit mit nur einer Person in Rufbereitschaft muss er entweder auf “info” gesenkt oder mit einem längeren Toleranzfenster versehen werden, damit er nicht das Telefon klingeln lässt.

Wir arbeiten dafür mit einem eigenen Alertmanager-Routing-Zweig, der über ein Label wie season: vacation aktiviert wird. Beispiel für einen Prometheus-Alert, der im Ferienbetrieb anders gruppiert wird:

groups:
- name: storage.rules
  rules:
  - alert: TrueNASPoolCapacityWarning
    expr: zfs_pool_capacity_ratio > 0.85
    for: 30m
    labels:
      severity: warning
      season: vacation-defer
    annotations:
      summary: "Pool {{ $labels.pool }} über 85 Prozent"
      runbook: "https://wiki.example.local/runbooks/zfs-capacity"

  - alert: TrueNASPoolCapacityCritical
    expr: zfs_pool_capacity_ratio > 0.92
    for: 10m
    labels:
      severity: critical
      season: vacation-page
    annotations:
      summary: "Pool {{ $labels.pool }} über 92 Prozent -- Handlungsbedarf"

Das Label season: vacation-defer landet in einem Alertmanager-Receiver, der ausschliesslich ein Ticket im Helpdesk anlegt und keine Push-Benachrichtigung auslöst. vacation-page dagegen geht direkt in die On-Call-Rotation. Wichtig ist, dass diese Umschaltung dokumentiert und terminiert ist — ein simpler Kalendereintrag mit dem Rückschalt-Datum verhindert, dass Sie im September mit einer stumpfen Monitoring-Landschaft dastehen.

On-Call-Rotation: Grafana OnCall oder PagerDuty im Mittelstand

Für die eigentliche Rufbereitschaft nutzen wir bei kleinen Teams zunehmend Grafana OnCall (seit Version 1.9 stabil integriert in Grafana 11) oder PagerDuty. Beide unterstützen zeitversetzte Rotationen, Handover-Zeiten und Eskalationsstufen. Für ein SMB-Team mit drei bis fünf Personen reicht meist eine Wochenrotation mit klarer Übergabe am Montagmorgen.

Ein bewährtes Schema für vier Ferienwochen:

Woche	Primary On-Call	Secondary	Eskalation nach 15 min
KW 31	Mitarbeiter A	Externer Partner	Geschäftsführung
KW 32	Mitarbeiter B	Externer Partner	Geschäftsführung
KW 33	Externer Partner	Mitarbeiter A	Geschäftsführung
KW 34	Mitarbeiter B	Externer Partner	Geschäftsführung

Der externe Partner — in vielen unserer Projekte ist das DATAZONE selbst — übernimmt entweder eine komplette Woche oder deckt die Sekundär-Rolle ab. Wichtig: Die Übergabe muss ein technisches Handover enthalten (offene Tickets, laufende Änderungen, geplante Wartungen), nicht nur den Kalenderwechsel. Wir dokumentieren das in einem einseitigen Handover-Sheet, das jeden Montag um 9 Uhr im Team-Kanal gepinnt wird.

Automatisches Ticketing an den Primärkontakt

Alerts der Severity “warning” sollen in der Ferienzeit niemanden aus dem Bett holen, dürfen aber auch nicht verloren gehen. Wir routen sie deshalb über Alertmanager direkt in das Ticketsystem — in aktuellen Projekten meist Zammad 6 oder OTRS/Znuny — und weisen sie einer generischen “Ferien-Queue” zu, deren einziger Bearbeiter der jeweilige On-Call-Primärkontakt ist.

Der Effekt ist zweifach: Erstens sieht die Rufbereitschaft am Morgen genau, was in der Nacht passiert ist, ohne dass jeder einzelne Vorfall ein manuelles Ticket erzwungen hätte. Zweitens bleibt die Nachvollziehbarkeit erhalten — gerade bei kapazitätsnahen Systemen wie TrueNAS-Pools oder OPNsense-Firewalls ist die zeitliche Reihung von Warnings vor einem echten Ausfall die entscheidende Diagnose-Grundlage.

Ein einfaches Alertmanager-Routing dafür:

route:
  receiver: default-oncall
  routes:
  - match:
      season: vacation-defer
    receiver: ticket-only
    group_wait: 2m
    group_interval: 15m
    repeat_interval: 12h

receivers:
- name: ticket-only
  webhook_configs:
  - url: "https://zammad.example.local/api/v1/alertmanager/webhook"
    send_resolved: true

Eskalationsketten: Wer wird wann geweckt

Eine Eskalationskette ohne Timeouts ist keine Kette, sondern eine Wunschliste. Wir setzen in Grafana OnCall typischerweise drei Stufen: Primary On-Call bekommt Push und SMS, nach 5 Minuten ohne Acknowledge folgt ein Anruf, nach weiteren 10 Minuten wird der Secondary alarmiert, nach weiteren 15 Minuten die Geschäftsführung oder der Bereitschafts-Manager beim externen Partner.

Diese Zahlen sind kein Dogma. In produktionsnahen Umgebungen (ERP, MES, Warenwirtschaft) verkürzen wir die erste Stufe auf 2 Minuten. In Umgebungen mit hoher Redundanz — etwa geclusterten Proxmox-Hosts mit funktionierendem HA — verlängern wir sie bewusst, weil der Cluster den Ausfall zunächst selbst kompensiert und nur die Nachbereitung wichtig ist.

Wichtig ist die regelmässige Übung: Wir empfehlen mindestens einen Trockentest der kompletten Kette pro Quartal, in dem eine synthetische Test-Alarmierung durch alle Stufen läuft. Nichts ist frustrierender, als in einer echten Nachtschicht festzustellen, dass die SMS-Route seit dem letzten Provider-Wechsel nicht mehr funktioniert.

Was in den Ferien stehen bleibt — und was warten kann

Neben dem Alerting geht es um eine bewusste Priorisierung der laufenden Arbeit. Wir teilen die IT-Aufgaben für die Ferienwochen in drei Kategorien:

• Muss laufen: Backup-Jobs, Replikations-Tasks, Antivirus-Definitionen, Zertifikats-Erneuerungen mit Ablauf in den nächsten sechs Wochen, Security-Patches der Kategorie “kritisch” gemäss Hersteller-CVE-Score.
• Kann warten: Feature-Upgrades von Betriebssystemen, Migration von Diensten, grössere Konfigurationsumbauten, nicht-kritische Firmware-Updates.
• Aktiv verschoben: Grosse Wartungsfenster mit potenziellem Reboot-Bedarf für zentrale Dienste, Storage-Erweiterungen, Netzwerk-Umbauten. Diese Themen packen wir bewusst in die Kalenderwochen 36 oder 37, wenn das Team wieder vollständig ist.

Ein zusätzlicher Tipp aus unseren Projekten: Zertifikate mit Ablauf in den Ferienwochen werden zwei Wochen vorher erneuert, nicht “kurz vor Ablauf”. Auto-Renewal über ACME/Let’s Encrypt für interne Services — via caddy, traefik oder direkt in OPNsense — reduziert diese Sorge deutlich.

Fazit

Ein sauber vorbereiteter Ferienbetrieb ist kein Notprogramm, sondern gute Betriebsführung. Die drei Kernelemente — temporäres Severity-Tuning, klare On-Call-Rotation mit Eskalationskette und bewusste Priorisierung der Arbeitspakete — lassen sich in wenigen Tagen aufsetzen und bringen dem ganzen Team spürbar Ruhe. Wichtig ist die Rückabwicklung: Am ersten Arbeitstag nach den Ferien werden die Alertmanager-Labels zurückgesetzt, das Handover-Sheet archiviert und die verschobenen Wartungen neu terminiert.

DATAZONE unterstützt Sie bei der Einrichtung Ihrer Monitoring- und Alerting-Landschaft — von Prometheus/Grafana über Zammad-Integration bis zur temporären Übernahme von On-Call-Slots durch unser Team. Sprechen Sie uns an, wenn Sie Ihren Sommer 2026 planbar durchziehen wollen: Kontakt aufnehmen.