Reliability-Prinzipien

Reliability, die nicht gemessen wird, existiert nicht.

Reliability-Investitionen ohne messbare Ziele führen zu Aktivitäten ohne Wirkung. Bevor ein Team Multi-AZ deployed, Circuit Breaker konfiguriert oder Chaos-Tests durchführt, muss es wissen: Was ist das aktuelle Zuverlässigkeitsniveau? Was ist das akzeptable Minimum? Was ist die Erwartung von Nutzern und Stakeholdern?

SLOs sind das Fundament. Ohne SLOs kann eine Organisation nicht entscheiden, ob sie over-engineered (zu viel in Reliability investiert) oder under-engineered (zu wenig) ist. Error Budgets transformieren SLOs von statischen Zielen zu dynamischen Entscheidungsgrundlagen.

WAF-REL-010, WAF-REL-100

Ausfälle sind unvermeidlich. Wer sie nicht einplant, plant zu scheitern.

In Cloud-Umgebungen sind Hardware-Ausfälle, AZ-Störungen, Netzwerkunterbrechungen und Software-Bugs keine Ausnahmen – sie sind Normalzustände, die statistisch auftreten. Ein System, das auf den Ausfall einer Komponente mit einem Gesamtausfall reagiert, wurde nicht für Reliability designed.

Reliability-Design bedeutet: Jeder Ausfall einer Komponente darf die Gesamtverfügbarkeit nur innerhalb definierter Grenzen beeinträchtigen. Multi-AZ-Deployment ist die Umsetzung dieses Prinzips für AZ-Ausfälle. Circuit Breaker sind die Umsetzung für Abhängigkeitsausfälle.

WAF-REL-030, WAF-REL-050, WAF-REL-080

Manuelle Recovery skaliert nicht. Systeme müssen lernen, sich selbst zu heilen.

Menschliche Reaktionszeiten (MTTR durch manuellen Eingriff) sind in modernen, verteilten Systemen zu langsam für hochverfügbare Services. Auto-Healing-Mechanismen – Health Check-basiertes Instance Replacement, Kubernetes Pod Restart, Auto-Scaling bei Lastspitzen – reduzieren MTTR von Minuten auf Sekunden.

Automatisierte Recovery erfordert: valide Health Checks (RP1), klar definierte Fehlerzustände, idempotente Restart-Prozeduren und gut konfigurierte Infrastructure-as-Code. Automation ist nur sicher, wenn die Automatik testzertifiziert ist.

WAF-REL-020, WAF-REL-030

Reliability, die nicht getestet wurde, ist eine Hypothese – keine Garantie.

Jede Reliability-Claim – "wir sind Multi-AZ", "unser Backup funktioniert", "der Circuit Breaker schützt uns" – ist ohne entsprechenden Test eine Behauptung. DR-Tests, Chaos-Engineering und Restore-Übungen sind keine nice-to-haves für fortgeschrittene Teams. Sie sind die einzige Methode, um Reliability-Behauptungen in Evidenz umzuwandeln.

Untestete Systeme scheitern anders, als Design-Reviews vorhersagen. Chaos Engineering als systematische Praxis ist der Unterschied zwischen einem Team, das glaubt, resilient zu sein, und einem Team, das es weiß.

WAF-REL-040, WAF-REL-070, WAF-REL-090

Ein Fehler darf nie das gesamte System treffen.

Blast Radius bezeichnet den Umfang des Schadens, den ein einzelner Fehler verursachen kann. Cascading Failures entstehen, wenn ein Fehler in einer Komponente unlimitierten Zugang zu Ressourcen anderer Komponenten hat: Thread Pools, Connection Pools, Anfrage-Queues.

Blast Radius Limitation ist das Ziel von Bulkheads (Isolation von Resource Pools), Circuit Breakers (Fast-Fail statt Resource-Drain), Feature Flags (selektive Deaktivierung) und AZ-Isolation (geografische Fehlergrenze).

WAF-REL-050, WAF-REL-080

Jeder SPOF ist eine Frage, nicht ob er ausfällt, sondern wann.

Ein Single Point of Failure (SPOF) ist eine Komponente, deren Ausfall zu einem Gesamtausfall oder einer SLO-Verletzung führt. In Cloud-Architekturen entstehen SPOFs häufig durch: Single-AZ-Deployments, Single-Instance-Datenbanken ohne Failover, Shared-Config-Endpoints, externe Abhängigkeiten ohne Fallback.

Das systematische Identifizieren und Eliminieren von SPOFs erfordert eine Architekturanalyse (Failure Mode and Effects Analysis, FMEA), die Reliability Debt Register (WAF-REL-100) dokumentiert und durch Chaos Engineering (WAF-REL-090) empirisch validiert.

WAF-REL-030, WAF-REL-100

Reliability entsteht durch Architekturentscheidungen – nicht durch Betriebsmaßnahmen.

Reliability kann nicht nachträglich in ein schlecht entworfenes System eingebaut werden. Entscheidungen über Multi-AZ, Datenbank-Failover, Circuit Breaker-Design und Recovery-Strategie werden im Architekturprozess getroffen – oder versäumt. Operations-Teams können durch Runbooks und Incident Response die Auswirkungen kompensieren, aber nicht die architektonischen Schulden eliminieren.

Reliability muss in Architecture Decision Records (ADRs), Design Reviews und Sprint-Planning als explizite Anforderung verankert sein. Architektur-Entscheidungen, die Reliability reduzieren, müssen im Reliability Debt Register dokumentiert werden.

WAF-REL-010, WAF-REL-100