Glossar: Reliability

Prozentualer Anteil der Zeit, in der ein System korrekt auf Anfragen antwortet. Gemessen als (uptime / total_time) * 100. Typische Ziele: 99.9% (8.7h/Jahr Downtime), 99.95% (4.4h/Jahr), 99.99% (52min/Jahr).

Physisch isoliertes Rechenzentrum innerhalb einer Cloud-Region. AZ-Ausfälle betreffen nur Ressourcen in der betroffenen Zone; andere AZs bleiben davon unberührt.

Kopie von Daten zu einem bestimmten Zeitpunkt zur Wiederherstellung bei Datenverlust. Backups werden durch RPO-Anforderungen getaktet. Ungetestete Backups sind keine Backups.

Umfang des Schadens, den ein einzelner Fehler verursachen kann. Reliability-Design zielt darauf ab, den Blast Radius durch Bulkheads, Circuit Breaker und AZ-Isolation zu begrenzen.

Muster zur Ressourcen-Isolation: Jede Abhängigkeitsklasse erhält eigene Thread- und Connection Pools. Verhindert, dass ein langsamer Service alle Ressourcen erschöpft. Benannt nach den wasserdichten Schotten in Schiffen.

Disziplin des Experimentierens mit Produktionssystemen durch kontrollierte Fehlerinjektion, um systemische Schwächen aufzudecken. Hypothesis-driven: "Wenn X ausfällt, passiert Y."

Muster für Ausfalltoleranz: Wenn Fehlerrate einen Schwellenwert überschreitet, werden Anfragen sofort abgelehnt (open state), ohne das fehlerhafte System weiter zu belasten. Nach Timeout wird Partial-Traffic erlaubt (half-open); bei Erfolg reset (closed).

Backup-Methode, die Datenänderungen in Echtzeit repliziert, anstatt periodische Snapshots zu erstellen. Ermöglicht RPO nahe null.

Jeder externe Service, jede API oder jedes System, von dem ein Workload für seine Funktion abhängt. Kritische Abhängigkeiten: Ausfall führt zu Workload-Ausfall. Optionale Abhängigkeiten: Ausfall führt zu Feature-Verlust, nicht Totalausfall.

Gesamtheit aller Pläne, Prozesse und Systeme zur Wiederherstellung nach einem katastrophalen Ausfall (Region-Ausfall, Ransomware, Naturkatastrophe).

Verbleibende Fehlertoleranz bis zur SLO-Verletzung. Berechnung: (1 - SLO) * Messfenster. Bei 99.9% SLO und 30-Tage-Fenster: 43.2 Minuten Error Budget pro Monat.

Geschwindigkeit, mit der das Error Budget verbraucht wird. Burn Rate 14x bedeutet: Das monatliche Budget wird in 2 Tagen aufgebraucht.

Automatischer Wechsel auf eine Standby-Ressource bei Ausfall der Primärressource. Bei RDS Multi-AZ: Automatischer Failover zur Standby-Instanz in <2 Minuten.

Kontrolliertes Einführen von Fehlern in ein System zu Testzwecken. Werkzeuge: AWS FIS, Azure Chaos Studio, Chaos Monkey.

Strukturiertes, teamweites Chaos-Ereignis zur Validierung der Resilienz des Gesamtsystems. Typisch: halbtägige Übung mit gezielten Szenarien und festgelegten Rollen.

Fähigkeit eines Systems, bei Ausfall von Teilkomponenten eingeschränkt, aber funktionsfähig zu bleiben. Gegenteil: Fail-Fast/Totalausfall.

Endpoint oder Probe, der den Zustand einer Service-Instanz prüft. Typen: Liveness (lebt der Prozess?), Readiness (nimmt der Service Traffic an?), Startup (ist der Service gestartet?).

Eigenschaft einer Operation, die bei mehrfacher Ausführung dasselbe Ergebnis liefert. Essenziell für sichere Retry-Logik.

Kubernetes-Probe, die prüft, ob ein Container noch lebt. Bei Fehlschlag: Container wird neu gestartet. Erkennt Deadlocks und Infinite Loops.

Framework zur Bewertung des aktuellen Stands einer Disziplin auf einer definierten Skala. WAF++ Reliability: 5 Stufen (Chaotisch → Selbstheilend).

Durchschnittliche Zeit zwischen zwei aufeinanderfolgenden Ausfällen. Je höher, desto zuverlässiger. Relevant für Hardware und langlebige Systeme.

Durchschnittliche Zeit vom Eintreten eines Fehlers bis zur vollständigen Wiederherstellung. Enthält Erkennungszeit (MTTD) + Diagnosezeit + Behebungszeit.

Durchschnittliche Zeit vom Auftreten eines Fehlers bis zur Erkennung durch Monitoring oder Nutzer. Gutes Monitoring reduziert MTTD auf < 5 Minuten.

Erwartete Betriebsdauer bis zum ersten Ausfall. Wird für nicht-reparierbare Systeme (Hardware-Bauteile) verwendet.

Fähigkeit, eine Datenbank auf einen beliebigen Zeitpunkt in der Vergangenheit wiederherzustellen. Erfordert kontinuierliche Transaction Log Archivierung.

Kubernetes-Probe, die prüft, ob ein Container bereit ist, Traffic anzunehmen. Bei Fehlschlag: Pod wird aus dem Service-Endpoint entfernt, aber nicht neu gestartet. Verhindert premature Traffic Routing während Startup.

Maximaler akzeptabler Datenverlust bei einem Ausfall, gemessen in Zeit. RPO = 1h: Bis zu 1 Stunde Datenverlust akzeptabel. Bestimmt Backup-Frequenz.

Maximale akzeptable Zeit für die vollständige Wiederherstellung nach einem Ausfall. RTO = 30min: Der Service muss innerhalb von 30 Minuten wiederhergestellt sein.

Bekannte Schwächen oder deferred Reliability-Improvements, die das Risiko von Ausfällen erhöhen. Analog zu technischer Schuld; wird im WAF-REL-100 Register erfasst.

Wiederholungsstrategie: Wartezeit zwischen Versuchen verdoppelt sich exponentiell. Verhindert Retry Storms. Mit Jitter: Zufällige Variation verhindert synchronisierte Retries vieler Clients.

Dokumentierter Schritt-für-Schritt-Leitfaden zur Diagnose und Behebung eines spezifischen Incidents oder Alert-Typs. Muss direkt aus Alert-Notifications verlinkt sein.

Vertragliche Vereinbarung über die Verfügbarkeit und Qualität eines Service. SLAs referenzieren SLOs und definieren Konsequenzen bei Nicht-Erfüllung.

Konkrete Metrik, die einen Aspekt der Service-Qualität misst. Beispiele: Verfügbarkeit (%), Latenz (p99 ms), Fehlerrate (%), Durchsatz (req/s).

Internes Ziel für einen SLI. Beispiel: "HTTP-Verfügbarkeit >= 99.9% über 30 Tage." SLOs leiten Error Budgets und Reliability-Entscheidungen.

Eine Komponente, deren Ausfall das gesamte System oder einen SLO-relevanten Teil unverfügbar macht. SPOFs sind architektonische Schuld und werden in WAF-REL-100 erfasst.