Chaos Engineering 第 12 章 · 实验选择问题

Chaos Engineering: System Resiliency in Practice · Ch 12 · The Experiment Selection Problem (and a Solution) · 2020

这一章讲什么？

你刷视频时，背后有上百个小程序在接力干活：一个查你是谁，一个挑推荐，一个找视频文件……混沌工程就是故意弄坏其中一些，看整体还撑不撑得住。

可问题来了：弄坏哪几个？坏一个的选法有一百种，同时坏两个就有将近五千种，坏三个是十几万种。一次只能试一种，挑错了就白试。这一章专门回答「该先试哪个」。

先说个怪事

想知道一座桥哪里最脆弱，直觉是盯着它出事的样子看。这一章反过来说：先认真看它平时是怎么好好站着的。

弄清楚「这次播放能成功，是靠了哪几根柱子」，你就知道：只踢那些没在扛重的柱子，什么也学不到；要踢，就踢正在扛重、而且没人替补的那几根。

旧世界为什么难

乱踢。像让一只猴子在机房里随手拔插头。简单、没偏见，可组合太多了，真正要命的「两根同时断」可能一辈子碰不上。
请老师傅指。经验丰富的工程师一眼看出「这两个一起坏最危险」。很准，但老师傅就那么几个，没法批量复制，而且老师傅心里的系统图本身也可能是错的。

核心机制直觉：顺着「功劳簿」找要害

每次请求成功，都让系统记一本「功劳簿」：这次是谁帮了忙、谁又是谁的备胎。

翻功劳簿，就知道「要让这次失败，最少得同时弄坏哪几个」——比如主力和它的备胎一起坏。
只试这几种组合，其余成千上万种直接跳过。
试了之后，要么真坏了——找到漏洞；要么居然还成功——说明还有一个你不知道的备胎，把它记进功劳簿，再算下一轮。

像侦探排查不在场证明：先搞清楚每个人「是怎么做到的」，再去针对性地拆。

带来了什么 / 该怎么选

好处是试的次数从「天文数字」降到「一张短清单」，而且每次试都有理由，还能顺便把老师傅脑子里的直觉变成机器能算的东西。

一句诚实的代价：前提是系统得能把「谁帮了忙」记清楚，记不全的地方，这套方法也会看漏。

一句话记住

别乱踢，也别只靠老师傅：先看系统怎么成功的，再专挑能让它失败的最小组合去试——每试一次，要么抓到漏洞，要么发现一个新备胎。

想看组合爆炸怎么算、血缘图和求解循环长什么样、在 Netflix 怎么落地？ → 切到精读版

一句话

你以为找漏洞要盯着失败看，其实该注入什么故障，答案藏在成功的请求里：把一次成功的「凭什么成功」记成血缘图，就能算出最少要打掉哪几个支撑才可能让它失败——只试这些组合，把无穷的故障空间缩成一张短清单。

Glossary · 术语表

故障注入（fault injection）：故意制造故障（杀进程、丢消息、让依赖超时），观察系统反应。
故障空间（fault space）：所有可能注入的故障及其组合构成的集合。
微服务（microservice）：把一个应用拆成许多独立部署的小服务，彼此通过网络调用。
降级 / 回退（fallback）：依赖失败时改走的备用路径，如返回缓存或默认值。
冗余（redundancy）：同一结果有不止一条路径能得到，坏一条还有别的。
分布式追踪（distributed tracing）：给每个请求打上 ID，记录它经过的所有服务调用，拼成一棵调用树。
可观测性（observability）：从系统输出（日志、指标、追踪）推断其内部在发生什么的能力。
SAT 求解器（SAT solver）：给一个由「与 / 或 / 非」组成的逻辑式，自动找出让它成立的变量取值；工业级实现能处理百万变量。

坐标

全书第 12 章，Part III「人的因素」收尾篇，作者 Peter Alvaro（加州大学圣克鲁兹分校教授，LDFI 的提出者）。Ch11 刚说完「选什么实验是人的判断」，本章接着问：这份判断能不能被机器复现、规模化；下游 Ch16 的持续验证正是这条路的工程化。

这章要解决什么

设想一个有 100 个服务的系统。只注入单点故障，候选是 100 个；任意两个同时故障是 C(100,2) = 4,950 种；三个同时故障是 161,700 种——还没算延迟、丢包、部分失败这些故障类型。每个实验都要占生产流量和观察时间，一天能跑几十个已算勤快。

更糟的是，成熟系统里真正致命的 bug 往往恰好藏在组合里：单个服务挂掉早就有降级兜着（否则早被发现了），只有「主路径和它的备胎同时出事」才会穿透。所以实验选择不是锦上添花的优化，而是决定混沌工程是否还能找到新东西的核心问题。不解决它，团队要么在海量无聊故障上烧资源，要么把「选什么」全押在少数专家的直觉上。

核心内容，讲透

一、两种老办法：随机搜索与专家指引

随机搜索以 Chaos Monkey 为代表：随机杀实例。优点是零先验、无偏见、实现简单，对「单点故障没兜住」这类浅层问题极其有效。但它的命中率随组合深度指数下降——若致命组合是某特定的两个服务同时出事，随机两两注入平均要试上千次才撞上一次。

专家指引是游戏日（game day）的模式：资深工程师凭对系统的理解指出「这里最可疑」。这在实践中很有效，许多最有价值的实验正出自专家之手。问题有三：不随人数之外的东西扩展（专家时间就是上限）；难以传授（直觉说不清来源）；以及最根本的——混沌工程要检验的正是人的心智模型，用同一个模型去挑实验，盲区会原样保留。

紫圈 = 真正会导致失败的故障组合；蓝点 = 实际做过的实验。

二、反转问题：从「怎么失败」到「怎么成功」

Alvaro 的关键一步是先研究成功。一次请求成功返回，背后有一组「支撑」：哪些服务被调用并返回了正确结果、哪些消息被送达。把这些因果依赖记下来，就是这次成功的血缘（lineage），概念来自数据库里的数据溯源（data provenance）。

血缘的价值在于它同时暴露了冗余。看一个例子：首页请求要成功，需要鉴权服务 A，并且推荐服务 B 或其降级的热门榜 C 之一可用，并且主库 D 或副本 E 之一可用。写成逻辑式就是 A ∧ (B ∨ C) ∧ (D ∨ E)——白话说：A 必须在，B、C 至少一个在，D、E 至少一个在。

注入只坏 B、只坏 D 这类实验注定「什么都没发生」——血缘图让你在动手之前就把它们排除掉。

五个组件的子集有 32 个，随机挑大多是浪费；而能让这次请求失败的最小组合只有 3 个。这就是把专家的直觉「主路径和备胎一起断才危险」变成了可计算的东西。

三、LDFI：一个「猜想—反驳」的循环

血缘驱动故障注入（Lineage-Driven Fault Injection, LDFI）把上面的推理自动化，可以把它看成一位不知疲倦、只按证据推理的专家，循环如下：

观察成功：跑一次正常请求，从追踪数据里抽出血缘。
转成逻辑式：「要让结果失败，每条支撑路径上至少要坏一个」——这是一个可满足性问题，交给 SAT 求解器，求出所有最小故障组合（集合论里叫最小碰撞集，hitting set：和每条路径都有交集的最小集合）。
注入并观察：挑一个组合注入。若请求失败，找到了一个真实漏洞（或一个需要被确认的已知风险）；若请求仍然成功，说明系统有一条血缘图里没有的备用路径——把新血缘加进去，重新求解。
收敛：直到再也算不出能打穿的组合，或者用完预算。

失败与成功都不浪费：失败是 bug，意外的成功是一条你原本不知道的冗余。

LDFI 最早在学术原型 Molly 上实现（SIGMOD 2015），针对的是用逻辑语言写的协议模型；本章讲的是它走出实验室、接到 Netflix 生产环境的版本。那里没有现成的「程序血缘」，于是用分布式追踪的调用树近似血缘，用 Netflix 已有的故障注入平台做执行，并且要处理现实噪声：同类请求每次走的路径不完全相同、服务一直在发版变化。

四、可观测性是前提，也是杠杆

本章的大框架是：可观测性基础设施本来是为排障建的，但它记录的「请求怎么成功」恰好是挑实验所需的知识。专家之所以准，是因为他们脑中有一张近似的依赖与冗余图；追踪系统把这张图从脑子里搬到了数据里，于是可以被机器读、被机器推理。这条路的本质是把直觉工程化——不是取代专家，而是让专家的推理方式在没有专家的地方也能运行。

关键权衡与选型

三种挑法不是替代关系，而是前提条件、成本与能找到的 bug 深度的交换。

挑法	前提	擅长找	扩展性	代价 / 盲区
随机搜索	几乎无，能杀实例即可	单点故障没兜住的浅层问题	随机器扩展，随组合深度崩溃	深层组合命中率极低；大量「什么都没发生」
专家指引	有懂系统的资深工程师	领域相关的高价值组合	上限 = 专家时间	继承专家心智模型的盲区；难传授
穷举	空间足够小	一切	100 个服务的三元组已 16 万	生产上不可行，只适合小模型 / 测试环境
LDFI	请求级追踪 + 「成功」的判据 + 可编程注入平台	主路径与备胎同时失效的组合	随计算扩展；每轮都在收窄	追踪看不到的依赖就推不到；建设成本高

判据：没有追踪就先随机 + 专家；追踪覆盖到关键路径后，LDFI 才有饭吃。

起步团队：随机杀实例足以清掉第一批「没做降级」的问题，性价比最高。
降级已普遍、浅层 bug 找不到了：说明问题在组合里，这时才值得投入血缘驱动的挑选。
专家仍有用：LDFI 给出候选清单，专家决定先跑哪个、何时跑（呼应 Ch11 的分工）。

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

这章把混沌工程从「工具」推向「搜索问题」：注入本身已是商品化能力，稀缺的是挑选。面试被问「你有 200 个微服务，混沌实验从哪开始」，好的回答是：先用调用链找出无冗余的单点（如例子里的 A），再找「主 + 备」成对的依赖，按「打掉它会伤到多少核心请求」排序——这正是 LDFI 思路的手工版。

大厂实证

Netflix：随机搜索的原型。其开源仓库开篇即写「Chaos Monkey randomly terminates virtual machine instances and containers that run inside of your production environment」——这正是本章所说的随机策略，擅长逼出单实例故障下的问题。Netflix · Chaos Monkey README（github.com/Netflix/chaosmonkey，经本次运行核实）
Netflix × UC Santa Cruz：LDFI 进生产。Alvaro 与 Netflix 的 Kolton Andrus、Casey Rosenthal、Lorin Hochstein 等在 SoCC 2016 发表《Automating Failure Testing Research at Internet Scale》，讲把 LDFI 接到 Netflix 故障注入平台的经验；其摘要指出随机策略把资源浪费在「无趣」的故障上，而由程序员指引的方式只能随人力扩展。Alvaro et al. · ACM SoCC 2016（DOI 10.1145/2987550.2987555）
Molly：LDFI 的原型实现。项目 README 自述为「An implementation of LDFI」，对应论文 Lineage-driven Fault Injection（Alvaro、Rosen、Hellerstein，SIGMOD 2015）。palvaro/molly（github.com/palvaro/molly，经本次运行核实）

易错点与争议

「随机就是最客观」。无偏不等于高效：在组合空间里，均匀撒点几乎等于不撒。随机的价值在浅层，不在深层。
「血缘图 = 依赖图」。不对。普通依赖图只说「A 调用了 B」，血缘图还要表达「B 和 C 是或的关系」；少了冗余信息就算不出最小致败组合。
追踪的盲区就是 LDFI 的盲区。没埋点的依赖、共享的底层资源（同一台交换机、同一个配置服务）、延迟而非失败类的故障，都不在调用树里，LDFI 推不到。
需要「成功」的判据。返回 200 不等于返回了对的东西；判据写错，循环会在错误的地方收敛。
落地门槛高、采用有限。它需要追踪、注入平台和求解器三件套，公开的生产级案例很少，最知名的就是 Netflix；多数团队仍停留在随机 + 专家。
算法求的是最小组合，不等于最重要。该先跑哪个仍需结合业务影响排序，这一步书中留给了人。

要点

① 问题：故障空间随组合爆炸（100 个服务的三元组 16 万），选什么实验才是瓶颈。

② 成熟系统的致命 bug 多藏在「主路径 + 备胎同时失效」的组合里，单点注入找不到。

③ 随机搜索无偏但浅；专家指引准但不扩展，且继承专家自己的盲区。

④ 反转：先研究请求怎么成功，把支撑与冗余记成血缘图。

⑤ 血缘转成逻辑式，用 SAT 求最小致败组合；例子里 32 个子集缩到 3 个。

⑥ 循环：注入后失败 = 找到 bug，仍成功 = 发现未知冗余、补图再算。

⑦ Netflix 用分布式追踪近似血缘，把 LDFI 接进生产（SoCC 2016）。

⑧ 盲区：追踪看不到的依赖、共享资源、延迟类故障，以及错误的成功判据。