用途：面向分布式系统开展混沌工程，覆盖实验设计、故障注入框架搭建、Game Day 演练规划与执行、爆炸半径控制与安全机制、CI/CD 持续混沌测试，以及基于实验发现改进系统韧性。
核心工作流：先做系统分析，梳理架构、依赖、关键路径与失效模式；再设计实验，定义假设、稳态、爆炸半径与安全控制；随后在监控与快速回滚下执行受控实验；最后记录发现、实施修复、增强监控，并将混沌测试集成到 CI/CD 实现持续韧性。
参考指南按主题加载：实验设计（references/experiment-design.md）、基础设施混沌（references/infrastructure-chaos.md）、Kubernetes 混沌（references/kubernetes-chaos.md）、工具与自动化（references/chaos-tools.md）、Game Day（references/game-days.md）。
安全约束：先定义并验证稳态基线再注入故障；从最小影响范围起步，验证后再扩大；回滚路径须脚本化并预先测试，自动回滚不超过 30 秒；一次只改变一个故障条件；面向客户的环境需具备熔断、特性开关或金丝雀隔离；每次实验须产出书面学习总结和至少一项跟踪改进。
输出模板：实验设计文档（假设、指标、爆炸半径）、实现代码（故障注入脚本或清单）、监控与告警配置、回滚流程与安全控制、学习总结与改进建议。
示例用法：Kubernetes 上可用 Litmus ChaosEngine 做 pod-delete 实验，通过 TOTAL_CHAOS_DURATION、CHAOS_INTERVAL、PODS_AFFECTED_PERC 控制时长与影响比例，用 kubectl apply -f chaos-pod-delete.yaml 应用，用 kubectl patch chaosengine ... engineState:stop 中止；网络延迟可用 toxiproxy-cli create 与 toxic add 注入、toxic remove 恢复；Chaos Monkey 可通过配置文件限制到单个 ASG 并排除金丝雀实例。
限制：资料未提供具体收费、价格、平台支持范围与效果数据，暂未提供。