chaos-engineering

Topics in the source

• Chaos Engineering
• When to use
• When NOT to use
• Core principle: chaos without abort criteria is an outage
• Quick start
• The 3 Python tools
• experimentdesigner.py
• blastradiuscalculator.py

Design experiments that surface real weaknesses in production systems — without becoming outages. Most "chaos engineering" attempts skip steady-state measurement, define no abort criteria, and have no blast-radius bound. This skill enforces the discipline that makes chaos experiments safe and useful. Planning a chaos experiment (what to break, where, when, how to abort) Calculating blast radius before running the experiment Reviewing an existing experiment plan for safety Choosing a chaos tool (Chaos Toolkit / Chaos Mesh / Litmus / Gremlin / AWS FIS) Writing a chaos experiment postmortem Running a Game Day exercise General incident response (use incident-response) Threat hunting / red-team (use red-team, threat-detection) Performance load testing (different goal — chaos is about failure modes, not capacity) Production debugging (chaos discovers weaknesses preemptively, not after-the-fact) The 4 Principles of Chaos Engineering (Netflix, 2016): 1. Build a hypothesis around steady-state behavior. Not "what breaks?" but "X holds; will it still hold under fault Y?" 2. Vary real-world events. Inject realistic failures: kill nodes, slow networks, lose cache, throttle dependencies. 3. Run

This is an excerpt. Refer to the complete source and its current requirements.