incident-postmortem

事件复盘报告编写器

概述

撰写无责备的事件复盘报告，将运营中断转化为学习机会。这些文档关注系统故障和流程漏洞，而非归咎于个人，从而推动持续改进并防止问题再次发生。

核心原则

1. 无责备：关注系统，而非个人。问“为什么会发生？”而不是“谁搞砸了？”
2. 心理安全：团队成员必须能够安心讨论根本原因，不必担心受到指责
3. 数据驱动：依据日志、指标和事实得出结论，而非依赖假设
4. 以行动为导向：每项发现都应带来可执行的改进措施
5. 学习文化：将事件视为宝贵的学习机会，而非失败
6. 透明：广泛分享调查结果，并沟通改进措施，以防类似事件再次发生

时间线重建

创建详细的事件时间顺序：

Time (UTC) | Who | What | Evidence | Context
-----------|-----|------|----------|----------
2024-02-15 14:32 | Jenkins | Deploy v2.1.3 (buggy) | Logs | Automated Friday deploy
14:35 | Customer | Website errors | CloudFront | 500 errors reported
14:37 | On-call | PagerDuty alert | Alert | Error rate exceeded threshold
14:42 | Eng team | Investigation starts | Slack #incidents | Identified deploy cause
14:55 | Lead | Rollback initiated | Logs | Reverted to v2.1.2
15:02 | On-call | Error rate normal | Metrics | Customers back to normal
15:30 | Team | Root cause meeting | Notes | Identified root cause

时间线模板：

• T+0（告警）：首次检测到问题的时间
• T+X（发现）：确认发生事件的时间
• T+Y（沟通）：通知相关方的时间
• T+Z（缓解）：事件负责人采取行动的时间
• T+N（解决）：系统恢复正常的时间
• 持续时间：从发现到解决的总时长

根本原因分析（5 个为什么）

不要止步于表面原因，要找出系统性问题：

Incident: Website down for 28 minutes

Why 1: Why did website go down?
Answer: Deployment v2.1.3 contained a bug causing infinite loop in auth service

Why 2: Why did the bug reach production?
Answer: Code review missed the issue; test suite didn't catch it

Why 3: Why didn't test suite catch the infinite loop?
Answer: Load/stress tests only run occasionally; not part of standard CI pipeline

Why 4: Why aren't load tests mandatory in CI?
Answer: Historically slow; team prioritized speed over reliability

Why 5: Why does team optimize for deploy speed over testing?
Answer: Pressure to ship features fast; no documented standard for testing rigor

ROOT CAUSE: Process gap - no mandatory load testing in CI; pressure to ship

避免：

• 过早停止分析（“操作员没有发现错误”）
• 将人为错误作为根本原因（“开发人员犯了错”）
• 对系统性问题的描述含糊不清

重点关注：

• 流程失效
• 监控缺口
• 沟通中断
• 知识缺口
• 工具局限
• 架构弱点

促成因素（瑞士奶酪模型）

大多数事件都涉及多项故障同时发生：

Incident: Late-night 30-minute outage

Contributing Factors:
1. Code change made Friday afternoon (rush to deploy before weekend)
2. No automated rollback capability (manual process)
3. On-call engineer had weak knowledge of new code (hired 3 weeks ago)
4. No load test coverage for auth service changes (technical debt)
5. Monitoring alert threshold set too high (missed early warning)
6. Deployment not staged; went straight to production (process gap)
7. No change advisory board approval (governance gap)

Any ONE of these alone wouldn't have caused incident. Combined: 28-minute outage.

根本原因与直接原因

直接原因（即时原因）：

• 身份验证代码中的无限循环
• 不应该发生的部署
• 缺少监控告警

根本原因（系统性故障）：

• 代码审查流程不足以应对关键变更
• 部署流程缺少分阶段部署或金丝雀部署
• 测试策略未包含压力测试
• 值班团队不了解近期变更

复盘应聚焦于根本原因，而非直接原因。

行动项（后续跟进）

结构：[优先级] | [事项] | [原因] | [负责人] | [截止日期] | [状态]

立即行动（0-7 天）

CRITICAL | Deploy hotfix for infinite loop | Prevent recurrence | Sarah | 2024-02-15 | DONE
HIGH | Document code change impact | Knowledge transfer | John | 2024-02-16 | IN PROGRESS
MEDIUM | Post-incident communication to customers | Transparency | PM | 2024-02-15 | DONE

短期行动（1-4 周）

HIGH | Implement automatic canary deployment | Catch issues pre-production | DevOps | 2024-03-01 | PENDING
HIGH | Add auth load tests to CI pipeline | Catch performance issues early | QA | 2024-03-01 | PENDING
MEDIUM | Onboard new on-call engineer on recent changes | Knowledge gap closure | Tech Lead | 2024-02-28 | IN PROGRESS

长期行动（1-3 个月）

MEDIUM | Implement automated rollback capability | Faster recovery time | Arch | 2024-04-15 | PENDING
LOW | Review change advisory board process | Governance improvement | Ops | 2024-05-01 | PENDING
LOW | Schedule quarterly load testing for critical services | Proactive risk management | Perf | 2024-06-01 | PENDING

SMART 行动项：

• Specific（具体）：具体需要完成什么？
• Measurable（可衡量）：如何确认已完成？
• Assignable（可分配）：由谁负责？
• Realistic（可实现）：是否切实可行？
• Time-bound（有时限）：截止日期是什么时候？

预防措施

预防策略：如何防止此类事件发生？

1. 流程变更：

   • 为关键服务实施分阶段部署或金丝雀部署
   • 要求身份验证服务变更必须经过代码审查
   • 要求关键路径变更通过负载测试

2. 监控与告警：

   • 降低错误率告警阈值，以便尽早预警
   • 为身份验证服务添加 CPU 和内存告警
   • 为金丝雀端点添加合成监控

3. 自动化：

   • 错误率 >2% 时自动回滚
   • 在 CI 流水线中设置负载测试门禁（必须执行，不可选）
   • 每周运行自动化混沌工程测试

4. 文档与培训：

   • 编写身份验证服务架构文档
   • 为身份验证服务事件创建运行手册
   • 为值班团队安排知识传递会议

5. 组织层面：

   • 消除截止日期压力；不要在周五下午部署
   • 邀请值班工程师参与关键服务的代码审查
   • 制定事件 SLA：P0 事件从发现到解决的时间 <15 分钟

模板结构

事件复盘

事件 ID：INC-2024-047 日期：2024-02-15 持续时间：28 分钟（14:35 UTC - 15:03 UTC） 影响：网站无法访问；50 万次页面请求失败 严重程度：P1（严重）

事件摘要 [用 1 段概述发生的情况及影响]

时间线 [按时间顺序排列的事件表]

根因分析 主要根因：[高层次结论]

5 个为什么分析： [连续追问原因]

促成因素： [系统性问题列表]

影响分析

• 受影响的客户：[数量或百分比]
• 持续时间：[分钟数]
• 收入影响：[可量化时填写]
• 声誉影响：[定性评估]
• 数据丢失：[是/否；如是，请说明详情]

检测与响应

• 检测时间：[检测所用分钟数]
• 响应时间：[开始缓解所用分钟数]
• 解决时间：[完全恢复所用分钟数]
• 响应质量：[顺畅/有些延迟/混乱——原因是什么？]

进展顺利之处

• [做得好的事情 1]：促成了[结果]
• [做得好的事情 2]：促成了[结果]
• [做得好的事情 3]：促成了[结果]

肯定出色的工作；强化良好行为

有待改进之处

• [不足 1]：影响是[后果]
• [不足 2]：影响是[后果]
• [不足 3]：影响是[后果]

行动项 [由负责人负责并注明日期的即时、短期和长期行动]

预防措施 [如何防止今后发生此类事件]

附录

• 错误日志（已匿名化）
• 客户沟通记录
• 事件期间的监控图表
• 架构图
• 相关事件（历史模式）

复盘会议引导

无责备会议原则：

1. 从背景开始，而非责备：“以下是 14:30 UTC 时正在发生的情况……”
2. 使用中性措辞：“代码发生了变更”，而不是“代码坏了”
3. 提出好奇式问题：“你当时在屏幕上看到了什么？”，而不是“你为什么不查看日志？”
4. 鼓励讲述经历：让大家描述自己的经历；保持叙述流畅
5. 记录假设：“我当时以为……”这样的陈述能揭示知识盲区
6. 不设层级：值班工程师的观察与 CTO 的观察同样重要
7. 记录决策：我们为什么选择回滚而不是修复？记录决策过程
8. 记录经验：哪些事情出乎大家的意料？大家学到了什么？

参与者：

• 值班工程师（事件响应人员）
• 服务负责人
• DevOps/基础设施团队
• 产品/业务负责人
• 引导人（经验丰富、立场中立）

会议时长：最多 30-60 分钟

召开时间：事件解决后的 48 小时内（趁细节还记忆犹新时）

分发与跟进

1. 广泛分享：复盘是用于学习的内部工具；与整个工程团队分享
2. 执行摘要：为管理层准备一页摘要
3. 客户沟通：公开说明发生了什么以及预防措施
4. 流程审查：每月审查未完成的行动项
5. 趋势分析：每季度审查——我们是在预防某类事件，还是只是在疲于救火？

预防类似事件

事件类别跟踪：

• 身份验证失败
• 数据库性能下降
• 内存泄漏
• 配置错误
• 依赖项故障
• 部署失败

同一类别的事件发生两次：升级预防措施 同一事件发生三次：升级至组织层面处理（管理层审查）

---

使用此技能：将事件转化为学习机会，提升系统韧性，并营造心理安全的事件响应文化。