chaos-resilience-testinglisted

# Chaos / Resilience Testing ## Safety boundary — read first Chaos testing is a controlled, authorized experiment, not random destruction: - Confirm explicit authorization and a defined blast radius (specific service, specific % of traffic, specific environment) before running anything. - Always have a kill switch / rollback ready before starting an experiment, and a monitoring dashboard open to abort immediately if impact exceeds the expected scope. - Start in staging; only run in production with explicit sign-off, a documented game-day plan, and off-peak timing. - Never run an experiment whose blast radius you can't predict or contain. ## What you're actually testing Not "does it break" (it will) — you're verifying the system's **failure mode is graceful**: does it degrade a feature, or does one dependency failure cascade into a full outage? The finding that matters is *how* it fails, not just *that* it failed. ## Failure types to inject - **Latency injection** — add artificial delay to a downstream call (Toxiproxy, a proxy sidecar, or code-level fault injection) and verify timeouts are actually configured (a call with no timeout will hang the caller indefinitely, which is itself the finding). - **Service/dependency failure** — kill a downstream service or dependency and verify the caller's circuit breaker trips, falls back (cache, default, degraded feature) or fails fast with a clear error, rather than retrying forever or hanging. - **Network partition** — split traffic