⚡

无责事后分析写作指南Skill postmortem-writing

此技能用于编写有效的事后分析文档，支持事件回顾、根因分析和改进项制定，促进无责文化。关键词：事后分析、无责文化、根因分析、事件管理、DevOps、组织学习、行动项、时间线。

DevOps 0 次安装 0 次浏览 更新于 3/10/2026

名称：事后分析写作 描述：编写有效的无责事后分析，包含根因分析、时间线和行动项。用于进行事件回顾、撰写事后分析文档或改进事件响应流程。 版本：1.0 模型：sonnet 调用方式：both 用户可调用：true 工具：[读取, 写入, Bash] 最佳实践：

  • 事件发生后立即开始
  • 具体化时间和错误
  • 包含图表和可视化证据
  • 为行动项分配负责人 错误处理：graceful 流支持：supported 已验证：false 最后验证时间：2026-02-19T05:29:09.098Z

模式：认知/提示驱动 — 无独立实用脚本；通过代理上下文使用。

事后分析写作

编写有效无责事后分析的综合指南，促进组织学习并防止事件复发。

何时使用此技能

  • 进行事件后回顾
  • 撰写事后分析文档
  • 促进无责事后分析会议
  • 识别根因和贡献因素
  • 创建可操作的后续项
  • 构建组织学习文化

核心概念

1. 无责文化

问责聚焦 无责
“谁造成的？” “什么条件允许了这种情况？”
“有人犯错了” “系统允许了这个错误”
惩罚个人 改进系统
隐藏信息 分享学习
害怕发声 心理安全

2. 事后分析触发条件

  • SEV1或SEV2事件
  • 面向客户的中断 > 15分钟
  • 数据丢失或安全事件
  • 可能严重的未遂事件
  • 新故障模式
  • 需要非常规干预的事件

快速开始

事后分析时间线

第0天：事件发生
第1-2天：起草事后分析文档
第3-5天：事后分析会议
第5-7天：最终化文档，创建工单
第2周+：行动项完成
季度：跨事件模式回顾

模板

模板1：标准事后分析

# 事后分析：[事件标题]

**日期**：2024-01-15
**作者**：@alice, @bob
**状态**：草案 | 审核中 | 最终版
**事件严重性**：SEV2
**事件持续时间**：47分钟

## 执行摘要

2024年1月15日，支付处理服务经历了47分钟的中断，影响了约12,000名客户。根因是部署版本v2.3.4中的配置更改触发了数据库连接池耗尽。事件通过回滚到v2.3.3并增加连接池限制解决。

**影响**：

- 12,000名客户无法完成购买
- 估计收入损失：$45,000
- 创建了847个支持工单
- 无数据丢失或安全影响

## 时间线（所有时间UTC）

| 时间  | 事件                                           |
| ----- | ----------------------------------------------- |
| 14:23 | 部署v2.3.4完成到生产环境       |
| 14:31 | 首次警报：`payment_error_rate > 5%`          |
| 14:33 | 值班工程师@alice确认警报      |
| 14:35 | 开始初步调查，错误率23% |
| 14:41 | 事件声明为SEV2，@bob加入              |
| 14:45 | 识别数据库连接耗尽       |
| 14:52 | 决定回滚部署                 |
| 14:58 | 启动回滚到v2.3.3                    |
| 15:10 | 回滚完成，错误率下降          |
| 15:18 | 服务完全恢复，事件解决      |

## 根因分析

### 发生了什么

v2.3.4部署包括对数据库查询模式的更改，无意中移除了频繁调用端点的连接池。每个请求打开新的数据库连接，而不是重用池连接。

### 为何发生

1. **直接原因**：`PaymentRepository.java`中的代码更改将池化`DataSource`替换为直接`DriverManager.getConnection()`调用。

2. **贡献因素**：
   - 代码审查未捕获连接处理更改
   - 无针对连接池行为的集成测试
   - 测试环境流量较低，掩盖问题
   - 数据库连接指标警报阈值过高（90%）

3. **5个为什么分析**：
   - 为什么服务失败？ → 数据库连接耗尽
   - 为什么连接耗尽？ → 每个请求打开新连接
   - 为什么每个请求打开新连接？ → 代码绕过连接池
   - 为什么代码绕过连接池？ → 开发人员不熟悉代码库模式
   - 为什么开发人员不熟悉？ → 无连接管理模式的文档

### 系统图

[客户端] → [负载均衡器] → [支付服务] → [数据库] ↓ 连接池（损坏） ↓ 直接连接（原因）


## 检测

### 有效之处
- 错误率警报在部署后8分钟内触发
- Grafana仪表板清晰显示连接峰值
- 值班响应迅速（2分钟确认）

### 无效之处
- 数据库连接指标警报阈值过高
- 无部署相关警报
- 金丝雀部署本可更早捕获此问题

### 检测差距
部署在14:23完成，但首次警报直到14:31才触发（8分钟）。部署感知警报本可更快检测问题。

## 响应

### 有效之处
- 值班工程师快速识别数据库为问题
- 回滚决定果断
- 事件频道中沟通清晰

### 可改进之处
- 花费10分钟将问题与近期部署关联
- 需手动检查部署历史
- 回滚耗时12分钟（本可更快）

## 影响

### 客户影响
- 12,000名唯一客户受影响
- 平均影响持续时间：35分钟
- 847个支持工单（受影响用户的23%）
- 客户满意度分数下降12点

### 业务影响
- 估计收入损失：$45,000
- 支持成本：~$2,500（代理时间）
- 工程时间：~8人小时

### 技术影响
- 数据库主库负载升高
- 事件期间一些副本延迟
- 系统无永久损坏

## 经验教训

### 良好之处
1. 警报在客户报告前检测到问题
2. 团队在压力下有效协作
3. 回滚过程顺利
4. 沟通清晰及时

### 不佳之处
1. 代码审查错过关键更改
2. 连接池测试覆盖缺口
3. 测试环境未反映生产流量
4. 警报阈值未适当调整

### 幸运之处
1. 事件发生在工作时间，团队全员在岗
2. 数据库处理负载而未完全失败
3. 无其他事件同时发生

## 行动项

| 优先级 | 行动 | 负责人 | 截止日期 | 工单 |
|----------|--------|-------|----------|--------|
| P0 | 添加连接池行为的集成测试 | @alice | 2024-01-22 | ENG-1234 |
| P0 | 降低数据库连接警报阈值至70% | @bob | 2024-01-17 | OPS-567 |
| P1 | 文档化连接管理模式 | @alice | 2024-01-29 | DOC-89 |
| P1 | 实施部署相关警报 | @bob | 2024-02-05 | OPS-568 |
| P2 | 评估金丝雀部署策略 | @charlie | 2024-02-15 | ENG-1235 |
| P2 | 用类似生产流量负载测试测试环境 | @dave | 2024-02-28 | QA-123 |

## 附录

### 支持数据

#### 错误率图
[链接到Grafana仪表板快照]

#### 数据库连接图
[链接到指标]

### 相关事件
- 2023-11-02：用户服务中的类似连接问题（POSTMORTEM-42）

### 参考文献
- [连接池最佳实践](内部维基/连接池)
- [部署运行手册](内部维基/部署运行手册)

模板2：5个为什么分析

# 5个为什么分析：[事件]

## 问题陈述

支付服务因数据库连接耗尽经历了47分钟中断。

## 分析

### 为什么 #1：为什么服务失败？

**答案**：数据库连接耗尽，导致所有新请求失败。

**证据**：指标显示连接数100/100（最大），有500+待处理请求。

---

### 为什么 #2：为什么数据库连接耗尽？

**答案**：每个传入请求打开新数据库连接，而不是使用连接池。

**证据**：代码差异显示直接`DriverManager.getConnection()`而非池化`DataSource`。

---

### 为什么 #3：为什么代码绕过连接池？

**答案**：开发人员重构存储库类，无意中更改了连接获取方法。

**证据**：PR #1234显示更改，在修复另一个错误时进行。

---

### 为什么 #4：为什么代码审查未捕获此点？

**答案**：审查者关注功能更改（错误修复），未注意到基础设施更改。

**证据**：审查评论仅讨论业务逻辑。

---

### 为什么 #5：为什么此类更改无安全网？

**答案**：缺乏验证连接池行为的自动化测试，缺乏连接模式的文档。

**证据**：测试套件无连接处理测试；维基无数据库连接文章。

## 识别出的根因

1. **主要**：基础设施行为缺失自动化测试
2. **次要**：架构模式文档不足
3. **第三**：代码审查清单未包含基础设施考虑

## 系统性改进

| 根因    | 改进                       | 类型       |
| ------------- | --------------------------------- | ---------- |
| 缺失测试 | 添加基础设施行为测试 | 预防 |
| 缺失文档  | 文档化连接模式      | 预防 |
| 审查缺口   | 更新审查清单           | 检测  |
| 无金丝雀     | 实施金丝雀部署      | 缓解 |

模板3：快速事后分析（次要事件）

# 快速事后分析：[简短标题]

**日期**：2024-01-15 | **持续时间**：12分钟 | **严重性**：SEV3

## 发生了什么

API延迟因缓存刷新后缓存未命中风暴飙升至5秒。

## 时间线

- 10:00 - 为配置更新启动缓存刷新
- 10:02 - 延迟警报触发
- 10:05 - 识别为缓存未命中风暴
- 10:08 - 启用缓存预热
- 10:12 - 延迟恢复正常

## 根因

针对次要配置更新的完整缓存刷新导致惊群效应。

## 修复

- 立即：启用缓存预热
- 长期：实施部分缓存失效（ENG-999）

## 经验

生产中不要完整刷新缓存；使用定向失效。

促进指南

运行事后分析会议

## 会议结构（60分钟）

### 1. 开场（5分钟）

- 提醒所有人无责文化
- "我们来学习，而非责怪"
- 回顾会议规范

### 2. 时间线回顾（15分钟）

- 按时间顺序回顾事件
- 询问澄清问题
- 识别时间线缺口

### 3. 分析讨论（20分钟）

- 什么失败了？
- 为什么失败？
- 什么条件允许了这种情况？
- 什么本可预防它？

### 4. 行动项（15分钟）

- 头脑风暴改进
- 按影响和努力优先排序
- 分配负责人和截止日期

### 5. 结束（5分钟）

- 总结关键经验
- 确认行动项负责人
- 如需，安排跟进

## 促进技巧

- 保持讨论正轨
- 将责备重定向到系统
- 鼓励安静参与者
- 文档化不同意见
- 时间限制题外话

需避免的反模式

反模式 问题 更好方法
责备游戏 阻止学习 聚焦系统
浅层分析 无法防止复发 问"为什么"5次
无行动项 浪费时间 总有具体后续步骤
不切实际的行动 从未完成 限定为可达成任务
无跟进 行动被遗忘 在工单系统中跟踪

最佳实践

要做的事

  • 立即开始 - 记忆迅速消退
  • 具体化 - 精确时间，精确错误
  • 包含图表 - 可视化证据
  • 分配负责人 - 无孤儿行动项
  • 广泛分享 - 组织学习

不要做的事

  • 不点名羞辱 - 永远不
  • 不跳过小事件 - 它们揭示模式
  • 不使其成为责备文档 - 那扼杀学习
  • 不创建无效工作 - 行动应有意义
  • 不跳过跟进 - 验证行动完成

资源

内存协议（强制）

开始前： 阅读.claude/context/memory/learnings.md

完成后：

  • 新模式 -> .claude/context/memory/learnings.md
  • 发现问题 -> .claude/context/memory/issues.md
  • 决策 -> .claude/context/memory/decisions.md

假设中断：如果不在内存中，它就未发生。