事故复盘模板：从证据记录到验证行动

先分清事故复盘是什么、又不是什么

事故报告可以记录响应人员做了什么；根因分析可以研究故障机制；决策日志可以保存为什么做出选择。事故复盘把这些记录与量化影响、响应表现、不确定性、纠正工作以及后续有效性验证连接起来。

服务尚未稳定时不要抢着写复盘

事故仍在进行时，优先任务是安全发现、分级、遏制、恢复和沟通。现有 OpenMax 事故响应自动化页面回答的是实时响应任务。不要让事故指挥在恢复服务期间分心调整复盘格式。

达到内部政策规定的稳定条件后再打开复盘。保留实时事故记录的原貌，不要把它改写成事后看来“一切都很明显”的时间线。记录证据截止时间，避免迟到材料悄悄改变已经批准的结论。

不要把复盘压缩成一句“根因”

“是部署导致的”通常过于宽泛。部署可能只是触发因素；宽松默认值导致无限并发，才可能是直接机制；校验、金丝雀覆盖和告警配置则可能是促成条件。不同层次对应不同控制措施。

一句话也容易掩盖未知。如果生产环境没有保留配置的实际生效值，那么由配置差异、相关指标和预发布回放支持的机制仍应标为 PLAUSIBLE。这比把推断升级成事实，或者因为不能完全确认就删除它，更有助于后续验证。

复盘会议不是最终交付物

会议用于纠正记录和承诺行动；长期交付物是获批文档以及行动验证证据。开完会却只留下“加强监控”这类无负责人笔记，不算闭环。工单标为完成、但没有执行复盘中约定的测试，也不算闭环。

Google 的公开 SRE 指南将复盘视为包括影响、缓解、原因和后续工作的书面记录，并强调审核与系统学习。Atlassian 的公开事故手册也描述了影响、缓解、原因和跟进行动。这些资料可以支持流程设计，但不能证明同一模板适合所有组织政策。

复盘会前先冻结证据

高压事件过后，人的记忆会变化；仪表盘会把旧数据聚合掉；聊天记录可能被编辑；后来形成的理论还可能让模糊事件看起来像必然结果。证据登记表的价值，就是让这些变化可见。

每份证据都要有稳定编号和局限说明

每一条日志查询、追踪、告警、部署事件、工单或决策记录都应包含：

1. 稳定的证据编号；
2. 事件时间或覆盖区间及其时区；
3. 权威保存位置和访问级别；
4. 收集者或负责系统；
5. 它能支持的窄结论；
6. 它不能证明的内容。

例如，功能开关审计记录可以证明某条路径在特定时间被关闭，却不能证明队列已清空，也不能证明后续每份结果都正确。这两项结论需要不同证据。

受限证据应保留链接和脱敏摘要

面向较广读者的复盘文档不需要复制访问令牌、请求正文、个人信息或客户标识。原始材料应留在获批系统中，复盘只保存稳定链接、访问级别和最小必要摘要。审核者打不开证据时，应通过正常权限流程解决，或制作经批准的摘要，而不是把秘密粘贴到文档里。

安全、隐私、法务和客户通知问题必须交由对应专业人员判断。NIST SP 800-61 Rev.3 于 2025 年 4 月定稿，把事故响应与更广泛的网络风险管理和改进联系起来。但使用本模板不代表符合 NIST，也不能自动判断监管义务。

明确截止时间和补充记录规则

“证据截至 2026-09-04T12:00:00Z”可以被检查，“事故以后收集的证据”则不够明确。规定重要新材料必须进入补充记录、列出受影响的结论并触发相应复审。旧状态应继续保留，让读者理解结论为何改变。

影响计算必须固定分母

一句合格的影响描述应写明统计单位、总体规则、时间区间和结果类别。“数百名用户受到影响”不能从“数百次失败请求”直接推导出来。

先选择证据真正能计量的单位

单位可以是请求、任务、订单、账号或人员。只能选择现有证据可以可靠统计的单位。如果重试会让同一个人产生多个请求，那么请求级查询不能在没有安全去重方法和审核的情况下变成唯一用户估计。

PM081 使用的是“渲染尝试次数”。它不对用户、工作区、客户、收入或合同做任何推断。统计总体包括虚构区域中 09:07:11 至 10:18:00 UTC 收到的生产渲染尝试，并排除标记为内部健康检查的重试。

结果类别必须互斥且覆盖总体

使用写清楚的优先级，让每条符合条件的记录只进入一个类别。PM081 先判断超时，再判断旧校验和，最后判断预期校验和：

总数核对为 248 + 31 + 2,921 = 3,200；受影响次数为 248 + 31 = 279；影响比例为 279 / 3,200 × 100 = 8.71875%，展示为 8.72%。应保留未舍入值或查询结果，以便审核者重算展示值。

保留排除规则和查询版本

查询从 impact-v2 变成 impact-v3 时，要记录修改原因。不要覆盖早期导出，再让新数字看起来像一开始就已知。列出被排除记录及对应规则；批准前由数据负责人检查类别是否重叠、时间边界和关联逻辑。

用证据建立 UTC 时间线

时间线不是聊天记录全文。它只保留理解影响、发现、决策、缓解和恢复所需的事件，并把每个时间与证据连接起来。

区分事件时间、观察时间、报告时间和决策时间

超时可以发生在 09:07，支持报告可以在 09:20 到达，告警可以在 09:24 触发，事故则在 09:29 宣布。这些时间回答不同问题。如果把支持工单接收时间当作起点，PM081 已确认影响中的 12m52s 就会消失。

PM081 核心时间线如下：

指标名称之前先定义计时起止点

根据表格，首次确认影响到自动告警为 16m49s；宣布事故到执行缓解为 12m00s；首次确认影响到抽样恢复确认为 1h10m49s。

不要直接把它们叫做 MTTA 或 MTTR。不同组织对起点、终点、严重级别和暂停时间的定义不同。没有获批指标定义前，使用描述性区间名称，避免仪表盘标签改变历史含义。

恢复判断至少使用两种不同观察

空队列只能证明没有任务继续等待，不能证明返回的预览是最新内容。PM081 因此同时记录队列清空和一个定义好的正确性合成测试。即便两者都存在，也只能支持抽样恢复，不能证明所有结果无误。

无责分析不能牺牲因果严谨性

无责分析假定人员依据当时可见的信息和系统采取行动，然后检查哪些条件使不安全结果成为可能。它应提高坦诚程度，而不是取消责任。

分开记录触发因素、直接机制和促成条件

结论表中每一行只写一个命题：

• 触发因素： 启动故障路径的变更或事件；
• 直接机制： 实际产生可观察故障的技术或运营过程；
• 促成条件： 增加发生概率或影响程度的防护、界面、负载、文档或信号条件；
• 替代解释： 在证据确认或否定之前应保留的竞争性说明。

PM081 中，部署引入配置结构变更作为触发因素是 CONFIRMED。缺失的 max_inflight 被解释为无上限、继而耗尽下游连接池的理论仍为 PLAUSIBLE。校验器接受缺失或非正数、金丝雀缺少突发负载、队列时长告警延迟属于已确认促成条件。完整性扫描否定了“本次事故由数据库内容损坏导致”，但不会因此宣称所有数据库故障都不可能。

记录当时决策所处的合理环境

要问响应者看到了什么、当时可用的是哪个版本的操作手册、他们具有什么权限、同时还存在哪些风险。“为什么工程师没有早点做？”充满事后偏见；“09:12 当时能看到哪些信号，现行手册允许采取什么动作？”更可能产生证据和可以修改的系统条件。

这并不禁止记录人的错误，而是避免只停留在个人身份上，忽略可以降低复发概率的校验、默认值、权限、审核和负载设计。

未知项也要留在正式记录里

PM081 无法确定首条保留追踪之前是否已有受影响尝试，因此 C07 保持 UNKNOWN。不能因为它让故事不够整齐就删除它。若关闭这一证据缺口值得相应成本和隐私影响，负责人可以建立留存或遥测行动。

纠正行动必须能够验证

行动项应写清对应风险、具体变更、责任人、截止日期和可观察的验证合同。“以后更小心”和“加强监控”都达不到这个标准。

已实施与验证有效是两个状态

可以使用 OPEN、IN_PROGRESS、IMPLEMENTED、EFFECTIVENESS_VERIFIED 和 ACCEPTED_RISK。回滚手册发布新版本时可以标为已实施；只有规定的独立操作测试成功且证据完成审核后，才能标为验证有效。

PM081 的 A04 在回滚手册中加入关闭功能、检查积压与正确性验证。截止时它是 IMPLEMENTED，但独立演练尚未发生，因此案例拒绝把它写成有效。

关闭工单之前先写验证合同

“增加负载测试”只是一项任务。“在 40 个工作进程上限下回放 1,000 个预发布任务；确认队列排空、活动进程不超过 40、定义夹具没有旧结果”才是验证合同，它写明负载、阈值和观察结果。

这些数字只是 PM081 的虚构设计条件，不是适用于所有系统的建议。真实服务负责人必须依据架构和风险容忍度设定容量与正确性标准。

接受风险也要成为正式决定

有些行动的成本可能高于风险。如果有权限的负责人选择接受风险，应记录理由、范围、复查日期和授权人。重要取舍可以链接到决策日志模板形成独立历史。无人跟进不等于接受风险。

完整案例：PM081 怎样保留可复核性

可下载资料包故意保留了足够多的细节：九条证据、七种角色、七项因果结论、五项纠正行动、一份 60 分钟复盘议程和一张后续台账。没有证据的审批和后续观察则保持未完成状态。

虚构服务发生了什么

Northstar Preview 在 09:02:14 UTC 部署 v4.18.0。09:06:50 起，队列时长和连接池占用上升；09:07:11 出现首条保留超时。支持团队在自动告警前收到症状报告。响应人员宣布虚构 SEV-2、关闭新路径、观察积压清空，并运行定义好的合成夹具。

案例不会因为部署发生在前就认定部署本身是全部原因。当前直接机制仍需服务负责人独立审核。

每份响应证据都有能力边界

功能开关记录证明缓解操作发生，不证明恢复完整；队列归零证明积压清空，不证明内容最新；合成夹具提供正确性样本，不是全量证明；影响查询提供尝试次数，不是唯一人数。

资料包反复写“支持什么、不能证明什么”，是为了阻止证据承载超出自身的信息确定性。

为什么资料包不把过程写成成功案例

截止时有三项审核未完成：服务负责人审核机制、数据负责人审核影响查询、安全与披露筛查。没有任何纠正行动达到 EFFECTIVENESS_VERIFIED，文档继续保持 IN_REVIEW。

下载完整 PM081 资料包，先尝试重算影响比例和三个时间区间，再使用空白工作表。好的模板应该让分歧可以被检查，而不只是让报告看起来漂亮。

用复盘会议纠正记录并确认权限

主持人应在会议前发送草稿和证据访问说明。参与者应在会上修正证据和承诺，不应第一次在通话中阅读长文档。

会议顺序要保护分母和证据

PM081 的 60 分钟示例先用 5 分钟确认范围和无责规则，10 分钟核对影响，12 分钟修正时间线，15 分钟审核因果与替代解释，12 分钟确认行动，最后 6 分钟回读审批条件。

该时长只是演示。复杂安全事故可能需要多个专业场次；低复杂度运营事件在政策允许且分歧很少时，也可能异步完成。

邀请真正能够修正记录的角色

通常需要事故指挥、服务负责人、影响数据负责人、可观测性负责人、相关行动负责人和相对独立的主持人。事故范围需要时再加入安全、隐私、法务、沟通或供应商人员。参加会议不自动获得审批权，文档必须记录谁能签署哪一类结论。

结尾应回读未决项，而不是只做乐观总结

逐项回读被修改的结论、剩余未知、已接受行动、负责人、日期、验证标准、脱敏要求和审批条件。专业审核缺失时继续使用 IN_REVIEW。迟到证据改变结论时发布补充记录，不能静默覆盖历史。

如何有限度地测试 OpenMax

OpenMax 的公开 DevOps 用例页面描述了利用给定事故材料整理报告、提示缺失字段和跟踪后续行动的场景。这一供应商描述可以支持一次范围有限的草稿测试，但本页面没有测试产品、连接器、检索权限、输出准确性或官网中的性能数字。

先使用答案已知的资料包

把虚构 PM081 资料包作为输入，要求草稿保留：

1. E01–E09 以及每项局限；
2. 3,200 次尝试的完整核对和舍入后的 8.72%；
3. 事件、报告、告警、决策与恢复时间之间的差别；
4. C01–C07，并且不升级 PLAUSIBLE 或 UNKNOWN；
5. A01–A05 的当前状态和验证合同；
6. 尚未完成的审批清单。

将输出与资料包逐项对照。只要草稿虚构客户、把尝试变成用户、称 A04 已验证有效、删除未知项，或者把供应商说法当成独立证据，就应拒绝该草稿。

人工权限必须留在证据与审批关口

只有获授权人员才能选择或披露源材料；数据和服务负责人分别审核数量与技术结论；安全、隐私与法务人员控制敏感材料；复盘审批人决定发布状态。AI 生成的文字不会自动获得其中任何权限。

接入真实记录前，应让 OpenMax 或相关管理员确认当前连接器、留存、权限和数据处理条款。本页引用的公开用例不能替代环境级确认。

低复杂度情形优先选择更简单的方法

事故不频繁、证据量小的团队，稳定的文档模板加工作跟踪器可能已经足够。源材料授权未解决、审核人无法检查引用、组织尚未定义责任时，不要额外增加 AI 草稿层。最小可信下一步是一次脱敏且答案已知的练习，不是自主接入生产资料。

警惕漂亮报告掩盖的六种失败

不同草稿悄悄更换分母

一处统计请求，另一处却写成用户；或者时间窗口改变，比例没有更新。应使用版本化总体规则、互斥类别和明确核对公式。

时间线变成集体记忆

参与者同意大致顺序，却丢失告警、日志与决策链接。每个时间旁保留证据编号，并标注推断时间。

“根因”吸收了所有条件

宽泛段落无法映射控制措施。应分别记录触发因素、机制、促成条件、替代解释和未知项，并给每项状态。

无责被误解为无人负责

报告避免个人指责，却也不指定行动负责人。分析可以面向系统，但实施、验证与审批责任必须清晰。

完成被误认为有效

代码合并或手册写完时工单就关闭。应保留单独的有效性状态，并等待预先约定的观察证据。

为方便而复制敏感证据

令牌、客户内容或个人信息进入广泛共享文档。应使用受限稳定链接、经批准摘要和专业脱敏审核。

常见问题

什么事故需要正式复盘？

预先在政策中定义触发条件，例如严重等级、客户或数据影响、异常恢复操作、重复故障、合规义务或较高学习价值。不要等看到事故故事是否“好写”后再决定。例外应由有权限负责人批准。

应在事故后多久开复盘？

稳定后立即保存证据，并在上下文仍可获得时安排审核；同时要给影响查询和因果分析留下足够时间。具体窗口取决于严重度、证据留存和专业人员可用性，本指南不规定统一天数。

无责复盘等于没有问责吗？

不等于。无责分析避免把系统故障简化为个人过错；证据负责人、结论审核、行动负责人、截止日期、审批和有效性验证仍然清晰可见。

AI 可以直接确定根因吗？

AI 可以协助整理给定证据并指出缺失字段，但合理叙述不等于因果证明。服务负责人审核机制，数据负责人验证影响；安全、隐私、法律和监管影响由合格人员判断。

纠正行动什么时候才算完成？

至少区分“已实施”和“已验证有效”。关闭前先定义测试、阈值、证据和审核人。测试失败时重新打开或替换行动，不能改写行动的原始意图。

来源与相关 OpenMax 工作流

以下主要及官方来源于 2026-09-05 查阅：

• Google SRE Book：Postmortem Culture
• Google SRE Workbook：Postmortem Culture
• NIST SP 800-61 Rev.3：事故响应建议
• Atlassian 事故管理手册：Postmortems
• OpenMax DevOps 用例文档

实时处置流程可继续查看事故响应自动化；需要单独保存风险或优先级取舍时，可使用决策日志模板。发布前还应根据最新官方文档和内部政策复核产品能力与安全敏感指导。