稳态假设与爆炸半径控制

可视化演示

展示稳态假设的观察假设实验分析验证闭环、爆炸半径按环境分级限制影响范围、以及从小范围到全链路的渐进式实验编排。

稳态假设——给系统先做“健康体检”

在疫苗临床试验中，第一步不是急着给小白鼠扎针，而是先记录每只小白鼠的体温、食欲、活动量。只有知道“正常”长什么样，才能在注射后判断疫苗有没有打破平衡。试想，如果连正常体温区间都不清楚，你怎么能说小白鼠发烧了？这正是混沌工程里“稳态假设”的意义：在注入故障之前，先把系统的健康状态量化成一串可以测量的指标。

混沌工程中的稳态假设，就是实验开始前对系统正常行为的预期。它通常写成一组带阈值的指标，例如“支付接口成功率 ≥ 99.9%”、“下单 P99 延迟 ≤ 800ms”。混沌实验的所有后续工作，都围绕“注入故障后，这些指标是否还在阈值之内”展开。如果还在，说明系统经受住了扰动；如果突破了，说明系统的韧性存在盲区。

稳态假设最常见的量化方式是 SLO（Service Level Objective），即服务应该达到的目标水平。计算方式是把一段时间的成功请求数除以总请求数，再换算成百分比。SLO 不是越高越好，也不是监控告警的一个普通阈值；它是混沌实验的“裁判标准”——提前定好，实验结果才有可比性。

回到疫苗试验的类比：如果小白鼠的体温在注射后始终落在预设的“健康范围”里，我们就认为疫苗没有破坏稳态。同理，一个服务只要在故障注入后仍能满足自己的 SLO，就说明系统的韧性设计是达标的。稳态假设做得好，混沌实验才可信。

指标选取——选对“体温计”

疫苗试验中，研究者测量体温、白细胞和心率，而不是毛色光泽或尾巴长度——因为前几个指标才是“健康”的直接信号。混沌实验也一样，稳态假设的质量取决于指标选取。如果选了一个与用户体验无关的指标，实验结果再漂亮也没有意义。

业界最常用的“体温计”是四大黄金信号：延迟（Latency）、流量（Traffic）、错误（Errors）和饱和度（Saturation）。延迟告诉你请求快不快；流量告诉你系统正在承受多大压力；错误告诉你请求失败比例；饱和度告诉你资源还有多少余量。这四类信号都能从用户体验的角度反映系统是否“活着”。

在黄金信号之外，还必须补充业务指标和用户视角指标。比如电商系统要关注下单成功率、订单金额趋势；内容平台要关注首屏渲染时间。业务指标决定实验的商业意义，黄金信号决定实验的技术可观测性，两者结合才是完整的稳态假设。指标并不是越多越好，选取的原则是可实时获取、可自动计算、与用户价值强相关。

就像疫苗试验中既要看体温也要看免疫应答，混沌实验也不只看一两个指标。选择正确的“体温计”，稳态假设才有判断力；选错了，你可能会像忽略尾巴毛色那样，忽略真正致命的系统问题。

验证方法——用对照组说话

疫苗试验不会只给一只小白鼠打疫苗，然后凭感觉说“它看起来还行”。严谨的做法是把小白鼠随机分成两组：一组注射疫苗，一组注射安慰剂（对照组），然后比较两组的发病率。混沌实验同样需要对照组，否则你无法判断指标变化到底是故障注入引起的，还是正常的业务波动巧合。

验证稳态假设的标准流程是：先做前置测量（记录未注入故障时的基线指标），再注入故障，最后做后置测量（记录注入后的指标）。把两组数据放在一起比较，计算差异。如果差异在允许范围内，我们认为稳态假设成立；如果差异超出预期，则说明系统在故障面前不够稳。

在实际操作中，可以通过时间序列对比和对照组同时进行。时间序列对比观察同一系统在注入前后两个时间窗口的指标变化；对照组则选择一批完全不注入故障的实例或流量，作为天然的参照系。观察窗口不宜太短，否则噪音和毛刺会掩盖真实信号。

正是这种“有对照组、有前后对比”的严谨设计，让混沌实验从一次随机的破坏游戏变成一门可以迭代的科学。就像疫苗试验的结论能拿去向药品监管机构交代，混沌实验的结论也能拿去向团队和领导交代：我们的系统经得起多大风浪，用了什么证据。

爆炸半径——把故障圈在可控范围

疫苗在推广到十万人之前，一定要先从几十只小白鼠开始。不是因为胆小，而是因为每一次实验都有风险和代价。混沌工程把“一次实验最多影响多大范围”定义为爆炸半径。它是故障注入的安全边界，决定了实验出问题时的最大受害者数量。

爆炸半径的度量单位通常是比例或范围，比如 5% 的生产流量、1 个可用区、10 个 Pod、单个用户分组。它不等于实验的“影响力大小”，而是“影响面的边界”。边界以内，故障可以发生；边界以外，一切必须照常。用公式表达，爆炸半径就是受影响节点数占节点总数的比例。

界定爆炸半径不是拍脑袋，要综合考虑系统的冗余度、业务容忍度、恢复速度和团队熟悉度。一个通用建议是从最小单元开始：先单机、再单集群、再单区域，逐步放宽。同时要设定失控保护——一旦当前实验破坏了稳态假设，立刻停止并回滚。这个保护机制是爆炸半径的“安全带”。

在疫苗试验中，小白鼠的数量就是爆炸半径；在微服务系统里，被注入故障的节点数量就是爆炸半径。把半径控制住，你才能放心地去实验——即便实验失败，损失也只是一小撮“小白鼠”，而不是整个业务。

渐进编排——从小白鼠到千万人

疫苗试验分为 I 期、II 期、III 期：I 期只有几十人，重点是安全性；II 期扩展到几百人，评估剂量和免疫反应；III 期再到几千人，确认有效性和统计显著性。混沌实验的编排思路一模一样：不是一步到位把所有故障注入全链路，而是从最小半径开始，通过一道道门槛逐步扩大。

每一步的“门槛”通常由上一阶段的结果决定：当前阶段的稳态假设没有被破坏、观测指标正常、团队完成复盘并签字确认，才允许进入下一个半径更大的阶段。这种门槛机制能把风险拆解成离散的、可决策的小步。如果某一阶段已经破坏了 SLO，就不该继续扩大，而应先回到修复环节。

实践中，阶段划分可以参考“单实例 → 单集群 → 单可用区 → 全链路”的路径，也可以按流量比例 1% → 5% → 10% → 50% 递增。关键在于每阶段必须有明确的进入条件和退出条件。进入条件决定“能不能开始”，退出条件决定“是否继续”。这两个条件都应该写成可被程序判断的规则，而不是依赖人工经验。

渐进编排不是保守，而是科学。疫苗试验的安全性数据正是靠一期期积累起来的；混沌实验对生产环境韧性的信心，也要靠小半径到大半径一步步建立。每一期实验都在为下一期提供证据，当走到全链路时，你的系统已经不是第一次面对故障了。

自动化闭环——自动监测与中止

疫苗试验全程有数据监控系统在记录受试者的副作用——一旦出现严重不良反应，试验会被马上暂停，而不是等人类实验员翻完 Excel 再拍板。混沌工程也必须有同样的自动机制：自动注入故障、自动观测指标、自动判断是否超过 SLO、自动回滚。整个环节构成一个闭环。

自动化闭环的第一步是“自动注入”——通过混沌平台或流水线在指定爆炸半径内释放故障；第二步是“实时观测”——连续采集黄金信号和业务指标；第三步是“智能决策”——当指标触碰 SLO 红线时，不等待人工介入，自动执行回滚或熔断。第四步是“结果沉淀”——把实验数据、结论、改进项写回知识库，供下一次实验参考。

这个闭环的价值在于缩短从“故障发生”到“影响消除”的恢复时间。一次手动的混沌实验可能要几十分钟才能完成注入、观察、回滚，而自动化的闭环可以把恢复时间压缩到分钟甚至秒级。闭环还能产生可复用的实验基线和历史数据，让团队逐步建立系统的“韧性档案”。

如果说爆炸半径决定了实验的“空间边界”，那么自动化闭环就决定了实验的“时间边界”——故障影响多久能结束。疫苗试验里，自动暂停机制保护的是受试者的生命；混沌工程里，自动回滚机制保护的是用户的体验和公司的业务。一个闭环成熟的混沌实验体系，才能真正做到持续、安全地演练。

AI 应用场景

Python 演示

import random  class Service:    """A single target service that can handle requests and inject failures."""     def __init__(self, name, base_err_rate=0.01):        # 服务名与基础错误率, 模拟正常运行时也会有小概率失败        self.name = name        self.base_err_rate = base_err_rate        self.failure_rate = 0.0     def inject_failure(self, rate):        # 注入额外故障比例, 模拟混沌故障对服务的影响        self.failure_rate = rate     def call(self):        # 模拟一次请求, 成功返回 True, 失败返回 False        if random.random() < self.base_err_rate + self.failure_rate:            return False        return True  class ChaosExperiment:    """A minimal chaos experiment scaffold with blast radius control."""     def __init__(self, services, slo=0.95):        # 稳态假设: 整体成功率应不低于 slo        self.services = services        self.slo = slo        self.results = []     def run_trial(self, blast_radius, request_count=2000):        # 在指定爆炸半径内注入故障并统计成功率        affected = random.sample(            self.services, max(1, int(len(self.services) * blast_radius))        )        for svc in affected:            svc.inject_failure(0.05)  # 注入 5% 额外故障        ok = 0        total = 0        for _ in range(request_count):            for svc in affected:                total += 1                if svc.call():                    ok += 1        for svc in affected:            svc.inject_failure(0.0)  # 实验结束立刻还原        return ok / total >= self.slo     def run_progressive(self, radii=(0.02, 0.05, 0.1, 0.2)):        # 从最小半径开始逐步扩大爆炸半径, 任一阶段失败即熔断        for r in radii:            ok = self.run_trial(r)            self.results.append((r, ok))            if not ok:                break        return self.results  if __name__ == "__main__":    services = [Service("svc-%d" % i) for i in range(20)]    exp = ChaosExperiment(services, slo=0.95)    for radius, ok in exp.run_progressive():        print("[radius={:.0f}%] steady-state: {}".format(radius * 100, "PASS" if ok else "FAIL"))

1. affected = random.sample(self.services, max(1, int(len(self.services) * blast_radius)))随机圈定受影响服务集合，把“爆炸半径”从百分比换算成具体的受害实例列表。
2. svc.inject_failure(0.05)对圈内的每个服务注入额外 5% 的故障率，模拟真实世界中的服务抖动。
3. ok / total >= self.slo将整体成功率和预设的稳态阈值比较，这是验证稳态假设是否被破坏的核心判据。
4. for svc in affected: svc.inject_failure(0.0)无论实验成败都立即把故障率归零，这正是“爆炸半径可控”的落地实现。
5. for r in radii: ... if not ok: break按从 2% 到 20% 的半径逐级推进，某个阶段一旦破坏 SLO，就立刻熔断不再扩大。
6. print("[radius={:.0f}%] steady-state: {}".format(...))把每个半径的实验结论输出到终端，供团队复盘和改进下一轮实验。

常见误区

面试题