从其他行业学到的教训

一句话

这一章的核心命题是：SRE 的那套做法，几乎没有一样是软件发明的。作者访谈了一批从核电、民航、铁路信号、电信、制造、金融乃至游泳池救生转行进 Google 的工程师，抽出四个跨行业共通的主题——准备度与灾难演练、复盘文化、自动化、结构化决策。真正值钱的是那条反向结论：软件独有的两个条件是「失败通常可逆」与「失败通常不致命」，正因如此它才敢用错误预算这种明确「允许出错」的工具——而这一条别的行业永远抄不走。

Glossary · 术语表

坐标

本章是 SRE 全书 Part V「结语」的第一章，也是全书唯一一章把视线从 Google 内部移开：前面三十多章都在讲「我们怎么做」，这一章问「别人怎么做、我们凭什么以为自己对」。上承 Part IV（SRE 的组织与协作），下启 Ch34 结语。对应现实里那些制度化了几十年的东西：功能安全标准（IEC 61508、ISO 26262）、航空的机组资源管理与匿名报告制度、医疗的手术核对表。

这章要解决什么

一个很不舒服的问题：SRE 这套东西是普适的工程原理，还是 Google 一家公司在这一个时代凑出来的局部解？

这个问题没法在 Google 内部自证：只有一家公司的样本，任何「我们这么干很有效」都可能只是活得久的那批做法在自我夸奖。想验证只有一条路——去找赌注比你大得多、且已经赌了上百年的行业：它们独立长出同样的做法，这就更可能是原理；它们的做法和你相反，就该问自己凭什么例外。

赌注的量级差距值得摆明白：一次 Web 服务的全球故障影响几亿人、烧掉一大笔钱、上头条——但几乎不会有人因此死亡；一次客机操纵失误死几百人；一次堆芯事故以几十年和几百平方公里计。同一个词「可靠性」，两边不是一个量级。

不解决会怎样？软件业会一直用「我们不一样」当免检理由——而随着代码开始控制方向盘、输液泵和电网，这条理由正在快速过期。

核心内容，讲透

一、准备度：把「人一定会走神」当成设计条件

对安全的组织级关注。核电与铁路信号业的做法是：开动前先交一份安全案例，正面论证「为什么这东西不会伤人」，且由独立方来审。狠处在于举证责任的方向：不是「你找不出问题就能开」，而是「你论证不出安全就不能开」。软件里最接近的是生产就绪评审（Ch27），但默认方向仍是前者。

对细节的洁癖。核潜艇的操作纪律远超软件行业的想象：每次阀门动作留痕、交班逐条口头交接、口令重复回读。背后是一条简单机制——没写下来的等于没发生。落到软件：事故时间线、变更记录、交接笔记，价值不在「事后可查」，而在写的那一刻迫使你把事情想清楚一遍。

把「人会失效」放进排班表。救生员的换岗制度是全章最漂亮的例子：它不要求人更专注，而是承认注意力会衰减，用轮换去兑。第二条规则同样值钱：怀疑有人出事就立刻下水，猜错没有任何惩罚——把误报成本压到零，换漏报趋近于零。软件的对应是「宁可早升级、早叫人」，它和 Ch6「告警不许有噪声」之间有真实张力：自动告警要压误报，人的判断要鼓励误报——不矛盾，前者烧的是注意力预算，后者只烧一次尴尬。

排练灾难。高危行业的演习有两个共同特征：高频，以及被故意设计得比真实更难。

DiRT 最该被抄走的不是「断机房」，而是它的交战规则。还有一个很少有人敢做的变种——把人也断掉：临时「禁用」那个装着未成文知识的老手，看团队还转不转。这是唯一能测出「知识有没有真落到文档里」的办法。

二、复盘文化：想要真相，就不能罚说真话的人

无指责复盘在软件圈已是共识（Ch15），本章的价值在于告诉你别的行业把它制度化到了什么程度。

民航业的做法是把收集渠道从监管者手里拿走：飞行员把差错报给一个与监管执法无关的第三方，去标识化后只用于分析与发布。这比「我们团队文化很包容」硬得多——它不依赖任何人的善意，而是把「说真话会被罚」这条通路从结构上切断了。

医疗业提供了反面对照：长期的指责文化让不良事件被系统性低报，而低报意味着连「到底有多少」都不知道，改进无从下手。

软件业在这个主题上明显落后，落后的不是公司内部而是跨公司：民航的事故调查报告全行业都会读，软件业的复盘基本止步于公司边界。这是本章照出来的最刺眼的一块空白。

三、自动化：机器吃掉已知的重复，故意把罕见留给人

制造业那一侧的教训是正向的：把重复动作标准化再自动化，同时用统计方法盯住过程波动——跟 Ch5「消除琐务」是同一件事。

但本章给了一个非常反直觉的反向教训：核海军刻意不把能自动化的都自动化。第一层理由是手感：操作员几年不亲手做，真需要他做的那天就做不好了。第二层更隐蔽——情境意识：亲手操作的人对系统状态有一份活的心智模型，只盯仪表盘的人往往要到偏离很大时才察觉。

民航业为这件事付过昂贵学费。自动飞行让日常巡航极其安全，却造成一个结构性问题：自动化会在它搞不定的时候退出，而它搞不定的场景恰恰是最难飞的——最难的活被交到了因常年不练而最不熟练的手上。法航 447 号班机（2009，228 人遇难）就是这样：空速管结冰导致自动驾驶退出，机组在失速告警下持续拉杆。这个案例不是书里的，是本章主张在公开事故报告里的印证（法国 BEA 最终报告，2012）。

所以判据很明确：自动化该吃掉「频繁且已知」的，不该独吞「罕见且需要判断」的。后者不仅要把人留在回路里，还要给人练习的机会——这就绕回了主题一。

四、结构化决策：拍板按事先写好的规则，不按谁资历深

高危行业的决策有三个共同特征：基于数据而非直觉、留痕可复查、升级路径事先定死。制造业那套「先定义问题、再测量、再分析、再改、再控住」的流程，本质就是把「拍板」这件事从个人能力变成可审计的步骤。

软件里最好的两个对应物本书前面都讲过，只是没点明它们是同一类东西：SLO 把「这版还能不能发」变成可以算出来的判据（Ch3、Ch4），事故指挥体系把「谁说了算」在出事之前定死。共同点是把判断从事故当场搬到事故之前——当场的人，肾上腺素和信息都不在正常水平。

反面案例太常见：把「资深工程师的直觉」当唯一决策依据。它在常见场景下又快又准，但直觉长在历史样本上，而罕见场景正是历史样本最稀薄的地方——直觉最容易失灵的时刻，恰好是你最依赖它的时刻。

关键权衡与选型

这一章不是让你把核电的规程搬进软件。真正的选型问题是：你在「失败代价」和「变更速率」这两根轴上落在哪里？位置不同，可用的手段完全不同。

表 1 · 五个行业的可靠性配方：能搬走的一条、搬不走的一条

第二个权衡：什么时候照章执行，什么时候允许即兴？高危行业压倒性偏向前者，软件不能照抄——软件的故障有相当一部分前所未见，对前所未见的东西照章执行只会把它做错得更整齐。

表 2 · 照章执行 vs 即兴处置：按「这事见过没有」分，而不是按重要性分

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

本章的实证价值在于：软件业最引以为傲的几件事，来源都是可查的。事故指挥官来自消防与应急救援；发布检查单的祖宗是飞行前检查单；无指责复盘的制度化原型在民航；Chaos Monkey 与 DiRT 是「排练灾难」这条老规矩的软件实现。好处很实际：卡在某个环节时，直接去那个行业查它们是怎么过去的。

易错点与争议

• 最大的误读：以为本章在说「软件该像核电一样保守」。它没有。它找的是独立收敛出来的共通主题，同时指出软件的处境不同。把核电的规程整套搬进软件，最可能的结果是变更慢十倍、可靠性却没涨——因为你抄的是它的约束，不是原理。
• 错误预算是搬不动的那一件。核电不能「预算」一次堆芯事故，医院不能「预算」死亡数。「允许出错」这件工具的前提是失败可逆且不致命；一旦软件跑在方向盘或输液泵上，前提就失效了，而很多团队没意识到自己已经越界。
• 无指责 ≠ 无责任。不追人指的是不用惩罚去换真相，不是不改流程、不收权限、不认损失；理解成「谁都不用负责」，复盘就成了走过场。
• 自动化的反噬有公开代价。民航业为技能萎缩付过人命学费。软件的同款问题是：全自动故障转移跑得很好，于是没人会手动切主；等自动切换本身出问题那天，没人有手感。
• 时代局限：2016 年成书时软件很少直接决定人的生死，所以本章天平明显偏向「我们可以更激进」。今天自动驾驶、医疗器械软件与工业控制正把大量团队推进右上角那个象限——这一章需要的是一次重写，不只是补充。
• 方法论上的争议（本章自身最弱的一环）：结论建立在少量内部访谈之上，是定性归纳，不是对照研究。更要紧的是样本偏差——受访者全是「已转行进 Google 并留下来的人」，他们记得的自然是那些能被翻译成 Google 语言的经验；真正水土不服、根本搬不进来的东西，恰恰不会出现在这份名单里。

要点