High Availability, Disaster Recovery und SRE
HA reduziert Ausfallwahrscheinlichkeit. Disaster Recovery reduziert Ausfalldauer und Datenverlust. SRE verbindet Zuverlässigkeit mit messbarer Betriebsdisziplin.
Fachliche Perspektive
Nicht jede Anwendung braucht dieselbe Verfügbarkeit. Ein internes Schulungssystem darf vielleicht einen Tag ausfallen. Zahlungsverkehr, Produktion oder Kundenportal brauchen kurze Wiederherstellungszeiten und klare Notfallprozesse.
HA vs DR
HA schützt gegen lokale Komponentenausfälle: Node, Pod, VM, Disk, Netzwerkpfad. DR schützt gegen größere Ereignisse: Standortausfall, Datenkorruption, Ransomware, Fehlkonfiguration, großflächiger Plattformfehler.
RTO/RPO in Architektur übersetzen
RTO/RPO entscheiden über Replikation, Backup-Frequenz, Standortstrategie, Datenbankarchitektur, DNS/Traffic-Switch und Testaufwand.
SRE-Prinzipien
SRE nutzt SLOs, Error Budgets, Automatisierung, Postmortems und Toil-Reduktion. Ziel ist nicht null Fehler, sondern kontrollierte Zuverlässigkeit mit Lernschleifen.
Game Days
Notfallprozesse müssen geübt werden. Ein DR-Plan, der nie getestet wurde, ist eine Annahme, kein Nachweis.
Ausführliche Beispiele
DR-Klassifikation
applications:
order-platform:
criticality: tier-1
rto: 60m
rpo: 15m
dr_pattern: warm-standby
backup: immutable-offsite
test_frequency: quarterly
reporting:
criticality: tier-3
rto: 24h
rpo: 24h
dr_pattern: restore-from-backup
test_frequency: yearly
Postmortem-Struktur
# Postmortem: Order API Ausfall
## Auswirkungen
- Checkout für 18 Minuten nicht möglich
- 1.240 fehlgeschlagene Anfragen
## Zeitlinie
- 10:02 Deployment gestartet
- 10:07 Fehlerquote steigt
- 10:12 Rollback eingeleitet
- 10:20 Service stabil
## Ursache
Fehlerhafte DB-Migration blockierte neue Schreiboperationen.
## Maßnahmen
- Migrationen vor Produktion mit produktionsnahen Daten testen
- Canary Deployment für Schreibpfade
- Alarm auf steigende Checkout-Fehlerquote schärfen
Failover-Runbook
1. Incident Commander bestimmen.
2. Status von Standort A, Datenbank und Netzwerk prüfen.
3. Freeze für nicht notwendige Changes aktivieren.
4. Datenreplikation bewerten: letzter konsistenter Stand?
5. Traffic auf Standort B umschalten.
6. Smoke Tests ausführen.
7. Fachbereich informieren.
8. Rückschwenk nur nach separater Entscheidung.
Typische Stolperfallen
- HA wird mit Backup verwechselt.
- DR-Pläne enthalten keine konkreten Befehle.
- RTO/RPO werden technisch geschätzt statt fachlich entschieden.
- Postmortems suchen Schuldige statt Systemursachen.
- Failover wird nie unter realistischen Bedingungen getestet.
Prüf- und Verständnis-Checkliste
- Kritikalitätsklassen sind definiert.
- RTO/RPO sind dokumentiert.
- DR-Tests finden regelmäßig statt.
- Postmortems sind blameless und maßnahmenorientiert.
- Runbooks sind aktuell und auffindbar.
Merksatz
Eine Infrastrukturkomponente ist erst enterprise-tauglich, wenn sie geplant, automatisiert, überwacht, geschützt, wiederherstellbar und fachlich begründet ist.