Azure Reliability, Resiliency und Recoverability erklärt

Einführung: Warum das wichtig ist

In vielen Post-Incident-Reviews stellen Teams fest, dass sie das Falsche optimiert haben – etwa indem sie stark in Disaster-Recovery-Runbooks investiert haben, obwohl die Anwendung eigentlich bessere Fault Isolation gebraucht hätte, oder indem sie davon ausgingen, dass „redundante“ Infrastruktur automatisch zu einer zuverlässigen User Experience führt. Microsofts aktuelle Guidance zieht in Azure eine klare Linie zwischen reliability, resiliency und recoverability und zeigt, wie man Kontinuität by design statt auf Basis von Annahmen aufbaut.

Schlüsselkonzepte (und das Leitprinzip)

Microsoft beschreibt diese als unterschiedliche, sich ergänzende Konzepte:

• Reliability: Der Grad, in dem ein Service/Workload innerhalb definierter Business-Constraints konsistent auf dem beabsichtigten Service Level performt. Das ist das Endziel, das Kunden erleben.
• Resiliency: Die Fähigkeit, Fehler und Störungen auszuhalten (zonen-/regionale Outages, Infrastrukturfehler, Cyberangriffe, Lastspitzen) und ohne kundenwahrnehmbare Auswirkungen weiter zu laufen.
• Recoverability: Die Fähigkeit, den Normalbetrieb wiederherzustellen, nachdem eine Störung die Resiliency-Grenzen überschritten hat.

Leitprinzip: Reliability ist das Ziel. Resiliency hält euch während einer Störung betriebsfähig. Recoverability stellt den Service wieder her, wenn eine Störung die Designgrenzen überschreitet.

Was neu ist / was Microsoft hervorhebt

1) Operating Model mit der Architektur ausrichten

Der Beitrag verknüpft organisatorische Zielsetzung mit technischem Design:

• Microsoft Cloud Adoption Framework (CAF) hilft dabei, Governance, Verantwortlichkeiten und Kontinuitätserwartungen zu definieren.
• Azure Well-Architected Framework (WAF) übersetzt diese Erwartungen in Architektur-Patterns und Trade-offs.

2) Reliability messbar und operativ machen

Reliability zählt nur, wenn ihr sie kontinuierlich nachweisen könnt:

• Akzeptable Service Levels für kritische User Flows definieren.
• Steady-State und Customer Experience mit Azure Monitor und Application Insights instrumentieren.
• Annahmen durch kontrollierte Fault Tests validieren (z. B. Azure Chaos Studio).
• Governance mit Azure Policy, Azure landing zones und Azure Verified Modules skalieren.
• Das Reliability Maturity Model nutzen, um die Konsistenz von Reliability-Praktiken zu bewerten.

3) Resiliency als Lifecycle behandeln (nicht als Checkliste)

Resiliency wird als fortlaufende Praxis positioniert:

• Start resilient (Design-time-Patterns, secure-by-default-Konfigurationen, Platform Protections)
• Get resilient (bestehende Apps bewerten, mission-critical Workloads priorisieren, Gaps schließen)
• Stay resilient (monitoren, Drift erkennen und kontinuierlich validieren)

4) Wechsel zu einer anwendungszentrierten Resiliency Posture

Microsoft betont, dass Nutzer Application-Outages erleben – nicht VM-/Disk-Events. Azures zone resiliency experience unterstützt das Gruppieren von Ressourcen in logische Application Service Groups, die Risikobewertung, das Tracking von Drift sowie Remediation-Guidance mit Kostentransparenz.

Auswirkungen für IT-Admins und Platform-Teams

• Klarere Shared-Responsibility-Grenzen: Das Built-in-Verhalten des Services vs. das, was ihr konfigurieren müsst, wird über Azure Reliability Guides explizit.
• Bessere Design-Entscheidungen: Ihr könnt unterscheiden, wann sich Investitionen in zonales/multi-region Design (Resiliency) lohnen versus Backups/Failover-Prozesse (Recoverability).
• Bessere Incident-Readiness: Messbare SLOs, Observability und Chaos-Drills reduzieren „unknown unknowns“ bei realen Outages.

Action Items / Next Steps

1. Terminologie baselinen über Teams hinweg (reliability vs. resiliency vs. recoverability) und Architekturstandards entsprechend aktualisieren.
2. Azure Reliability guides für jeden zentralen Service prüfen, den ihr betreibt, um Fault-Verhalten und Konfigurationsanforderungen zu bestätigen.
3. Workloads anhand von Failure Domains und Business Impact auf zonal, zone-resilient, oder multi-region Patterns mappen.
4. SLOs + Monitoring (Azure Monitor/App Insights) implementieren und Fault Injection Drills (Chaos Studio) einplanen.
5. Policy/landing zones nutzen, um Configuration Drift zu verhindern und Resiliency Controls in großem Maßstab zu standardisieren.