用途：面向分布式系统开展混沌工程，覆盖实验设计、故障注入框架实现、game day 演练规划与执行、爆炸半径控制与安全机制、CI/CD 持续混沌测试，以及基于实验发现改进系统韧性。
主要能力：按五步工作流推进——系统分析（梳理架构、依赖、关键路径与失效模式）、实验设计（定义假设、稳态、爆炸半径与安全控制）、执行混沌（受控实验、监控与快速回滚）、学习改进（记录发现、修复、增强监控）、自动化（接入 CI/CD）。参考资料按主题划分：实验设计、基础设施混沌（服务器、网络、可用区、区域故障）、Kubernetes 混沌（Pod、节点、Litmus、Chaos Mesh）、工具与自动化（Chaos Monkey、Gremlin、Pumba、CI/CD 集成）、game day 规划与复盘。
安全约束：先定义并验证稳态基线再注入故障；爆炸半径从最小范围起步，验证后再扩大；自动回滚须在实验前脚本化并测试，目标不超过 30 秒；一次只改变一个故障变量；面向客户的环境需具备熔断、特性开关或金丝雀隔离；每次实验须产出书面学习总结和至少一项跟踪改进。
使用方式：以 Litmus Chaos 为例，先验证基线（如 kubectl get deploy my-service -n production、kubectl top pods -n production -l app=my-service），再编写并应用 ChaosEngine 清单（kubectl apply -f chaos-pod-delete.yaml），通过 kubectl describe chaosengine 与 kubectl get chaosresult 观察状态，实验期间跟踪日志，违反稳态时用 kubectl patch chaosengine ... -p '{"spec":{"engineState":"stop"}}' 中止并确认 rollout 状态。网络延迟可用 toxiproxy：brew install toxiproxy、toxiproxy-server &、toxiproxy-cli create -l 0.0.0.0:22222 -u downstream-db:5432 db-proxy、toxiproxy-cli toxic add db-proxy -t latency -a latency=300 -a jitter=30，恢复时移除 toxic。Chaos Monkey 通过配置文件限制范围（如 grouping: APP、exceptions 排除 canary），可用 chaos-monkey --app my-service --account staging --dry-run false 手动触发测试。
适用场景：Kubernetes 与微服务环境的韧性验证、故障演练、持续混沌测试。限制：具体平台支持范围、收费与价格、效果数据暂未提供；生产环境使用需自行落实上述安全控制。