Slack 的灾难剧场

一句话

你以为落地混沌工程的第一步是选一个故障注入工具。Slack 的答案是：第一步是一份文档、一次评审、一场在非生产环境的预演，和一个被量过耗时的中止方案。因为 Chaos Monkey 那条路有个藏起来的前置条件——被摇的东西本来就是按「随时会死」设计的；而任何活了几年的公司，最关键的那几个系统恰恰不是。这一章给的不是工具，是一套让存量系统（legacy system）第一次被摇时，产出的是知识而不是一次事故的流程。

Glossary · 术语表

坐标

全书 21 章的第 4 章，Part II「原则落地」的开篇——Ch4 到 Ch8 是五家公司把上一章五条原则在各自约束下的变形，而这一章是第一种、也是门槛最低的那种变形：原则三（在生产跑）保留，原则四（自动化、持续跑）暂时让位于「人在回路」。往下 Ch5 是 Google 的 DiRT（同一种人在回路，但做到公司规模），Ch7 是 LinkedIn 对爆炸半径的伦理约束，Ch8 是 Capital One 在合规下的渐进路线，Ch16 才回到全自动。现实里它对着的，是有一堆多年前写的服务、平台不统一、却必须开始验韧性的团队——也就是绝大多数团队。

这章要解决什么

上一章的五条原则有个没说出口的假设：被实验的系统是为失败而设计的。Chaos Monkey 能随机终止实例，前提是实例无状态、被统一平台编排、死了之后流量会自动绕开。

但真实公司的基础设施是分层沉积的。本章在 Slack 内部划的分水岭很干脆：新系统按「故障是常态」设计——无本地状态、可随时重启、流量自动绕开；老系统按「基础设施可靠」设计——有本地状态、切换要人、甚至依赖某台具体机器的身份。不巧的是，老系统往往正是最关键的那一层：数据库、服务发现、消息路由、身份。给个量级感：Slack 当时日活在数百万量级，每个在线客户端维持一条长连接（WebSocket），连接层一抖是所有在线用户同时重连。

所以这章的问题是：怎么给一个压根没为失败设计过的系统做实验，而且不让实验本身变成那次事故？

不解决会怎样？一是不敢做：最关键那层永远是未验证的黑箱，你的信心全来自「它一直没出事」——上一章刚说过这不算证据。二是硬做：第一场演练炸成一次真事故，技术损失有限而政治损失致命，混沌工程在这家公司的信誉当场清零。本章的流程一半是技术设计，一半是在保护这件事的政治生命。

核心内容，讲透

分水岭：一台机器消失，是自动绕开还是需要人？

这是全章最可操作的一句判据，拿它去问手上每一个系统。「自动绕开」意味着后果有界且已知：实例死掉 → 健康检查摘除 → 剩下的分摊，最坏情况你算得出来，可以放手让机器随机去摇。「需要人」意味着后果不可预先界定：注入后系统进入一个没人见过的中间态，恢复时间取决于当时谁在、他多熟、文档准不准。对这类系统自动随机注入，不是实验，是开盲盒。

这也解释了 Chaos Monkey 为什么不通用——它硬要求你先有一个把应用管起来的平台（见 §6 实证）：没有那个平台的系统不是「还没接入」，是架构上不满足前提。

流程骨架：文档 → 评审 → 预演 → 生产演练 → 跟进

本章主体就是这条流水线：看着很「重」，但每一环都在消掉一类特定的失败。

① 文档（最重要的一步）。主持人事先写一份不长的文档，必须回答：摇哪个系统、注入什么故障、敲哪几条命令、动哪几台实例；盯哪些看板、告警、日志；以及假设——预计会发生什么，包括哪些告警会响、用户有没有感觉。

文档里有一个设计得极妙的问题：「你有多确信非生产环境里的容错，能预测生产环境里的容错？」它把上一章原则三那个抽象争论变成主持人必须书面回答的具体问题，而且回答会改变设计：答「很有信心」，生产那场可以轻快；答「没什么信心」，就得更小的半径、更短的时长、更多人在场。

② 评审。文档在相关团队里传阅。这一步常被低估：很多问题在传阅阶段就被想出来，根本不用真的注入——这是整条流水线里最便宜的一次「实验」。

③ 非生产预演。先在 dev 演一遍。它不替代生产（否则就是偷偷放弃原则三），只负责把和假设无关的丢人错误先摔完：命令写错、权限不够、工具自己坏了、依赖起不来。这些错留到生产，会让你死在一个毫不相干的地方，白烧一个时间窗。

④ 生产演练。约定时间窗，把专家集中在一处一起看。为什么不靠告警把人叫来？因为告警本身也在被检验——不能用待验证的东西去保障验证过程。排在工作时间还有个好处：最熟的人是清醒的，不是凌晨三点被叫起来的值班同学。

⑤ 记录与跟进。写下实际发生了什么、与假设差在哪、开修复项。缺这步，前四步的产出会停在「大家当时都知道」，三个月后归零。

中止方案是第一等公民，不是附录

绝大多数团队的中止方案就一句「有问题就回滚」，等于没写。本章要求它具体到三件事：

• 撤回的确切操作：哪条命令、改哪个开关、谁有权限执行。
• 撤回生效需要多久。最常被漏掉、也最容易带来惊喜的一项：撤回路径本身往往没被测试过，可能要几分钟——服务发现有传播延迟、连接池要重建、缓存要重新预热。所以真正的爆炸半径是 影响范围 × (注入时长 + 中止耗时)，后一项不量，前面压到 1% 也没意义。
• 谁能喊停、按什么判据。答案是「在场任何人都能喊」，判据事先写死（上一章原则一）——现场不该出现「这算不算异常」的辩论。

这套流程最常撞上的三类发现

按价值排序，最有价值的那类最反直觉：

1. 系统扛住了，但没人知道它扛住了。容错生效、用户无感，而告警一声没响，或者响了几条不相干的。它说明下次真出事，你会晚几十分钟才知道——换句话说，演练首先验的不是系统扛不扛得住，而是你会不会知道。
2. 扛住了故障，却死在恢复上。撤回那一刻集体重连、缓存全空、重试风暴。因为恢复路径比故障路径更少被测试——出事时大家都在救，很少有人回头验恢复动作本身安不安全。
3. 故障根本注入不进去。按文档敲完命令，什么也没发生——真实配置和你以为的不一样：那个「冗余」早在某次变更里被改成了单点，或者流量压根不走你以为的那条路。这类发现说明你的心智模型是错的，正是 Ch1 的论断在你面前兑现了一次。

为什么「人在回路」是对的起点，而不是落后的妥协

自动化注入有个前置条件：你已经知道这个故障的后果是有界的。第一次摇一个老系统你恰恰不知道——所以人在场不是保守，是在补那个缺失的前提。

这也给出了演进方向：人在场的边际价值在第一次最高、第 N 次最低。同一个实验演过几轮、后果摸清、判据能写成代码，就该交给机器天天跑（Ch16）。流程不是终点，是入口。

还有一个自动化永远产不出的副产品：教育。一场演练把五到十个工程师放在同一处、看同一组指标、在同一分钟里修正自己的猜测——这是把 Ch1 里各自残缺的局部心智模型强行拼一次。流水线产出的是一条绿灯，演练产出的是五个人更新过的理解。

关键权衡与选型

第一张表是那条判据的落地：手上每个系统该用哪种做法。

判据只有一句：这台机器消失，是自动绕开还是需要人？它决定你能不能把判断权交给机器。

第二张表是「在哪演」的权衡，关键在认清每一档各自抓不到什么。

落到具体选择：

• 第一次摇某个关键存量系统：走完整流程，一个变量、一个时间窗、工作时间、人在场。别省预演——省掉的那一步会让你在生产时间窗里死于一条敲错的命令。
• 平台团队想把这件事铺开：先投「中止开关 + 分组指标 + 演练文档模板」，别先堆注入手段。上一章说注入从来不是瓶颈；这一章补一句：主持人的信心才是瓶颈，模板和预演是在造信心。

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

这一章给的是三句能直接改变评审结论的话。一：在问「先摇哪个系统」之前，先问「它消失时是自动绕开还是需要人」——答案决定方法，而不是反过来先选工具。二：演练首先验的不是系统扛不扛得住，而是你会不会知道。三：中止方案要报一个数——撤回生效需要多少秒。

面试被问「你们怎么在生产做故障验证」，答「我们用了 XX 工具」是工具层；答「关键系统不是为失败设计的，所以走文档 + 评审 + 预演 + 人在回路，中止耗时必须量过」是另一个层级——它显示你知道自动化的前置条件。

易错点与争议

• 只验「扛住了」，不验「告警响了」。系统无感通过、告警全哑，很多人会记成一次成功——它其实是一次红灯。
• 预演通过就跳过生产那场。这是悄悄放弃上一章原则三：预演抓命令和权限，抓不到任何和量级有关的机制。
• 把流程当成「我们还不够先进」的临时品，急着跳到自动化。自动化的前提是后果已有界；前提没补齐就跳，是把开盲盒外包给机器。
• 反过来，把流程当终点。频率上不去是它的真缺陷：一个季度几场，覆盖率没法比。演过几轮、每次都很无聊，是该自动化的信号，不是该庆祝的信号。
• 把演练当成对工程师的考核。一旦有人因为演练暴露的问题被追责，下次就没人愿意当主持人、没人愿意把悲观假设写进文档——流程立刻退化成表演。这是 Ch18（HOP）的主题，也是本章流程能跑起来的隐含前提。
• 争议：这还算混沌工程吗？严格按上一章原则四，人在回路的演练更像 game day。诚实地讲代价：它牺牲了频率和覆盖面；它的辩护是——对这类系统，自动化的前提还不存在，而不做比做慢更糟。
• 时代局限。这是 2018–2020 年 Slack 的经验。今天统一的编排平台与成熟的注入框架让「右边那列」变短了，但没变空：任何公司都还有自己那层沉积物——数据库、身份、计费、清算。这套流程的保质期和它一样长。

要点