[MSP] Alarme als Objekt: Quittierung, Deduplizierung, Eskalation, Bereitschaft, Stummschaltung

chinux commented

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

Owner

Benachrichtigungen existieren (services/notifications.py), der Betriebsteil fehlt: Es ist nicht erkennbar, ob ein Alarm gesehen wurde und ob sich jemand kümmert.

Problem

Bei mehr als einem Techniker ist die entscheidende Frage nach einem Alarm nicht „was ist kaputt", sondern „macht das schon jemand". Ohne Quittierung fahren entweder zwei hin oder keiner. Und ein Alarm, der niemanden erreicht, weil der Empfänger im Urlaub ist, fällt erst auf, wenn der Kunde anruft.

Umfang

Alarm als Objekt, nicht als Ereignis. Heute wird eine Nachricht verschickt und ist damit erledigt. Nötig ist ein Zustand: offen → quittiert → geschlossen, mit Zeitstempel und Bearbeiter. Erst dadurch wird „seit 40 Minuten offen und niemand hat reagiert" überhaupt eine beantwortbare Frage.

Deduplizierung. Ein flappender Node darf nicht 200 Meldungen erzeugen. Gleiche Ursache + gleiches Objekt = ein Alarm mit Zähler. Das ist der Unterschied zwischen einem System, das man ernst nimmt, und einem, dessen Kanal man stummschaltet.

Eskalation. Bleibt ein Alarm einer Schwere X länger als Y Minuten unquittiert, geht er an die nächste Stufe. Stufen sind Empfängerlisten, keine Personen — sonst pflegt man bei jedem Urlaub die Konfiguration um.

Bereitschaft. Wer ist außerhalb der Geschäftszeiten zuständig? Minimal: Zeitplan mit Empfängerliste pro Zeitraum. Bewusst kein vollwertiger Dienstplan.

Stummschaltung. Pro Objekt und Zeitraum, mit Pflicht-Begründung. Gekoppelt an die Wartungsfenster — während geplanter Arbeit automatisch still.

Bewusst nicht enthalten

Keine Alarmregel-Sprache mit Schwellwerten und Zeitreihenauswertung. Das ist ein Monitoringsystem und ein eigenes Produkt. Hier geht es um die Verarbeitung der Ereignisse, die theProx ohnehin schon erzeugt.

Abhängigkeiten

Wartungsfenster-Issue (automatische Stummschaltung)
#155 (Task-Center) — gleiches Muster für Zustand und SSE

Benachrichtigungen existieren (`services/notifications.py`), der Betriebsteil fehlt: Es ist nicht erkennbar, ob ein Alarm gesehen wurde und ob sich jemand kümmert. ## Problem Bei mehr als einem Techniker ist die entscheidende Frage nach einem Alarm nicht „was ist kaputt", sondern „macht das schon jemand". Ohne Quittierung fahren entweder zwei hin oder keiner. Und ein Alarm, der niemanden erreicht, weil der Empfänger im Urlaub ist, fällt erst auf, wenn der Kunde anruft. ## Umfang **Alarm als Objekt, nicht als Ereignis.** Heute wird eine Nachricht verschickt und ist damit erledigt. Nötig ist ein Zustand: offen → quittiert → geschlossen, mit Zeitstempel und Bearbeiter. Erst dadurch wird „seit 40 Minuten offen und niemand hat reagiert" überhaupt eine beantwortbare Frage. **Deduplizierung.** Ein flappender Node darf nicht 200 Meldungen erzeugen. Gleiche Ursache + gleiches Objekt = ein Alarm mit Zähler. Das ist der Unterschied zwischen einem System, das man ernst nimmt, und einem, dessen Kanal man stummschaltet. **Eskalation.** Bleibt ein Alarm einer Schwere X länger als Y Minuten unquittiert, geht er an die nächste Stufe. Stufen sind Empfängerlisten, keine Personen — sonst pflegt man bei jedem Urlaub die Konfiguration um. **Bereitschaft.** Wer ist außerhalb der Geschäftszeiten zuständig? Minimal: Zeitplan mit Empfängerliste pro Zeitraum. Bewusst kein vollwertiger Dienstplan. **Stummschaltung.** Pro Objekt und Zeitraum, mit Pflicht-Begründung. Gekoppelt an die Wartungsfenster — während geplanter Arbeit automatisch still. ## Bewusst nicht enthalten Keine Alarmregel-Sprache mit Schwellwerten und Zeitreihenauswertung. Das ist ein Monitoringsystem und ein eigenes Produkt. Hier geht es um die Verarbeitung der Ereignisse, die theProx ohnehin schon erzeugt. ## Abhängigkeiten - Wartungsfenster-Issue (automatische Stummschaltung) - #155 (Task-Center) — gleiches Muster für Zustand und SSE

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 referenced this issue

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

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

chinux commented

2026-07-20 23:15:04 +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.