opsmith / monitoring-incident-operations / Modul

Resilienz validieren

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

Resilienz ist eine belegte Eigenschaft

Einführung · 4 Abschnitte · ~12 Min Lesezeit · Stand

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.

Kontrollierter Test

  1. Hypothese und Nutzerwirkung definieren
  2. Freigabe, Scope und Abbruchkriterium festlegen
  3. Nur den geplanten Fehler injizieren
  4. Service- und Plattformsignale beobachten
  5. 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.

Gelesen ist nicht geprüft: Im Modul entscheidest du die Fälle selbst und siehst danach, wo dein Urteil trägt.

3 Checks starten →

Modul-Aufbau

EINFÜHRUNGResilienz ist eine belegte Eigenschaft~12 Min
ADR-001RESILIENCE-TESTsenior
TRACE-002MISSION · RECOVERY-EVIDENCEsenior
FLOW-003MISSION · CONTROLLED-EXPERIMENTsenior

Quellen

  1. 01sre.google/sre-book/accelerating-sre-on-call
  2. 02sre.google/workbook/reliability-testing
  3. 03sre.google/sre-book/monitoring-distributed-systems