Wartungsfenster¶

Ein Wartungsfenster (MaintenanceWindow) ist eine Policy-Vorlage für erlaubte Wartungsslots — zum Beispiel "Jeden Sonntag 02:00–04:00 Europe/Berlin". Wartungsfenster beschreiben, wann Wartungen stattfinden dürfen (oder typischerweise stattfinden), und mit welchen Vorlaufzeiten sie zu planen sind.

Wartungsfenster ≠ Wartung

Ein Wartungsfenster (dieses Dokument) ist eine wiederkehrende Regel, keine einzelne Ausführung. Die konkrete, datierte Ausführung heißt Wartung. Ein Wartungsfenster erzeugt nicht automatisch Wartungen — es gibt den Rahmen vor, innerhalb dessen eine Wartung geplant werden darf.

Kernfelder¶

Feld	Bedeutung
`name` / `display_name`	Name des Fensters, z. B. "Wöchentliches Maintenance-Fenster"
`time_slots`	JSON-Liste aus Einträgen `{weekday, start, end, timezone}`
`lead_time_days`	Minimale Vorlaufzeit (in Tagen), mit der eine Wartung angekündigt werden muss
`notice_required`	Boolean: Müssen Wartungen in diesem Fenster angekündigt werden?
`is_system_default`	Boolean: globales Standard-Fenster der Plattform
`organization` / `workspace`	Scope — wem gehört die Policy (optional)

`time_slots` — Beispiele¶

[
  {"weekday": "sunday", "start": "02:00", "end": "04:00", "timezone": "Europe/Berlin"}
]

[
  {"weekday": "tuesday",  "start": "23:00", "end": "23:30", "timezone": "UTC"},
  {"weekday": "thursday", "start": "23:00", "end": "23:30", "timezone": "UTC"}
]

Die Slots sind deskriptiv: Polycrate erzeugt daraus keine automatischen Wartungen. Sie dienen der Planung, Anzeige und Validierung.

Wofür ein Wartungsfenster¶

Planungsrahmen: Teams sehen auf einen Blick, in welchen wiederkehrenden Slots Wartungen vorgesehen sind. Die Kalenderansicht im Dashboard kombiniert Wartungsfenster-Slots mit konkreten Wartungen.
Validierung beim Anlegen einer Wartung: Wenn ein Workspace oder eine Organisation ein Wartungsfenster hat, prüft die UI beim Anlegen einer Wartung, ob der gewünschte Zeitraum in einem Slot liegt. Liegt er außerhalb, gibt es eine Warnung (optional harte Ablehnung, wenn die Policy das verlangt).
Vorlauf-Vorgabe: lead_time_days definiert, wie weit im Voraus eine Wartung angelegt werden muss. Eine Wartung, die das unterschreitet, wird als "Emergency Maintenance" markiert.
Kommunikation gegenüber Kunden: Ein exportierbarer Wartungsfenster-Kalender dient als Service-Zusage: "Wir reservieren uns diese Slots für Upgrades; du kannst damit rechnen, dass es dort ggf. laut werden darf."

System-Default vs. eigene Fenster¶

System-Default (is_system_default=true) — Ein globales Fenster, das für alle Organisationen gilt, wenn sie kein eigenes definiert haben. Pflege: Plattform-Admins.
Organisations- oder Workspace-Fenster — Überschreiben das System-Default für ihren Scope. Mehrere Fenster pro Scope sind möglich (z. B. "Standard" und "High-Risk").

Reihenfolge der Auflösung: Workspace-Fenster → Organisation-Fenster → System-Default.

Zusammenspiel mit Wartungen¶

Wartungsfenster und Wartungen sind nicht per Fremdschlüssel verknüpft. Ein Wartungsfenster:

erzeugt keine Wartungen,
verhindert keine Wartungen,
hält die Regel fest, innerhalb derer Wartungen idealerweise liegen.

Wird eine Wartung angelegt, kann die UI anhand der zutreffenden Wartungsfenster folgende Hinweise geben:

"Zeitraum liegt außerhalb eines Wartungsfensters"
"Vorlaufzeit unter der geforderten lead_time_days → Emergency Maintenance"
"Überschneidung mit einem existierenden Wartungsfenster-Slot → alles gut"

Das gibt Teams eine konsistente Checkliste, ohne ihnen freie Hand zu nehmen.

Darstellung in der UI¶

Wartungsfenster-Liste pro Scope, mit Filterung nach "aktiv/inaktiv" und "default/override".
Detail-View mit allen time_slots, lead_time_days, Beschreibung, Verwendungsstatistik (wie viele Wartungen wurden in diesem Fenster geplant?).
Kalender: Kombi-Sicht, die Wartungsfenster als Hintergrundstreifen und Wartungen als farbige Blöcke darstellt.
"Nächster Slot"-Widget: zeigt den nächsten verfügbaren Wartungsfenster-Slot pro Workspace.

API-Endpunkte¶

GET /api/v1/maintenance-windows/ — Liste
POST /api/v1/maintenance-windows/ — Anlegen (nur für berechtigte Admins)
PATCH /api/v1/maintenance-windows/{id}/ — Bearbeiten (time_slots, lead_time_days)
GET /api/v1/maintenance-windows/{id}/applicability/ — "Passt dieser Zeitraum in ein Slot?"-Check

DRF-Router-Basename: maintenancewindow. (Nicht verwechseln mit maintenance für einzelne Wartungen.)

RBAC¶

Lesen: Alle Benutzer des Scopes sehen das Wartungsfenster — transparente Regel.
Bearbeiten: Organisations-Admin für Organisations-Fenster, Plattform-Admin für das System-Default.

Typische Use Cases¶

Standard-Slot für Managed Platform: Die Plattform definiert als System-Default ein Wartungsfenster "Sonntag 02:00–04:00 Europe/Berlin" mit lead_time_days=7. Damit weiß jeder Kunde, dass sonntags morgens Unterbrechungen möglich sind, und dass Ankündigungen mindestens eine Woche vor Ausführung eingehen.
Kunden mit eigenen Regeln: Ein Kunde verlangt Wartungen ausschließlich dienstagnachts 23:00–23:30 UTC mit 14 Tagen Vorlauf. Für seine Organisation wird ein eigenes Wartungsfenster angelegt, das das System-Default überschreibt.
Emergency Maintenance: Bei produktionskritischen Sicherheits-Patches wird eine Wartung mit weniger als lead_time_days angekündigt. Die UI markiert sie als "Emergency Maintenance" und benachrichtigt breiter, damit die Abweichung von der Regel sichtbar ist.