📦 Postmortem Generator — 事后分析报告生成器

事后分析报告生成器 生成无责备的事后分析报告，以防止重复发生的事件。 从警报、聊天记录和指标中编译时间线，生成结构化报告，包括根本原因分析、促成因素和跟踪的操作项——遵循Google SRE和Etsy无责备格式。 使用时： "写事后分析报告"、"事件回顾"、"无责备回顾"、"中断期间发生了什么"、"事件报告"、"事件后回顾"，或在任何SEV1/SEV2事件之后。

命令

• generate — 从事件数据创建事后分析报告

步骤1：收集时间线数据 # PagerDuty事件时间线 curl -s "https://api.pagerduty.com/incidents/$INCIDENT_ID/log_entries" \ -H "Authorization: Token token=$PD_TOKEN" | python3 -c " import json, sys entries = json.load(sys.stdin)['log_entries'] for e in entries: ts = e['created_at'][:19] entry_type = e['type'] summary = e.get('summary', e.get('channel', {}).get('summary', '')) print(f'{ts} [{entry_type}] {summary}') " # 告警历史（Prometheus/Alertmanager） curl -s "http://alertmanager:9093/api/v2/alerts?filter=incident_id=$INCIDENT_ID" | python3 -c " import json, sys alerts = json.load(sys.stdin) for a in sorted(alerts, key=lambda x: x['startsAt']): print(f'{a[\"startsAt\"][:19]} 告警：{a[\"labels\"][\"alertname\"]} ({a[\"status\"]})') " # 事件时间周围的Git部署 git log --since="$INCIDENT_START" --until="$INCIDENT_END" --oneline 2>/dev/null

步骤2：分析根本原因 使用"5个为什么"技术： 为什么服务宕机？→ 数据库连接池耗尽 为什么连接池耗尽？→ 慢速查询占用连接 为什么查询慢？→ 新列缺少索引 为什么索引缺少？→ 迁移没有包括它 为什么没有被捕获？→ CI中没有查询性能测试 确定： 根本原因：最深的可以采取行动的"为什么" 促成因素：使其变得更糟糕的因素（没有告警、手动过程、缺少运行手册） 缓解因素：有助于缓解的因素（快速检测、良好的回滚过程）

步骤3：生成事后分析报告文档 # 事件事后分析报告：[标题] 日期： [YYYY-MM-DD] 持续时间： [Xh Ym] 严重性： SEV-[1/2/3] 作者： [姓名] 状态： 草稿/已审查/完成

摘要

[2-3句话：发生了什么、影响、如何解决]

影响

• 受影响的用户： [数量或百分比]
• 收入影响： [估计，如果适用]
• 持续时间： [从检测到解决]
• 受影响的服务： [列表]

时间线（所有时间为UTC）

| 时间 | 事件 | |------|-------| | 14:23 | 部署提交abc123到生产环境 | | 14:31 | 告警：API错误率>5% | | 14:33 | 值班人员确认，开始调查 | | 14:41 | 确定慢速数据库查询 | | 14:45 | 决定：回滚部署 | | 14:48 | 回滚完成 | | 14:52 | 错误率恢复到基线 | | 14:55 | 确认：所有系统正常 |

根本原因

[明确的解释，说明什么出了问题以及为什么，没有责备]

促成因素

• [因素1：例如，在CI中没有查询性能测试]
• [因素2：例如，告警阈值太高，延迟了8分钟的检测]
• [因素3：例如，数据库问题的运行手册过时]

做得好的地方

• 快速检测（从部署到告警8分钟）
• 回滚顺利（3分钟）
• 良好的事件通讯

做得不好的地方

• 没有预部署性能检查，可能会捕获缺少的索引
• 告警阈值5%太高——影响从1%开始
• 需要10分钟才能确定根本原因（没有慢速查询仪表板）

操作项

| 优先级 | 操作 | 所有者 | 到期 | 状态 | |----------|--------|-------|-----|--------| | P1 | 将迁移lint器添加到CI（检查缺少的索引） | @alice | 2026-05-05 | 待办 | | P1 | 将错误率告警阈值降低到1% | @bob | 2026-05-01 | 待办 | | P2 | 将慢速查询仪表板添加到Grafana | @carol | 2026-05-10 | 待办 | | P2 | 更新数据库事件运行手册 | @dave | 2026-05-07 | 待办 | | P3 | 将查询性能测试添加到分阶段部署 | @alice | 2026-05-20 | 待办 |

经验教训

[我们学到了什么，可以应用于超出此特定事件的范围？]

• review — 促进无责备的回顾

生成回顾会议议程： 时间线演练（仅事实，无责备） 我们有什么惊讶？ 我们的假设在哪里失败了？ 什么本可以防止这一事件？ 操作项分配和优先级

• track — 跟踪操作项

检查事后分析报告操作项的状态： 最近事后分析报告的哪些操作项仍然打开？ 我们是否重复相同的根本原因？（集群分析） 按优先级关闭操作项的平均时间 可以通过完成的操作项防止的事件