用途
混沌工程用于通过受控的故障注入来验证系统韧性。它不是在系统中随意制造故障，而是以假设驱动的方式，在明确的范围和时长内注入特定故障，观察系统是否按预期表现，从而发现韧性缺口并加以修复。
核心原则
- 假设驱动：每次实验前先定义假设，例如“我们相信如果主数据库不可用，应用将为读请求提供缓存数据，并将写请求排队最多 5 分钟，且不出现用户可见错误”。假设需指明具体的稳态指标（错误率、延迟、吞吐量）及其允许的波动边界。
- 从小开始：第一次实验不应是“关闭生产环境”，而应是“在预生产环境为一个非关键服务增加 200ms 延迟”。随着信心和工具成熟逐步扩大范围。
- 监控是前提：如果无法实时检测问题，就无法安全注入故障。实验前需验证仪表盘、告警和值班流程。
- Game Day 培养肌肉记忆：在自动化流水线中运行实验有价值，但定期的团队演练能培养真实事故中所需的人工技能。
实验工作流（五步）
- 定义稳态假设：确定定义“正常”的指标，并预测实验期间应发生的情况。
- 引入变量：以明确的范围和时长受控地注入故障，并设定中止条件。
- 观察：实验期间实时监控所有相关指标，为观察者分配具体仪表盘。
- 分析恢复与数据完整性：对比实际与预期，检查影响时长、用户可见错误、数据丢失或损坏、监控告警是否正常触发、恢复时间。
- 修复并迭代：记录发现，修复韧性缺口，安排复跑验证修复。每个行动项都需有负责人和截止日期。
故障注入类型
网络故障：延迟注入（tc、toxiproxy、Gremlin）、丢包（tc netem、Chaos Mesh）、DNS 故障（iptables、CoreDNS 操作）、网络分区（iptables、Chaos Mesh）、带宽限制（tc、toxiproxy）。
服务故障：服务崩溃（杀进程、删除 Pod）、服务变慢（CPU 压力、线程池耗尽）、错误注入（返回 500/503、抛异常）、内存压力（stress-ng、Chaos Mesh）。
基础设施故障：磁盘满（fallocate、dd）、CPU 耗尽（stress-ng）、内存耗尽（stress-ng）、时钟偏移（chrony 操作、timedatectl）。
依赖故障：API 宕机（toxiproxy、mock server）、数据库不可用（封端口、杀进程）、缓存不可用（封 Redis 端口）、消息队列满（填满队列、阻塞消费者）。
工具选择
- LitmusChaos（Kubernetes 原生，CNCF）：适合 K8s 环境与 CI/CD 集成，提供 ChaosCenter UI、Workflows 实现 GameDay-as-code，2025 年 10 月发布 MCP Server 可用自然语言驱动实验。
- Chaos Mesh（Kubernetes 原生，CNCF）：适合需要细粒度控制的 K8s 环境，通过 bpfki 运行时支持 eBPF 内核级故障。
- AWS FIS：托管 AWS 服务，适合 AWS 工作负载（EC2、ECS、RDS、EKS），支持 CloudWatch 告警停止条件自动中止。
- Gremlin：托管平台，适合需要引导式实验与合规报告的团队，Health Checks 在 SLO 违规时暂停并回滚。
- Steadybit：托管平台，覆盖 Kubernetes、云和本地环境的可靠性中心。
- kube-monkey：开源，轻量级 K8s 替代方案。
- Pumba：开源，仅限 Docker 的混沌（容器、网络）。
- toxiproxy：开源网络代理，适合集成测试中的网络故障注入。
- tc：Linux 内核工具，用于网络延迟和丢包。
- stress-ng：Linux 工具，用于 CPU、内存、磁盘压力测试。
- k6（+ xk6-disruptor）：负载测试工具，可结合负载与混沌场景。
选择决策树：K8s 上云托管 AWS 工作负载选 AWS FIS；K8s 需细粒度选 Chaos Mesh；K8s 需工作流和 UI 选 LitmusChaos；K8s 轻量选 kube-monkey；纯 Docker 选 Pumba；Linux 手动选 tc + stress-ng；集成测试网络故障选 toxiproxy；负载+混沌选 k6 + xk6-disruptor；需托管平台与合规选 Gremlin 或 Steadybit。
新项目应避免使用 Netflix Chaos Monkey：它仅注入实例终止且依赖 Spinnaker 部署流水线，活跃度低。
Game Day 规划
Game Day 是团队共同运行混沌实验、演练应急响应的定期会议。准备包括：提前 2 周定义 2-3 个实验、编写假设、获取批准、通知相关方、验证监控告警、确定回滚流程、安排 3-4 小时时段；提前 1 天确认参与者与角色、测试故障注入工具、干跑回滚、准备仪表盘、简报值班团队、确认中止标准。角色包括实验负责人（运行并决定中止）、观察者（应用指标、基础设施指标、日志、用户体验）和记录员。事后回顾需确认假设、记录意外、列出行动项并安排下次 Game Day。
入门三个实验
- 数据库变慢：用 toxiproxy 为数据库连接增加 500ms 延迟，持续 5 分钟，预生产环境。观察响应时间、连接池、超时处理、熔断器、缓存效果。
- 第三方 API 返回 500：配置 mock/代理使支付 API 返回 500，持续 10 分钟。观察错误消息质量、重试行为、幂等性、降级路径、监控告警。
- 缓存不可用：用 toxiproxy 或 iptables 封 Redis 端口，持续 5 分钟。观察数据库查询量、响应时间、错误率、连接池、恢复行为。
反模式
无监控的混沌：无法观察影响就注入故障不是混沌工程，而是破坏。修复方法：实验前验证能实时看到错误率、延迟、吞吐量和依赖健康；进一步将监控接入实验实现自动中止（AWS FIS CloudWatch 停止条件、Gremlin Health Checks、Litmus promProbe 连续模式）。
适用场景与限制
适用于预生产环境或经批准的生产环境，前提是具备实时监控、告警、回滚能力和团队应急经验。生产实验需要管理层支持。若监控不成熟或团队对受控故障不适应，应先投资监控和演练。资料中未提供具体收费价格信息。