创造前瞻

一句话

你以为混沌实验的价值在「注入故障那一刻看到了什么」，其实大半价值发生在注入之前：把一群工程师召集起来设计实验，逼每个人说出自己对系统的预期——分歧与答不上来的地方，就是心智模型的盲区。本章把混沌工程从「事后学习」的工具，重新定位为制造前瞻（foresight）的工具：在事故发生之前，就去想象它。

Glossary · 术语表

坐标

全书第 9 章，Part III「人的因素」的第一篇，作者 Andy Fleener。Part II 五家公司讲的是「怎么跑实验」；从这一章起，视角从机器转向人脑里的那张图，下接 Ch10 人性化的混沌、Ch11 人在回路。标题与韧性工程学者 David Woods 研究哥伦比亚号失事的一篇文章同名，取的是同一个意思：安全来自事前想象，而非事后归因。现实里它对着任何「事故复盘做了不少、事故却还在重复」的团队。

这章要解决什么

先摆一个典型场景：一个下单服务依赖缓存、数据库、支付网关和消息队列，四五个团队各管一块，每周上线几十次。出了事，复盘会上大家才第一次把各自的理解拼到一起——「原来连接池满了以后会一直重试」「原来那个告警早就没人订阅了」。

这种学习方式有两个结构性问题。一是太贵：每条知识都是用一次真实事故换来的，用户已经付了学费。二是被后见污染：知道了结局，人会不自觉地把一连串当时模糊的信号排成一条「明显的因果链」，然后问「为什么当时没看到」——复盘滑向追责，人们开始少说话。

混沌实验本来可以把学习挪到事故之前。但很多团队把它当成「装个工具、随机关机器」：没人事先说清预期，结果出来只能说「好像没啥事」，学不到东西；或者摇到了真事故，却发现原本就没人能说清楚系统会怎样。

所以这章的问题是：怎么用混沌工程主动制造前瞻——在事故发生之前，就把工程师心智模型里的分歧与盲区挖出来？

核心内容，讲透

一、混沌循环有三段，最被低估的是「之前」

本章把一次混沌实验拆成之前（设计）、之中（注入与观测）、之后（分析与学习）三段。工具厂商和大多数讨论都集中在「之中」：怎么注入、怎么控制爆炸半径、怎么一键中止。Fleener 的主张是：「之前」这一段本身就能产出大量洞见，它决定了「之中」看什么、「之后」能学到什么。

直觉很简单：注入只是一个按钮，而要按下它，一群人得先回答「我们预期会发生什么」。这个问题一旦被认真问出来，很多答案在按钮按下之前就已经出现了——有时是发现一个从没配好的告警，有时是两个资深工程师对同一条路径给出相反的预期。

二、混沌工程服务的是韧性的「预见」能力

本章借用了韧性工程（resilience engineering）学者 Erik Hollnagel 的框架：一个系统要表现出韧性，需要四种能力——响应（出事时能处置）、监控（知道该盯什么）、学习（从经验里改进）、预见（想象未来可能发生什么）。

传统的可靠性工作大多补在前三项：告警补监控、值班与预案补响应、复盘补学习。预见是最难练的一项，因为它要求人去想一件还没发生的事。混沌实验的设计环节恰好给了一个结构化的练习场：「如果这个依赖慢了 2 秒，会怎样？」——这就是在人为地制造一次「事前回顾」。

三、心智模型：每个人都只摸到大象的一部分

Part I 已经立下前提：复杂系统大到没有任何一个人装得下。每个工程师脑子里都有一个局部的模型——应用工程师知道重试逻辑，数据库工程师知道连接上限，平台工程师知道节点怎么被调度——而且这些模型彼此不同、各自过时。

设计会的作用，是把这些模型放到同一张桌子上。它能挖出两类东西：

• 分歧：两个人对同一件事给出相反的预期。比如「缓存挂了，下单会变慢但不失败」对上「缓存挂了，数据库连接池几十秒内就会被打满」。分歧点是最值得做实验的地方——至少有一个人的模型是错的。
• 盲区：一个问题抛出来，没有人答得上。「这个告警发给谁？」「这个服务超时设的是多少？」答不上本身就是发现，往往不用注入任何故障就能先去修。

四、设计会怎么开：主持人与四个议题

本章最可操作的部分，是怎么组织实验前的这场讨论。核心角色是主持人：主持人不是来给答案的，而是来提问、追问、把每个人的说法记下来。好主持人往往对这个系统不那么熟——「外行」的问题更容易戳到大家默认为显然、其实没人验证过的地方。

讨论围绕四个议题展开，大致按这个顺序：

• 理解运行规程。先问「平时出这种事，会发生什么」：谁会被呼叫？看哪个面板发现？预案写在哪、上次用是什么时候？这一步对照的是想象中的工作与实际的工作（work-as-imagined vs work-as-done）之间的差距——文档里写的流程，常常不是大家真正在做的。
• 讨论范围。「我们要摇的到底是什么？」一台实例、一个可用区，还是整个依赖？影响哪些用户、多长时间？范围的讨论经常暴露出大家心里想的根本不是同一件事，也顺带定下了爆炸半径。
• 形成假设。让每个人说出（最好先各自写下）预期：稳态指标会怎样变、哪些告警会响、多久恢复。假设必须具体到能被证伪，例如「注入 2 秒延迟后，下单成功率保持在 99.9% 以上，p99 从 300 毫秒升到 2.5 秒以内」。先各自写再公开，能避免最资深的人一开口就带走全场。
• 选择工具与内部协作。工具要能精确控制范围、随时中止、让参与者看到同一份观测数据；实验要和被影响的团队、值班、客服事先打招呼。

提问的手艺决定这场会的质量。好的问题是开放的、描述性的：「你觉得会先发生什么？」「你会怎么发现？」「上次类似情况是怎样的？」；坏的问题是封闭的或带评判的：「这应该没问题吧？」「为什么没加熔断？」——前者打开模型，后者让人开始辩护。

五、从「之前」回到「之后」：让前瞻成为循环

实验跑完，回到设计会上写下的假设逐条对照：哪些预期成立，哪些被推翻，谁的模型需要更新。被推翻的假设不是谁的失败，而是一次不用付事故学费的学习。把这些结论写进规程、告警和架构改动里，再进入下一轮设计——每转一圈，团队对系统的集体想象就离真实更近一点。

关键权衡与选型

第一张表：团队获取「系统会怎样失效」这类知识的几种途径。

设计会的独特之处在于把「想象」和「验证」接在一起：纸上推演只有前者，直接注入只有后者。

第二张表：主持人从哪来。

落到具体选择：

• 团队刚开始做混沌：别急着上工具。先挑一条最近出过事的关键路径开一场设计会，只跑一个实验——第一次的收获往往在会上。
• 设计会上大家意见一致、信心十足：这个实验的信息量可能不高；把精力挪到有分歧或没人答得上的地方。
• 会上发现了盲区（如告警没人收）：先修，再实验。为一个已知缺陷去注入故障，只是在花钱证明已知的事。

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

三句能直接带进评审的话。一：混沌工程的产出是知识，不是故障；而知识最大的一份在实验之前。二：分歧点和答不上来的问题，是实验选题的最好指针。三：复盘是在付过学费之后学习，设计会是在付学费之前学习。

面试被问「你们怎么做混沌工程」：答「我们用某某工具每周随机关实例」是一个层级；答「每次实验前开一场设计会，先对运行规程、定范围、各自写假设，把分歧点挑出来做实验，跑完对照假设更新规程」是另一个层级——后者说明你理解混沌工程针对的是人对系统的理解，而不只是系统本身。

易错点与争议

• 把设计会开成审批会。如果会议的目的是「确认实验安全、签字放行」，大家只会说让实验通过的话，分歧被压下去。安全检查要做，但不能取代「你预期会怎样」这个问题。
• 资深者先开口。最有经验的人一说预期，其他人就跟着点头，分歧消失了。对策是先各自写下、再一起公开。
• 只记结论、不记预期。没有事前写下的假设，事后每个人都会觉得「我早就知道」——后见偏差在实验里同样成立。
• 为了实验而实验。会上已经发现的缺陷，先修再说；对一个全员都确信结果的场景做实验，信息量很低。
• 「前瞻」不是预测。设计会不能保证想到所有失效方式，复杂系统里总有没人想到的组合。它的价值是让团队更擅长想象与发现，而不是给出一份完整清单——Ch12 的血缘驱动故障注入正是从另一个方向补「人想不到」的那一块。
• 时代局限与争议。本章更像实践者的经验总结，论证以案例和韧性工程文献为主，缺少量化证据证明「设计会」本身降低了多少事故；它的成本（多人、数小时）在快速迭代的团队里也常被砍掉。但它把混沌工程从「工具」拉回「学习」的方向，为后面几章的人的因素讨论定了调。

要点