生产事故响应、值班与复盘完整指南

生产事故处理的目标不是尽快找到“谁改错了”，而是在信息不完整、时间紧迫的情况下控制影响、恢复服务、保持沟通，并把经验转化为可验证的改进。一个成熟的事故体系必须覆盖准备、发现、响应、恢复、复盘和整改跟踪，而不是只准备一份联系人表。

本文适用于应用、系统、网络、数据库和基础设施团队。文中的等级、时间和角色是参考模板，组织应根据业务影响、监管要求和人员规模调整。

一、事件、故障与事故

• 事件（Event）：系统状态发生变化，例如实例重启或延迟升高，不一定需要人工处理。
• 告警（Alert）：监控认为某个条件需要关注。
• 故障（Failure）：组件未按设计工作。
• 事故（Incident）：故障或操作已经影响、或很可能影响用户、数据、安全、收入或合规，需要协调响应。
• 问题（Problem）：一个或多个事故背后的未知或已知根因，需要长期治理。

不是每条告警都应升级为事故，也不能等到根因确定后才宣告事故。只要影响扩大、跨团队协作困难或需要统一对外沟通，就应尽早进入事故管理流程。

二、事故分级参考

分级应使用可观察条件，例如受影响用户比例、交易失败率、数据丢失风险、持续时间和区域范围。不要只用“服务器数量”判断严重程度。

三、事故前必须准备什么

1. 值班制度

值班表至少包含主值、备值和升级联系人。需要明确：

• 什么告警会叫醒值班人员；
• 多久未确认会自动升级；
• 无法登录生产环境时联系谁；
• 交接班需要说明哪些未解决风险；
• 连续值班和夜间事故后的休息安排；
• 外包或厂商参与时的数据与权限边界。

值班不是让一个人记住所有系统。每个可呼叫告警都应关联服务负责人、仪表盘和最小 Runbook。

2. 应急访问

需要定期验证：

• 单点登录、堡垒机和 MFA 是否在事故中仍可用；
• 紧急账号是否密封保管、按需启用并完整审计；
• 管理网络、带外管理和备用通信渠道是否可用；
• 关键文档是否能在主系统不可用时读取；
• 备份、DNS、证书、云账号和域名注册信息由谁控制。

3. 演练

演练应覆盖真实困难，而不只是走读文档。例如：主机房断电、证书过期、数据库误删、云账号异常、监控系统自身失效、值班人员无法联网。每次演练都应记录发现的问题和完成期限。

四、事故响应角色

人数不足时可以兼任，但职责不能消失。

事故指挥官（Incident Commander）

负责定级、分工、决策节奏和整体方向，不应同时埋头执行所有命令。指挥官要不断确认：当前影响是什么、最安全的止损动作是什么、还缺什么资源、下一次更新时间是什么。

技术负责人

组织证据收集、提出假设、评估修复和回退。技术负责人应阻止多人同时无记录地改动系统。

沟通负责人

面向客服、业务、管理层和外部用户统一发布状态。技术人员可以提供事实，但不应由多人分别给出互相矛盾的结论。

记录员

记录时间线、命令、变更、观察结果、决策和责任人。聊天记录不能完全替代结构化时间线。

领域专家

按需加入数据库、网络、安全、云平台、机房或供应商专家。加入后先阅读当前摘要，避免从头重复询问。

五、从告警到恢复的标准流程

第一步：确认信号

检查告警是否真实、监控是否失效，并使用独立信号交叉验证。例如内部指标显示网站异常时，再用外部探测、用户报障和日志确认。不要因为某个仪表盘为绿色就否认真实用户影响。

第二步：确定影响范围

快速回答：

• 哪些用户、区域、功能和数据受影响？
• 从什么时候开始？
• 是否仍在扩大？
• 最近有哪些发布、配置、证书、网络或依赖变化？
• 是否涉及数据完整性或安全风险？

第三步：宣告事故并建立即时协作空间

创建事故编号、沟通群或会议、时间线文档和状态页面。第一条摘要建议包含：

14:20 开始，华东区域登录失败率升至 38%，已定级 P1。当前暂停发布并回滚 14:10 的认证配置。下一次状态更新不晚于 14:35。事故指挥：张某；技术负责人：李某。

不要在事实不明时发布具体根因，也不要只说“正在处理中”。

第四步：先止损，再深挖根因

常见止损动作包括回滚最近变更、切换只读、隔离异常节点、停止批任务、降低流量、启用缓存或降级非核心功能。每个动作执行前应说明：

• 预期改善什么；
• 最大风险是什么；
• 由谁执行和复核；
• 多久判断是否有效；
• 无效时如何回退。

避免“重启看看”“多改几个参数试试”。一次只改变有限变量，并立即记录结果。

第五步：验证恢复

恢复不能只看进程启动或告警消失。至少验证：

• 用户关键路径成功；
• 错误率、延迟和吞吐回到可接受范围；
• 队列积压、复制延迟和失败任务已处理；
• 数据完整性和权限没有异常；
• 外部探测与客服反馈恢复；
• 临时措施不会在短时间后再次触发故障。

第六步：结束事故

只有影响稳定、监控正常、遗留风险有负责人时才能结束。临时修复必须转化为问题单，不能因为服务恢复就消失。

六、事故期间的沟通模板

首次通知

【P1】【INC-20261018-01】14:20 起部分用户无法登录。影响范围仍在确认，团队已暂停相关发布并开始回滚。当前没有确认数据丢失。下一次更新：14:35。

过程更新

14:32 更新：问题与认证配置变更高度相关，回滚已完成 70%，新请求成功率正在恢复。仍在处理失败队列。下一次更新：14:45。

恢复通知

15:05 更新：登录功能于 14:52 恢复，已连续观察 13 分钟，成功率和延迟恢复正常。失败队列已重放完成，暂未发现数据丢失。事故进入复盘阶段。

对外沟通只陈述事实、影响、当前措施和下一更新时间，不公开敏感架构、账号或未经确认的个人责任。

七、证据收集原则

• 先保存易失信息：当前连接、进程、队列、内存状态和临时日志；
• 所有时间统一时区，记录命令执行时间；
• 导出日志时脱敏，保留原始证据的完整性和访问记录；
• 安全事件避免在受感染主机上随意安装工具；
• 不因收集证据延误必要止损，但要记录做不到的部分；
• 把“观察结果”和“推测”分开书写。

八、无责复盘怎么写

复盘不是事故经过的聊天记录，也不是批评会。推荐结构：

1. 摘要：发生了什么、影响多大、持续多久；
2. 用户影响：哪些功能、客户和数据受到影响；
3. 发现方式：监控、用户还是人工发现，是否及时；
4. 时间线：关键事实、操作和沟通；
5. 促成条件：技术、流程、组织和环境因素；
6. 有效措施：哪些动作缩短了恢复；
7. 无效或有风险的措施：为什么没有达到预期；
8. 整改项：负责人、优先级、完成时间和验收证据；
9. 经验共享：其他系统是否存在同类风险。

“某人配置错误”不是充分根因。还要继续问：为什么错误配置能进入生产、为什么没有预检、为什么回滚慢、为什么监控没有提前发现。

九、整改项必须可验证

无效整改：

• 加强责任心；
• 后续多注意；
• 完善监控；
• 优化流程。

有效整改示例：

• 在 10 月 30 日前为认证配置增加语法和语义校验，错误样例加入流水线测试；
• 将生产变更改为 5% 金丝雀，连续 10 分钟错误率低于阈值才继续；
• 为登录成功率建立外部探测和燃尽率告警，并完成一次通知链路演练；
• 为回滚脚本增加版本检查、幂等验证和季度演练。

整改项完成后要提交验证证据。长期未完成的高风险项应升级，而不是一直保留在复盘文档中。

十、事故指标

不要用 MTTR 排名或惩罚个人，否则团队会降低事故等级、延迟宣告或隐藏问题。

十一、值班健康度检查

• 每个值班人员是否具备需要的权限和培训；
• 每班可呼叫告警数量是否合理；
• 夜间告警中有多少真正需要立即处理；
• 是否存在长期由一个人掌握的系统；
• 值班文档是否能由新成员独立执行；
• 是否有备值、交接和替班机制；
• 是否定期清理无动作告警；
• 事故后是否安排休息并提供心理安全环境。

十二、事故响应检查清单

响应阶段

• [ ] 确认真实用户影响；
• [ ] 定级并指定事故指挥官；
• [ ] 建立统一沟通空间和时间线；
• [ ] 暂停可能扩大影响的变更；
• [ ] 明确止损动作、风险和回退；
• [ ] 按约定周期更新状态；
• [ ] 使用业务路径验证恢复；
• [ ] 将临时措施登记为遗留风险。

复盘阶段

• [ ] 完成影响和时间线校对；
• [ ] 区分触发因素与系统性促成条件；
• [ ] 整改项有负责人、期限和验收方式；
• [ ] 排查其他系统是否有同类问题；
• [ ] 跟踪整改直至验证关闭；
• [ ] 将可复用经验更新到 Runbook 和演练。

十三、示例：一次配置变更导致登录失败

14:10，认证配置完成发布；14:18，外部探测发现登录成功率从99.9%下降到72%。值班人员没有先重启认证集群，而是对比变更时间、错误码和未变更区域，确认新配置高度相关。14:23宣告P1，暂停同系统发布并指定事故指挥官。技术负责人执行配置回滚，沟通负责人每15分钟更新影响。

14:35成功率恢复，但失败消息队列仍有积压，因此团队没有立即宣布结束。队列重放后抽取多类账号验证登录、令牌刷新和退出流程，并确认没有数据丢失。14:52业务恢复，继续观察15分钟后关闭事故。

复盘发现问题并不只是“配置写错”：测试环境缺少对应租户；配置校验只检查语法；生产直接全量发布；登录成功率没有短窗口告警；回滚需要人工查找旧版本。整改项因此分别落到测试数据、语义校验、金丝雀、SLO告警和一键回滚，而不是要求操作人员“以后仔细一点”。

这个案例体现三个关键点：事故中先恢复用户服务，根因分析可以随后继续；恢复验证必须覆盖积压和数据；整改应降低下一次同类错误进入生产或扩大影响的概率。

十四、参考资料

• Google SRE：Incident Management Guide
• Google SRE Workbook：Incident Response
• Google SRE：Emergency Response
• Google SRE：Postmortem Culture

成熟的事故体系不是保证系统永不失败，而是让团队在失败时能够快速协调、控制风险、透明沟通，并确保相同教训不会被反复支付。