微软：实验的变化与优先级

一句话

你以为混沌工程的门槛是注入能力——能不能杀进程、断网络、注延迟。这一章把门槛挪了位：注入从来不是瓶颈，选择才是。故障空间随依赖数与失效形态组合爆炸，而实验预算在人力、风险、时间窗三头都是有限的。于是真正的工程问题是实验的变化（variation）与优先级：从一份完整的依赖清单出发，沿失效形态的梯度（挂掉 → 变慢 → 返回错数据）铺开变化，按 概率 × 影响 ÷ 成本 排序，并且不跑答案已知的实验——实验的产出是消除不确定性，不是制造一次事故。

Glossary · 术语表

坐标

全书第 6 章，Part II「原则落地」的第三篇，视角来自微软。它和前两篇是「怎么演」与「演哪场」的分工：Ch4 Slack 给存量系统写剧本、Ch5 Google 把演练放大到公司规模，这一篇退一步问预算该花在哪；往后 Ch7 LinkedIn 管实验的伦理上限，Ch12 用血缘驱动故障注入（LDFI）把本章从人的判断升级成算法。现实里它对着工具已经就位、但实验清单上只有「随机杀实例」一条的团队。

这章要解决什么

先把规模摆出来。一个中等规模的线上服务，一次请求路径上的依赖：显式的十来个（数据库、缓存、鉴权、几个下游 RPC、消息队列、对象存储），隐式的还有一打（DNS、TLS 证书、服务发现、配置与开关下发、时钟、指标后端、镜像仓库）。按二三十个算、每个至少 4 种失效形态，单依赖单形态就上百个候选；允许两个依赖同时出问题是上万；再叠负载、区域、失败比例，继续往上。

而实验预算三头都有限：人力（一个像样的实验要写假设、定指标、备中止方案，Ch4 示范过这有多重）、风险（每次生产注入都可能变成真事故）、时间窗（要挑低峰、要人在回路）。一个认真做的团队一年做得好的实验在几十次量级，不是几千次。

不解决会怎样？三种典型退化：

• 工具驱动的清单。工具会杀实例，清单就是杀实例。杀两百次全绿，而真把你打倒的「下游变慢」一次没摇过。
• 有趣驱动的清单。挑技术上刺激的（时钟回拨、脑裂）。它们确实存在，但在你的系统上概率低两个数量级，花掉的却是同一份预算。
• 答案已知还去摇。明知那个调用没设超时，还注一次延迟去「证明」它会挂——这不是实验，是自己安排的一次事故。

所以这章的问题是：在枚举不完的故障空间里，用什么可解释的规则选出接下来那十个实验？

核心内容，讲透

故障空间组合爆炸，所以目标是排序，不是覆盖

一句数量关系就够：候选实验数 ≈ 依赖数 × 失效形态数 × 其他变化维度。三个因子各自只是十位量级，乘起来就到四五位。这决定了混沌工程不可能像单元测试那样追覆盖率——它天生是抽样，而全部质量取决于抽样规则。

这也解释了为什么注入能力不是瓶颈：手上的工具早已能造出远超你跑得完的实验。稀缺的是判断力。

从依赖清单起步：隐式依赖是最大的漏项

清单从哪来决定了你的上限：从工具能做什么起步，清单长得像工具的功能列表；从依赖起步，它才长得像你的系统。

判据一句话：它坏了你的请求会变慢或失败，它就是依赖。按这条过一遍，通常能捞出一批从没被测过的东西：DNS、TLS 证书过期与吊销检查、服务发现、配置与开关下发、NTP、指标后端（写不进去时线程会不会被阻塞？）、镜像仓库（只在扩容时用到，于是只在你最需要扩容的那一刻失效）。

最值钱的发现藏在这里：被标为「非关键」的依赖。「埋点失败不影响下单」只是一句假设；真注一次常发现它是同步调用、没设超时、还和主链路共用一个线程池。关键性是实验结论，不是设计文档里的声明——「大家都说它不重要」反而是高优先级信号。

失效形态有梯度：「变慢」和「错数据」才是真凶

这是本章最该带走的东西。同一个依赖，按「容错代码接得住的难度」排有四档：

• ① 快速失败：连接被拒、立刻报错。最容易接——熔断、重试、降级基本都是冲它设计的。
• ② 不可用但不报错：请求挂着直到超时。前提是你真设了超时，且值是算过的、不是默认 60 秒。
• ③ 劣化：还活着，只是 p99 从 50ms 变 3s。最阴的一档：没有任何错误码，监控上「可用率 100%」。
• ④ 返回错的或部分的数据：正常 200，内容不对或只有一半。零信号，静默污染下游与缓存。

第③档为什么最危险，可以算出来：上游 200 QPS、下游 p99 50ms，按 并发 ≈ QPS × 延迟 稳态只需约 10 个槽；劣化到 3s 就需要 600 个槽，而连接池只有 50——几秒内池子占满，连不经过这个下游的请求也开始失败。一个「非关键」依赖就这样升级成全站故障，而它从头到尾没返回过一个错误。

所以变化的第一刀该沿这条梯度切：任何一个你已摇过「杀掉」的依赖，都还欠两个实验——注延迟、注错数据。这比再找一个新依赖杀掉便宜得多，收获却大得多。

排序规则：期望损失除以成本，再减去答案已知的

优先级 = 概率 × 影响 ÷ 成本。三项都要落到能说清的输入：

• 概率最硬的输入是事故历史：发生过两次的那类故障，概率是实测的不是估的。其次是依赖自身的 SLA 与历史可用性，再次是变更频率——刚改过的东西更可能坏。
• 影响按流量和钱算，不按「组件重不重要」算：这条路径多少 QPS、涉不涉及支付、失败后用户是重试还是流失。
• 成本含设计时间、跨团队协调与爆炸半径管理。同等收益下优先便宜的：先在单实例或小比例流量上做，过了再放大。

排序之后还有两条过滤规则，比排序本身更省预算：

一、跳过答案已知的。确信它会失败（没超时、没降级）→ 直接提单去修，别注入；确信它会通过而且验过 → 也不必再占一个窗口。实验的产出是消除不确定性，所以该跑的恰好是「你有信心会过、却从没验过」的那一批——惊喜全藏在那里。

二、一次注入收三样东西。同一次实验顺带能验：系统行为、告警是否触发、人与预案跟不跟得上。挂上监控验证的边际成本近乎为零，却最常被忘。这也抬高了某些「我有信心」的实验的优先级——摇它不为看系统，是为看告警会不会响。

关键权衡与选型

第一张表是梯度的落地：同一个依赖，四种摇法各验到什么、为什么常被漏。

误区是把预算全花在第①档。它恰恰是唯一一档你大概率已经接住了的。

第二张表按本章的尺子排了一遍，给出「先做哪几个」的样子。

落到具体选择：

• 刚起步、只有一个杀实例的工具：别急着扩工具。先用一个下午把依赖清单列全（含隐式），再给排前三的依赖各加一个延迟注入——延迟通常是最便宜也最高产的那一刀。
• 跑了上百次实验、全绿：全绿不是成绩，是抽样偏差的证据。换维度铺变化——同一批依赖换到第③④档，或把失败比例从 100% 调到 30%（部分失败常比全挂更难处理）。
• 预算极紧、一年只做几次：全押「复现上次事故那一类」——概率实测、影响已知、假设最清楚，还顺带是一次回归。

为什么重要 / 落到真实系统

三句能直接改掉评审结论的话。一：混沌工程的质量不等于注入能力，等于抽样规则的质量。二：「被说成非关键」是高优先级信号。三：已摇过「杀掉」的依赖，都还欠「注延迟」和「注错数据」。

面试被问「你们怎么做混沌工程」，答「每周随机杀实例」是工具层；答「先列全依赖清单（含 DNS、证书、配置下发），按概率 × 影响排序，优先给被认为非关键的依赖注延迟，并用同一次注入验证告警」是另一个层级——它显示你知道瓶颈在选择而不在注入。

易错点与争议

• 把注入能力当成熟度。能注的形态再多，清单选错了照样只验证已知。
• 全绿就庆祝。上百次全通过，更可能说明抽样偏向了你已有信心的那一侧，而不是系统真的硬。
• 「非关键」当低优先级。正好相反：那是未经验证的假设，而假设错了的代价是整条链路。
• 概率全凭感觉。事故历史是免费又实测的先验，但很多团队的复盘报告从不回流到实验清单。
• 只摇 100% 失败。部分失败（30% 请求出错、一个分片慢）常比全挂更难处理，因为熔断器都够不到阈值。
• 争议：排序本身会把尾部排掉。按期望损失排序天然冷落低概率高损失的那一类；真要防它，得另立一条「不管概率多低也要验」的清单（Ch17 的信息物理系统就是这种）。
• 时代局限与后续。本章仍是人在排序。后来的方向是用系统自身的数据算出该注哪里——Ch12 的血缘驱动故障注入（LDFI）、Ch16 的持续验证都在替换这一步的人工判断。另一方面，今天大量依赖落在 SaaS 上，你既改不动也注不进去，这让排序比写作时更重要：能摇的本就只是一部分。

要点