专业书籍精读 · Chaos Engineering · 第 21 章
Chaos Engineering: System Resiliency in Practice · Ch 21 · Conclusion · 2020
你每天刷的视频网站、用的支付软件，背后是成百上千个小程序互相调用。这本书写了二十章、请了 Slack、Google、微软、领英、Capital One 等公司的人现身说法，最后一章要把它们收成一句话：这么大的系统，已经没有任何一个人能把它全部装进脑子里；想知道它出事时会怎样，唯一诚实的办法是自己先小心地让它出点事，然后看。
想象一座大城市的交通。没有哪位交警知道全城每个路口此刻的样子；每个司机都只按自己看到的那一小段做决定。一场暴雨来了，堵在哪儿、哪条路会瘫，谁也算不准——不是因为哪个路口坏了，而是很多各自正常的路口凑在一起出了意外。你能做的不是画一张「完美的地图」，而是定期搞小规模演练：临时封一条路，看车流怎么绕、哪里先堵。
它带来的不是「保证不出事」，而是信心有了证据：哪些地方真的扛得住，哪些只是大家以为扛得住。刚起步的团队先从一次小演练开始，熟了再交给机器天天做。一句诚实的代价：它只能检验你想到要试的那些情况，而且「什么都没发生」的价值很难向老板算清楚。
没人能看清整个系统，那就别假装看清——小心地让它出点事，用结果去修正大家脑子里的地图。
想看这本书二十章怎么拧成一条主张、实验和测试到底差在哪、五条原则怎么落地，以及它在数据库、安全、实体设备上的延伸？ → 切到精读版
你以为混沌工程是「故意搞破坏」，其实它是一种认识论：在一个没人装得下全貌的复杂系统里，可靠性不能靠推演和检查证明，只能靠受控的实验不断修正人的心智模型来逼近。结语把全书收束成这一个主张——工具会换、场景会变，但「先写假设、再小范围制造真实扰动、用观测去证伪」这个方法，从 Netflix 的虚拟机一路适用到数据库、安全和实体设备。
全书最后一章，篇幅很短，由两位编者 Casey Rosenthal 与 Nora Jones 执笔，不引入新技术，而是回望 Part I（复杂系统与原则）→ Part II（各公司实践）→ Part III（人的因素）→ Part IV（商业）→ Part V（演进）这条线。对应现实里「我们该不该、怎么开始做混沌工程」这一类架构与组织决策。
读完二十章，读者容易得到一堆碎片：Slack 的灾难剧场、Google 的 DiRT、微软的实验排序、领英的请求级注入、Capital One 的合规留痕……结语要回答的是：这些看起来五花八门的做法，背后是不是同一件事？
答案是肯定的，而且问题的根在 Part I：现代系统的复杂性是业务价值的副产品——每加一个功能、一个服务、一个依赖，交互就多一截。组件数大致线性增长，组件之间可能的交互却按 n² 量级增长（意思是：100 个服务两两之间就有约 4950 种可能的牵连）。故障不住在某个坏零件里，而住在一堆各自正常的部件之间的接缝上。不把这一点讲透，读者就会把混沌工程当成「多一种测试工具」，买个注入平台跑几次，然后因为「没发现什么」而放弃。
全书的地基是一个不太讨喜的判断：你不能把复杂性设计掉。一部分复杂性是偶然的（坏抽象、历史包袱），可以还；但大部分是本质的——它就是业务本身。更麻烦的是，系统在经济、工作量、安全三条边界之间受力，前两条会「提前喊疼」（预算超了、人累了），唯独安全边界不会，于是系统会悄悄向它漂移（Ch2）。
由此推出结语的第一个立场：与其追求一张完美的设计图，不如承认图永远不全，转而建立持续发现「图哪里画错了」的机制。混沌工程就是这个机制。
测试（test）验证一个已知的性质：给定输入，断言输出，结果是通过 / 失败。实验（experiment）面对的是未知：先写一个关于稳态的假设（「杀掉一个可用区的实例，每秒成功播放数波动不超过 1%」），再制造真实世界会发生的扰动，看假设是否被证伪。证伪了，你学到了系统的一种新行为；没证伪，你的信心多了一条证据。
全书反复强调的五条原则——围绕稳态建假设、模拟真实世界事件、在生产中实验、自动化持续运行、最小化爆炸半径——都是在给「实验」加约束，让它既真实又可控。实践中最常被砍掉的是「在生产中」，而它恰恰是让实验有意义的那一条，因为测试环境的流量、配置和依赖都不是真的。
Part III 把镜头从机器转向人：实验前逼每个人写下预期，分歧本身就是盲区（Ch9）；组织也会有单点和延迟（Ch10）；执行可以自动化，但「为什么做、结果意味着什么」必须留给人（Ch11）；人为错误是症状不是根因（Ch18）。全书由此落到一点：混沌工程的最终产出不是一份「通过 / 失败」报告，而是工程师对系统更准确的理解——这也是它必须无责：一旦结果被拿来追责，大家就会停止暴露自己的认知盲区。
Part V 的四个方向是最好的证据：持续验证把实验接进流水线（Ch16）；信息物理系统把它搬到会伤人的场景，先在仿真和台架上做（Ch17）；数据库上用「转账总额守恒」这类不变量判定对错（Ch19）；安全领域注入配置错误，验预防、检测、响应三层（Ch20）。对象变了，骨架没变：稳态 / 不变量 → 假设 → 受控扰动 → 观测 → 修正。这说明混沌工程的核心不在某个工具，而在一种面对不确定性的态度。
结语留给读者的实际问题是：我的团队现在该做哪一种？先分清几种「看起来像」的做法各自回答什么：
| 做法 | 回答的问题 | 适合阶段 | 代价 / 局限 |
|---|---|---|---|
| 单元 / 集成测试 | 已知性质是否成立 | 永远要有 | 覆盖不到没想到的交互 |
| Game Day 演练 | 人和流程能否接住一次故障 | 起步期 | 按季度做一次，协调成本高、规模难扩大 |
| 生产混沌实验 | 真实流量下稳态假设能否成立 | 有监控、有中止开关之后 | 需严控爆炸半径；会碰到真实用户 |
| 持续验证（CV） | 每次变更后假设是否依然成立 | 成熟期 | 平台投入大；判定逻辑本身要可信 |
再看全书各家给出的起步路径，差别主要来自约束：
| 约束 | 书中例子 | 起步方式 | 代价 |
|---|---|---|---|
| 老系统没为失败设计 | Slack（Ch4） | 先写文档、预演、量好中止耗时 | 前期几乎全是准备工作 |
| 强监管 | Capital One（Ch8） | 非生产起步，挂在流水线门禁上，留痕换许可 | 真实性打折，进生产慢 |
| 用户规模巨大 | 领英（Ch7） | 把故障挂在单个请求上，逐级放量配自动叫停 | 需要请求级注入的基础设施 |
| 故障空间爆炸 | 微软（Ch6）、LDFI（Ch12） | 先排序，只做最可能致败的几十个实验 | 排序模型可能漏掉真正的风险 |
经验法则：先能观测稳态、先有一键中止，再谈注入；从 Game Day 起步积累信任，再把成熟的实验交给自动化。用成熟度模型（Ch15）同时看「做得多精细」和「多少团队在做」，补落后的那条腿，而不是只数实验次数。
微服务、多云和高频发布让系统变化从「每季度」变成「每小时」，任何静态的架构评审都会迅速过期。混沌工程给出的回答是：可靠性不是一次性认证，而是一个持续获取证据的过程。面试或架构评审里被问「你怎么知道这个系统能扛住某个可用区挂掉」，好的回答不是「我们有冗余」，而是「我们按季度在生产里切过，稳态指标波动在阈值内，上一次发现并修掉了一个重试风暴」。
这条路也已从一家公司的内部实践变成行业基础设施：从 Netflix 2010 年前后迁移上云时写的 Chaos Monkey，到 Kubernetes 生态里的开源混沌平台，再到各大云厂商提供的托管故障注入服务。
大厂实证
① 结语一句话：没人装得下整个系统，可靠性只能靠受控实验持续修正心智模型来逼近。
② 复杂性是业务价值的副产品：组件线性涨，接缝按平方涨；故障住在接缝上。
③ 实验 ≠ 测试：测试验已知性质，实验以稳态假设面对未知、产出新知识。
④ 五条原则：稳态假设、真实事件、生产中、自动持续、最小爆炸半径——最常被砍的是「生产中」。
⑤ 人是系统的一部分：最终产出是人的理解，所以必须无责。
⑥ 方法可迁移：数据库、安全、实体设备、流水线，骨架都是「不变量 → 假设 → 扰动 → 观测」。
⑦ 选型看约束：老系统先准备、强监管先留痕、大规模按请求放量、故障空间大先排序。
⑧ 先有观测与中止开关，再谈注入；从 Game Day 走向持续验证。
⑨ 易错：随机破坏不是实验；有工具不等于在做；它只验证想得到的扰动。