Chaos Engineering 第 10 章 · 人性化的混沌

Chaos Engineering: System Resiliency in Practice · Ch 10 · Humanistic Chaos · 2020

这一章讲什么？

你半夜刷不开某个 App，第二天它恢复了。修好它的，除了服务器，还有一群被电话叫醒的人：谁先被叫醒、谁拍板、消息怎么传，决定了你等了五分钟还是五个小时。

前几章的混沌工程，是故意弄坏机器，看系统扛不扛得住。这一章说：团队本身也是一个系统，同样可以——也应该——被小心地「摇一摇」。

打个比方：消防演习

学校每学期搞消防演习。真正有用的演习不只是「拉警铃、大家往外走」，而是故意加点变数：「今天楼梯 A 封了」「平时带队的班主任请假了」。

一加变数，问题就冒出来：没人知道备用楼梯在哪；代课老师不知道集合点。这些问题在演习里暴露，比在真火灾里暴露便宜得多。

旧世界为什么难

很多公司把机器备了两份、三份，却没发现人只有一份：某个系统只有老王懂，老王一休假，出事就没人会修。

另一个老毛病是改组织「一刀切」：明天起换一套值班办法，全公司同时生效，不试点、也没想过改坏了怎么退回去。换成机器，没人敢这样上线新版本。

核心机制直觉：把演习的思路搬到人身上

先说清「正常是什么样」。比如：出了大事，十分钟内应该有人站出来指挥、客户能收到通知。
再加一个真实会发生的变数。最懂的那个人「这次不在」；平时用的聊天工具「这次用不了」。
从小范围开始。先在一个小组里演，演坏了随时喊停，不拿真实客户冒险。
改规矩也当实验做。想换值班办法？先让一个小组试几周，看指标变好还是变坏，不行就退回。

带来了什么 / 该怎么选

好处是那些「只存在于某个人脑子里」的知识被逼出来写成文档、教给别人；团队出事时不再靠一两个英雄硬扛，而是谁在场谁都能接上。

一句诚实的代价：对象是人，搞砸了伤的是信任——不打招呼地「突袭」别人，或者拿演习结果去评谁表现差，会让大家从此不敢说真话。

一句话记住

团队也是系统：人可能是单点，沟通会有延迟，规矩会出 bug——用演习的办法，小范围、可喊停地去试它，在真事故之前把这些弱点找出来。

想看三个真实案例、怎么定假设、怎么控制范围？ → 切到精读版

一句话

你以为混沌工程的对象是机器，其实组织本身就是一个复杂分布式系统：人是节点，沟通是网络，流程是协议。混沌工程的四条原则——定义稳态、提出假设、变化真实事件、控制爆炸半径——可以原样拿来安全地试探、甚至安全地改变一个组织。

Glossary · 术语表

社会技术系统（sociotechnical system）：把人、团队、流程和软件硬件看成一个整体的系统，坏与好都由两者共同决定。
游戏日（Game Day）：事先安排好的故障演练日，团队在受控条件下制造或模拟故障，练习发现与处置。
事故指挥体系（Incident Command System, ICS）：源自美国消防的应急组织方法，按角色而不是按职级分工：谁指挥、谁动手、谁对外沟通。
事故指挥官（Incident Commander, IC）：事故中负责协调与拍板的人，原则上自己不动手修。
值班（on-call）：轮流负责在非工作时间接告警、处理故障的安排。
稳态（steady state）：系统「正常」时可观测的指标水平，实验用它判断有没有出问题。
爆炸半径（blast radius）：一次实验如果出岔子，最多会波及多大范围。
适应能力（adaptive capacity）：系统（包括其中的人）在意料之外的情况下调整做法、继续运转的能力。
弱信号（weak signal）：事故前零散、模糊、单看不起眼的异常迹象。

坐标

全书第 10 章，Part III「人的因素」的第二篇，作者 Andy Fleener（体育类 SaaS 公司 SportsEngine 的平台运维负责人）。上承 Ch9 用设计会挖人脑里的盲区，下接 Ch11 人在回路；本章把「人」从实验的观察者变成实验的对象。

这章要解决什么

摆一个典型场景：一个 SaaS 平台，基础设施做了多可用区冗余，任何一台数据库宕掉都能自动切换。但凌晨三点的一次大故障里，真正卡住恢复的是：值班的人不确定该不该叫醒数据库负责人；三个团队在三个聊天频道各查各的；客服二十分钟后才知道出事。技术上没有单点，组织上处处是单点。

传统做法有两个盲区。一是只摇机器不摇人：故障演练检验的是自动切换，从没检验过「最懂的人不在」时会怎样。二是改组织不做实验：换值班制度、重组团队，通常全员一夜切换，没有灰度、没有回滚开关——这恰恰是混沌工程在技术侧最反对的上线方式。

所以本章的问题是：能不能把混沌工程的方法用在人和组织上，提前暴露组织的脆弱点，并且让组织变更像代码变更一样可试、可退？

核心内容，讲透

一、把「socio」放回社会技术系统

本章的出发点是一个常被忽略的事实：事故里的系统从来不只有软件。一个告警响了，接下来发生的事——谁看到、怎么判断、找谁、何时升级——全是人的行为。组织是由系统组成的系统：每个团队有自己的目标、工具和习惯，团队之间靠沟通耦合。

一旦这样看，技术侧熟悉的概念都能找到对应：节点是人和角色，网络是沟通渠道，协议是流程，单点就是那个「只有一个人懂」的环节，而沟通的来回就是组织的网络延迟。

把组织看成分布式系统：每个技术概念都有人的对应物，混沌工程的方法因此可以平移。

二、适应能力：成功与失败是同一枚硬币

本章站在韧性工程的「新视角」上：大多数日子里系统没出事，不是因为没有扰动，而是人在不断地、往往没被看见地调整——有人顺手重启了卡住的任务，有人注意到某个指标怪怪的去问了一句。成功和失败来自同一种适应行为，只是结果不同（这就是 Hollnagel 所说的 Safety-II：研究「为什么平常没出事」，而不只研究出事）。

所以工程目标不只是「消灭错误」，而是培养适应能力：让更多人能识别弱信号、能接手陌生的局面。混沌实验在这里的作用，是在可控条件下给组织制造「意料之外」，看适应能力在哪里够、在哪里断。

三、把四条原则平移到人身上

稳态：组织也有可观测的「正常」。例如：重大事故中多快有人担任 IC、多快对外发出第一条通知、多少人被拉进来。
假设：「最懂这套系统的人不在场时，团队仍能在约定时间内定位问题」——要可证伪，事前写下。
变化真实事件：注入的必须是真会发生的事：关键人休假或联系不上、主沟通工具不可用、新人第一次值班。
控制爆炸半径：先在演练中、先在一个团队里，随时可喊停；参与者知情，结果只用于改进流程，不用于评人。

四、三个案例：SportsEngine 的实践

本章用作者所在平台运维团队与产品研发组织的三个案例，把上面的原则落地。每个案例留一条可带走的判据：

「玩转游戏日」（Gaming Your Game Days）：游戏日不该只考机器能否自愈，更要考人：谁担任指挥、信息怎么在团队间流动、手册写的和实际做的是否一致。判据：一次游戏日结束时，如果收获全是技术问题、没有一条关于角色与沟通的发现，说明它只演练了一半。
「连点成线」（Connecting the Dots）：事故前的弱信号往往分散在不同人手里，单看都不起眼。判据：问「这个信号谁看到了、他会告诉谁」，如果答案是「没人会说」，组织的这条链路就是断的——这和监控里没人订阅的告警是同一种缺陷。
「安全地改变一个基本假设」（Changing a Basic Assumption Safely）：组织里有些前提人人默认、从没被检验过。要改它，就像上线高风险变更：先写假设与成功指标，小范围试点，观察稳态，准备好退回的路。判据：任何组织变更都应能回答「爆炸半径多大、怎么回滚」。

五、沟通是网络延迟，领导力是涌现属性

在事故里，沟通就是组织的网络延迟：同一个发现在三个频道里各说一遍、IC 不知道哪条消息最新，等于丢包加重传。ICS 式的固定角色（指挥、操作、对外沟通）和单一事故频道，本质是给这张网络定协议。

另一条观察是：领导力是系统的涌现属性，而不是职位。事故中谁来协调，应由角色与训练决定，而不是谁职级最高——所以 IC 应当是可轮换、可被训练出来的角色，实验可以专门检验「平时那位 IC 不在时，别人能不能接上」。

关键权衡与选型

第一张表：同一个原则，在机器上和在人身上的差别。

维度	技术混沌	人性化的混沌
注入什么	杀进程、加延迟、断网	关键人缺席、工具不可用、角色轮换
稳态指标	成功率、`p99` 延迟	IC 就位时间、首次对外通报时间
可重复性	高，同样注入大致同样结果	低，人会学习，第二次就不一样
主要风险	用户受影响	信任受损、被当成绩效考核
知情同意	通知相关团队即可	参与者须知情，结果不评人

人会学习、会记住被「整」的感受，所以组织实验的爆炸半径要按信任算，而不只按用户影响算。

第二张表：几种组织层面的扰动方式怎么选。

方式	适合	代价
纸上推演	刚起步、流程还没成文	便宜，但不检验真实反应
游戏日（含人的变数）	检验角色、沟通、交接	每次数小时、多人投入
流程变更小组试点	换值班、换升级规则、重组	周期长（数周），指标易受噪声干扰
真实事故中轮换 IC	有成熟培训与后备时	真用户在线，须有资深者兜底

流程只存在于少数人脑子里：先纸上推演把它写出来，再上游戏日。
团队有明显的「英雄」：游戏日专门让英雄缺席，最快暴露知识单点。
要改一个全员默认的规矩：别一夜切换，按灰度发布的方式试点、量指标、留退路。

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

ICS 本身就是一个「把人当系统设计」的成功先例：它诞生于 1970 年代美国加州山火的多机构协同救火，后来被软件行业的事故响应广泛借用。本章的贡献是再往前走一步——不只照搬这套协议，还要用实验去检验它在你的组织里是否真的生效。

面试或架构评审里被问「你们的系统有没有单点」，只答数据库主从是一个层级；能接着说「我们也检查人员单点：游戏日会让主要负责人缺席，IC 是轮换角色、按流程培养」，说明你理解可靠性是社会技术系统的属性。

大厂实证

PagerDuty：指挥官按角色、不按职级，且自己不动手。其公开的事故响应文档写道，IC「become the highest ranking individual on any major incident call, regardless of their day-to-day rank」，并强调「You should not be performing any actions or remediations, checking graphs, or investigating logs」——这正是「领导力来自角色」的落地。PagerDuty · Incident Response Docs · Incident Commander 培训页（github.com/PagerDuty/incident-response-docs，经本次运行核实）
同一份文档把「人」当成要演练的部件。IC 的培养路径包括跟岗、反向跟岗，以及「Participate in Failure Friday」——在其故障演练中担任记录员、再担任 IC；毕业标准是「an IC puts themselves on the schedules」。同上
Safety-II 的定义。曾在 Netflix 混沌工程团队工作的 Lorin Hochstein 维护的韧性工程资料汇编，把 Safety-II 概括为「the system’s ability to succeed under varying conditions」，并写「performance is always variable」——本章「成功与失败同源」的理论来源。Lorin Hochstein · resilience-engineering（github.com/lorin/resilience-engineering，经本次运行核实）

易错点与争议

把「摇人」做成突袭。不打招呼地拿掉某人、看团队出丑，短期也许暴露问题，长期毁掉心理安全——下次没人愿意说真话。人性化（humanistic）这个词的重点正在这里。
拿实验结果评人。演练是在测流程和组织，不是在测个人；一旦结果进了绩效，大家会演给你看。
以为组织实验可复现。人会学习，同一场演练第二次就失真；要不断变化场景，而不是反复跑同一个剧本。
只搬 ICS 的名词。设了 IC 角色却从不演练、只有一个人会当，等于纸面冗余。
指标被噪声淹没。组织变更的效果周期长、样本少，「IC 就位时间」几周内的变化很难归因；要诚实对待结论的不确定性。
局限。本章以单一公司的实践经验为主，缺少跨组织的量化证据；对小团队而言，专门为人做实验的成本可能高于收益。但它把可靠性的边界从机器扩到了组织，这是后面 Ch11、Ch18 的伏笔。

要点

① 核心命题：组织是复杂分布式系统，混沌工程的四条原则可以原样用来试探和改变它。

② 痛点：技术冗余做足了，人仍是单点；组织变更常一夜全量切换、没有回滚。

③ 对应关系：人＝节点，沟通＝网络（延迟），流程＝协议，「只有一个人懂」＝单点故障。

④ 韧性观：成功与失败来自同一种适应行为（Safety-II），目标是培养适应能力、识别弱信号。

⑤ 平移原则：组织稳态（IC 就位、对外通报时间）、可证伪假设、真实变数（关键人缺席）、小爆炸半径＋知情。

⑥ 三个案例：游戏日要演练人；把散落的弱信号连成线；改基本假设要像灰度发布一样可退。

⑦ 沟通是组织的网络延迟；领导力是涌现属性，IC 按角色轮换、可训练。

⑧ 易错：突袭伤信任、结果评人、以为可复现、只搬名词不演练。