Wartungsfenster

1) Was ist ein „Wartungsfenster“ und warum ist es notwendig

Das Wartungsfenster ist eine im Voraus vereinbarte Zeitspanne für Arbeiten, die sich möglicherweise auf die Verfügbarkeit/Leistung auswirken. Ziel ist ein kontrollierter Wandel mit vorhersehbarem Risiko, transparenter Kommunikation und evidenzbasierter Berichterstattung.

• Geplant: Releases, Migrationen, Zertifikat-/Schlüsselrotationen, DB/Broker-Upgrades.
• Notfall: Dringende Sicherheitsprotokolle/Incident Rollbacks.
• Silent/Zero-impact: ohne Benutzereinfluss (versteckte Kanarienvögel, Repliken, parallele Eingabe).
• Provider-led: Fenster externer Anbieter (PSP/KYC/CDN/Cloud).

2) Grundsätze

SLO-first: Die Zeit-/Formatentscheidung des Fensters wird über die Auswirkungen auf SLI und Fehlerbudgets getroffen.
Minimaler Explosionsradius: Der Kanarienvogel → schrittweise → vollständige Aufnahme.
Reversibilität: Jede Operation hat einen Backout-Plan und einen verifizierten Rollback.
Eine einzige Quelle der Wahrheit: Fensterkalender + Ticket/RFC mit vollständigem Datenpaket.
Evidence: Sammlung von evidence (Protokolle, Grafiken, Screenshots, Hashes von Artefakten).
SLA-Kommunikation: im Voraus, während der Arbeit, nach Abschluss.

3) Planung: Timing und Reichweite

Fensterauswahl: geringer Traffic, minimaler Impact für wichtige Kohorten (Regionen/VIP/Partner).
Zeitzonen: Erfassen Sie in UTC + die Ortszeit (z. B. Europa/Kyiv).
Blacklout-Perioden: Verbot der Arbeit während der Hauptsaison/Ereignisse (Spiele, Verkäufe, Release „Fenster des Todes“).
Blast radius: klar definieren, wer betroffen ist (Dienste, Regionen, Anbieter).

4) Genehmigungsprozess (RFC/CAB lite)

1. Der Initiator erstellt ein Ticket/RFC mit Risikoanalyse und Plan (siehe Vorlage unten).
2. Risikobewertung (Low/Med/High) und Genehmigung durch den Service Owner + SRE/Sicherheit.
3. Kalender: Slot Reservierung; Konfliktprüfung (andere Fenster/Anbieter).
4. Komma-Plan: vorab vereinbarte Benachrichtigungen und Status-Seite.
5. Go/No-Go-Meeting (in 24-48h) für risikoreiche Änderungen.

5) Vorbereitung: Sicherheitsgates

Kontrollen vor dem Start: erfolgreiche Tests auf dem Stapel, Artefakte unterzeichnet, Gesamtrisiken ≤ zulässig.
Kanarienvogel: 1%→5%→25% nach Kohorte/Region; automatische SLO-Gardrails und Auto-Rollback.
Die Ficha-Fahnen der Degradierung und die Grenzen sind fertig.
Rollback/Backout-Plan in Sandbox geprüft; Rollback-Befehle werden dokumentiert.
Alert-Suppression: Nur für erwartetes Rauschen, SLO-Signale nicht störend.
Zugänge: JIT/JEA Rechnungen für Operationen, Mandatsaudit.

6) Kommunikation (Timing und Inhalt)

T-14/7/2 Tage (geplant): heads-up für Kunden/interne Teams (was/wann/Einfluss/Kontakte).
T-60/30/15 Minuten: Erinnerungen innerhalb und auf der Statusseite.
Während der Arbeit: Updates alle 15-30 Minuten (SEV-abhängig) nach Vorlage: Impact → Stage → Next Update.
Im Anschluss: Finale „Completed/Partially completed/Rolled back“, Änderungsliste, SLO-Check.

7) Durchführung der Arbeiten (Referenzszenario)

1. Freeze ungebundenen Releases.
2. Übergang zu Canary (eingeschränkte Kohorte) → beobachten SLI/Metriken p95/p99.
3. Schrittweise Erhöhung des Anteils bei grünen Gardrails.
4. Überprüfung des Business SLI (Conversion, Erfolg von Zahlungen/Registrierungen).
5. Überprüfung der Funktionalität mit einer Checkliste (happy path + critical scripts).
6. Release/No-Release-Lösung (IC/SRE/Service Owner).
7. Unterdrückung entfernen, Alert-Richtlinien zurückgeben.

8) Nach dem Fenster: Verifizierung und Berichterstattung

Beobachtungsfenster (z.B. 1-24 h): SLO und Fehler nachverfolgen.
Fensterbericht: Was sie taten, Metriken, Abweichungen, Evidence, Total.
Wenn es Probleme gab: AAR→RCA→CAPA (Fix-Regeln, Tests, Dokumentation).
Archiv: Ticket, Artefakte, Signaturen, Prüfsummen.

9) Abstimmung mit externen Anbietern

Bestätigte Slots und Kontakte des Anbieters; Fenster in ihrem Status-System.
Folback/Routing zu einem alternativen Anbieter für den Zeitraum der Arbeiten.
Ein einziger Kriegsraum mit Anbieter (Chat/Bridge) und SLA-Updates.

10) Prozessreifemetriken

On-time rate:% der Fenster, die rechtzeitig gestartet/abgeschlossen wurden.
Änderungsfehlerrate:% der Fenster mit Rollbacks/Auswirkungen auf SLO.
Incident-during-MW: Vorfälle, die sich während eines Fensters ereigneten.
Kommunikation SLA: Anteil der zeitnahen Aktualisierungen.
Evidence completeness:% der Fenster mit vollständigem Beweismaterial.
Kundenwirkung: Beschwerden/Tickets für 1 Fenster, Trend.
Nach 7/30 Tagen: SLO-Stabilität und kein Rezidiv.

11) Checklisten

Vor dem Fenster

• RFC/Ticket voll; die Risikobewertung wurde durchgeführt; Besitzer zugewiesen.
• Kanarienvogel und Backout-Plan geprüft; Rollback-Befehle getestet.
• JIT-Zugänge werden erteilt; Alerts sind konfiguriert (SLOs jammen nicht).
• Kalender/Status-Seite und Benachrichtigungen vorbereitet.
• Releases/konkurrierende Fenster - eingefroren/verschoben.
• Die Anbieter werden bestätigt; Kontakte und SLAs werden aufgezeichnet.

Während der

• Upgrades im Zeitplan; war-room ist aktiv.
• Gardrails per SLO/Error Peak werden eingehalten; im Falle eines Verstoßes - Auto-Rollback.
• Evidence wird gesammelt (Screenshots, Vorher/Nachher-Grafiken, Aktivitätsprotokoll).

Nach

• SLO im grünen Bereich während des Beobachtungsfensters.
• Abschlussbericht mit evidence; Status-Seite aktualisiert.
• CAPAs ausgestellt (wenn es Abweichungen gab); Dokumentation aktualisiert.

12) Vorlagen

RFC-Vorlage pro Wartungsfenster

RFC: MW-2025-11-05-DB-Upgrade
Window: 2025-11-05 00: 00-02: 00 UTC (Europe/Kyiv 02: 00-04: 00)
Service/component: payments-db (PostgreSQL cluster A)
Type: Planned (High)
Target: Upgrade to 15. x for security/bugs
Blast radius: EU region, tenant EU, all write operations
Impact: up to 2 × p99 growth to 400 ms; short-term read-only (≤5 min)
Gardrails: error-rate <0. 5%, p99 <400 ms, SLO not impaired
План: expand→migrate→contract; canary 1 %/5 %/25%; 1..N steps (with commands)
Backout: rolling back replica/slots; TTL DNS does not change; rollback time ≤ 10 min
Suppression: noise of database/replica alerts; SLO alerts are active
Communications: T-7/T-2 days and T-60/15 minutes; war-room #mw-db-a
Owners: @ db-tl, @ sre-ic, @ payments-pm
Evidence: before/after p95/p99 graphs, migration logs, checksums
Risk: High (data) - confirmed by CAB

Vorlage für Client-Benachrichtigungen (kurz)

Topic: Planned work 05. 11. 2025 02:00–04:00 (Europe/Kyiv)
We will update the payment database. Short delays and read-only mode (up to 5 minutes) are possible.
On-call contacts: status. example. com      support@example. com

Suppressionsregeln (Idee)

yaml suppress:
- name: db-maintenance when: window("2025-11-05T00:00Z","2025-11-05T02:00Z")
match: [ "db. replica. lag", "db. connection. reset", "migration. progress" ]
keep: [ "slo. payment. success", "api. availability" ]

13) Besonderheiten für regulierte Domains

Audit-Log ist unveränderlich: Wer hat genehmigt, wer hat ausgeführt, welche Befehle, Hashes von Artefakten.
PII/Finanzen: Maskierung in evidence, eingeschränkter Zugang zu Berichten.
Benachrichtigungsfristen für Kunden und Partner - gemäß den Verträgen.
Provider-Fenster - dokumentiert mit externen SLAs und Kontakten.

14) Anti-Muster

Fenster ohne Backout-Plan und verifiziertes Rollback.
Dämpfung von SLO-Signalen „nur für den Fall“.
Konkurrierende Fenster in derselben Domäne/Region.
Komm-Stille: keine Upgrades „vor/während/nach“.
Manuelle Bearbeitungen in der Produktion ohne Audit und Skripte.
„Endlose“ Fenster aufgrund unsicherer Erfolgskriterien.
Mangel an evidence - nichts, um die Qualität zu bestätigen.

15) Umsetzungsfahrplan (4-6 Wochen)

1. Ned. 1: Geben Sie einen einzigen Kalender und RFC-Vorlage; Bestimmung von Blacklout-Perioden.
2. Ned. 2: Standardisierung der Tore (Kanarienvogel, SLO-Gardrails, Backout).
3. Ned. 3: Automatisieren Sie die Suppression/Release Annotation und die Status-Seite.
4. Ned. 4: Berichterstattung und Reifegradmetriken; wöchentliche MW-Überprüfung.
5. Ned. 5-6: Integration mit Anbietern und Audit-Archiv; Simulation des Hochrisikofensters.

16) Das Ergebnis

Richtig organisierte Wartungsfenster sind überschaubare, reversible und nachweislich sichere Veränderungen. Mit SLO-Gardrails, Kanarienrollen, strenger Kommunikation und einem kompletten Set von evidence verwandelt sich das Fenster von einer „gefürchteten Ausfallzeit“ in einen routinemäßigen Verbesserungsmechanismus ohne Überraschungen für Anwender und Partner.