《互联网产品的服务端架构·规模化与架构演进》附录 B 演练与应急预案模板

演练的目的不是证明系统不会坏，而是证明坏了以后有人知道该做什么。本附录把这件事拆成可以填写的表格与模板。

模板本身不产生价值。只有当它被填过、跑过、改过，才会变成团队的反应能力。

演练解决什么问题

没有演练的团队，第一次遇到故障时，往往同时面对三个问题：

• 不知道哪里坏了，观测点没覆盖。
• 不知道谁来决策，权限在谁手里不明确。
• 不知道先做什么，处置步骤只存在某个人脑子里。

演练的价值在于提前暴露这三件事。它检验的不是代码，而是「观测、决策、执行」这条链。

因此，演练的产出不是「通过了」，而是一份具体的问题清单：哪个指标没看到、哪一步卡了多久、哪个角色缺位。

演练的四种类型

不同类型的演练，成本与收益差别很大。不要一上来就做最重的。

建议的推进顺序是：桌面推演 → 单点演练 → 链路演练 → 全域演练。每一级跑顺了再升一级。

跳过前两级直接做全域演练，通常的结果是「演练本身变成一次故障」，而且没人有能力处理。

演练计划模板

一份演练计划至少回答五个问题：练什么、谁来看、什么时候、怎么算成功、出问题怎么办。

「成功标准」和「中止条件」是最容易漏的两栏。没有成功标准，演练结束只能写「基本正常」；没有中止条件，演练可能演变成事故。

演练剧本模板

剧本是执行时逐条对照的文档，不是给人看的报告。它应该细到「第几分钟做什么」。

前置条件

• 变更冻结已生效，演练窗口内无其他发布。
• 备份已完成，并抽验过一次恢复。
• 监控与告警已确认可用，关键看板已打开。
• 值班与升级名单已更新，所有人知道自己在剧本里的角色。
• 回退方案已演练过，或至少由两人独立确认可行。

前置条件不满足就不开始。这一条要写进剧本，而不是靠自觉。

注入方式

注入要可回滚、可限流、可观测。最忌讳的是「一把梭」：一次性注入大范围故障，然后把系统打挂。

观测点

剧本要提前列出「故障发生时应该看哪几个指标」，而不是事后去翻。

观测点缺失，是演练最常见的发现。演练结束后第一件事就是补监控。

判定标准

判定标准必须能在演练当场得出结论，不能留到事后分析。

好的判定标准是二值的：切换完成或未完成、数据丢失或未丢失、错误率超阈值或未超。

坏的判定标准是模糊的：「整体感觉还行」「用户应该没受影响」。

回退与中止

中止不是失败，是剧本的一部分。以下情况应立即中止：

• 错误率超过预设阈值且持续扩大。
• 影响到演练范围之外的业务。
• 关键角色联系不上。
• 出现数据不一致且无法快速确认范围。

中止后先恢复，再分析。不要在系统不正常的时候继续「观察一下」。

一次失败的演练

「回声」做过一次订单库主备切换演练。计划写得很完整，成功标准是 RTO ≤ 60 秒。

演练开始，主库被摘除。30 秒后，备库没有接管。执行的同学以为是切换脚本慢，又等了两分钟。这时错误率已经升到 12%。

问题出在三处：

• 切换脚本依赖一个配置中心开关，而这个开关在演练前被另一项变更关掉了。
• 观测看板只监控主库，备库状态不在看板上，没人第一时间发现没切过去。
• 剧本里写了「60 秒未完成则中止」，但中止条件由谁执行没写清，执行的同学不敢停。

演练中止后，团队补了三件事：切换脚本增加自检、备库状态进看板、中止权限明确给到值班负责人。

这次演练的价值不在「没通过」，而在于它暴露的三个问题如果发生在真实故障里，代价会高得多。

应急预案的结构

应急预案不是演练剧本的复制。剧本面向「已知故障的验证」，预案面向「未知故障的响应」。

一份可用的预案通常包含：

预案最常见的失效原因不是写得不全，而是「没人知道它在哪」。预案要放在值班同学三秒内能找到的地方。

故障分级与响应时限

分级的作用是让响应强度与影响匹配，避免小事大动干戈，也避免大事反应不足。

分级应该在故障发生后的几分钟内完成，而不是等查清原因。先定级，再处置，边处置边修正。

定级过高会消耗不必要的资源，定级过低会延误处置。判断不准时，宁可先高后低。

角色与职责

故障响应中最常见的混乱，是「大家都在看，没人做决定」。

小团队可以一人兼多角，但「指挥」和「执行」最好分开。同一个人既决策又动手，容易在压力下做出未经验证的操作。

值班与升级路径

值班不是排个表就完事。它需要三样东西：明确的响应时限、清晰的升级路径、可用的工具。

升级路径建议写成两级：

• 第一级：当班同学，负责初步判断与止血。
• 第二级：模块负责人，负责定位与修复。
• 第三级：技术负责人，负责跨团队协调与重大决策。

每一级都要有「多久联系不上就跳过」的规则。故障不会等人。

值班同学要能独立完成的事：看告警、查看板、执行预案里的标准操作、联系升级人。超出这些的，升级而不是硬扛。

沟通模板

沟通的目标是让相关方知道「发生了什么、影响多大、我们在做什么、下次更新是什么时候」。

对内通告

【故障通告 · P1】
现象：订单创建接口错误率上升至 18%，集中在华东区域。
开始时间：14:05。
影响：约 3% 的下单请求失败，支付不受影响。
当前动作：已摘除异常实例，正在观察。
下次更新：14:25。
指挥：张三；执行：李四；沟通：王五。

四个要素缺一不可：现象、影响、动作、下次更新时间。「下次更新时间」是最容易被省略、也最能让相关方安心的一项。

对外与状态页

对外沟通的原则是：说事实、说影响、说进展，不猜测原因，不承诺未确认的恢复时间。

【服务状态更新】
部分用户可能遇到下单失败。我们已定位到订单服务异常，正在处理。
其他功能正常。下一次更新将在 30 分钟内发布。

对外不要写内部术语、不要写责任人、不要写「预计 X 分钟恢复」除非已经验证。

演练记录模板

演练结束后 24 小时内完成记录，趁记忆还新。

「与预期差异」比「是否通过」更有价值。通过但过程惊险，和失败但发现了关键问题，后者通常更有收获。

改进跟踪

演练和复盘最大的浪费，是产出了一堆改进项然后没人跟。

改进项要满足三个条件才算闭环：

• 有唯一负责人，不是「团队」。
• 有明确截止时间，不是「尽快」。
• 有验收方式，能判断做没做完。

建议把改进项放进与业务需求同一个待办系统，而不是单独建一个文档。单独文档的下场通常是半年后没人打开。

每月过一遍未闭环的改进项，超过截止时间的要说明原因或重新排期。

成熟度自评

用下面这张表评估团队的演练能力，每项 0–2 分。

总分 14 分。低于 6 分说明还处在「出事靠人扛」的阶段，优先补预案与角色；6–10 分说明有基础，重点补演练类型与闭环；10 分以上可以考虑把演练编排进发布流程。

常见误区

• 把演练当表演。 提前打好招呼、选最顺的路径，演练通过但没验证任何东西。
• 只演练已知故障。 真实故障往往来自没想到的组合，要留一部分「随机故障」演练。
• 演练不影响真实流量就不算数。 影子流量能验证链路，但验证不了用户感知与业务影响。
• 复盘只写原因不写动作。 「因为配置错误」不是结论，「增加配置校验并纳入发布门禁」才是。
• 预案写完就锁进文档库。 预案要跟着架构变，架构变更不更新预案，等于没有预案。
• 把中止当丢人。 该停不停，才会把小问题变成大事故。

把模板放进研发流程

模板只有嵌进流程才会被使用。三个嵌入点：

• 发布流程：重大变更前，要求填写回退方案与影响范围，格式取自本附录的演练计划。
• 季度演练：把演练排进季度计划，与业务目标一起评审，而不是有空才做。
• 复盘流程：复盘必须产出改进项，改进项进待办系统并月度复查。

嵌入流程的关键是「不填就过不去」，而不是「建议填写」。

检查清单

上线前、演练前、故障后，可以分别对照下面三组问题。

演练前：

• 目标是否具体到可判定？
• 成功标准与中止条件是否都写了？
• 观测点是否覆盖入口、服务、依赖、数据、业务？
• 回退方案是否有人独立确认过？
• 参与人是否都知道自己的角色？

故障中：

• 是否已定级？
• 指挥是否明确？
• 是否已发出第一次对内通告？
• 是否记录了关键时间点？
• 是否有人负责对外沟通？

故障后：

• 是否在 24 小时内出了时间线？
• 改进项是否有负责人、截止时间、验收方式？
• 预案是否需要更新？
• 监控是否需要补点？
• 同类故障是否做过演练？

三组问题都能回答，说明团队的响应能力已经落到流程上，而不只是依赖个别人的经验。