Wartungsfenster¶

Übersicht¶

Wartungsfenster (Maintenance Windows) ermöglichen die Planung von Wartungsarbeiten mit automatischer Benachrichtigung der betroffenen Kontakte und Unterdrückung von Alerts während der Wartungszeit.

graph LR
    PLAN[Planung] --> ANNOUNCE[Ankündigung<br/>automatisch]
    ANNOUNCE --> ACTIVE[Wartungsfenster<br/>aktiv]
    ACTIVE --> END[Wartungsende<br/>Notification]

Wartungsfenster erstellen¶

Über die Web-UI¶

1. Navigieren Sie zu Operations → Wartungsfenster
2. Klicken Sie + Neues Wartungsfenster
3. Füllen Sie die Details aus:

Betroffene Ressourcen¶

Wählen Sie, welche Ressourcen von der Wartung betroffen sind:

• Kubernetes Cluster: Gesamter Cluster oder spezifische Namespaces
• Endpoints: HTTP/ICMP-Endpunkte
• Hosts: Linux-Server
• Workspaces: Alle Ressourcen eines Workspaces

# Beispiel: Betroffene Ressourcen
affected_resources:
  clusters:
    - prod-eu-cluster
  endpoints:
    - api.example.com
    - app.example.com
  namespaces:
    - production

Ankündigungen¶

Automatische Benachrichtigungen¶

Das System sendet automatisch Ankündigungen:

Ankündigungs-Konfiguration¶

Passen Sie an, wann und wie benachrichtigt wird:

maintenance:
  announcements:
    pre_announcement_hours: [24, 1]  # 24h und 1h vorher
    send_start_notification: true
    send_end_notification: true
    channels:
      - email
      - webhook

E-Mail-Template¶

Die Ankündigungs-E-Mails enthalten:

• Wartungszeitraum: Start und Ende
• Betroffene Systeme: Liste der Ressourcen
• Erwartete Auswirkungen: Was funktioniert nicht?
• Kontaktinformationen: Bei Fragen
• Kalender-Link: ICS-Datei zum Importieren

Alert-Unterdrückung¶

Während der Wartung¶

Alerts für betroffene Ressourcen werden automatisch unterdrückt:

graph TB
    MW[Wartungsfenster aktiv] --> ALERT[Alert wird generiert]
    ALERT --> CHECK{Ressource in<br/>Maintenance?}
    CHECK -->|Ja| SUPPRESS[Suppress<br/>silent]
    CHECK -->|Nein| NORMAL[Normal<br/>notify]

Unterdrückte Alerts¶

• Kein Notification-Versand während Wartung
• Alert wird trotzdem erstellt (für Audit)
• Label: suppressed_by_maintenance: true
• Nach Wartungsende: Re-Evaluation aller Alerts

Override-Option¶

Kritische Alerts können trotzdem durchkommen:

maintenance:
  alert_suppression:
    enabled: true
    override_severities:
      - critical  # Critical Alerts werden trotzdem gesendet

Wiederkehrende Wartungsfenster¶

Regelmäßige Wartungen¶

Für geplante, wiederkehrende Wartungen:

recurring_maintenance:
  name: "Wöchentliches Update Window"
  schedule:
    day: sunday
    time: "02:00"
    duration: "2h"
    timezone: "Europe/Berlin"
  affected_resources:
    - all_clusters

Cron-basierte Schedules¶

# Jeden 1. Sonntag im Monat, 03:00-05:00 UTC
recurring_maintenance:
  cron: "0 3 1-7 * 0"  # 1.-7. Tag, wenn Sonntag
  duration: "2h"

Wartungsfenster-Dashboard¶

Übersicht¶

Das Dashboard zeigt:

• Aktive Wartungen: Aktuell laufende Fenster
• Geplante Wartungen: Kommende Wartungen
• Vergangene Wartungen: Historie
• Kalender-Ansicht: Monatliche Übersicht

Kalender-Integration¶

Wartungsfenster können in externe Kalender exportiert werden:

• iCal-Feed: URL für Kalender-Apps
• ICS-Export: Einzelne Events herunterladen
• Google Calendar: Direkter Import

Best Practices¶

Planung¶

1. Rechtzeitig ankündigen: Mindestens 48h für kritische Systeme
2. Off-Peak-Zeiten wählen: Nachts oder am Wochenende
3. Realistische Dauer: Puffer einplanen
4. Rollback-Plan: Was wenn etwas schiefgeht?

Kommunikation¶

1. Klare Beschreibungen: Was wird gemacht?
2. Auswirkungen beschreiben: Was funktioniert nicht?
3. Status-Updates: Während langer Wartungen
4. Abschlussmeldung: Bestätigung nach Ende

Dokumentation¶

# Wartungs-Checkliste
pre_maintenance:
  - [ ] Backup erstellt
  - [ ] Rollback-Plan dokumentiert
  - [ ] Team informiert
  - [ ] Wartungsfenster in API erstellt

during_maintenance:
  - [ ] Änderungen durchführen
  - [ ] Tests nach Änderung
  - [ ] Probleme dokumentieren

post_maintenance:
  - [ ] Funktionalität verifiziert
  - [ ] Wartungsfenster schließen
  - [ ] Post-Mortem bei Problemen

Management-Commands¶

Wartungen können auch über Management-Commands gesteuert werden:

# Anstehende Ankündigungen verarbeiten
python manage.py process_maintenance_announcements

# Start-Benachrichtigungen (15 Min vor Beginn)
python manage.py process_start_announcements --minutes 15

# End-Benachrichtigungen (5 Min nach Ende)
python manage.py process_end_announcements --minutes 5

# Dry-Run (ohne tatsächlichen Versand)
python manage.py process_maintenance_announcements --dry-run

API-Zugriff¶

Wartungsfenster erstellen¶

curl -X POST https://hub.polycrate.io/api/v1/maintenances/ \
  -H "Authorization: Bearer $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "title": "Database Upgrade",
    "description": "PostgreSQL 15 → 16 Upgrade",
    "start_time": "2025-01-20T02:00:00Z",
    "end_time": "2025-01-20T04:00:00Z",
    "organization": "acme-corp",
    "affected_resources": ["db-cluster-1"]
  }'

Wartungsfenster abfragen¶

# Alle aktiven Wartungsfenster
curl https://hub.polycrate.io/api/v1/maintenances/?status=active \
  -H "Authorization: Bearer $API_KEY"

# Geplante Wartungsfenster
curl https://hub.polycrate.io/api/v1/maintenances/?status=scheduled \
  -H "Authorization: Bearer $API_KEY"