混沌工程与系统韧性验证

混沌工程不是在生产环境随机关服务器，而是以明确假设、受控范围和自动停止条件主动验证系统面对故障时能否保持目标服务。它关注的不只是“组件有没有重启”，而是用户请求是否仍满足 SLO、告警是否到达、值班人员能否判断、降级与恢复是否按预期发生。

本文适用于虚拟机、Kubernetes、数据库和分布式应用。所有实验先在测试或预发布环境完成，只有具备审批、隔离、可观测性和回退能力后，才考虑有限的生产实验。

一、先区分三件事

故障演练不是为了证明系统一定会失败，而是建立对系统行为的信心，并发现架构图和操作手册中没有暴露的依赖。

二、什么是稳态

稳态应从用户视角定义，而不是“所有 Pod 都是 Running”。一个订单系统的稳态可以是：

5 分钟窗口内：
- 下单成功率 >= 99.9%
- P95 延迟 <= 500 ms
- 库存重复扣减 = 0
- 消息积压能够在 10 分钟内恢复

实验前、实验中和实验后都测量同一组稳态指标。若没有稳态，实验只能看到基础设施变化，无法判断业务是否具备韧性。

三、提出可证伪假设

一个完整假设包含：

• 故障对象和故障方式；
• 预期系统行为；
• 用户允许影响；
• 观察指标；
• 实验持续时间；
• 停止与回滚条件。

示例：

当任意一个订单 API 实例被终止时，负载均衡应在 30 秒内摘除它；
下单成功率保持在 99.9% 以上，P95 不超过 600 ms；
若连续 1 分钟错误率超过 1%，立即停止实验并恢复实例数。

“看看关掉会怎样”不是可验证假设。

四、建立故障目录

按层级组织实验，避免只测试 Pod 删除：

计算

• 进程退出、容器终止、主机宕机；
• CPU 压力、内存压力和文件描述符耗尽；
• 时钟偏差、线程池和连接池耗尽。

网络

• 延迟、抖动、丢包、带宽限制；
• DNS 超时或错误解析；
• 单向中断、跨可用区中断；
• TLS 证书到期或握手失败。

存储与数据

• 磁盘空间不足、I/O 延迟；
• 存储卷暂时不可用；
• 数据库主从切换、复制延迟；
• 缓存清空或缓存服务故障。

依赖与平台

• 第三方接口超时、限流和错误返回；
• 消息队列积压或消费者停止；
• 配置中心、密钥服务不可用；
• 单可用区或关键控制面故障。

五、爆炸半径控制

从最小范围逐步扩大：

单进程 → 单实例 → 单节点 → 单可用区 → 区域级恢复演练

限制维度包括：

• 只对测试租户、内部用户或少量流量生效；
• 只选择一个服务、节点或故障域；
• 限制持续时间和并发故障数；
• 避开发布、大促、结算和备份窗口；
• 设置全局停止按钮和自动超时；
• 保留足够值班、数据库和网络人员。

首次实验不要同时注入多个变量，否则失败后无法判断原因。

六、实验前安全门禁

• 变更审批和业务负责人同意；
• 当前无高等级事故、发布或容量告警；
• 监控、日志、Trace 与业务探测正常；
• 最近备份和恢复路径可用；
• 自动停止条件已测试；
• 实验工具权限限制在目标范围；
• 通知值班、客服和相关依赖团队；
• 回退命令、负责人和通信频道明确。

实验工具本身属于高权限系统，应启用身份认证、审批、审计和最小权限，不能让普通用户任意注入生产故障。

七、Kubernetes实验示例

先在隔离命名空间验证一个 Pod 故障：

apiVersion: chaos-mesh.org/v1alpha1
kind: PodChaos
metadata:
  name: order-api-single-pod
  namespace: chaos-test
spec:
  action: pod-kill
  mode: one
  selector:
    namespaces: ["test-order"]
    labelSelectors:
      app: order-api
  duration: "30s"

示例字段可能随工具版本变化，应以当前官方文档为准。实验前确认选择器只匹配预期对象，可先以只读查询列出目标。

八、网络延迟实验

网络实验要区分入口、服务间调用和依赖出口。一个假设可能是：“库存服务增加 300 ms 延迟时，订单接口不会无限重试，P95 仍小于 1 秒，熔断器在阈值后打开。”

重点观察：

• 客户端与服务端超时层级是否合理；
• 重试是否带指数退避和随机抖动；
• 重试总时长是否超过上游超时；
• 熔断和降级是否真正减少下游压力；
• 连接池是否被慢请求占满；
• Trace 是否能显示等待位置。

错误配置的重试会把小故障放大为重试风暴。

九、数据库切换实验

数据库实验风险高，应先在复制环境进行：

1. 记录当前主从角色、日志位置和复制状态；
2. 停止或隔离原主，防止双写；
3. 触发计划内切换；
4. 观察连接池刷新、DNS/代理切换和事务错误；
5. 验证关键读写、任务和复制恢复；
6. 核对数据完整性和实际 RTO/RPO；
7. 按流程将原节点重新加入，而不是直接恢复写入。

混沌工具不能替代数据损失决策。可能产生数据丢失的实验必须由业务和数据负责人明确批准。

十、告警和值班也要纳入验证

实验不仅验证系统自动恢复，还要验证人和流程：

• 告警是否在预期时间触发；
• 告警是否指向用户影响而非单个组件噪声；
• 值班人员是否能找到 Runbook；
• 升级路径和事故角色是否清晰；
• 恢复后告警是否自动关闭；
• 时间线和证据是否足以复盘。

如果实验只由发起人观察而不经过真实告警路径，就没有验证值班体系。

十一、一次完整实验案例

目标：验证单可用区订单服务失效。

1. 使用历史数据确认剩余两区具备峰值容量；
2. 选择内部租户和 5% 流量作为首轮范围；
3. 定义错误率、P99、积压和数据库连接硬停止条件；
4. 隔离一个可用区的应用流量；
5. 发现全局缓存客户端仍优先访问故障区，连接超时导致 P99 超标；
6. 自动停止实验并恢复路由；
7. 修复缓存节点发现和跨区超时；
8. 重新实验通过后，逐步扩大到 25% 和全部测试租户；
9. 更新架构图、Runbook 和容量模型。

失败的实验是有价值的结果，前提是影响受控且整改闭环。

十二、实验报告模板

实验编号：CE-2026-006
假设：单实例退出不影响订单 SLO
范围：测试环境 / order-api / 1 个 Pod
稳态：成功率、P95、积压、重复订单数
故障方式：pod-kill，持续 30 秒
停止条件：错误率 > 1% 持续 60 秒
实际结果：P95 短暂升高，成功率达标
未预期现象：告警延迟 7 分钟
整改：调整燃尽率窗口并补充合成探测
复验日期与负责人：...

十三、如何进入生产实验

满足以下条件再考虑生产：

• 同一实验在测试和预发布稳定通过；
• 业务 SLO、回退和停止条件自动化；
• 影响范围可以精确限定；
• 所有依赖团队和业务方知情；
• 工具权限、操作审计和双人复核到位；
• 当前容量、错误预算和备份状态健康；
• 实验从小流量、短时间开始；
• 结束后立即验证并形成报告。

生产实验应成为可靠性计划的一部分，而不是个人临时尝试。

十四、常见错误

• 没有稳态和假设，直接删除资源；
• 同时注入 CPU、网络和磁盘故障；
• 只看 Pod 是否恢复，不看业务成功率；
• 实验停止后不验证积压、复制和数据一致性；
• 工具使用集群管理员权限且无审计；
• 在错误预算已耗尽或容量不足时做实验；
• 发现问题后只恢复现场，不形成整改和复验；
• 把演练成功当成所有故障都已覆盖。

十五、建立年度韧性验证计划

实验不应只在事故后临时开展。可以按照业务风险制定年度计划：

高频实验应自动化并保持小范围；低频高影响演练应由技术、业务、安全和管理角色共同参与。实验库需要记录最后执行时间、最近结果、未关闭整改和下次复验时间。

覆盖率不能只统计“执行了多少次”。更有意义的指标包括关键服务稳态覆盖率、关键故障模式覆盖率、自动停止成功率、发现问题后的平均关闭时间，以及相同缺陷是否重复出现。

十六、实施检查清单

• [ ] 稳态使用用户可感知指标定义；
• [ ] 假设、范围、持续时间和停止条件明确；
• [ ] 第一次实验只改变一个变量；
• [ ] 工具选择器经过只读确认；
• [ ] 监控、告警、值班和通信路径同时验证；
• [ ] 数据风险和备份状态已评估；
• [ ] 结果包含未预期现象、整改和复验日期；
• [ ] 生产实验从最小流量和最小故障域开始；
• [ ] 实验库按系统风险持续维护。

十七、参考资料

• CNCF：Building Resilience with Chaos Engineering and Litmus
• Chaos Mesh Documentation
• LitmusChaos Documentation