#220 - [MSP] Wartungsfenster und Change-Freeze je Mandant — Voraussetzung für scharfes Auto-Update - chinux/theProx

chinux commented

2026-07-20 23:15:02 +00:00

Owner

Pro Mandant definierbare Zeitfenster, in denen Änderungen erlaubt sind. Ohne das lässt sich Auto-Update (#174) bei Kunden nicht scharf schalten.

Warum

Auto-Update und der Scheduler existieren, kennen aber keine Kundenrestriktionen. Real hat jeder Mandant andere Vorgaben: der Handwerksbetrieb will Neustarts nur sonntags nachts, die Steuerkanzlei nicht während der Fristenläufe, der Produktionsbetrieb gar nicht ohne Ankündigung.

Der zweite, mindestens ebenso wichtige Effekt: das Fenster unterdrückt Alarme. Ein geplanter Neustart darf keine Ausfallmeldung erzeugen. Ohne diese Kopplung erzieht das System die Techniker dazu, Alarme zu ignorieren.

Und der dritte: geplante Arbeit muss aus dem Verfügbarkeitsbericht herausgerechnet werden, sonst sinkt die ausgewiesene Verfügbarkeit durch die eigene Wartung.

Umfang

Fenster je Mandant, wiederkehrend (Wochentag + Uhrzeit + Dauer) und einmalig (konkreter Termin, z. B. angekündigte Migration)
Vererbung: Mandant → Node → Guest, jeweils überschreibbar. Ein einzelner Server darf ein abweichendes Fenster haben.
Change-Freeze als eigener Typ: Zeitraum, in dem nichts passieren darf (Jahresabschluss, Inventur). Gewinnt immer gegen jedes Erlaubnis-Fenster.
Wirkt auf: Auto-Update (#174), geplante Jobs, Node-Agent-Update, Distro-Upgrade
Wirkt nicht auf manuell ausgelöste Aktionen — der Techniker muss eingreifen können. Aber: Warnhinweis im UI („außerhalb des Wartungsfensters von Mandant X") und Audit-Eintrag.
Zeitzone explizit pro Mandant. Serverzeit ist UTC, Kundenerwartung ist Ortszeit — das ist eine klassische Fehlerquelle bei Sommerzeitwechsel.

Offene Entscheidungen

Was passiert mit einem Job, der beim Fensterende noch läuft? Abbrechen ist bei einem dist-upgrade gefährlich. Vorschlag: laufen lassen, aber keine neuen Schritte starten, und im Task-Log vermerken.
Sollen Fenster für den Kunden sichtbar sein (siehe Kundenblick-Issue)?

Abhängigkeiten

#174 (Auto-Update) — der Hauptkonsument
Alarm-Issue (Unterdrückung während Wartung)
Verfügbarkeitsbericht-Issue (Herausrechnen)

Pro Mandant definierbare Zeitfenster, in denen Änderungen erlaubt sind. Ohne das lässt sich Auto-Update (#174) bei Kunden nicht scharf schalten. ## Warum Auto-Update und der Scheduler existieren, kennen aber keine Kundenrestriktionen. Real hat jeder Mandant andere Vorgaben: der Handwerksbetrieb will Neustarts nur sonntags nachts, die Steuerkanzlei nicht während der Fristenläufe, der Produktionsbetrieb gar nicht ohne Ankündigung. Der zweite, mindestens ebenso wichtige Effekt: **das Fenster unterdrückt Alarme.** Ein geplanter Neustart darf keine Ausfallmeldung erzeugen. Ohne diese Kopplung erzieht das System die Techniker dazu, Alarme zu ignorieren. Und der dritte: geplante Arbeit muss aus dem Verfügbarkeitsbericht herausgerechnet werden, sonst sinkt die ausgewiesene Verfügbarkeit durch die eigene Wartung. ## Umfang - Fenster je Mandant, wiederkehrend (Wochentag + Uhrzeit + Dauer) und einmalig (konkreter Termin, z. B. angekündigte Migration) - Vererbung: Mandant → Node → Guest, jeweils überschreibbar. Ein einzelner Server darf ein abweichendes Fenster haben. - **Change-Freeze** als eigener Typ: Zeitraum, in dem *nichts* passieren darf (Jahresabschluss, Inventur). Gewinnt immer gegen jedes Erlaubnis-Fenster. - Wirkt auf: Auto-Update (#174), geplante Jobs, Node-Agent-Update, Distro-Upgrade - Wirkt **nicht** auf manuell ausgelöste Aktionen — der Techniker muss eingreifen können. Aber: Warnhinweis im UI („außerhalb des Wartungsfensters von Mandant X") und Audit-Eintrag. - Zeitzone explizit pro Mandant. Serverzeit ist UTC, Kundenerwartung ist Ortszeit — das ist eine klassische Fehlerquelle bei Sommerzeitwechsel. ## Offene Entscheidungen - Was passiert mit einem Job, der beim Fensterende noch läuft? Abbrechen ist bei einem `dist-upgrade` gefährlich. Vorschlag: laufen lassen, aber keine neuen Schritte starten, und im Task-Log vermerken. - Sollen Fenster für den Kunden sichtbar sein (siehe Kundenblick-Issue)? ## Abhängigkeiten - #174 (Auto-Update) — der Hauptkonsument - Alarm-Issue (Unterdrückung während Wartung) - Verfügbarkeitsbericht-Issue (Herausrechnen)

chinux referenced this issue

2026-07-20 23:15:03 +00:00

[MSP] Verbrauchsreport je Mandant + Metrik-Rollup und Retention (Abrechnungsgrundlage) #218

chinux referenced this issue

2026-07-20 23:15:03 +00:00

[MSP] Kundenbericht: Verfügbarkeit und Backup-Erfolg je Mandant und Monat #219

chinux commented

2026-07-20 23:15:03 +00:00

Author

Owner

Teil des MSP-Themenblocks: #218, #219, #220, #221, #222, #223, #224, #225. Reihenfolge-Vorschlag: #218 (Datengrundlage) → #223 (Vertragsstatus) → #220 (Wartungsfenster) → #219 (Kundenbericht) → Rest.