Ein gut gezeichnetes Architekturdiagramm vermittelt Sicherheit – aber es ist kein Beweis für Resilienz. Microsoft hat in einem aktuellen Blogbeitrag klar formuliert, was viele Azure-Architekten im Alltag verdrängen: Ausfallsicherheit ist kein Zustand, den man einmalig herstellt, sondern eine Eigenschaft, die man aktiv pflegt. Das klingt selbstverständlich, wird in der Praxis aber regelmäßig vernachlässigt.
Was steckt hinter der Aussage?
In meinen Azure-Kursen erlebe ich es immer wieder: Teams zeigen stolz ihre Architekturdiagramme mit Availability Zones (Verfügbarkeitszonen), Geo-Redundanz und automatischem Failover – und glauben, damit sei die Sache erledigt. Microsoft stellt in dem Beitrag genau diese Denkweise in Frage. Jahrelang wurde Resilienz als Projekt behandelt: planen, umsetzen, abhaken. Das Problem dabei ist das Abhaken.
Systeme verändern sich. Abhängigkeiten wachsen. Teams wechseln. Was zum Zeitpunkt der Architekturentscheidung noch stimmig war, kann sechs Monate später bereits überholt sein – durch neue Services, geänderte Konfigurationen oder schlicht durch Drift (schleichende Konfigurationsabweichungen vom Sollzustand). Ein Diagramm dokumentiert eine Absicht, keinen Betriebszustand.
Merksatz: Ihr Architekturdiagramm beschreibt, wie Ihr System aussehen soll. Ob es so funktioniert, zeigt nur der Test.
Was bedeutet das für Azure-Admins und Architekten?
Folgendes Problem aus der Praxis: Ein Kunde hatte eine Multi-Region-Architektur mit Traffic Manager und aktivem Failover in eine sekundäre Region dokumentiert. Im Ernstfall – einem simulierten regionalen Ausfall im Rahmen eines Chaos-Engineering-Tests – versagte das Failover, weil die Health Probes (Zustandsprüfungen) des Traffic Managers falsch konfiguriert waren. Das Diagramm war korrekt. Die Konfiguration nicht.
Der Microsoft-Beitrag adressiert genau diesen Gap. Resilienz muss als laufende Eigenschaft verstanden werden, nicht als Projektabschluss. Das hat konkrete Konsequenzen:
| Ansatz | Risiko | Besser |
|---|---|---|
| Einmalige Resilienz-Architektur | Drift, vergessene Abhängigkeiten, kein Test | Regelmäßige Resilience Reviews |
| Diagramm als Beweis | Konfiguration weicht vom Diagramm ab | Infrastructure as Code + Drift Detection |
| Failover nur geplant | Failover funktioniert im Ernstfall nicht | Chaos Engineering, regelmäßige Failover-Tests |
Praxistipp: Nutzen Sie Azure Chaos Studio, um kontrollierte Ausfallszenarien in Nicht-Produktionsumgebungen zu testen. Kombinieren Sie das mit Azure Policy und Azure Monitor, um Konfigurationsdrift frühzeitig zu erkennen.
Noch mal in Kürze: Ein Architekturdiagramm ist eine Planungsgrundlage. Resilienz entsteht durch Tests, Monitoring, Chaos Engineering und regelmäßige Reviews – nicht durch das Zeichnen von Pfeilen zwischen Azure-Diensten. Wer das verinnerlicht, betreibt keine Resilience-Projekte mehr, sondern Resilience-Engineering als Dauerbetrieb.
Alle Details finden Sie in der Originalankündigung bei Azure Blog.