专业书籍精读 · Chaos Engineering · 第 11 章
Chaos Engineering: System Resiliency in Practice · Ch 11 · People in the Loop · 2020
前几章讲的是：大公司会故意在自家系统里「搞破坏」——关掉一台服务器、让网络变慢——看系统扛不扛得住。这一招叫混沌工程。
很自然的下一步是：既然这么有用，干脆让电脑全自动地、天天随机地搞破坏好了，人就不用管了。这一章说：别急。搞破坏这件事，最值钱的部分恰恰是人。
医院可以买一台机器，自动给每个人抽血、出报告。但「为什么要查这一项」「什么时候查」「报告上这个数偏高到底要不要紧」——这些都得医生来判断。
如果把医生拿掉，只剩机器每天自动出报告，你会得到一堆没人看懂的数字。机器负责「怎么查」，人负责「为什么查、什么时候查、查出来意味着什么」。
工程师常有一种直觉：人慢、人会犯错，所以能自动化的都该自动化，人越少越安全。
可这里有个怪事：活儿全交给机器后，人平时插不上手，慢慢就忘了系统长什么样；真出了机器没见过的情况，偏偏又得靠这些已经生疏的人来救场。自动化做得越彻底，人在最关键时刻反而越不熟。
好处是：演练不再是机器自顾自地跑，而是每一次都在更新人脑子里对系统的理解，下次真出事，人更知道该看哪里。
一句诚实的代价：人的时间有限，每次演练都要人来想、来看、来读，就做不了太多次——所以熟悉的老套路可以交给机器重复，新问题才值得占用人的注意力。
混沌工程不是「让机器自动搞破坏」，而是让人借着受控的破坏，更新自己对系统的理解——机器管「怎么做」，人管「为什么、什么时候、意味着什么」。
想看自动化的反讽、人机分工表和真实公司怎么做？ → 切到精读版
你以为混沌工程的终点是「全自动、无人值守」，其实它的产出不是一份故障清单，而是人脑中更准确的系统模型。实验的「为什么、怎么做、什么时候做」都是人的判断；自动化只该接管「怎么做」里可重复的那部分，而不是把人移出回路。
全书第 11 章，Part III「人的因素」第三篇，作者是 John Allspaw（Etsy 前 CTO、韧性工程方向的代表人物）。上承 Ch10 把组织当实验对象，下接 Ch12 用算法回答「该注入哪里」；本章站在两者之间，追问实验中哪些判断必须留给人。
设想一个已经做了几年混沌工程的团队：起初每次演练要三五个工程师花半天准备，后来平台化了，系统可以每天自动挑服务、自动注入、指标恶化自动中止。下一步看起来顺理成章——把人彻底拿掉，让实验像单元测试一样在流水线里静默运行。
Allspaw 认为这里藏着一个误解。混沌工程存在的理由，是复杂系统里没有人完整理解系统，每个人的心智模型都有偏差。实验之所以有价值，是因为它让人看到模型与现实的差距。如果实验全自动地跑、结果没人读，系统也许被「测过」了，但没有任何人的理解因此变好。不解决这个问题，团队会得到一个越来越自动、却越来越没人懂的系统。
本章把一次实验拆成三个问题，逐一看谁该回答：
常见的成功指标是「本季度发现了多少个漏洞」。Allspaw 的视角不同：实验真正的产出，是参与者对系统的认识发生了变化。一次「什么都没坏」的实验，若让大家发现某个降级路径其实从没被触发过、或监控面板根本看不出问题，价值可能高于一次找出小 bug 的实验。
由此推出一条可操作的判据：实验报告要回答「我们以为会怎样、实际怎样、差在哪」，而不只是列出待修工单。没有「以为」这一栏，实验就退化成了自动化测试。
本章的理论背景来自人因工程（human factors）：Lisanne Bainbridge 1983 年的经典论文《自动化的反讽》（Ironies of Automation）指出，把常规操作自动化后，人只剩下处理异常这一项最难的工作，却因为平时不再动手而技能退化、对现场情况不熟。
放到混沌工程上：如果实验平台全自动地选目标、跑实验、关工单，工程师就失去了一个了解系统的主要通道。等真正的事故来临——那恰是自动化没覆盖到的情况——人反而更陌生。所以自动化的目标应是扩展人的能力（让人能看更多、试更多），而不是替代人的判断。
自动中止条件是必需的：例如实验组成功率比对照组低超过事先约定的阈值，就立即停止并回滚。但阈值只覆盖预料到的坏法。实验期间出现阈值之外的异常——日志里冒出没见过的错误、另一个团队报告奇怪现象——是否停止、是否缩小范围，需要有人在场判断。
反过来，人也可能成为瓶颈：每次实验都要资深工程师盯全程，实验频率就被人的日程卡死。合理的做法是分级：已理解、重复运行的实验交给平台按阈值自动执行；新假设、新目标、触及核心路径的实验，必须有人设计、在场、复盘。
核心权衡是：自动化换来频率和一致性，代价是人的理解；人的参与换来理解和上下文，代价是规模。
| 环节 | 交给自动化 | 留给人 | 选错的代价 |
|---|---|---|---|
| 选目标（why） | 按依赖图、流量自动排序候选 | 结合事故历史与团队疑虑定优先级 | 全自动：试的都是好测的，不是最没底的 |
| 定时机（when） | 避开已知高峰与发布窗口 | 判断组织状态、业务事件 | 团队疲惫时出事，演练变真事故 |
| 执行（how） | 注入、分流、按阈值中止 | 设计假设与对照 | 纯手工：慢、易漏步骤、难重复 |
| 中止 | 可量化阈值（如成功率差 > 约定值） | 阈值外的异常信号 | 只靠阈值：没预料到的坏法放过去 |
| 解读 | 生成对比报表 | 回答「以为 vs 实际」 | 无人读：系统测过了，人没学到 |
每一行都不是二选一，而是边界画在哪里；边界应随实验从陌生变熟悉而右移。
业界的实践大体印证了「执行自动、判断留人」的分界。Netflix 后来的 ChAP 平台把实验执行做成了自动化：把一小部分流量分成对照组与实验组、指标偏离就自动停止（详见本书 Ch16 持续验证）；但它自动化的是「怎么做」，选哪些实验值得跑、结果意味着什么，仍是人的工作。面试里被问「混沌实验要不要全自动」，好答案不是是或否，而是能说出哪三类判断不能交出去。
大厂实证
① 核心命题：混沌工程的产出是人对系统更准确的理解，不是故障清单。
② 痛点：平台化后容易把人移出回路，系统被测了，人没学到。
③ 三问：为什么（选目标）和什么时候（时机）由人答；怎么做（执行）可自动化。
④ 实验报告必须有「以为 vs 实际」一栏，否则退化成自动化测试。
⑤ 自动化的反讽（Bainbridge 1983）：自动化越彻底，人在异常时越生疏。
⑥ 中止：阈值自动停管预料内的坏法，阈值外的异常要人判断。
⑦ 分级：新实验人在场，熟悉的回归实验交给平台，人退到审批与抽查。
⑧ 面试答法：不说「要不要全自动」，而说哪三类判断不能交出去。