# Resilienz validieren

> Failover, Degradation und Recovery als kontrollierte Hypothesen testen, ohne Produktion blind zu gefährden.

Track: [Monitoring, Troubleshooting & Incident Operations](https://opsmith.app/learn/monitoring-incident-operations)  
Kanonische Fassung: https://opsmith.app/learn/monitoring-incident-operations/resilience-validation  
Stand: 2026-07-30  
Interaktiver Teil: 3 Checks (nur im Browser)

## Resilienz ist eine belegte Eigenschaft

### Die Betriebsfrage

Ein dokumentierter Failover beweist nicht, dass er unter heutiger Last, mit aktuellen Abhängigkeiten und Alarmwegen funktioniert. Resilienztests prüfen eine Hypothese mit klarer Begrenzung und Abbruchregeln.

> **Lernziel:** Du kannst einen Resilienztest mit Hypothese, Blast Radius, Beobachtung und Recovery-Kriterium entwerfen.

### Kontrollierter Test

Hypothese und Nutzerwirkung definieren → Freigabe, Scope und Abbruchkriterium festlegen → Nur den geplanten Fehler injizieren → Service- und Plattformsignale beobachten → Recovery belegen und Folgemaßnahmen dokumentieren

### Sicherheitsgrenze

Ein Experiment ersetzt keine Incident-Reaktion. Bei unerwarteter Wirkung gilt das Abbruchkriterium, nicht Neugier. Besonders bei Datenintegrität, Sicherheitskontrollen oder regulatorischen Diensten benötigt der Test einen expliziten Owner und Change-Prozess.

### Im Check

Die Missionen bewerten nicht Mut, sondern kontrollierbare Lernfähigkeit: eine prüfbare Hypothese, kleinster Scope und eine gemessene Rückkehr in den Sollzustand.

## Quellen

- sre.google/sre-book/accelerating-sre-on-call — https://sre.google/sre-book/accelerating-sre-on-call/
- sre.google/workbook/reliability-testing — https://sre.google/workbook/reliability-testing/
- sre.google/sre-book/monitoring-distributed-systems — https://sre.google/sre-book/monitoring-distributed-systems/