Prüfung der Nachhaltigkeit

1) Grundbegriffe und Ziele

Zuverlässigkeit (reliability) - die Wahrscheinlichkeit der Arbeitsfähigkeit; resilience (resilienz) - Verhalten bei und nach einem Ausfall.
SLO/fehlerhaftes Budget: Kriterien für die „Förderfähigkeit“ von Degradation.
Steady-state-Hypothese: formale Erwartung stabiler Metriken (z.B. p95 <200 ms, Fehlerrate <0. 5%). Ein Experiment gilt als erfolgreich, wenn die Hypothese eingehalten wird.
Fehlermodi: Netzwerk (Latenz, Verlust/Takes, Diskontinuitäten), Computing (CPU, Speicher), Story (I/O, Disc-Erschöpfung), Abhängigkeiten (5xx, Timeouts, Rate-Limit), logisch (partielle Vorfälle, „langsame Degradation“), operativ (Release, config), „dunkel“ (Split-Brain, Stundenschicht).

2) Die Pyramide der Nachhaltigkeit

1. Unit-Tests von logischen Fehlern (Retrays, Idempotenz, Timeouts).
2. Komponenten mit fehlerhaften Adaptern (Testcontainers/tc-netem).
3. Integration/System mit Netzwerk/DB/Caches und Real-World-Profilen.
4. Chaos-Experimente im Pre-Prod (und dann begrenzt im Prod) nach Runbook 's.
5. Game-Day - Szenario-Übungen des Teams (Menschen + Werkzeuge).

3) Beobachtbarkeit als Grundlage

SLI: p50/p95/p99 Latenz, Fehlerrate, Sättigung (CPU/Heap/FD/IOPS), Drop/Timeout, Queue Depth.
Traces: um „Engpässe“ unter Ablehnung zu finden.
Semantische Nachhaltigkeitsmetriken: Anteil erfolgreicher Graceful-Degrade, Anteil Shed-Requests, Selbstheilungsrate (MTTR).
Kennzeichnung der Experimente: 'chaos. experiment_id', 'phase = inject/recover' in Ereignissen/Protokollen.

4) Fehlerinjektionskatalog (Fehler)

Netzwerk: Latenz/Jitter, Verlust/Duplikate/Reorder, Bandbreitenbeschränkung, Paket „Stürme“, TLS-Clips.
Host: CPU-Limit, Speicherlecks/Limits, GC-Pausen, Deskriptoren erschöpft, „clock skew“.
Speicher: Latenzwachstum, EROFS, ENOSPC, Replikatabbau, Verlust des Führers.
Abhängigkeiten: 5xx/429, Verlangsamung, DNS-Flapping, veraltete Zertifikate, Rate-Limit, „partielle Antworten“.
Daten: Beschädigung des Datensatzes, „Löcher“ in den Streams, Ereignisse, Versionskonflikte.
Operationen: fehlgeschlagene Freigabe, Ficha-Flag, Config-Drift, manueller Fehler (im Rahmen der Simulation).

5) Resistenzmuster (was zu überprüfen ist)

Retrays mit Jitter und Timeouts auf jedem RPC.
Circuit Breaker (öffnen/halb öffnen, exponentielle Erholung).
Bulkheads (Isolierung von Pools/Warteschlangen auf kritische Domänen).
Load Shedding (Wir setzen Abfragen mit niedriger Priorität bei Sättigung zurück).
Backpressure (Signale nach oben in der Kette, Grenzen der Parallelität).
Idempotency (Schlüssel der Idempotency auf „Nebenwirkungen“).
Caching und Stacks im Falle einer Degradation der Quelle.
Graceful Degradation (einfache Antworten, Stale-Daten, Deaktivierung von Fich).
Timeout-Budget (gesamtes Zeitbudget entlang der Anrufkette).
Atomarität/Kompensation (Saga/Outbox/Transactional Inbox).
Quorum und Replikation (R/W Quorum, Consistency Degradation for Availability).
Anti-Entropy/Repleys (Wiederherstellung bei „Löchern“ von Ereignissen).

6) Rezepte für Injektionen und Erwartungen (Pseudocode)

Rückzug mit Jitter und Breaker

for attempt in 1..N:
if breaker. open(): return fallback()
res = call(dep, timeout = base 0. 8)
if res. ok: return res sleep(exp_backoff(attempt) jitter(0. 5..1. 5))
if attempt == N: breaker. trip()
return fallback()

Shading und Backpresher

if queue. depth() > HIGH          cpu. load() > 0. 85:
if request. priority < HIGH: return 503_SHED limiter. acquire () # constrain concurrency

Idempotenz

key = hash("payout:"+external_id)
if store. exists(key): return store. get(key)
result = do_side_effect()
store. put(key, result, ttl=30d)
return result

7) Experimente: Szenarien und Hypothesen

7. 1 „Langsame Abhängigkeit“

Injektion: + 400 ms p95 an externe API.
Erwartung: Wachstum der Timeouts ≤ X%, Öffnung des Breakers, Fallback-Antworten, Beibehaltung des p99-Dienstes <SLA, keine Kaskade bei Retrays.

7. 2 „Partieller Cache-Verlust“

Injektion: Ausfall von 50% der Redis/Cache-Shard-Knoten.
Erwartung: Erhöhte Miss, aber keine Lawine an die Quelle (request coalescing/immutable TTL), Auto-Warm-up und Erholung.

7. 3 „Geteiltes Gehirn in der DB“

Injektion: Verlust des Führers, Umschalten auf Replik.
Erwartung: Kurzzeitige Deny-Einträge, aus dem Quorum zu lesen, kein Datenverlust, Outbox verliert keine Nachricht.

7. 4 „ENOSPC/Disc voll“

Injektion: Scheibe zu 95-100%.
Warten: Notrotationen von Protokollen, Ausfall von Non-Blocking-Fich, Erhaltung kritischer Protokolle (WAL), Alerts und Autoliquid.

7. 5 „Burst des Verkehrs“

Injektion: × 3 RPS zu heißem Endpoint 10 min.
Erwartung: Shading mit niedriger Priorität, stabiles P95 bei „nuklearen“ Gleisen, steigende Warteschlangen innerhalb der Grenzen, keine DLQ-Stürme.

7. 6 «Clock Skew»

Injektion: Verschiebung der Node-Zeit um +/ − 2 min.
Erwartung: korrekte TTL/Signaturen (Leeway), monotone Timer in Retrays, gültige Token bei zulässiger Drift.

8) Umgebungen und Sicherheit von Experimenten

Beginnen Sie mit Pre-Prod, synthetischen Daten so nah wie möglich am Produkt Configi/Topologie.
In der Produktion - nur kontrollierte Fenster, Fitscha-Flaggen, schrittweise Amplitude, Auto-Rollback, „roter Knopf“.
Guardrails: RPS/Fehlerlimits, SLO-Wachen, Blockierung von Releases bei kritischen Vorfällen.
Ein obligatorisches Runbook: wie man zurückrollt, wen man anruft, wo man schaut.

9) Automatisierung und CI/CD

Versuchskatalog als Code (YAML/DSL): Ziele, Injektionen, Metriken, Schwellenwerte, „Buttons“ des Rollbacks.
Smoke-Chaos in jedem Release: kurze Injektionen (z.B. 2 min + 200 ms zur Abhängigkeit) im Stage.
Nachtläufe der Matrix: Dienste × Arten von Fehlern.
Release Gate: Verbot von Deploys, wenn die Resistenz unterhalb der Schwelle liegt (z.B. 'fallback coverage <95%' unter 'slow dependence').

10) Daten und Konsistenz

Kompensation prüfen (Saga): Teilweise ausgeführte Tätigkeiten müssen in den vereinbarten Zustand gebracht werden.
Testen Sie Wiederholungen/Duplikate von Ereignissen, Out-of-Order-Lieferung, „Löcher“ und Replays.
Überprüfen Sie Domain-Invarianten nach Fehlern: Das Guthaben ist nicht negativ, Transaktionen bleiben nicht „stecken“, Limits werden nicht verletzt.

11) Anti-Muster

Nur Happy-Path und Last ohne Fehler testen.
Retrai ohne Jitter → Sturm unter Degradation.
Das Fehlen eines globalen Zeitlimits → kaskadierende Zeitlimits.
Ein einziger Pool für alle Aufgaben → keine Isolation (Bulkheads).
„Endlose“ Warteschlangen → das Wachstum der Latenz/OOM.
Null-Telemetrie-Experimente → „blinde“ Chaos-Praktiken.
Chaos im Verkauf ohne Rollback/Limits/verantwortlichen Besitzer.

12) Checkliste des Architekten

1. Steady-State-Hypothese und SLO definiert?
2. Hat jeder RPC Timeouts, Jitter-Retrays, Breaker?
3. Bulkheads, Limiter, Backpress, Load-Shedding umgesetzt?
4. Cache nachhaltig: Coalescing, Schutz vor Cash-Stürmen, Aufwärmen?
5. Outbox/Saga für Nebenwirkungen, idempotente Schlüssel?
6. Quoren/Replikation/Failover getestet?
7. Haben Sie einen Katalog von Experimenten, nightly Chaos und Gates in CI/CD?
8. Metriken/Traces markieren Experimente, gibt es Dashboards?
9. Das Runbook'i und der „rote Knopf“ sind fertig, Verantwortung zugewiesen?
10. Regelmäßige Spieltage mit Dev/SRE/Support?

13) Mini-Tools und Beispielszenarien (YAML-Sketche)

Netzwerk (tc/netem)

yaml experiment: add-latency target: svc:payments inject:
netem:
delay_ms: 300 jitter_ms: 50 loss: 2%
duration: 10m guardrails:
error_rate: "< 1%"
p95_latency: "< 400ms"

CPU/Heap

yaml inject:
cpu_burn: { cores: 2, duration: 5m }
heap_fill: { mb: 512 }

Abhängigkeit

yaml inject:
dependency:
name: currency-api mode: slow p95_add_ms: 500 fallback_expectation: "serve stale rates ≤ 15m old"

Schlussfolgerung

Die Nachhaltigkeitsprüfung sei kein „Chaos-Trick“, sondern eine Disziplin, die das System unter Störungen berechenbar mache. Klare Hypothesen, Telemetrie, ein Katalog von geführten Experimenten und in die Architektur eingebettete Muster (Timeouts, Breakers, Isolation, Idempotenz) verwandeln potenzielle Vorfälle in kontrollierte Szenarien. Das Team erhält Vertrauen in die Releases und die Nutzer erhalten einen stabilen Service, auch unter Ausfallbedingungen.