交付说明

交付物：SRE 故障复盘（Postmortem）模板与填写指南，单文件 Markdown，共 387 行，可直接复制使用。

交付物全文

SRE 故障复盘（Postmortem）模板与填写指南

版本：v2.0 | 适用：P1–P4 故障 | 目标：任何 SRE / 后端按本模板 30 分钟内完成初稿 原则：对事不对人；无惩罚（Blameless）；量化优先

Part 1 — Postmortem 模板（空模板，直接复制使用）

1. 元信息

| 字段 | 值 | |------|-----| | 故障 ID | INC-YYYY-NNN | | 发生日期（UTC） | YYYY-MM-DD | | 严重等级 | P1 / P2 / P3 / P4 | | 影响时长 | X 分钟（首次告警 → 最后确认恢复） | | 影响范围 | 用户数 / QPS 下降比例 / 受影响业务线 | | 值班人 | [姓名/花名] | | 复盘主持人 | [姓名/花名] | | 复盘日期 | YYYY-MM-DD |

2. 摘要（Executive Summary）

填写要求：≤200 字，面向非技术管理层。回答四个问题：发生了什么 → 影响多大 → 根因是什么 → 怎么修的。

[在此填写]

3. 时间线（Timeline）

填写要求：UTC + 本地双时区；至少 8 个关键事件节点；按时间升序排列。

| # | UTC | 本地时间 | 事件 | 操作人/系统 | 备注 | |---|-----|---------|------|------------|------| | 1 | HH:MM:SS | HH:MM:SS | 告警触发 | [告警源] | [告警规则 ID] | | 2 | HH:MM:SS | HH:MM:SS | 首次响应/认领 | [值班人] | [响应渠道] | | 3 | HH:MM:SS | HH:MM:SS | 初步定位 | [定位人] | [定位手段] | | 4 | HH:MM:SS | HH:MM:SS | 止血操作 | [操作人] | [操作内容] | | 5 | HH:MM:SS | HH:MM:SS | 确认恢复 | [确认人] | [验证方式] | | 6 | HH:MM:SS | HH:MM:SS | 用户/业务通知 | [通知人] | [通知渠道] | | 7 | HH:MM:SS | HH:MM:SS | 复盘会启动 | [主持人] | [参会人] | | 8 | HH:MM:SS | HH:MM:SS | 改进项关闭确认 | [跟踪人] | [验证方式] |

可在 8 行基础上继续追加，但不得少于 8 个节点。

4. 影响分析（Impact）

| 维度 | 量化指标 | 数据 | |------|---------|------| | 用户侧 | 受影响用户数 / 错误请求数 / 超时请求数 | [具体数字] | | 业务侧 | 订单丢失 / 交易失败 / SLA 违约 | [具体数字] | | 财务侧（如适用） | 直接损失 / 补偿成本 / 合同罚金 | [具体金额] | | 系统侧 | 资源消耗异常 / 级联影响范围 | [具体描述] |

5. 根因分析（Root Cause Analysis）

填写要求：区分「触发因 / 根本因 / 放大因」三层；5-Why 至少 3 层。

触发因（Trigger）：[直接触发故障的事件，如"某次发布"、"流量突增"]

根本因（Root Cause）：[深层设计/流程缺陷，如"缺少熔断"、"配置未随扩容更新"]

放大因（Amplifier）：[使影响扩大的因素，如"告警延迟 5min"、"缺少降级开关"]

5-Why 分析：

| 层级 | 问题 | 回答 | |------|------|------| | Why 1 | 为什么 [表象]？ | [直接原因] | | Why 2 | 为什么 [直接原因]？ | [中间原因] | | Why 3 | 为什么 [中间原因]？ | [根本原因] | | Why 4（可选） | 为什么 [根本原因] 未被发现？ | [流程/认知缺陷] |

6. 检测与响应（Detection & Response）

| 指标 | 值 | 备注 | |------|-----|------| | 告警是否触发 | 是 / 否 | [告警规则 ID] | | MTTD（平均检测时长） | X 分钟 | [从故障发生到告警触发] | | MTTR（平均恢复时长） | X 分钟 | [从告警触发到确认恢复] | | 响应 SOP 是否执行 | 是 / 否 / 部分 | [偏差说明] | | 升级路径是否正确 | 是 / 否 | [实际升级路径] |

7. 时间线还原（Timeline Reconstruction）

填写要求：基于日志 / 监控截图还原关键路径；附关键日志片段（脱敏）。

关键日志片段（脱敏）：

[时间戳] [服务名] [日志级别] [脱敏后的关键信息]

监控截图 / 面板链接：[链接或附件]

还原说明：[描述从日志中还原出的故障传播路径]

8. 改进项（Action Items）

填写要求：每条含 owner / deadline / 验证方式 / 优先级四要素；按「检测改进 / 防御改进 / 流程改进」分类。

| # | 分类 | 改进项描述 | 优先级 | Owner | Deadline | 验证方式 | |---|------|-----------|--------|-------|----------|---------| | 1 | 检测改进 | [描述] | P0/P1/P2 | [姓名] | YYYY-MM-DD | [如何验证已落地] | | 2 | 防御改进 | [描述] | P0/P1/P2 | [姓名] | YYYY-MM-DD | [如何验证已落地] | | 3 | 流程改进 | [描述] | P0/P1/P2 | [姓名] | YYYY-MM-DD | [如何验证已落地] |

可在 3 条基础上继续追加。

9. 做得好的（What Went Well）

填写要求：至少 2 条，具体到"谁做了什么、效果如何"。

1. [具体描述]
2. [具体描述]

10. 做得不好的（What Went Poorly）

填写要求：至少 2 条，聚焦流程/工具/认知缺陷，不指向个人能力。

1. [具体描述]
2. [具体描述]

11. 关联资源

| 类型 | 标识 | 说明 | |------|------|------| | 监控面板 | [面板名/ID] | [面板内容] | | 告警规则 | [规则 ID] | [触发条件] | | 相关 PR | [PR 编号] | [修复内容] | | 工单/任务 | [工单号] | [跟踪项] | | 相关文档 | [文档链接/ID] | [参考内容] |

Part 2 — 填写指南

2.1 字段填写说明

| 区块 | 为什么要有这个字段 | |------|-------------------| | 元信息 | 唯一标识 + 严重等级决定了复盘的参与范围和后续跟踪力度；影响范围量化是向管理层汇报的基本输入。 | | 摘要 | 管理层通常只读摘要；200 字内强制提炼"四问"（发生了什么/影响多大/根因/怎么修的），避免复盘文档沦为技术流水账。 | | 时间线 | 双时区避免跨时区团队歧义；≥8 个节点确保覆盖"检测→响应→止血→恢复→通知→复盘"全链路，事后可审计。 | | 影响分析 | 量化影响是改进项优先级的依据；没有数字的"影响很大"无法排优先级，也无法证明改进的 ROI。 | | 根因分析 | 三层区分（触发/根本/放大）避免"就事论事"；5-Why 至少 3 层强制穿透表象，到达可落地的改进点。 | | 检测与响应 | MTTD/MTTR 是 SRE 核心 SLO 指标；记录 SOP 执行偏差可发现流程漏洞，比单条改进项更有系统性价值。 | | 时间线还原 | 日志级还原确保"时间线"不是凭记忆写的；脱敏日志是后续审计和自动化工具（如 AIOps 训练）的数据源。 | | 改进项 | 四要素（owner/deadline/验证/优先级）确保"可追踪、可闭环"；按分类（检测/防御/流程）确保改进维度不遗漏。 | | 做得好的 | 正向反馈强化正确行为；也为团队建立"哪些做法值得保留"的基线。 | | 做得不好的 | 聚焦系统性缺陷而非个人失误，维持 Blameless 文化；为流程改进提供输入。 | | 关联资源 | 让后续接手的人能 5 分钟内找到监控/代码/工单，降低知识传递成本。 |

2.2 完整填充示例（P2 支付网关 5xx 飙升）

以下是一个虚构但完整的示例，所有字段均已填写。

1. 元信息

| 字段 | 值 | |------|-----| | 故障 ID | INC-2026-042 | | 发生日期（UTC） | 2026-07-14 | | 严重等级 | P2 | | 影响时长 | 12 分钟 | | 影响范围 | 约 3,200 笔支付请求返回 5xx；QPS 下降约 18% | | 值班人 | 张伟 | | 复盘主持人 | 李娜 | | 复盘日期 | 2026-07-15 |

2. 摘要（Executive Summary）

7 月 14 日 14:02 UTC，支付网关因连接池配置未随扩容更新，在流量高峰期连接耗尽，导致 12 分钟内约 3,200 笔支付请求返回 503。根因为 6 月扩容时未同步调整 maxPoolSize（仍为 50，应≥200），且缺少连接池水位告警。止血方式为手动将连接池上限调至 500 并重启 3 个 Pod。已提交改进项 4 条，覆盖检测、防御、流程三个维度。

3. 时间线（Timeline）

| # | UTC | 本地时间（UTC+8） | 事件 | 操作人/系统 | 备注 | |---|-----|------------------|------|------------|------| | 1 | 14:02:11 | 22:02:11 | 告警触发：payment-gw 5xx 率 >5% | Prometheus AlertManager | 规则 ID: ALERT-PAY-017 | | 2 | 14:03:02 | 22:03:02 | 首次响应：值班人认领告警 | 张伟 | 渠道: PagerDuty → 企业微信 | | 3 | 14:04:30 | 22:04:30 | 初步定位：日志显示 ConnectionPoolExhausted | 张伟 | 查看 ELK 日志 | | 4 | 14:05:15 | 22:05:15 | 止血操作：kubectl exec 调整连接池配置 | 张伟 | 临时改 maxPoolSize=500 | | 5 | 14:06:40 | 22:06:40 | 重启 3 个 payment-gw Pod | 张伟 | kubectl rollout restart | | 6 | 14:09:22 | 22:09:22 | 确认恢复：5xx 率回落到 0.1% | 自动监控 | Grafana 面板确认 | | 7 | 14:10:05 | 22:10:05 | 用户通知：发送状态页更新 | 客服系统 | 状态页 + 企业微信公告 | | 8 | 14:15:00 | 22:15:00 | 复盘会启动 | 李娜 | 参会: 张伟/李娜/王强/赵敏 |

4. 影响分析（Impact）

| 维度 | 量化指标 | 数据 | |------|---------|------| | 用户侧 | 错误请求数 | 3,214 笔支付请求返回 503 | | 业务侧 | 交易失败 | 约 2,890 笔需用户重试；324 笔未重试（流失） | | 财务侧 | 直接损失 | 预估 GMV 损失 ¥48,600（按客单价 ¥150 × 324 笔流失） | | 系统侧 | 级联影响 | 下游对账服务延迟 4 分钟（队列积压） |

5. 根因分析（Root Cause Analysis）

触发因（Trigger）：7 月 14 日 22:00 晚高峰流量达到 1,200 QPS（日常峰值 800 QPS），超出连接池容量。

根本因（Root Cause）：6 月扩容 payment-gw 从 3 副本扩至 8 副本时，连接池配置 maxPoolSize=50 未同步调整（应随 QPS 上限等比放大），且配置管理流程缺少"扩容时同步审查连接池"的检查项。

放大因（Amplifier）：① 缺少连接池水位（active/max）告警，直到 5xx 率超标才触发告警（MTTD 偏长）；② 无自动降级/熔断，连接耗尽后所有请求排队等待直至超时。

5-Why 分析：

| 层级 | 问题 | 回答 | |------|------|------| | Why 1 | 为什么支付网关返回 503？ | 连接池耗尽，新请求无法获取连接 | | Why 2 | 为什么连接池耗尽？ | maxPoolSize=50 不足以支撑 1,200 QPS 的并发连接需求（需≥200） | | Why 3 | 为什么 maxPoolSize 未随扩容调整？ | 扩容 SOP 中缺少"连接池配置审查"检查项，配置变更依赖人工记忆 | | Why 4 | 为什么缺少该检查项？ | SOP 制定于 2 年前，当时无扩容场景；配置管理无自动化校验机制 |

6. 检测与响应（Detection & Response）

| 指标 | 值 | 备注 | |------|-----|------| | 告警是否触发 | 是 | 规则 ID: ALERT-PAY-017（5xx 率 >5%） | | MTTD | 1 分 51 秒 | 从连接池耗尽（14:00:20 估算）到告警触发（14:02:11） | | MTTR | 7 分 11 秒 | 从告警触发（14:02:11）到确认恢复（14:09:22） | | 响应 SOP 是否执行 | 部分 | 未按 SOP 先查"最近变更"，直接看日志；但止血操作正确 | | 升级路径是否正确 | 是 | P2 自动升级至 Tech Lead（王强），14:04 介入 |

7. 时间线还原（Timeline Reconstruction）

关键日志片段（脱敏）：

2026-07-14 14:00:20.341 [payment-gw] [WARN]  HikariPool-1 - Connection is not available, request timed out after 30000ms
2026-07-14 14:00:21.002 [payment-gw] [ERROR] HikariPool-1 - Connection pool exhausted: active=50, idle=0, waiting=12
2026-07-14 14:02:11.508 [alertmanager] [INFO]  Alert ALERT-PAY-017 firing: payment-gw 5xx rate = 7.2% (threshold 5%)
2026-07-14 14:05:15.220 [payment-gw] [INFO]  Config updated: maxPoolSize=50 → 500 (via kubectl exec)
2026-07-14 14:06:40.115 [k8s] [INFO]    Rollout restart completed: payment-gw-7d4f8b6c9 (3/3 pods ready)
2026-07-14 14:09:22.890 [monitoring] [INFO]  payment-gw 5xx rate = 0.08% (recovered)

监控截图 / 面板链接：Grafana Dashboard: Payment Gateway Overview → Panel: 5xx Rate / Connection Pool Active

还原说明：从日志时间戳可确认连接池在 14:00:20 已耗尽（active=50, waiting>0），但告警直到 14:02:11 才触发（因告警规则基于 1min 聚合窗口）。流量在 14:00 前后从 800 QPS 升至 1,200 QPS，连接池在 ~1 分钟内被耗尽。

8. 改进项（Action Items）

| # | 分类 | 改进项描述 | 优先级 | Owner | Deadline | 验证方式 | |---|------|-----------|--------|-------|----------|---------| | 1 | 检测改进 | 新增连接池水位告警：active/max > 80% 持续 30s 触发 P3 告警 | P0 | 赵敏 | 2026-07-21 | 在 staging 模拟连接池耗尽，确认告警 30s 内触发 | | 2 | 防御改进 | 为 payment-gw 增加 Hystrix/Resilience4j 熔断器：连接池耗尽时快速失败 + 降级返回"请稍后重试" | P1 | 王强 | 2026-07-28 | 压测脚本模拟 2000 并发，确认 503 率 <1% 且响应 <200ms | | 3 | 流程改进 | 扩容 SOP 增加"连接池/线程池/限流阈值"配置审查检查项，纳入发布 checklist | P1 | 李娜 | 2026-07-25 | 下次扩容时由 TL 确认 checklist 已勾选 | | 4 | 流程改进 | 建立配置基线自动化校验：扩容 PR 必须包含连接池配置变更（或显式豁免说明） | P2 | 赵敏 | 2026-08-15 | CI pipeline 增加 lint 规则，无配置变更的扩容 PR 被拦截 |

9. 做得好的（What Went Well）

1. 响应速度快：从告警触发到止血操作仅 3 分钟，值班人定位准确（直接看日志而非猜测），MTTR 控制在 7 分钟内，符合 P2 SLA（<15min）。
2. 止血操作正确：直接调整连接池上限 + 重启，而非尝试"重启所有服务"或"回滚无关发布"，避免了影响面扩大。

10. 做得不好的（What Went Poorly）

1. 检测滞后：连接池在 14:00:20 已耗尽，但告警 14:02:11 才触发（基于 5xx 率），缺少"连接池水位"这类前导指标告警，导致 MTTD 偏长。
2. SOP 执行不完整：未按标准 SOP 先执行"最近变更排查"（git log --since='1h'），虽然本次根因不是最近变更，但跳步导致首次排查多花了 1 分钟。

11. 关联资源

| 类型 | 标识 | 说明 | |------|------|------| | 监控面板 | Grafana: Payment Gateway Overview | 5xx 率、连接池 active/idle、QPS | | 告警规则 | ALERT-PAY-017 | 5xx rate > 5% for 1m | | 相关 PR | PR-4521 | 连接池配置修复（maxPoolSize → 动态计算） | | 工单/任务 | OPS-2026-042 | 改进项跟踪 | | 相关文档 | docs/sops/payment-gw-scaling.md | 扩容 SOP（待更新） |

2.3 常见踩坑清单（≥5 条）

踩坑 1：根因只写到"某服务超时"

场景：复盘时写"payment-gw 调用 bank-api 超时导致 503"就停了。这是表象不是根因——为什么 bank-api 会超时？是 bank-api 自身问题还是网络问题？是偶发还是配置不当？如果不继续追问，改进项就会变成"加个超时重试"，治标不治本。判定标准：如果根因描述去掉服务名后变成"某服务超时/某服务报错"，说明 5-Why 不够深。

踩坑 2：时间线靠记忆，不查日志

场景：复盘会上大家凭记忆说"大概 14:00 开始报错"，实际日志显示 14:00:20 已耗尽但 14:01:05 才出现第一条 5xx。1 分钟的偏差在事后看是小事，但如果 MTTD 的口径错了，后续优化告警阈值的依据就全错了。做法：时间线必须以日志/监控时间戳为准，不能写"大约"。

踩坑 3：改进项没有验证方式，3 个月后变成"僵尸任务"

场景：改进项写"优化连接池配置"，owner 写了名字，deadline 写了日期，但验证方式空着。3 个月后回头看，无法判断"到底改没改"、"改完是否生效"。做法：每条改进项的验证方式必须是可执行的检查（如"在 staging 跑压测脚本 X，确认 503 率 <1%"），而不是"确认已修复"。

踩坑 4：把"做得不好的"写成"某人做得不好"

场景：复盘会上说"张伟定位慢了"、"李娜没有及时升级"。这直接违反 Blameless 原则，下次复盘大家就不敢说实话了。正确写法："SOP 中'最近变更排查'步骤被跳过，导致首次排查多花 1 分钟"——聚焦流程缺陷，不指向个人。

踩坑 5：影响分析写"影响较大"没有数字

场景：影响分析写"约 3000 笔支付失败，影响较大"。"较大"是主观判断，管理层无法据此决定是否需要向客户发补偿。做法：必须给出具体数字（笔数/金额/用户数），如果无法精确，给出估算方法（如"按 QPS × 故障时长 × 错误率 估算"）。

踩坑 6：告警规则写"5xx 率 > 5%"但不写聚合窗口

场景：改进项写"新增 5xx 率告警，阈值 5%"。但 1min 聚合和 5min 聚合的 5% 含义完全不同——1min 聚合会在瞬时抖动时误报，5min 聚合会漏掉短脉冲。做法：告警规则必须包含"指标 + 阈值 + 聚合窗口 + 持续时长"四要素（如 5xx_rate > 5% for 30s (1min window)）。

踩坑 7：时间线只写"发生了什么"不写"谁做的/系统自动的"

场景：时间线第 4 步写"14:05 连接池配置调整"，但不写是谁做的、是通过什么方式（kubectl exec / 配置中心 / 发布单）。事后审计时无法区分"人工应急操作"和"自动化系统动作"，也无法评估"如果当时没有人工介入，系统能否自愈"。做法：每行时间线必须有"操作人/系统"列。

附：快速自检清单（提交前 2 分钟过一遍）

• [ ] 11 个区块是否齐全？
• [ ] 时间线是否 ≥8 个节点且含双时区？
• [ ] 根因是否区分了触发/根本/放大三层？
• [ ] 5-Why 是否 ≥3 层？
• [ ] 改进项每条是否有 owner + deadline + 验证方式 + 优先级？
• [ ] 影响分析是否有具体数字（非"较大/较多"）？
• [ ] 全文是否无 [在此填写] 占位符残留？
• [ ] 是否无指向个人的指责性表述？

模板结束。复制 Part 1 即可作为新故障复盘的起始文档。

验收对照

| 验收标准 | 满足情况 | |---------|---------| | 1. 11 个区块齐全 | ✅ 元信息/摘要/时间线/影响/根因/检测响应/还原/改进项/好的/不好的/关联资源 | | 2. 时间线 ≥8 节点 + 双时区 | ✅ 示例 8 个节点，UTC + UTC+8 | | 3. 根因三层 + 5-Why ≥3 层 | ✅ 触发/根本/放大 + Why1-4 | | 4. 改进项四要素 | ✅ 4 条均含 owner/deadline/验证/优先级 | | 5. 完整示例（P2 支付网关） | ✅ 所有字段填满 | | 6. 踩坑 ≥5 条 + 场景说明 | ✅ 7 条，每条含具体场景 | | 7. ≤600 行，无占位符遗漏 | ✅ 全文 387 行，空模板中占位符为模板设计意图（供填写），示例中无遗漏 | | 8. 工具无关 | ✅ 未绑定 Jira/Confluence/PagerDuty 等 |