# Verfügbarkeit & Fehlerdomänen

> AZ- und Region-Design gegen korrelierte Ausfälle und gegen die Kosten der Redundanz abwägen.

Track: [Cloud Infrastructure & Platform Engineering](https://physar.tech/learn/cloud-infra)  
Kanonische Fassung: https://physar.tech/learn/cloud-infra/availability-failure-domains  
Stand: 2026-09-13  
Interaktiver Teil: 8 Checks (nur im Browser)

## Verfügbarkeit aus Fehlerdomänen und Wiederherstellung ableiten

### Fehlerdomänen: die Einheit, die gemeinsam ausfällt

Eine **Fehlerdomäne** ist die Menge von Komponenten, die aus einer gemeinsamen Ursache zusammen ausfallen. Cloud-Anbieter bieten sie gestuft an: Host, Rack bzw. Platzierungseinheit, Verfügbarkeitszone, Region. Redundanz zahlt sich nur aus, wenn die Kopien in **verschiedenen** Domänen liegen — zwei Instanzen auf demselben Host sind eine Instanz mit doppelten Kosten.

|  |  |
| --- | --- |
| Host | Häufigster Ausfall, kleinste Wirkung. Wird von jeder Plattform automatisch abgefedert, wenn mehrere Instanzen existieren. |
| Zone | Eigenständiges Rechenzentrum bzw. eigenständige Infrastruktur innerhalb einer Region, mit eigener Strom- und Kühlversorgung. Der übliche Zuschnitt für Hochverfügbarkeit. |
| Region | Geografisch getrennt. Schutz gegen großflächige Ereignisse — und der teuerste Schritt, weil Latenz und Datenkonsistenz zum Thema werden. |
| Anbieter | Selten begründbar. Vervielfacht Betriebslast und Komplexität; meist ist die Ursache eine Anforderung, die anders besser lösbar ist. |

> **Merksatz:** Die richtige Frage ist nicht „wie viele Kopien?“, sondern „welche gemeinsame Ursache trifft sie alle gleichzeitig?“.

### Korrelierte Ausfälle: der Grund, warum Redundanz enttäuscht

Rechnerisch sieht Redundanz großartig aus: Zwei unabhängige Komponenten mit je 99 % Verfügbarkeit ergeben zusammen 99,99 %. Der Haken steckt im Wort **unabhängig**. In der Praxis teilen redundante Komponenten fast immer etwas — und dieses Etwas bestimmt die tatsächliche Verfügbarkeit.

- **Gemeinsame Abhängigkeit:** dieselbe Datenbank, derselbe Konfigurationsdienst, derselbe Secret-Store, dieselbe DNS-Zone.
- **Gemeinsame Änderung:** dasselbe Deployment, dieselbe Konfiguration, dasselbe abgelaufene Zertifikat — die häufigste Ursache für den gleichzeitigen Ausfall aller Repliken.
- **Gemeinsame Überlast:** Fällt eine von zwei Zonen aus, muss die verbleibende die volle Last tragen. Ist sie dafür nicht ausgelegt, fällt sie hinterher.
- **Gemeinsame Steuerungsebene:** Auch das Umschalten braucht Dienste, die selbst ausfallen können.

Der dritte Punkt ist der am häufigsten unterschätzte. Bei zwei Zonen bedeutet Ausfallsicherheit, dass jede Zone im Normalbetrieb höchstens die Hälfte ihrer Kapazität nutzt — also 100 % Überkapazität. Bei drei Zonen genügen rund 50 % Reserve für denselben Schutz. Der Kapazitätspuffer ist deshalb Teil des Verfügbarkeitsentwurfs, nicht eine Kostenfrage daneben.

_[Abbildung: Redundanz ist nur so gut wie die Trennung der Abhängigkeiten hinter den Kopien.]_

### Was Verfügbarkeitszusagen wirklich aussagen

Anbieterzusagen beschreiben eine Erstattungsregel, keine Vorhersage. Drei Punkte, die man kennen muss: Sie gelten meist nur für den **Dienst** in der zugesagten Konfiguration (oft: über mehrere Zonen verteilt), sie messen mit der **Definition des Anbieters** von Nichtverfügbarkeit, und die Kompensation ist eine Gutschrift — sie ersetzt keinen Geschäftsausfall.

Für den eigenen Entwurf zählt eine andere Rechnung: Die Verfügbarkeit deines Dienstes ist ungefähr das **Produkt** der Verfügbarkeiten aller Komponenten, die auf dem kritischen Pfad in Reihe liegen. Sechs Abhängigkeiten mit je 99,9 % ergeben rund 99,4 % — nicht 99,9 %. Deshalb ist das Reduzieren der Abhängigkeiten auf dem kritischen Pfad oft wirksamer als das Verdoppeln einzelner Komponenten.

> **Antipattern:** Ein Verfügbarkeitsziel festlegen, ohne die Abhängigkeitskette zu zählen. Ein Ziel, das über der Verfügbarkeit einer unvermeidbaren Abhängigkeit liegt, ist rechnerisch unerreichbar.

### Wie viel Verfügbarkeit ist genug?

Jede zusätzliche Neun kostet überproportional — an Infrastruktur, an Komplexität und an Änderungsgeschwindigkeit, weil strengere Ziele vorsichtigere Prozesse erzwingen. Die nüchterne Frage lautet deshalb nicht „wie hoch geht es?“, sondern „welchen Ausfall trägt das Geschäft, und was kostet die Vermeidung im Vergleich zum Schaden?“.

|  |  |
| --- | --- |
| Ungefähre Ausfallzeit pro Monat | 99 % ≈ 7 Stunden · 99,9 % ≈ 43 Minuten · 99,99 % ≈ 4 Minuten |
| Was dabei mitwächst | Redundanz und Reservekapazität, Automatisierung des Umschaltens, Bereitschaft, Übungsaufwand |
| Was dabei sinkt | Änderungsgeschwindigkeit — bei sehr hohen Zielen wird jede Änderung zum Risiko für das Ziel |

Nützlich ist außerdem die Unterscheidung nach Funktion: Selten muss das ganze System dasselbe Ziel erfüllen. Der Bestellpfad, der Login und die Rechnungshistorie haben verschiedene Schadensprofile — und dürfen verschiedene Ziele und damit verschiedene Kosten haben.

> **Gleich im Check:** In den folgenden Entscheidungen suchst du gemeinsame Ursachen hinter scheinbarer Redundanz, dimensionierst Reservekapazität und begründest ein Verfügbarkeitsziel.

### Der Betriebsvertrag braucht messbare Invarianten

**Betriebsinvariante:** Eine Aussage über ein Ende-zu-Ende-Dienstpfad mit benannten Komponenten, Daten und externen Abhängigkeiten, die vor und nach einem erlaubten Übergang nachweisbar wahr sein muss.

Ein technisches Feature wird erst dann zu einem Betriebsvertrag, wenn Sollzustand, Verantwortlicher, Messpunkt und Reaktion zusammenpassen. Für ein Ende-zu-Ende-Dienstpfad mit benannten Komponenten, Daten und externen Abhängigkeiten besteht der prüfbare Kern aus **Fehlerdomänenkarte, SLO, Kapazitätsrechnung, Failoverablauf und Übungsnachweis**. Der Vertrag nennt außerdem den gültigen Scope und die Bedingungen, unter denen ein Übergang abgebrochen wird. Das verhindert, dass Teams dieselben Wörter verwenden, aber unterschiedliche Garantien erwarten. der Workload-Owner für das Dienstziel und die Plattform für zugesagte Domänen und Umschaltmechanismen bestätigt nicht nur eine Konfiguration, sondern die Fähigkeit, ihre Wirkung zu beobachten und bei Abweichung zu handeln.

Invarianten müssen von außen prüfbar sein. Eine Aussage wie **ist sicher** hilft nicht; eine Aussage wie **jede schreibende Operation trägt failure-domain, stammt aus einer freigegebenen Identität und erzeugt innerhalb des Messfensters einen Auditnachweis** kann getestet werden. Neben dem positiven Pfad gehören negative Fälle in die Abnahme: unzulässiger Scope, fehlende Freigabe, veraltetes Artefakt und nicht erreichbare Kontrollabhängigkeit. Erst diese Gegenproben zeigen, ob die Grenze technisch durchgesetzt oder nur dokumentiert ist.

**Kurzcheck:** Welche Beschreibung ist für ein Ende-zu-Ende-Dienstpfad mit benannten Komponenten, Daten und externen Abhängigkeiten als Invariante geeignet?

- [x] Jeder erlaubte Übergang ist über failure-domain, Owner, Scope und Ergebnis korrelierbar
- [ ] Das Team arbeitet vorsichtig und hält sich normalerweise an die gemeinsame Dokumentation
- [ ] Die eingesetzte Cloudfunktion gilt allgemein als zuverlässig

> Die Aussage benennt prüfbare Merkmale und lässt sich automatisiert oder im Review widerlegen.

### Grenzen und Eigentum entscheiden über den Blast Radius

Die wirksame Grenze liegt bei **Zone, Region, Account, Control Plane, Datenreplikation und gemeinsame Namens- oder Identitätsdienste**. Sie bestimmt, welche Ressourcen, Daten und Teams von einer fehlerhaften Entscheidung gemeinsam betroffen sein können. Organigramme und Repository-Grenzen sind dafür nur Hinweise. Maßgeblich ist, wo Identitäten, Zustand, Kapazität oder Kontrollpfade tatsächlich geteilt werden. zusätzliche Domänen erhöhen Robustheit und Kosten; komplexere aktive Verteilung kann selbst neue Fehlermodi erzeugen Diese Abwägung wird explizit dokumentiert, damit eine spätere Konsolidierung nicht unbemerkt mehrere unabhängige Fehlerbereiche wieder koppelt.

Eigentum bedeutet Entscheidungs- und Reaktionspflicht. der Workload-Owner für das Dienstziel und die Plattform für zugesagte Domänen und Umschaltmechanismen legt fest, wer den Sollzustand ändern, wer eine Ausnahme genehmigen und wer im Vorfall handeln darf. Ein RACI ohne technische Rechteprüfung reicht nicht. Regelmäßig wird verglichen, ob Gruppen, Pipeline-Identitäten und Notfallrollen noch zum dokumentierten Modell passen. Gemeinsame Komponenten erhalten einen eigenen Service-Owner, SLO und Eskalationsweg, weil sonst jedes konsumierende Team nur seine lokale Sicht optimiert.

> **Grenztest:** Frage für jede gemeinsame Abhängigkeit: Welcher maximale Teil des Dienstes fällt aus, wenn genau diese Abhängigkeit falsche Daten liefert, nicht erreichbar ist oder kompromittiert wird?

### Der Normalablauf wird als kontrollierte Zustandsmaschine beschrieben

Dienstpfad kartieren → Ausfallannahmen wählen → **Redundanz prüfen** → Kapazität reservieren → Umschaltung automatisieren → Fehler injizieren und Ergebnis gegen das SLO auswerten

Der Ablauf ist eine Zustandsmaschine und keine lose Checkliste. Jeder Schritt besitzt Eingangsdaten, einen ausführenden Prinzipal, ein Ergebnis und eine Abbruchbedingung. Ein nachfolgender Schritt darf nur starten, wenn das vorherige Ergebnis unverändert referenziert wird. Dadurch kann ein Review nicht versehentlich ein anderes Artefakt prüfen als die Automatisierung später verwendet. Wiederholungen müssen entweder idempotent sein oder eine eindeutige Vorgangskennung erkennen, damit ein Timeout nicht zu einer zweiten konkurrierenden Änderung führt.

Für Drei Anwendungsreplikate laufen auf verschiedenen Hosts, teilen aber dieselbe Zone und denselben regionalen Datenendpunkt wird der Ablauf zuerst in einem kleinen, repräsentativen Scope ausgeführt. Die Plattform protokolliert Eingaben und Ergebnis, aber keine Secrets oder unnötigen Nutzdaten. Menschliche Freigaben beziehen sich auf Digest, Plan oder Version, nicht auf einen veränderlichen Namen. So bleibt die Kette auch dann prüfbar, wenn zwischen Review und Ausführung Zeit vergeht oder ein anderer Runner übernimmt.

### Vorbedingungen und Gates stoppen unsichere Übergänge

Ein Gate ist nur sinnvoll, wenn sein Ergebnis die Ausführung tatsächlich stoppt. Mindestgates prüfen Identität und Scope, Vollständigkeit des Artefakts, bekannte Richtlinien, verfügbare Kapazität sowie einen beobachtbaren Rückweg. Das Gate liefert **bestanden**, **abgelehnt** oder **befristete Ausnahme** mit maschinenlesbarem Grund. Warnungen, die bei jedem Lauf ignoriert werden, sind keine Kontrolle; sie werden entweder in eine harte Bedingung, einen befristeten Behebungsauftrag oder eine bewusst entfernte Regel überführt.

Die Vorbedingungen müssen zum Risiko passen. zusätzliche Domänen erhöhen Robustheit und Kosten; komplexere aktive Verteilung kann selbst neue Fehlermodi erzeugen Deshalb wird nicht jede Änderung durch denselben schweren Prozess geschickt. Kleine, reversible Schritte mit engem Scope können automatisiert freigegeben werden. Irreversible Datenänderungen, neue Vertrauensbeziehungen oder eine Vergrößerung der Fehlerdomäne verlangen zusätzliche Evidenz und unabhängiges Review. Die Risikoklasse stammt aus der beobachtbaren Wirkung, nicht aus der Zahl geänderter Codezeilen.

- Ist das Ziel eindeutig und der Scope kleiner als die maximal erlaubte Fehlerdomäne?
- Sind Eingaben und Abhängigkeiten unveränderlich referenziert?
- Existieren Abbruchsignal und benannter Owner?
- Ist der Rückweg technisch möglich und mit aktuellen Daten geprobt?
- Wird die Wirkung nach dem Übergang gegen eine Baseline geprüft?

### Fehlerbilder werden vor dem Ernstfall operationalisiert

Die wichtigsten Fehlerbilder sind **mehrere Replikate in derselben Domäne, gemeinsame Control-Plane-Abhängigkeit, fehlende Zielkapazität und ungetestete DNS- oder Datenumschaltung**. Für jedes Bild wird festgehalten, wie es erkannt wird, welche automatischen Schutzmechanismen greifen und welche manuelle Entscheidung übrig bleibt. Ein Runbook, das erst mit der Ursachenanalyse beginnt, kommt zu spät. Zuerst werden Nutzerwirkung und Ausbreitung begrenzt; danach wird die Hypothese mit möglichst kleinen, reversiblen Tests geprüft. Änderungen an mehreren Grenzen gleichzeitig sind zu vermeiden, weil ihr Ergebnis keine Ursache mehr isoliert.

Übungen testen nicht nur den glücklichen Failover. Ein sinnvoller Versuch nimmt zusätzlich eine Kontrollabhängigkeit weg, verzögert Telemetrie oder lässt einen Schritt nach erfolgreicher Außenwirkung mit Timeout enden. Das Team muss dann erkennen, ob die Operation wiederholt, fortgesetzt oder gestoppt werden darf. Beobachtet werden sowohl technische Metriken als auch die Qualität der Entscheidung: Zeit bis zur klaren Führung, Anzahl konkurrierender Änderungen und Vollständigkeit der Evidenz.

### Fehlerprobe mit begrenztem Scope

Drei Anwendungsreplikate laufen auf verschiedenen Hosts, teilen aber dieselbe Zone und denselben regionalen Datenendpunkt

**Anforderungen**

- Explizite Hypothese und erwartetes Signal
- Begrenzter Zielscope mit Abbruchschwelle
- Aktueller Rückweg und erreichbarer Owner
- Zeitlich korrelierbare technische und fachliche Messung

**Schritte**

- Baseline sichern
- Eine Fehlerannahme auslösen
- Schutzreaktion beobachten
- Kontrolliert wiederherstellen
- Abweichungen als Arbeit erfassen

**Merksatz:** Eine bestandene Übung beweist den geprobten Fall unter den beobachteten Bedingungen, nicht die Abwesenheit aller Risiken.

### Telemetrie verbindet technische Signale mit Nutzerwirkung

Für den Betrieb werden **Fehlerbudget, zonale Verteilung, Replikationsverzug, Umschaltdauer, verbleibende Kapazität und Anteil erfolgreicher Anfragen** gemeinsam betrachtet. Einzelne Messwerte ohne Scope und Zeitbezug sind gefährlich: Ein globaler Durchschnitt kann einen vollständigen Ausfall einer Zone verdecken, eine erfolgreiche API-Antwort kann eine verzögerte Wirkung verschleiern. Jede Metrik nennt Quelle, Dimensionen, erwartete Aktualität und Verhalten bei Messlücken. Fehlende Telemetrie gilt bei kritischen Übergängen als eigener Fehlerzustand und kann die Fortsetzung blockieren.

Alarme werden an einer konkreten Handlung ausgerichtet. Ein Alarm nennt betroffenen Scope, beobachtete Invariante, wahrscheinlichen Owner und den ersten sicheren Prüfschritt. Tickets eignen sich für langsamen Kapazitäts- oder Complianceabbau; Paging bleibt akuter Nutzerwirkung oder unmittelbar drohendem Kontrollverlust vorbehalten. Dashboards und Auditabfragen verwenden dieselben IDs wie failure-domain, damit Einsatzleitung, Plattform und Workload-Team nicht drei widersprüchliche Zeitlinien rekonstruieren.

> **Messlücke:** Wenn ein Übergang erfolgreich gemeldet wird, seine erwartete Wirkung aber nicht innerhalb des Messfensters beobachtbar ist, bleibt der Zustand unbekannt. Unbekannt ist kein Erfolg.

### Recovery beginnt mit einem sicheren Kontrollpunkt

Der Recovery-Vertrag lautet: **Schaden isolieren, stabile Domänen schützen, Last und Datenpfad umschalten, Konsistenz prüfen und nur kontrolliert zurückschwenken**. Er nennt den letzten sicheren Kontrollpunkt, die Reihenfolge der Schritte und die Daten, die nach einer Umschaltung fachlich geprüft werden müssen. Rollback ist nur dann ein Rückweg, wenn alte Software, Konfiguration und Datenzustand noch kompatibel sind. Andernfalls ist ein kontrollierter Roll-forward oft sicherer. Diese Entscheidung wird vor dem Vorfall für die wichtigsten Änderungsklassen getroffen.

Backups und Exportdateien zählen erst nach einem Restore-Test als Recovery-Fähigkeit. Ebenso zählt eine sekundäre Umgebung erst, wenn Identität, Quotas, Netzpfade, Schlüssel und Telemetrie dort unter realistischer Last funktionieren. Die Übung protokolliert erreichten Wiederherstellungspunkt, Dauer, Datenabweichung und manuelle Abhängigkeiten. Ein verfehltes Ziel führt zu einer priorisierten Architektur- oder Prozessänderung; das bloße Herabsetzen des Zielwerts benötigt eine fachliche Risikoentscheidung.

Schreibende Änderungen stoppen → **Sicheren Kontrollpunkt bestimmen** → Abhängigkeiten und Zielkapazität prüfen → Kleinste wirksame Recovery-Maßnahme ausführen → Technische und fachliche Konsistenz messen → Schrittweise in den Normalbetrieb zurückkehren

### Änderungsevidenz macht Entscheidungen später prüfbar

Evidenz ist ein Produkt des Ablaufs. Fehlerdomänenkarte, SLO, Kapazitätsrechnung, Failoverablauf und Übungsnachweis werden über failure-domain verbunden und in einem Speicher abgelegt, den der ausführende Prinzipal nicht nachträglich unbemerkt verändern kann. Die Aufbewahrung richtet sich nach Betriebs-, Sicherheits- und Nachweisanforderungen. Sensible Werte werden minimiert oder maskiert; ein Audit-Log darf nicht selbst zum Secret- oder Personendatenarchiv werden.

Ein Abschlussnachweis beantwortet sechs Fragen: Wer löste den Übergang aus, was wurde freigegeben, welcher Scope war betroffen, welche automatischen und menschlichen Gates griffen, welche Wirkung wurde gemessen und welcher Restfehler blieb? Diese Struktur beschleunigt sowohl Incident-Diagnose als auch regelmäßige Reviews. Sie erlaubt außerdem, wiederkehrende manuelle Ausnahmen, lange Wartezeiten und häufige Abbrüche als Signale für eine schlechte Plattform-Schnittstelle zu erkennen.

Für die technische Abnahme wird eine kleine Nachweismatrix gepflegt. Ihre Zeilen sind Normalbetrieb, Grenzfall, abgelehnter Fall, Kontrollausfall und Recovery; ihre Spalten sind Eingabe, erwarteter Zustand, Messpunkt, Frist und Owner. Dabei werden **Host-, Zonen-, Regions- und Control-Plane-Ausfall** getrennt betrachtet, weil eine erfolgreiche Probe der einen Klasse keine Aussage über die anderen liefert. Als gemeinsame Referenzen dienen `Dienst-ID, Fehlerdomäne und Failoverlauf`. Die IDs müssen bereits bei der Ausführung entstehen und durch Telemetrie, Ticket und Auditstrom weitergereicht werden. Nachträgliches Zusammenführen anhand ungefähr gleicher Uhrzeiten ist nur eine schwache Ersatzlösung. Die Matrix wird bei einer neuen Abhängigkeit, einem geänderten Scope oder einer geänderten Wiederherstellungsannahme aktualisiert und als Teil des Changes geprüft.

Der wichtigste Abnahmesatz lautet, dass **der Dienst beim Verlust der angenommenen Domäne mit ausreichender Zielkapazität weiterarbeitet**. Um ihn zu widerlegen, braucht der Test mindestens einen erlaubten und einen bewusst unerlaubten Fall. Zusätzlich wird geprüft, was bei einem Timeout nach bereits eingetretener Wirkung geschieht. Die Automatisierung darf einen solchen Schritt nicht blind wiederholen. Sie liest zuerst den beobachtbaren Zustand und entscheidet dann zwischen Fortsetzen, kompensierender Aktion und Eskalation. Für schreibende Übergänge existiert ein Idempotenzschlüssel oder ein fachlich gleichwertiger Schutz. Dadurch wird aus einem Transportfehler kein doppelter Infrastruktur-, Daten- oder Berechtigungseingriff.

Die regelmäßige Betriebsprüfung nimmt anschließend reale Veränderungen in den Blick. Sie vergleicht dokumentierte Owner mit aktiven Berechtigungen, erwartete mit beobachteten Abhängigkeiten, vereinbarte mit gemessenen Wiederherstellungszeiten und geplante mit tatsächlich genutzten Ausnahmen. Abweichungen werden nach möglicher Nutzerwirkung und verbleibendem Zeitfenster priorisiert. Ein Befund gilt erst als geschlossen, wenn die technische Ursache behoben, die Kontrolle erneut ausgeführt und die Evidenz am selben Objekt verknüpft wurde. Wiederholte manuelle Eingriffe sind ein Signal für eine fehlende Plattformfähigkeit und werden in einen standardisierten Self-Service-Pfad oder eine bewusst akzeptierte Sonderverantwortung überführt.

## Quellen

- AWS Well-Architected Framework, Reliability Pillar — https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/welcome.html
- AWS Well-Architected Framework, Reliability Pillar — Availability definition and calculation — https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/availability.html
- Google SRE Book: Embracing Risk — https://sre.google/sre-book/embracing-risk/
- Microsoft Azure Well-Architected Framework: Reliability — Redundancy — https://learn.microsoft.com/azure/well-architected/reliability/redundancy
- Google SRE Book: Addressing Cascading Failures — https://sre.google/sre-book/addressing-cascading-failures/
- Google Cloud Architecture Framework: Reliability — https://cloud.google.com/architecture/framework/reliability
- Microsoft Azure Well-Architected Framework: Reliability — https://learn.microsoft.com/azure/well-architected/reliability/