Zum Inhalt

Wartungen

Eine Wartung (Maintenance) ist ein konkretes, geplantes Event mit Start- und Endzeitpunkt — zum Beispiel "PostgreSQL 15 → 16 Upgrade am 2026-04-22 02:00 bis 04:00 UTC". Wartungen informieren Benutzer proaktiv, erscheinen in der Activity-Timeline und der Downtime-Timeline und unterscheiden angekündigte Ausfälle von ungeplanten Störungen.

Wartungen ≠ Wartungsfenster

Die Wartung (dieses Dokument) ist ein einzelnes, datiertes Event. Das Wartungsfenster ist hingegen eine Policy/Vorlage für erlaubte Wartungsslots (z. B. "jeden Sonntag 02:00–04:00"). Beide Modelle sind getrennt und können, müssen aber nicht, zusammen benutzt werden.

Kernfelder

Feld Bedeutung
name / display_name Titel der Wartung
message / Embedded Note Beschreibung / Hinweis an Betroffene
scheduled_start / scheduled_end Geplanter Zeitraum
progress_status Lebenszyklus — draft, scheduled, running, completed, cancelled
draft Boolean: true unterdrückt Benachrichtigungen (Vorbereitung)
organization Optional — null = systemweite Wartung (plattformweit sichtbar)
workspace Optional — Scope auf einen Workspace (nur mit Organisation)
pop Primärer PoP (Anzeige)
affected_pops M2M — alle betroffenen PoPs (kanonische Menge)
affected_hosts M2M — betroffene Hosts
affected_volumes M2M — betroffene K8sVolumes
provider Optional — verknüpfter Provider (z. B. aus Status-Feed)
reference_url Optional — Link zum Change-Ticket, Playbook o. ä.

Scope

Scope organization workspace
Systemweit null null
Organisation gesetzt null
Workspace gesetzt gesetzt (muss zur Org gehören)

Betroffene Ressourcen

Neben Workspace- und PoP-Scope können konkrete Ressourcen verknüpft werden:

  • affected_pops — mehrere PoPs; pop bleibt der primäre Anzeige-PoP
  • affected_hosts / affected_volumes — feinere Zuordnung für Impact und Filter in Workspace-/PoP-/Provider-Tabs
  • Automatische Verknüpfung ist möglich über Provider-Status-Ingestion und KI-Erkennung — siehe Incidents

Lebenszyklus

┌────────┐  publish  ┌───────────┐  scheduled_start  ┌─────────┐
│ draft  │──────────▶│ scheduled │──────────────────▶│ running │
└────────┘           └─────┬─────┘                   └────┬────┘
                           │                              │
                           │   cancel                     │ scheduled_end
                           ▼                              │ oder manuell enden
                      ┌──────────┐                        ▼
                      │ cancelled│                  ┌───────────┐
                      └──────────┘                  │ completed │
                                                    └───────────┘
  • draft — angelegt, noch nicht sichtbar für Empfänger; keine Benachrichtigungen
  • scheduled — veröffentlicht; Benachrichtigungen und Timeline-Einträge entstehen
  • running — scheduled_start erreicht
  • completed — scheduled_end erreicht oder manuell vorzeitig beendet (end=now)
  • cancelled — vor Ausführung abgesagt

Benachrichtigungen

Activity Wann
maintenance_scheduled Beim Veröffentlichen aus draft
maintenance_started Beim Erreichen von scheduled_start
maintenance_ended Beim Erreichen von scheduled_end bzw. manuellem Beenden

Empfänger ergeben sich aus Contacts auf Organisation/Workspace-Ebene und deren Notification-Präferenzen. Jede gesendete Notification erzeugt zusätzlich einen Activity-Eintrag.

Draft bleibt still

Solange draft=true, werden keine Benachrichtigungen ausgelöst.

Darstellung in der UI

  • Liste — Filter nach Status, PoP, Host, Volume, Zeitraum; aktive Wartungen mit in_progress-Badge
  • Detail — Metadaten, Embedded Note, Tabs für Affected Hosts / Volumes / PoPs, Activity-Timeline
  • Downtime-Timeline — Wartungen als geplante Blöcke neben ungeplanten Downtimes
  • Operations-Dashboard — anstehende und laufende Wartungen

Praxis

Geplante Upgrade-Wartung

  1. Als draft anlegen (Titel, Zeitfenster, Workspace, ggf. affected_hosts)
  2. Publish → maintenance_scheduled
  3. Im Zeitfenster arbeiten; Alerts klar als „während geplanter Wartung“ einordnen
  4. Ende automatisch oder manuell → maintenance_ended

Systemweite Provider-Wartung

Provider-Statusfeeds (RSS/Webhook) können per KI eine Maintenance mit organization=null, verknüpftem Provider und affected_pops / Hosts / Volumes erzeugen. Siehe DataSources und Incidents.

Post-Mortem

Bei unerwarteten Problemen während der Wartung: Note kind=post-mortem und Verknüpfung zur Wartung bzw. zu Downtimes — siehe Notes.

API

  • GET/POST /api/v1/maintenances/
  • PATCH /api/v1/maintenances/{id}/
  • POST /api/v1/maintenances/{id}/publish/
  • POST /api/v1/maintenances/{id}/cancel/
  • Schreibbare M2M-IDs u. a. affected_host_ids, affected_volume_ids, affected_pop_ids

DRF-Basename: maintenance.

Verwandte Themen