Google 灾难恢复演练 DiRT

一句话

你以为灾难演练是在验证技术冗余够不够。Google 跑了十余年 DiRT 得到的结论恰恰相反：技术冗余大多是好的，真正的单点落在流程、权限、文档和人身上——而这四样从来不在任何自动化测试、任何 SLO 里。所以 DiRT 把「被测系统」的边界从服务扩到整个公司的恢复能力，连「关键工程师联系不上」都当成一种可注入的故障；同时用一套交战规则（rules of engagement）保证摇公司不会变成毁公司。

Glossary · 术语表

坐标

全书 21 章的第 5 章，Part II「原则落地」的第二篇。和上一章同一种姿势、不同量级：Ch4 的 Slack 把一个存量系统推到人在回路的演练，Ch5 把这套做法放大到公司规模，并把非技术对象正式纳入被测范围；往下 Ch7 是 LinkedIn 对爆炸半径的伦理约束，Ch8 是 Capital One 在金融合规下的渐进路线。现实里它对着的，是已有多机房冗余、也有一份写好的 DR / BCP 文档、却从没真验过的组织。

这章要解决什么

一个典型的大型服务，技术冗余看起来是满的：三个以上区域、数据多副本、流量能按区域切、RPO 接近零、RTO 写着 15 分钟。但这些数字是部件级承诺，拼起来不等于「公司能从一场灾难里恢复」。

缺的是中间那层。真实的区域级事故里，恢复动作长这样：有人判定这是事故 → 定级 → 找到有权限的人批准切换 → 翻出预案 → 执行一串从没在生产跑过的命令 → 通知客服与上下游。这条链上只有一步是技术，其余全是流程、权限、文档和人——而它们一个都没被测过。

不解决会怎样？三种很典型的失败：

• 人形单点。真会操作切换的只有一个人，隐性知识没进文档。Google 早期的 DiRT 测试就直接问：「这位工程师在把服务拉起来这件事上，是不是一个单点？」
• 恢复路径的循环依赖。预案存在内网 wiki，而 wiki 跑在挂掉的那个区域。
• 决策悬空。所有人都在等一个够级别的人点头切换，而值班表也在挂掉的系统里。这类延迟常比技术恢复本身长一个数量级：切换 5 分钟，找人与决策 90 分钟。

所以这章的问题是：怎么在不制造真事故的前提下，验证「整个公司」的恢复能力，而不只是「每个组件」的冗余？

核心内容，讲透

被测对象有四层，冗余都做在最里面那层

这是本章最该带走的一张图。把一次恢复拆开，依次是：技术组件 → 流程与权限 → 文档与工具链 → 人。工程投入和自动化测试几乎只覆盖第一层，而真出事时断掉的概率从第一层往下递增。

原因不神秘：第一层有拥有者、有监控、有 CI；后三层没有拥有者——没人给「审批链」写单元测试，也没人每周验一次预案里的命令还能不能跑。DiRT 的价值几乎全在后三层：它是目前唯一能给这三层打分的手段。

恢复路径的循环依赖：几乎只能靠演练发现的一类 bug

这是第③层最锋利的失效，而且静态审查几乎看不出来：架构图上恢复工具和被恢复的系统是两个框，没人注意到它们最终落在同一个故障域里。

典型形态：区域 A 失联 → 按预案处置 → 预案在内网 wiki → wiki 只跑在区域 A。四步成环，卡死。变体很多：事故频道依赖的 SaaS、登录要过的 SSO、下发配置的控制面，甚至机房门禁。

判据只有一句，拿它去问每一份预案：恢复 X 所依赖的一切（文档、工具、凭据、沟通、人），是否都不在 X 的故障域里？答不上来就说明你需要一次演练，而不是一次评审。解法是每一环都备带外通道：离线的预案副本（导出 PDF 也算）、不依赖主站的第二条沟通渠道、独立的应急凭据。

交战规则：让「摇公司」不变成「毁公司」

演练放大到公司规模，风险也跟着放大。本章的护栏是一套事先公布、所有团队必须遵守的规则，核心四条：

• 真事故永远压过演练。线上一出真问题，所有演练立即中止。不写进规则就会出现「两边都在救」的最坏情况。
• 每个测试自带回滚方案。同上一章的要求：撤回的确切操作、生效耗时、谁能喊停。
• 影响预期写明。是否预计影响线上，要写成可判断的句子，不是「应该没事」。
• 评审与分级审批。跨职能技术团队评审通过；有较高概率影响线上的升到 VP 级批准。这条最易被低估：它把「这实验值不值得做」从工程判断变成一次有人署名的业务决策。

还有一条隐含规则：沟通协议——何时发公告、发给谁、用什么前缀标明「这是演练」。没有它，演练会在别的团队那里被当成真事故，触发一串真的升级。

真实性阶梯与那条「我会去…」判据

不是所有故障都能真注入：「总部所在城市发生强震」只能纸上演。于是有一道由虚到实的阶梯：纸上推演 → 角色扮演（Google 内部叫 Wheel of Misfortune，由一位资深工程师当主持人出题）→ 受控真实注入 → 全公司多日演练。

越往上越真，但纸上那几档有个致命陷阱：参与者说的是「应该怎么做」，不是真做。「我会去查那份预案」「我会找 X 批准」——听起来完美，掩盖的恰恰是第③④层的全部问题。

所以本章最可操作的判据是：凡回答里出现「我会去…」，当场要求他真做一次。现在打开那份预案、现在打那个电话、现在跑那条命令。主持人还能反向加压——被叫来救场的资深工程师，判定「正卡在没信号的地铁车厢里」。这是把演练从「我们知道该怎么做」逼成「我们刚才真做到了」。

结果收集：失败的测试才是产出

最后一环最容易被省掉。要求是：每个发现变成有明确负责人的待修项，修完重跑同一个测试——没有重跑，你只有一份结论，没有回归。

还有一条文化要求：「演练通过」不是目标，学到东西才是。全部通过其实是设计失败，说明只摇了已有信心的部分。政治前提也在这里：一旦暴露的问题被用来追责，下次就没人敢把悲观假设写进方案（Ch18 的主题）。

关键权衡与选型

第一张表是真实性阶梯的落地：手上这个故障场景该用哪一档。关键在认清每一档各自抓不到什么。

越往下越真也越贵。误区是只做两头：要么只填表，要么只砸年度大演练——中间两档性价比最高。

第二张表按被测的四层给出测法与代价。

落到具体选择：

• 十几人的小团队：别模仿年度大演练，做第二档——一小时角色扮演、强制「当场打开」。第一次大概就能捞到两三份失效预案和一个人形单点。
• 有合规 DR 要求的组织：危险不是不做，是做成填表。一条判据就能救回来：这次演练有没有任何一件事是事先不确定结果的？答「没有」，那就只是表演。
• 平台 / SRE 团队想铺开：先投三样——方案模板（含回滚与影响预期）、主持人培训、结果跟踪到复测的闭环。注入手段不是瓶颈。

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

这一章给的是三句能直接改变灾备评审结论的话。一：RPO / RTO 只承诺第①层，公司级恢复能力是四层串联的结果。二：恢复 X 所依赖的一切，都不许在 X 的故障域里。三：凡回答里出现「我会去…」，当场要求他真做一次。

面试被问「你们怎么做灾备演练」，答「每季度做一次故障切换」是组件层；答「流程、预案和关键人也是被测对象，事先约定真事故优先与回滚方案，结果跟踪到复测」是另一个层级——它显示你知道要测的是四层。

易错点与争议

• 做成填表。最常见的退化：年度 DR 演练按剧本走完、全部通过、报告归档。判据见上。
• 全部通过就庆祝。全通过说明只摇了已有信心的部分，是设计失败——失败的测试才是产出。
• 把纸上推演当验证。它只验决策链。不逼「当场打开」，第③④层一个问题都抓不到。
• 「摇人」被当成针对个人。最需要配套沟通的一条：测的是「这件事只有一个人会」这个系统缺陷，不是那个人不行。讲不清就变成得罪人的游戏。
• 只有大公司玩得起。误解：最便宜那一档几乎零成本，而循环依赖和人形单点在小公司更严重——它的 bus factor 本来就低。
• 争议：频率太低、自动化太少。按 Ch3 原则四，年度大演练不合格。诚实的辩护是第②③④层目前没有自动化手段；但把第①层也锁在年度演练里，就是真落后了。
• 时代局限。这是工具链高度自建的 Google 的经验。今天典型公司的恢复路径横跨多个 SaaS：事故频道、告警、SSO、CI 分属不同厂商，你对它们的故障域几乎没有可见性——循环依赖的面更大而不是更小，这条判据因此比写作时更值钱。

要点