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

Open
opened 2026-07-20 23:15:02 +00:00 by chinux · 1 comment
Owner

Monatlicher Bericht an den Mandanten: Verfügbarkeit und Backup-Erfolg. Das ist der Bericht, den Kunden anfragen und den MSPs sonst von Hand zusammenstellen.

Datenlage

Node.status + Node.last_seen (Verfügbarkeit Node), BackupLog mit status, started_at, ended_at, size (Backup-Erfolg), VMMetric (Guest-Laufzeit).

Ehrlichkeitsproblem, das vorab entschieden werden muss: last_seen misst die Erreichbarkeit des Agents, nicht die des Systems. Ein Node kann laufen, während der Agent hängt (siehe #214), und umgekehrt kann die WS-Verbindung über einen kurzen Netzausfall hinweg bestehen bleiben. Ein daraus abgeleiteter Verfügbarkeitswert ist eine Näherung und muss im Bericht auch so benannt werden — „Agent-Erreichbarkeit" statt „Verfügbarkeit". Alles andere wäre eine Zahl, die man vertraglich nicht halten kann.

Inhalt

Verfügbarkeit je Node und Monat: Anteil erreichbarer Zeit, Anzahl und Dauer der Unterbrechungen, längste Unterbrechung. Wartungsfenster (siehe Wartungsfenster-Issue) werden herausgerechnet und separat ausgewiesen — geplante Arbeit ist kein Ausfall.

Backups je Guest: Anzahl Läufe, Erfolgsquote, Gesamtvolumen, letzter erfolgreicher Lauf, Guests ohne Backup im Berichtszeitraum. Der letzte Punkt ist der wichtigste und fällt in einer reinen Erfolgsquote unter den Tisch: eine VM, die nie gesichert wurde, hat keine fehlgeschlagenen Läufe.

Bestandsveränderungen: hinzugekommene und entfernte Guests. Das erklärt dem Kunden Abweichungen zum Verbrauchsreport, bevor er nachfragt.

Offene Entscheidungen

  • Ausgabeformat. PDF ist das, was Kunden erwarten. Der Docgen-Unterbau erzeugt Markdown; ein PDF-Renderer ist eine zusätzliche Abhängigkeit im Container. Alternative: HTML mit Druck-Stylesheet, dann erzeugt der Browser das PDF. Weniger Abhängigkeiten, aber kein automatischer Mailversand.
  • Automatischer Versand an eine Mandanten-Mailadresse zum Monatsanfang, oder nur Download? Versand bedeutet: Mailadresse pro Mandant, Fehlerbehandlung, und ein Bericht, der rausgeht, bevor jemand draufgeschaut hat.
  • Branding. Bei Weiterverkauf (#188) müsste das Logo tauschbar sein.

Abhängigkeiten

  • Verbrauchsreport-Issue (gemeinsame Aggregationsschicht, usage_daily)
  • Wartungsfenster-Issue (Ausfall vs. geplante Arbeit)
  • #212 (korrekte Mandantenzuordnung)
Monatlicher Bericht an den Mandanten: Verfügbarkeit und Backup-Erfolg. Das ist der Bericht, den Kunden anfragen und den MSPs sonst von Hand zusammenstellen. ## Datenlage `Node.status` + `Node.last_seen` (Verfügbarkeit Node), `BackupLog` mit `status`, `started_at`, `ended_at`, `size` (Backup-Erfolg), `VMMetric` (Guest-Laufzeit). **Ehrlichkeitsproblem, das vorab entschieden werden muss:** `last_seen` misst die Erreichbarkeit des *Agents*, nicht die des *Systems*. Ein Node kann laufen, während der Agent hängt (siehe #214), und umgekehrt kann die WS-Verbindung über einen kurzen Netzausfall hinweg bestehen bleiben. Ein daraus abgeleiteter Verfügbarkeitswert ist eine Näherung und muss im Bericht auch so benannt werden — „Agent-Erreichbarkeit" statt „Verfügbarkeit". Alles andere wäre eine Zahl, die man vertraglich nicht halten kann. ## Inhalt **Verfügbarkeit** je Node und Monat: Anteil erreichbarer Zeit, Anzahl und Dauer der Unterbrechungen, längste Unterbrechung. Wartungsfenster (siehe Wartungsfenster-Issue) werden herausgerechnet und separat ausgewiesen — geplante Arbeit ist kein Ausfall. **Backups** je Guest: Anzahl Läufe, Erfolgsquote, Gesamtvolumen, letzter erfolgreicher Lauf, Guests **ohne** Backup im Berichtszeitraum. Der letzte Punkt ist der wichtigste und fällt in einer reinen Erfolgsquote unter den Tisch: eine VM, die nie gesichert wurde, hat keine fehlgeschlagenen Läufe. **Bestandsveränderungen**: hinzugekommene und entfernte Guests. Das erklärt dem Kunden Abweichungen zum Verbrauchsreport, bevor er nachfragt. ## Offene Entscheidungen - **Ausgabeformat.** PDF ist das, was Kunden erwarten. Der Docgen-Unterbau erzeugt Markdown; ein PDF-Renderer ist eine zusätzliche Abhängigkeit im Container. Alternative: HTML mit Druck-Stylesheet, dann erzeugt der Browser das PDF. Weniger Abhängigkeiten, aber kein automatischer Mailversand. - **Automatischer Versand** an eine Mandanten-Mailadresse zum Monatsanfang, oder nur Download? Versand bedeutet: Mailadresse pro Mandant, Fehlerbehandlung, und ein Bericht, der rausgeht, bevor jemand draufgeschaut hat. - **Branding.** Bei Weiterverkauf (#188) müsste das Logo tauschbar sein. ## Abhängigkeiten - Verbrauchsreport-Issue (gemeinsame Aggregationsschicht, `usage_daily`) - Wartungsfenster-Issue (Ausfall vs. geplante Arbeit) - #212 (korrekte Mandantenzuordnung)
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.

Teil des MSP-Themenblocks: #218, #219, #220, #221, #222, #223, #224, #225. Reihenfolge-Vorschlag: #218 (Datengrundlage) → #223 (Vertragsstatus) → #220 (Wartungsfenster) → #219 (Kundenbericht) → Rest.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
chinux/theProx#219
No description provided.