想象你是一栋 30 层写字楼的消防负责人。你绝不会等到大楼真正着火才第一次拉响警报，而是定期在安全的楼层放烟饼、鸣响火警，让所有人演练逃生路线。今天你突然意识到，楼里的备用发电机十年没启动过，应急照明坏了三年也没人发现——这些脆弱点，只有靠一次次“假火灾”才能暴露出来。混沌工程（Chaos Engineering）就是给软件系统做同样的“消防演练”，只不过它放的“烟”不是烟雾弹，而是网络延迟、GPU 掉线、依赖服务罢工这些真实故障。故障注入是放烟饼的那只手，爆炸半径控制是演练前划定的安全隔离区，自动化平台则是把演练变成每月固定的安全制度。读完这篇文章，你就能理解如何系统化地给系统“找茬”，让它在大规模的 AI 推理和训练场景中真正“火烧不垮”。

岗位关联

对 AI 从业者：大模型推理与分布式训练系统动辄依赖数百个 GPU 和微服务，一次隐性脆弱点就可能引发连锁故障。掌握混沌工程与故障注入，帮你系统化提前拦截故障，全面提升 AI 系统的韧性与你的工程竞争力。

目录
  1. 可视化演示
  2. 混沌工程概述
  3. 故障注入设计
  4. 网络故障模拟
  5. GPU故障注入
  6. 依赖降级测试
  7. 爆炸半径控制
  8. 自动化平台韧性
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

展示混沌工程三大核心：故障注入实验流程（设计→假设→注入→系统响应→监控→反馈循环）、网络故障模拟（延迟/丢包/带宽限制/DNS失败四种故障类型+目标推理服务影响）、爆炸半径控制（同心圆影响范围+隔离/时间窗口/自动终止安全机制+受影响服务高亮）。

本节配有交互动效（进入视口后自动加载，约 3KB）。

故障注入实验流程 实验设计→假设构建→故障注入→系统响应监控→结果分析→反馈改进 故障类型：网络延迟/丢包、GPU OOM、依赖服务降级 通过/失败结果驱动系统韧性改进，形成持续验证闭环 Chaos = Hypothesis + Inject + Monitor + Analyze + Improve 混沌工程主动发现系统脆弱点。

混沌工程概述

消防演练的经验告诉我们：平时不放烟，着火就抓瞎。你不会等到真火灾才第一次测试喷淋系统是否出水、消防通道是否被杂物堵死。混沌工程就是把这个朴素道理搬到软件系统中——刻意制造可控的故障，观察系统在压力下如何反应，从而在事故发生前把脆弱点一个个揪出来。

2011 年 Netflix 发布了 Chaos Monkey 工具，它会随机“杀死”生产环境中的实例，迫使系统学会从容面对实例丢失。这套方法论后来演化为混沌工程：一门“在系统上进行实验、以建立对系统承受动荡冲击能力的信心”的学科。它不是在制造麻烦，而是在用科学的方式提前排雷。

要衡量这套方法的价值，我们需要一把“尺子”。可用性是系统可靠性最经典的度量：

大楼每年做两次消防演练，不是为了好玩，而是为了确保真起火时逃生时间最短。混沌工程同样在反复演练中，把系统的 MTTR 从“两个小时手忙脚乱”压缩到“三十秒自动恢复”。这就是它最大的价值。

A=MTBFMTBF+MTTR\displaystyle A = \frac{MTBF}{MTBF + MTTR}
可用性 A 表示系统正常服务时间的比例，MTBF 越长（不容易坏）、MTTR 越短（修得快），系统就越接近“永不断电”。
  1. MTBF 的含义MTBF 全称 Mean Time Between Failures，指两次故障之间的平均间隔时间。它衡量的是“系统健康能持续多久”，单位通常是小时。计算方法是统计周期内的总运行时间除以故障次数。
    MTBF=TtotalNfailures\displaystyle MTBF = \frac{T_{\text{total}}}{N_{\text{failures}}}
  2. MTTR 的含义MTTR 全称 Mean Time To Repair，指一次故障从发生到完全恢复的平均耗时。它衡量的是“团队救火的速度”。
    MTTR=TrepairNfailures\displaystyle MTTR = \frac{T_{\text{repair}}}{N_{\text{failures}}}
  3. 可用性 A 的合成把 MTBF 和 MTTR 放在同一个式中，A 越接近 1 表示系统越可靠。混沌工程的两大抓手正好对应这两项：故障注入用于发现导致 MTBF 缩短的隐患，韧性验证通过反复演练缩短 MTTR。
    A=MTBFMTBF+MTTR\displaystyle A = \frac{MTBF}{MTBF + MTTR}

故障注入设计

消防演练前，消防队长会做一件事：写剧本。在几楼放烟饼？放多少？重点观察哪条通道？预期多少人能在三分钟内撤离？没有剧本的演练只会变成一场混乱。混沌实验同样需要精心设计，而不只是“随手把服务关掉”。

一个标准的混沌实验通常包含六步：定义稳态指标、提出假设、设计最小化实验、注入故障、观测系统行为、复盘改进。其中“定义稳态”是第一步——你要先知道系统正常时 CPU 使用率、P99 延迟、错误率是多少，才能判断故障注入后是否偏离了基线。这就像消防演练要先记录“平时从这里跑到出口需要多久”。

为了让实验足够安全，业内普遍采用“金丝雀发布”的思路：只对一小部分实例注入故障。金丝雀实例数量可以这样计算：

剧本写得越精准，演练就越安全越有效。一个好的混沌实验设计，就是让你的“消防演习”既逼真又可控——先在小范围放烟，观察清楚了再决定下一步。

Ncanary=max⁡(1,⌊Ntotal×r⌋)\displaystyle N_{\text{canary}} = \max\left(1, \left\lfloor N_{\text{total}} \times r \right\rfloor\right)
金丝雀数量 = 总实例数乘以一个很小的比例 r（通常 1%～10%），至少保留 1 个实例参与实验，确保既测得出问题又不会伤筋动骨。
  1. 总实例数 N_total你的服务一共部署了多少个实例（进程/容器）。它决定了事故的理论影响范围，分母越大，单个金丝雀的绝对影响越小。
    Ntotal=集群中全部实例数量\displaystyle N_{\text{total}} = \text{集群中全部实例数量}
  2. 比例 r 的选取r 是参与故障注入的实例占比，经验范围是 1%～10%。r 太小学不到东西，r 太大风险失控，所以用 floor 向下取整来保守计算。
    Ncanary=⌊Ntotal×r⌋\displaystyle N_{\text{canary}} = \left\lfloor N_{\text{total}} \times r \right\rfloor
  3. max 下限保护若 N_total × r 不足 1，max(1, ……) 让实验至少有一个金丝雀实例，否则实验就没有意义。
    Ncanary=max⁡(1,⌊Ntotal×r⌋)\displaystyle N_{\text{canary}} = \max\left(1, \left\lfloor N_{\text{total}} \times r \right\rfloor\right)

网络故障模拟

消防演练里有个魔鬼科目：故意封死一条逃生通道。当人们发现平时习惯走的那条路被堵死，才会开始留意备用出口在哪里。网络故障就是分布式系统的“逃生通道封锁”——延迟一高、丢包一多，服务就必须启用备选方案。

网络层的故障注入主要有三种：延迟注入、丢包注入、带宽限制。以延迟为例，我们不能简单地把所有请求都加上一个固定延迟，因为真实网络的延迟是波动的。通常用正态分布来模拟这种自然抖动：

至于丢包注入，本质是“以概率 p 丢弃一个请求”，模拟的是逃生通道随机关闭几秒的场景。AI 推理服务遇到网络抖动时会重试，但大量重试会造成“重试风暴”。所以演练网络故障，就是逼着系统学会优雅地超时、重试、降级，而不是在重试循环中把自己压垮。

P(x)=1σ2πe−(x−μ)22σ2\displaystyle P(x) = \frac{1}{\sigma \sqrt{2\pi}} e^{-\frac{(x-\mu)^2}{2\sigma^2}}
这条钟形曲线描述了延迟值的分布规律：绝大多数请求的延迟落在均值 μ 附近，σ 越大，延迟波动越剧烈，系统面对的“路况”越不稳定。
  1. 均值 μ（目标延迟）μ 是我们希望注入的平均延迟值。比如把每次请求延迟设置为 500ms，μ 就取 500，它是抖动曲线的“中心点”。
    μ=目标延迟中心值\displaystyle \mu = \text{目标延迟中心值}
  2. 标准差 σ（抖动强度）σ 描述延迟偏离平均值的程度。σ 越大，延迟忽快忽慢越明显，越能模拟弱网环境的真实路况。
    σ=抖动标准差\displaystyle \sigma = \text{抖动标准差}
  3. 概率密度 P(x)P(x) 表示延迟恰好为 x 的概率密度。利用它生成随机延迟，可以让每次请求的延迟在 μ 附近自然浮动，而不是机械地卡住所有请求。
    P(x)=1σ2πe−(x−μ)22σ2\displaystyle P(x) = \frac{1}{\sigma \sqrt{2\pi}} e^{-\frac{(x-\mu)^2}{2\sigma^2}}

GPU故障注入

GPU 是 AI 系统的“主发动机”。消防演练中有一项必修课是“关掉主电源，看备用发电机能否自动接管”。GPU 故障注入做的就是让主发动机在半路熄火，验证系统能不能自己换挡。

GPU 的故障率通常高于普通 CPU：显存比特翻转、ECC 校验失败、驱动无响应、NVLink 断连，任何一种都足以让训练任务中断。故障注入的手段分几个层级：在驱动层可以用 nvidia-smi 模拟 Xid 错误；在框架层可以制造 CUDA error；在容器编排层可以直接 kill 掉 GPU 进程。最贴近业务的注入，是在分布式训练的某个 rank 节点上“拔掉显卡”，验证训练框架能否从最近的 checkpoint 恢复。

要衡量故障注入是否覆盖到位，可以用一个简单的检测率公式：

“备用发电机十年没启动过”是消防大忌，同样，“GPU 故障恢复逻辑从没跑过”也是 AI 系统的大忌。通过在演练中反复让 GPU“死机”，团队才能真正相信 checkpoint 恢复机制不是一纸空文。

Rdetect=CdetectCtotal\displaystyle R_{\text{detect}} = \frac{C_{\text{detect}}}{C_{\text{total}}}
故障检测率 = 被系统正确捕获的故障数 ÷ 注入的总故障数。这个指标告诉你的监控和容错机制到底接得住多少意外。
  1. 注入总数 C_total本轮混沌实验中注入的 GPU 故障次数。比如设定 100 次显存错误注入，它就是分母。
    Ctotal=全部注入的故障事件数\displaystyle C_{\text{total}} = \text{全部注入的故障事件数}
  2. 捕获数 C_detect系统监控或容错逻辑正确感知到的故障次数。如果框架能自动触发 checkpoint 恢复，就算捕获一次。
    Cdetect=被监控或容错机制识别的故障数\displaystyle C_{\text{detect}} = \text{被监控或容错机制识别的故障数}
  3. 检测率 R_detectR_detect 越接近 1，说明你的监控和容错越完善。如果只有 40%，说明 60% 的 GPU 故障会成为“隐形炸弹”。
    Rdetect=CdetectCtotal\displaystyle R_{\text{detect}} = \frac{C_{\text{detect}}}{C_{\text{total}}}

依赖降级测试

消防演练中最怕的不是火，而是人群在慌乱中互相踩踏。系统中也有类似的“踩踏”——依赖服务一旦抖动，整个调用链路像多米诺骨牌一样连环倒下。所以要专门演练一个科目：让某个“队友”掉线，看系统还能不能独立完成核心任务。

现代 AI 服务几乎不可能孤立运行：推理网关要查 Redis 缓存，训练任务要读写对象存储，业务逻辑要调认证服务。只要其中一个依赖响应变慢或返回 500，错误的传播就会引发级联失败。比如缓存服务超时 2 秒，网关等待 2 秒后线程池被占满，后续所有请求排队，最终整条链路雪崩。

可以这样量化级联风险：如果有 n 个依赖，第 i 个依赖出问题的概率是 p_i，那么至少一个依赖出问题的概率是：

应对级联失败，最常用的机制是熔断器：当依赖错误率超过阈值，熔断器打开，后续请求快速失败而不等待；经过冷却时间后进入半开状态，放少量试探流量验证依赖是否恢复。降级测试的目标，就是确保每个依赖都有对应的“应急预案”——能降级就降级，不能降级就快速失败，绝不无休止地死等。

Pcascade=1−∏i=1n(1−pi)\displaystyle P_{\text{cascade}} = 1 - \prod_{i=1}^{n} (1 - p_i)
这个公式揭示了一个反直觉的事实：即使每个依赖都很稳定（p_i = 1%），只要依赖数量一多，整体出事的概率就会迅速升高。队友越多，越要演练缺队友。
  1. 单个依赖的稳定概率第 i 个依赖正常的概率是 1 - p_i。如果 p_i = 0.01，那它 99% 的时间是健康的。
    1−pi=第 i 个依赖不发生故障的概率\displaystyle 1 - p_i = \text{第 } i \text{ 个依赖不发生故障的概率}
  2. 全部依赖都正常的概率n 个依赖同时正常的概率是各自概率的乘积，用连乘符号 ∏ 表示。
    ∏i=1n(1−pi)=所有依赖都健康的概率\displaystyle \prod_{i=1}^{n} (1 - p_i) = \text{所有依赖都健康的概率}
  3. 级联失败概率用 1 减去“全部健康”的概率，就得到“至少一个依赖出问题”的概率。依赖越多，这个值越大，系统越脆弱。
    Pcascade=1−∏i=1n(1−pi)\displaystyle P_{\text{cascade}} = 1 - \prod_{i=1}^{n} (1 - p_i)

爆炸半径控制

消防演练最怕什么？本来只是在一层楼放烟饼，结果整栋楼的喷淋全部启动、电梯停运、几百人涌到楼梯间——演练事故比真火灾还吓人。所以演练有一条铁律：把影响控制在一个可接受的范围内。混沌工程里对应的概念就是爆炸半径（Blast Radius）。

控制爆炸半径的手段有很多：只对 1% 的请求注入故障、只挑选一台实例、单独划一个测试租户、避开业务高峰时段、设置自动回滚阈值。一句话概括，就是“小步快跑，随时刹车”。注入带来的影响范围可以用这个公式粗估：

控制爆炸半径不是“越胆小越好”。半径太小，实验不痛不痒，测不出真实问题；半径太大，安全没保障。经验做法是从 1% 开始，逐步加压，同时让自动回滚机制随时待命——这就像消防演练先在一个空楼层放烟，确认可控后，再逐步增加规模。

I=Ntotal×p×s\displaystyle I = N_{\text{total}} \times p \times s
影响实例数 = 集群总实例数 × 参与注入的流量比例 × 故障严重度。这个式子提醒你，三个乘数中只要把任何一个调小，爆炸半径就会显著收缩。
  1. 总实例数 N_total集群中承担业务流量的全部实例数量。它是影响范围的“天花板”，因为无论如何故障都不可能波及不存在的实例。
    Ntotal=集群内全部实例数量\displaystyle N_{\text{total}} = \text{集群内全部实例数量}
  2. 参与比例 p有多少比例的流量会被引导到故障场景中。只让 5% 的请求进入故障环境，就等于把事故影响打了 95% 的折扣。
    p=故障注入流量占总流量的比例\displaystyle p = \text{故障注入流量占总流量的比例}
  3. 故障严重度 s单个实例故障后对整体服务的影响程度，取值 0～1。例如实例宕机但负载均衡可以摘除它，s 就很低；而故障导致数据写坏，s 就接近 1。
    I=Ntotal×p×s\displaystyle I = N_{\text{total}} \times p \times s

自动化平台韧性

消防演练一年做一次靠人组织没问题，但如果每个月、每个新员工入职都要做一次呢？靠人肉安排迟早会漏。成熟的消防管理会把演练排进日历、固定流程、自动触发。混沌工程的最终归宿也一样：把实验沉淀成平台，让韧性验证成为日常习惯。

混沌工程平台（如 Chaos Mesh、LitmusChaos）通常由三大模块构成：实验编排（定义故障场景、调度执行时间）、指标观测（采集注入前后的监控数据，自动对比基线）、安全回滚（当错误率超过阈值时自动终止实验）。有了平台，每次代码发布后都能自动跑一组基础混沌实验，做到“上线即演练”。

持续演练的效果需要一把尺子来衡量，这里我们定义一个简单的韧性指数：

从“手动放烟饼”到“智能消防系统”，自动化平台让混沌实验不再是每年一次的惊悚大片，而成了每周一次的例行巡检。系统在这个过程中变得越来越耐造，团队也越来约有底气——这，才是韧性工程真正想要的。

M=MTBFafterMTBFbefore\displaystyle M = \frac{MTBF_{\text{after}}}{MTBF_{\text{before}}}
韧性指数 M 是实施混沌工程后的平均无故障时间与实施前的比值。M 大于 1，说明系统确实变皮实了；小于 1，说明越演越糟，需要复盘实验设计。
  1. 基线 MTBF_before引入混沌工程前，系统在一段时间内的平均无故障时间。它是你的起跑线。
    MTBFbefore=改进前的平均无故障时间\displaystyle MTBF_{\text{before}} = \text{改进前的平均无故障时间}
  2. 对比 MTBF_after持续演练并修复若干问题后，系统在同一统计口径下的平均无故障时间。
    MTBFafter=改进后的平均无故障时间\displaystyle MTBF_{\text{after}} = \text{改进后的平均无故障时间}
  3. 韧性指数 MM 就是改进前后的对比。当 M = 2 时，意味着系统平均能“扛”的时间翻了一倍。
    M=MTBFafterMTBFbefore\displaystyle M = \frac{MTBF_{\text{after}}}{MTBF_{\text{before}}}

AI 应用场景

AI推理服务稳定性验证

阶段：模型部署与在线推理

解决的问题：大语言模型推理服务依赖 GPU 和多个微服务，传统做法是等线上真的出现“显存泄漏导致 OOM”才去排查，被动且代价高。混沌工程用故障注入的方式，提前制造 GPU 掉线和延迟抖动，观察推理网关能否快速摘除故障节点、自动扩容。

具体案例：某 LLaMA 推理集群在日常运维中发现 GPU ECC 错误率升高，但服务没有明显异常。SRE 团队用显存错误注入工具在灰度实例上模拟 Xid 错误，结果发现监控告警延迟高达 5 分钟——远超自动重启的 30 秒间隔。修复告警阈值后，再次演练，故障节点在 12 秒内被自动替换，推理成功率保持在 99.9%。

分布式训练容错演练

阶段：分布式模型训练

解决的问题：千卡级分布式训练中网络抖动几乎不可避免，而传统容错测试只能靠“碰运气”。通过混沌实验主动注入节点延迟和丢包，可在训练上线前验证 elastic training 的 checkpoint 恢复能力，避免训练到一半因一个 rank 掉线而全军覆没。

具体案例：某团队训练 70B 参数模型时，在训练中期对 5% 的通信流量注入 800ms 延迟。结果显示 AllReduce 通信时间从 2 秒膨胀到 15 秒，触发心跳超时。训练框架自动回滚到最近 checkpoint 并剔除故障节点，整个过程只损失 3 分钟。对比未演练前的预期损失，演练帮团队省下了数万美元的算力成本。

SRE韧性平台中的持续验证

阶段：服务上线与版本迭代

解决的问题：每次新版本上线都可能导致隐藏的脆弱点，传统人工测试无法覆盖所有故障场景。将混沌实验编排进 CI/CD 流水线，在发布后自动执行一组基础故障注入，可以即时发现“新版把超时时间改短导致熔断误触发”这类回归问题。

具体案例：某公司搭建了内部混沌平台，每次发布会自动在 1% 流量上注入依赖超时故障。一次发布后，实验发现新的 Redis 客户端把重试次数从 2 次改为 5 次，导致故障峰值时线程池被打满。平台自动回滚并定位原因，避免了潜在的雪崩事故。

Python 演示

python52 行
import randomimport time  class FaultInjector:    """极简混沌工程故障注入器，演示延迟/丢包/GPU故障/爆炸半径控制。"""     def __init__(self, service, total_instances=20):        self.service = service        self.total_instances = total_instances        self.gc_count = 0        self.circuit_open = False     def _report(self, event, detail):        msg = "[%s] %s: %s" % (time.strftime("%H:%M:%S"), event, detail)        print(msg)     def inject_latency(self, target_ms=500, jitter_ms=50):        self.gc_count += 1        delay_ms = max(0, target_ms + random.gauss(0, jitter_ms))        time.sleep(delay_ms / 1000)        self._report("LATENCY", "injected delay %.0f ms" % delay_ms)     def inject_packet_loss(self, rate=0.1):        if random.random() < rate:            self._report("LOSS", "request dropped by rate %.1f" % rate)            return "request lost"        return self.service     def inject_gpu_fault(self, iter_index, fail_at=100):        if iter_index == fail_at:            self._report("GPU", "stuck, trigger checkpoint recovery")            raise RuntimeError("GPU stopped responding")        return self.service     def blast_radius(self, ratio):        n = max(1, int(self.total_instances * ratio))        self._report("BLAST", "target %d/%d instances" % (n, self.total_instances))        return n  if __name__ == "__main__":    fx = FaultInjector("translation-api", total_instances=50)    fx.blast_radius(0.05)    fx.inject_latency(target_ms=300, jitter_ms=20)    resp = fx.inject_packet_loss(rate=0.1)    print("payload:", resp)    try:        model_train_iter = 100        fx.inject_gpu_fault(model_train_iter, fail_at=100)    except RuntimeError as err:        print("recover from checkpoint:", err)
目的：用 50 行代码演示混沌故障注入器的四个核心动作——爆炸半径计算、延迟抖动注入、丢包注入和 GPU 故障触发，帮助理解混沌工程的基本实现思路。
  1. delay_ms = max(0, target_ms + random.gauss(0, jitter_ms))用正态分布生成带抖动的延迟值，模拟真实网络波动，而不是机械地加固定延迟。
  2. if random.random() < rate:按概率随机丢弃请求，这就是丢包注入的本质：让系统时不时体验“请求石沉大海”。
  3. raise RuntimeError("GPU stopped responding")在指定迭代号制造 GPU 掉线异常，用于验证训练框架的 checkpoint 恢复路径。
  4. n = max(1, int(self.total_instances * ratio))计算爆炸半径内的目标实例数，并保证至少注入 1 个实例；ratio 越小越安全。
  5. self.gc_count += 1每次注入都记录一次，便于统计本轮混沌实验的注入总次数。

常见误区

误区“混沌工程不就是把服务随便搞挂看还能不能用吗？我直接 kill 几个进程不就完了，不需要什么设计。”

正解混沌工程的核心是“科学实验”，必须先定义稳态指标、提出假设（比如“单实例故障不影响 P99 延迟”）、再最小化注入、最后对比观测。没有假设的破坏只是单纯的作死，不是演练。消防演练要写剧本、放烟饼、控制范围，绝不会为了“看看反应”就真放一把火。

为何常见：Netflix 的 Chaos Monkey 名字太有迷惑性，让人误以为核心是“捣乱”，忽略了它背后严谨的自动化验证和监控体系。

误区“测试环境都演练过了，生产环境绝对不能碰，万一出了问题谁负责？”

正解测试环境缺少真实流量、真实依赖和真实数据规模，演练不出真正的脆弱点。正确的做法是先在小规模的 staging 环境反复验证实验脚本，再以 1%～5% 的流量小步在生产环境执行，同时配好自动回滚。就像消防演练一样，必须到真正的楼层里做才有意义，但要严格控制范围。

为何常见：人对生产环境有天然的恐惧，容易把“受控的实验”和“盲目的破坏”混为一谈，从而过度保守。

误区“故障注入执行完了，看到系统没挂，任务就算完成了。”

正解故障注入只是手段，真正的价值在于“观测与改进”。注入前后的指标对比、发现的脆弱点记录、后续的修复跟进，这些才是实验的产出。如果只是放烟饼不看逃生情况，那这演练没有任何意义。平台让注入变得简单，恰恰会让没经验的人低估分析和改进的难度。

为何常见：混沌工程平台把故障注入做成了“一键执行”的按钮，容易让人以为跑通流程就等于完成了韧性建设。

误区“为了绝对安全，每次只影响一台实例、持续 1 秒就恢复，这样永远不会翻车。”

正解爆炸半径过小，实验就失去了发现问题的能力——样本量不足、压力不够，脆弱点根本不会被触发。正确做法是在安全与有效之间找平衡：1%～10% 的流量比例、足够的持续时间、清晰的回滚阈值，既安全又能暴露真问题。就像消防演练不能在空无一人的房间放一小片烟，那确实安全，但什么都练不出来。

为何常见：对事故的恐惧让人自然滑向过度保守，却忘了混沌工程的初衷是“演练出真问题”，而不是“证明自己没惹麻烦”。

面试题

Q1. 混沌工程的核心理念是什么？

单选题 · easy

  • A.随机破坏系统以检验承受力
  • B.用科学实验验证系统假设← 正确答案
  • C.定期重启全部服务防范故障
  • D.完全模拟生产环境所有故障

答案：B。混沌工程是一套科学实验方法：先定义稳态、提出假设、注入故障、观测验证。A 错在“随机”，C 是运维手段不是实验方法，D 追求“全部”违背了最小化原则。

Q2. 一次混沌故障注入实验的第一步应该做什么？

单选题 · easy

  • A.注入最大规模的故障
  • B.定义系统的稳态指标← 正确答案
  • C.通知所有下游用户
  • D.临时关闭监控告警

答案：B。没有稳态基线就无法判断故障注入是否偏离预期。定义稳态指标（P99 延迟、错误率等）是实验设计的起点。A 违背最小化原则，D 自废武功，C 不是第一步。

Q3. 金丝雀故障注入的实例比例通常控制在多少？

单选题 · mid

  • A.50%到80%的流量
  • B.1%到10%的实例← 正确答案
  • C.一次注入全部实例
  • D.30%到50%的链路

答案：B。金丝雀比例取 1%～10% 是最佳实践：足够小以保证安全，足够大以暴露问题。规模过大会放大爆炸半径，过小则测不出脆弱点。

Q4. 根据级联失败概率公式 P = 1 - ∏(1-pᵢ)，当依赖数量增加时会发生什么？

单选题 · mid

  • A.整体故障概率越来越低
  • B.整体故障概率基本不变
  • C.整体脆弱性反而持续升高← 正确答案
  • D.每个依赖会变得更加稳定

答案：C。每个依赖都正常时系统才正常，因此依赖数量越多，乘积部分越小，1 减去的越少，级联失败概率越大。这说明微服务化后依赖越多，越需要做降级演练。

Q5. 用正态分布模拟网络延迟时，σ（标准差）参数代表什么？

单选题 · mid

  • A.目标延迟的均值
  • B.延迟抖动的剧烈程度← 正确答案
  • C.请求的丢包概率
  • D.网络带宽的上限值

答案：B。σ 衡量延迟值偏离均值的程度，σ 越大延迟波动越明显，可以模拟弱网环境。μ 才是目标延迟均值，丢包用概率 p，带宽是另一个维度。

Q6. 下列哪些是控制爆炸半径的常见手段？

多选题 · mid

  • A.限制故障注入的流量比例← 正确答案
  • B.限制受影响的实例数量← 正确答案
  • C.使用独立租户进行隔离← 正确答案
  • D.关闭所有监控和告警

答案：ABC。流量比例、实例数量、租户隔离都是标准的爆炸半径控制手段。关闭监控会让人看不到影响，反而放大了风险，是错误操作。

Q7. 在 GPU 故障注入中，模拟 Xid 错误属于哪个层级的注入方式？

单选题 · hard

  • A.业务代码层写死 Bug
  • B.驱动或系统层级注入← 正确答案
  • C.物理拔除所有显卡
  • D.等待自然发生的故障

答案：B。Xid 错误是 NVIDIA 驱动报告的 GPU 运行错误，通过驱动级注入可以最真实地模拟显存或执行单元故障。A 只影响单次计算，C 影响面过大，D 不是主动注入。

Q8. 依赖服务降级测试通常需要覆盖哪些故障场景？

多选题 · hard

  • A.依赖响应超时← 正确答案
  • B.依赖返回 500 错误← 正确答案
  • C.依赖完全无响应← 正确答案
  • D.依赖性能大幅提升

答案：ABC。超时、错误码和无响应是依赖故障的三种典型表现，分别对应熔断器、降级开关和快速失败策略。性能提升不是故障，不需要演练。

Q9. 熔断器处于“半开”状态时，应该做什么？

单选题 · extreme

  • A.拒绝所有经过的请求
  • B.放少量试探流量验证恢复← 正确答案
  • C.永久关闭依赖调用入口
  • D.直接返回缓存数据即可

答案：B。半开状态的目的是做“健康检查”：放一小部分请求真实地调用依赖，观察成功率和延迟。如果成功则关闭熔断器恢复正常流量；失败则重新打开。A 是全开状态的行为，C 和 D 是降级手段而非熔断状态机行为。

Q10. 混沌工程自动化平台通常必备哪些能力？

多选题 · easy

  • A.实验编排与调度← 正确答案
  • B.指标采集与对比← 正确答案
  • C.安全网与自动回滚← 正确答案
  • D.自动修复全部源码缺陷

答案：ABC。编排调度让实验可重复执行，指标对比让结果可量化，安全网和回滚保证实验可控。D 属于自动编程范畴，不是混沌平台的责任。