Chaos Engineering 第 13 章 · 混沌工程的投资回报

Chaos Engineering: System Resiliency in Practice · Ch 13 · The ROI of Chaos Engineering · 2020

这一章讲什么？

假设你在一家视频网站管着一个小组，专门「故意把系统弄坏一点」来找隐患。年底老板问：这一年花了这么多钱，换来了什么？最诚实的回答是：「什么都没发生。」——而这恰恰是世上最难证明的成绩。

这一章就回答一个很现实的问题：怎么向不懂技术的人证明，预防工作值这个钱。

先说个怪事

你会以为：系统越练越稳，事故就一路往下掉，拿事故数一比就有了证据。可现实常常是：事故少了几个月，又慢慢回来了。

不是白练了，而是大家觉得稳了，就开始跑得更快——更频繁地上新功能、改代码。就像修好了刹车的司机，会不自觉地开快一点。省下来的安全余量，被换成了速度。

旧世界为什么难

没发生的事没法数。今年没着火，是消防演习的功劳，还是运气好？你看不到「没演习的那个平行世界」。
大事故本来就少。一年就那么几次，多一次少一次，很难说是谁的功劳。
好处会被花掉。就像上面说的，稳了就提速，事故数又被拉回原地。

核心机制直觉：把它当成一门培训来评分

作者的点子是：混沌演练真正的产物，是工程师脑子里那张「系统怎么运转」的地图变准了。既然本质是「让人学会东西」，那就借用评估培训课的老办法，像评一所驾校那样分四层台阶：

学员满意吗？演练完问一句：值不值得来？
学到东西了吗？有没有发现「原来系统不是我以为的那样」？
回去改了吗？有没有因此修了漏洞、加了备用方案？
结果变好了吗？公司的服务是不是更少掉线、更少赔钱？

越往上越接近老板关心的「钱」，也越难算清；但下面三层很好记录，能一级一级把证据垒起来。

带来了什么 / 该怎么选

还有一笔常被忽略的「顺带收益」：一次演练会把平时不打交道的几个组拉进同一个房间，大家认识了彼此、知道出事该找谁——这在真正出事时值千金。

一句诚实的代价：最上面那层永远只能估算，拿不出一张精确的账单。

一句话记住

别拿「事故少了几个」当成绩单——它会被提速吃掉；把混沌当培训，从「满意—学到—改了—结果」四层逐级拿证据。

想看为什么事故数会「回弹」、四层各量什么指标、怎么对管理层讲？ → 切到精读版

一句话

你以为混沌工程的回报是「事故变少」，其实事故数是最差的成绩单：它看不见反事实，样本又小，而且省下的余量会被组织重新花在速度上。更稳的做法是把混沌工程当作一种培训，用 Kirkpatrick 四层模型逐层度量：反应、学习、迁移、结果。

Glossary · 术语表

ROI（投资回报率，return on investment）：投入换来多少收益，常用于向管理层论证一笔开销值不值。
事故（incident）：线上服务出现用户可感知的故障或降级，需要人介入处置。
反事实（counterfactual）：「如果当初没做某件事，会怎样」——现实中无法直接观察的那条平行路径。
安全余量（safety margin）：系统离出事边界还有多远；越大越经得起意外。
心智模型（mental model）：工程师脑中对「系统如何运转、哪里会坏」的理解，混沌实验检验的正是它。
游戏日（game day）：预先约好时间、多个团队一起在线上或准生产环境演练故障的活动。
稳态（steady state）：系统正常时某个业务指标的典型取值，混沌实验用它判断「有没有出事」。
错误预算（error budget）：可用性目标之外允许的不可靠额度，例如 99.9% 目标下每月约 43 分钟不可用。

坐标

全书第 13 章，Part IV「商业因素」的开篇，作者 Casey Rosenthal（前 Netflix 混沌工程团队负责人、本书主编之一）。Part III 讲完人怎么从实验里学习，这一章把同一个洞见翻译成管理层的语言；下接 Ch14 开放科学与 Ch15 成熟度模型。

这章要解决什么

一个专职混沌工程团队要人、要平台、还要占生产流量做实验，每年都得在预算会上回答「值不值」。和新功能不同，它的产出是非事件（non-event）：成功的标志是什么都没发生。

如果找不到可信的度量，后果很具体：要么团队在第一轮预算收紧时被砍掉，要么被迫拿「本季度事故数下降 30%」这类数字邀功——而下一个季度事故数一回弹，同一个数字就会被拿来证明它没用。选错度量，比没有度量更伤。

核心内容，讲透

一、为什么「事故少了」站不住

直觉上的算法是：做混沌之前每月 10 起事故，之后 7 起，省下 3 起 × 单次损失 = ROI。书里指出它至少有三处裂缝：

反事实看不见。事故数受发版节奏、流量季节性、组织变动等许多因素影响，你无法把「没做混沌的那个世界」拿出来对照。
样本太小。真正严重的事故一年可能只有个位数，几起的差异落在正常波动里，统计上说明不了因果。
收益是短暂的（ephemeral）。这是本章最反直觉的一点：系统变稳之后，组织会把多出来的余量重新投资——发版更频繁、改动更大胆、功能上得更快，于是系统又被推回风险边界附近，事故数回落到原来的水平。

示意图（非真实数据）：只盯蓝线，会误以为混沌「失效了」；真正的收益转成了紫线——同样的事故水平下跑得更快。

注意第三点并不是说混沌没用，而是说收益换了形态：同样的事故水平下，组织跑得更快了。安全科学里 Rasmussen 的「动态安全模型」描述的正是这种漂移——经济和效率压力会持续把系统推向安全边界。用事故数考核，等于只看了收益被花掉之后的余额。

二、换个参照系：混沌工程本质是一种学习

本章的转折建立在全书反复出现的观点上：混沌实验真正的产物，是工程师心智模型的更新——发现系统并不按自己以为的方式运转。既然产物是「学习」，就可以借用评估学习最成熟的框架：Donald Kirkpatrick 在 1950 年代为企业培训提出的四层评估模型。它被培训行业用了几十年，好处是不要求一步算出钱，而是一层层垒证据。

三、Kirkpatrick 四层，逐层落到混沌工程

越往上越接近管理层关心的钱，也越难把功劳归给混沌工程；下三层是可以稳定采集的证据链。

L1 反应（Reaction）：参与者觉得这次实验或游戏日值不值得？最便宜的度量是一份演练后问卷。它不证明价值，但如果连参与者都觉得浪费时间，后面几层基本无从谈起。
L2 学习（Learning）：参与者有没有学到新东西？可以数「实验前写下的预期被推翻了几次」、发现了多少此前不知道的依赖或行为。这直接接上 Ch9「创造前瞻」：把预期写下来，学习就变得可记录。
L3 迁移（Behavior / Transfer）：学到的东西有没有变成行动？例如实验后提交的修复、新加的超时与降级、更新的运行手册（runbook）、被改掉的架构决定。这一层已经可以对接工单系统自动统计。
L4 结果（Results）：组织层面的结果有没有改善——可用性、事故严重度、恢复时间、业务稳态指标。它最值钱，也最受上一节那三处裂缝的影响，所以书中的态度是：别只押这一层，用下三层把因果链补齐。

这套框架的妙处在于把一个无法回答的问题拆成了几个能回答的问题：你说不清「避免了多少损失」，但能说清（数字仅为示意）「这季度 40 次实验推翻了 12 个预期、催生了 9 个修复，其中 3 个补上的是无降级的单点」。

四、附带收益（collateral ROI）

书中还单独点出一类常被忽略的回报：实验本身之外的东西。筹备一次游戏日，往往要把平时不打交道的团队拉进同一个房间——他们第一次对齐彼此对系统的理解，知道了出事该找谁；讨论「该注入什么」时，分歧本身就暴露了文档缺失和知识孤岛；实验还常顺带撞见与假设无关的问题（某个告警根本没人收）。这些收益很难计价，但在下一次真实事故的协作效率里会兑现。

关键权衡与选型

度量方法没有完美的，权衡在于好不好量、可不可信、会不会被操纵。

度量	好量程度	说服力	主要代价 / 陷阱
事故数前后对比	高，现成数据	表面强，实则弱	反事实缺失、样本小；收益被提速吃掉后会「证明」混沌无用
漏洞数 × 估算单次损失	中	中，数字好看	假精确：「本可能造成的损失」靠假设；数漏洞会诱导刷数量
L1 反应	很高，一份问卷	弱	满意 ≠ 有用；只能当「门槛」证据
L2 学习	中，需事先写预期	中	依赖团队愿意如实记录「我错了」，需要不追责的文化
L3 迁移	中高，可接工单	较强	修复多不代表修对了；要区分「因实验而做」和「本来就要做」
L4 结果	低	最强（若可归因）	同样受反事实与回弹影响；须与 L2/L3 组成因果链才站得住

判据：对工程团队讲 L2/L3，对管理层讲「L3 → L4 的链条」，别单独拿 L4 或事故数邀功。

起步期（每月几次实验）：先把 L1、L2 采集做扎实——每次实验前写下预期，事后记录推翻了哪些，成本几乎为零。
规模化后：把实验结果和工单打通，自动统计 L3；配合错误预算等 L4 指标，讲「多少修复对应哪类风险」。
面对财务：如果必须给金额，把它标为区间估算并写明假设，别给单点数字——一个被戳穿的精确数字会连累全部可信度。

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

这章的价值超出混沌工程本身：所有预防性工作都有同一个困境——安全、测试、技术债清理、容量冗余，做得好的标志都是「什么都没发生」。Kirkpatrick 式的分层举证，是这类工作在预算会上活下来的通用打法。面试或架构评审被问「你怎么证明可靠性投入值得」，好的回答不是报一个事故下降百分比，而是讲清学习 → 行为改变 → 结果这条链，并主动指出事故数会因提速而回弹。

大厂实证

Netflix 对 Chaos Monkey 价值的自述是「改变行为」，不是「减少事故」。其开源仓库写道：「Exposing engineers to failures more frequently incentivizes them to build resilient services.」——让工程师更频繁地面对故障，从而激励他们构建有韧性的服务。这恰是 Kirkpatrick 的 L3：回报落在工程师的设计习惯上。Netflix · Chaos Monkey README（github.com/Netflix/chaosmonkey，经本次运行核实）
Google 把「余量换速度」写成了制度。Google SRE 的主张大意是：可靠性不该追求 100%，可用性目标之外的那部分即错误预算，可以明确地花在发布新功能上；预算用完才放慢发布。这正是本章「收益会被花掉」的另一面——与其被动回弹，不如主动、可见地花。Google · Site Reliability Engineering（O'Reilly，2016），「Embracing Risk」一章（大意转述）
Netflix 用业务指标定义稳态。Netflix 的混沌实验以每秒播放启动数（SPS，stream starts per second）衡量系统是否健康，而不是 CPU 或错误率——让实验结果天然能对接 L4 的业务语言。Basiri et al., 「Chaos Engineering」, IEEE Software, 2016

易错点与争议

「事故少了就是 ROI」。最常见也最危险：它让团队的生死取决于一个会自然回弹的数字。
「收益短暂 = 没价值」。相反，回弹往往说明余量被成功换成了交付速度；问题只在于这笔收益记在了别人的账上。
Goodhart 陷阱。一旦把「发现漏洞数」或「实验次数」设成 KPI，团队就会去刷容易发现的小问题，深层组合风险反而没人碰。
L1 满意度 ≠ 价值。演练热闹、参与者开心，不代表有人学到东西，更不代表有人改了系统。
Kirkpatrick 本身也有争议。培训评估领域早有批评：四层之间的因果链并不必然成立，L1 高不保证 L4 好。把它搬到混沌工程，同样只是组织证据的框架，不是证明。
本章偏论证、少数据。书里没有给出可复用的行业基准或公开的 ROI 数字，落地时需要每个组织自己积累基线。

要点

① 混沌工程的成果是「非事件」，最难向业务证明。

② 事故数前后对比不可靠：反事实看不见、严重事故样本太小。

③ 收益是短暂的：变稳后组织会提速，把余量花掉，事故数回弹。

④ 回弹不等于失效，收益换成了交付速度——Google 的错误预算把这件事制度化。

⑤ 换参照系：混沌实验的产物是心智模型的更新，可按培训来评估。

⑥ Kirkpatrick 四层：反应、学习、迁移、结果，越往上越值钱也越难归因。

⑦ 用 L2/L3 的证据链撑起 L4，别单押事故数，也别给假精确的金额。

⑧ 附带收益：游戏日拉近团队、暴露知识孤岛，在下次真实事故中兑现。