故障注入实验：设计稳态假设与爆炸半径

FreeGuideOnline 最新 2026-07-02

故障注入实验：从假设到安全边界的设计方法

故障注入实验是混沌工程的核心实践，它的目标不是随机制造破坏，而是通过有控制的实验主动暴露系统弱点。一次高质量的故障注入实验，始于清晰的稳态假设，成于合理的爆炸半径控制。

什么是故障注入实验

故障注入实验是一种通过有意向系统引入故障（如网络延迟、CPU 压力、服务宕机等）来验证系统弹性的方法。与被动等待故障发生不同，它让你在生产环境或类生产环境中主动“排练”故障，从而回答一个根本问题：当这个组件出问题时，系统真的能如我们预期那样保持稳态吗？

任何一次实验都必须建立在两个基石之上：稳态假设和爆炸半径。前者告诉你“预期中的正常是什么样”，后者告诉你“实验影响的范围有多大”。

第一步：设计稳态假设

稳态假设是对系统正常运行时关键指标的精确描述。没有它，你就无法判断实验结果是成功还是失败——因为你根本不知道“正常”长什么样。

稳态假设的核心要素

一个可用的稳态假设必须满足三个条件：

  • 可测量：必须依赖具体指标，而不是主观感受。“系统感觉变慢了”不是稳态假设，“P99 延迟 ≤ 200ms”才是。
  • 与业务直接相关：优先选择能反映用户体验或核心交易的指标，如订单创建成功率、API 错误率、视频启播耗时等。
  • 有正常波动区间：稳态不是一条直线，而是一个范围。你需要观察至少一周的历史数据，定义出“正常”的上限和下限。

如何写出合格的稳态假设

以电商系统的“下单服务”为例，一个糟糕的稳态假设写法是：

系统在下单时不要报错。

这个假设有两个致命问题：第一，“不要报错”无法量化，偶发的超时算不算？第二，没有覆盖用户侧的真实表现。更好的写法是：

在故障注入期间，从点击“提交订单”到返回成功页面的端到端成功率 ≥ 99.9%；P95 响应时间 ≤ 800ms，且不高于基线值的 1.5 倍。

写完假设后，你需要明确观测窗口：实验开始后多长时间内必须满足该假设？实验结束后系统应该在多长时间内恢复？一般建议观测窗口覆盖实验全过程加上故障撤销后 5~10 分钟，以防“延迟故障”影响。

从假设倒推监控盲区

在设计稳态假设时，常常会暴露监控的缺口。如果你发现某个关键假设指标根本没有现成看板，这就是一个高优先级改进项。实验之前，先补齐监控，否则实验形同盲测。

第二步：理解并最小化爆炸半径

爆炸半径（Blast Radius）是指故障注入可能影响到的那部分系统、用户、业务资源的总和。控制爆炸半径的目的不是让实验变得毫无风险，而是让风险可控、可逆、可隔离。

不控制爆炸半径的典型表现

  • 在流量入口层注入全量延迟，导致所有用户被影响。
  • 对主库进行压力测试，导致事务日志堆积，影响同库的所有服务。
  • 没有限制故障作用范围，让实验故障和真实故障同时发生，难以区分。

这些做法直接将实验变成了一次生产事故。控制爆炸半径，就是要让你在“尽可能贴近生产”和“尽可能隔离影响”之间找到平衡。

爆炸半径的缩小技术

  1. 用户维度隔离

    • 通过路由规则将一小部分用户（比如 1% 的内测用户、内部员工账号）导向实验目标。
    • 在 HTTP 请求头中植入实验标记（例如 X-Chaos-Experiment: user-basket-timeout），让中间件只对标记流量注入故障。
    • 配合灰度发布系统，使实验只命中特定版本、特定地域或特定设备类型。

  2. 基础设施维度隔离

    • 只对集群中单个 Pod、单个虚拟机、单个可用区注入故障，而非对整个服务。
    • 使用独立的消息队列 Topic、独立的 Redis 实例或只读副本进行实验。
    • 对数据库实验时，优先在只读副本上注入故障，验证读写分离的切换逻辑。

  3. 时间维度隔离

    • 选择业务低峰期执行实验，即使爆炸半径稍微扩大，造成的绝对影响也能降到最低。
    • 设定自动回退时间窗口：实验持续 5 分钟自动终止，或当某项绕行指标超标时立刻熔断。

  4. 请求维度隔离

    • 只对特定类型请求注入故障，例如只影响下订单中“优惠券校验”步骤，而不影响整个下单链路。
    • 通过服务网格（如 Istio）的规则，精确匹配请求路径、Header 或源服务。

为爆炸半径设定安全边界

在实验前，必须回答以下问题，并将答案固化为实验审批清单：

  • 受影响的用户最多有多少？如果超出怎么办？
  • 是否涉及资金、交易一致性、用户隐私等高敏感数据？
  • 是否有不可逆的操作（如删除、写主库、发送真实通知）？
  • 实验终止按钮由谁负责？终止流程是否演练过？
  • 监控告警是否已针对爆炸半径配置？一旦异常扩大，能在几秒内感知？

一个实用的做法是：从最小可行爆炸半径开始。第一次实验只影响一台机器、一个内部测试账号，成功后逐步放大范围。永远不要首次实验就在全量用户身上进行。

实验设计实践：将假设与半径结合

假设你要验证“用户服务缓存故障”下的系统表现。你的设计过程如下：

  1. 明确目标：验证当 Redis 缓存不可用时，用户服务能否在 2 秒内降级到数据库查询，并且不会拖垮数据库连接池。
  2. 定义稳态假设：
    • 核心指标：用户信息接口的可用性 ≥ 99.99%，P99 延迟 ≤ 150ms。
    • 降级指标：数据库查询平均耗时 ≤ 30ms，活跃连接数 ≤ 峰值容量的 60%。
    • 观测窗口：故障注入后 3 分钟。
  3. 限制爆炸半径：
    • 仅对标签为 tester 的内部测试用户的请求注入“缓存连接拒绝”故障。
    • 故障作用范围限定在单个用户服务 Pod，不跨 Pod 扩散。
    • 在业务低峰期（凌晨 3 点）进行，最长持续 5 分钟。
    • 配置自动熔断规则：如果用户服务实例的数据库活跃连接数超过 80%，立即终止实验。
  4. 准备回退和通知：
    • 终止方案：一键删除注入规则，或手动重启 Pod 恢复。
    • 通知范围：提前告知 DBA 和当班运维，实验开始和结束时发送群消息。

通过上述设计，你拥有了一个清晰可判定的成功标准，并且将潜在损害限制在了极小的、预先定义的区域内。

常见反模式

  • 没有稳态假设就直接动手：很多人上来就杀进程、断网，然后看着监控图说“好像没啥变化”。这不是实验，是盲猜。
  • 爆炸半径由系统自己决定：比如用 kill -9 随机杀某个进程，没有做流量隔离，等同于在全量用户面前直接炸掉一块积木。
  • 只在测试环境做：测试环境的流量模型、数据量、配置几乎都不相同，得到的结论可信度极低。正确的做法是逐步从类生产环境推进到生产环境。
  • 实验终止靠人工手动：如果终止线程或终止按钮的调用链路本身也受到了故障影响，你就失去了控制权。必须确保终止通道的独立性和高优先级。

文档化你的实验

每次实验都应当留下一页简单的记录，它不仅是审计所需，更是团队知识沉淀：

  • 实验名称：简短描述（如：Redis 缓存失效降级实验）。
  • 稳态假设与实测结果：列出具体指标、阈值及实际观察值。
  • 爆炸半径定义：受影响的范围、隔离手段。
  • 发现的意外现象：是否有监控告警未触发？是否有下游服务出现意料之外的连锁反应？
  • 待办事项：产生的改进任务。

这套流程并不复杂，但能系统性地提升你每一次故障注入的收益。

故障注入实验的价值，不在于你制造了多少漂亮的故障，而在于你通过严密的稳态假设和克制的爆炸半径，发现了多少系统设计中的盲区。始终记住：一次实验的结束，不是测量的停止，而是系统改进的起点。