---
name: report-postmortem
description: 生成故障复盘与改革计划文档。当用户说"故障复盘"、"事故复盘"、"P0复盘"、"P1复盘"、"线上事故分析"、"写改革计划"、"障碍分析"、"写稳定性改进"、"写事后总结"时触发。核心逻辑：先直面事实建立信任，再做系统性根因分析，改革计划必须和根因直接对应，不能是泛化的「加强X」。
metadata:
  author: archon
  version: "2.0"
---

# report-postmortem — 故障复盘

## 核心原则：直面先于解法（内部复盘）/ 判断先于细节（高层汇报）

**内部复盘**：受众（上级、相关团队）进入文档时带着警惕和疑虑，他们的第一个问题是「你们真的搞清楚发生了什么吗」。  
正确顺序：先用客观的事实重建建立信任 → 再给出让人信服的根因分析 → 最后才是改革计划。  
如果先讲改革，读者会怀疑「你们是不是在敷衍，根本没搞清楚」。

**高层汇报**：高层没有耐心跟随时间线——他们的问题是「这件事有多严重、你们搞清楚了吗、改了什么」。  
正确顺序：先给影响摘要和改革决心 → 再给精简根因结论 → 细节放附录供需要时查阅。  
如果按内部复盘顺序给高层，他们会在时间线里迷失，找不到判断入口。

---

## 写作前必须收集的信息

向用户确认以下内容：

1. **汇报对象**：直属上级 / 更高层（VP/CTO）/ 跨团队？
   → **先确认受众，再进入下方对应版本**
   - 内部复盘（直属上级/相关团队）→ 收集完整信息后使用「内部复盘版」结构
   - 高层汇报（VP/CTO等）→ 收集完整信息后使用「高层汇报版」结构
2. **事件基本信息**：发生时间、发现时间、恢复时间、影响范围（用户数、服务数、业务损失）
3. **时间线**：从触发到恢复的关键节点（越细越好）
4. **直接原因**：是什么操作/变更/配置触发了问题
5. **根因**：为什么系统/机制允许这件事发生（不是「谁做错了」）
6. **应对过程**：发现、响应、排查、恢复各阶段的表现

---

## 文档结构

> 根据受众分支选择对应结构；高层版在内部版基础上调整顺序和颗粒度，不是两套完全不同的文档。

### 内部复盘版（直属上级 / 相关团队）

适用于：故障例行复盘会、团队内部改进同步、直属上级的定期汇报

### 一、事件概要（执行摘要）

> 用于快速同步，让受众在读详情前先有全局认知

| 维度 | 内容 |
|------|------|
| 事件级别 | P[N] |
| 发生时间 | [时间] |
| 持续时长 | [时长] |
| 影响范围 | [受影响的用户/服务/业务指标] |
| 直接原因 | [一句话] |
| 根本原因 | [一句话] |
| 当前状态 | 已恢复 / 部分恢复 / 持续跟进中 |

---

### 二、事件还原（时间线）

📌**原则**：客观陈述，不做评价，不做辩护。只写「发生了什么」，不写「我们很努力」。

```
[时间] — [事件/操作/现象]
[时间] — [事件/操作/现象]
[时间] — 发现异常：[具体表现，有数据]
[时间] — 介入排查：[谁做了什么]
[时间] — 定位原因：[具体是什么问题]
[时间] — 实施恢复：[采取了什么措施]
[时间] — 服务恢复：[恢复到什么状态]
```

**影响数据**（用具体数字，不用「大量」「严重」）：
- 受影响用户：[X人/X%]
- 受影响服务：[X个服务]
- 业务损失：[如有]
- 持续时长：[X小时X分钟]

---

### 三、根因分析

⚠️**根因不是「谁操作失误」，而是「什么机制缺失让这件事能发生」。**

**3.1 直接触发原因**
[具体是什么操作/变更/配置，导致了什么]

**3.2 根本原因**（系统性原因）

用「5 Why」或「鱼骨图」逻辑展开：
```
为什么发生？→ [直接原因]
  为什么这个直接原因能发生？→ [缺少某类检查/防护]
    为什么缺少这个检查？→ [流程/系统设计上的缺失]
      为什么流程上有这个缺失？→ [更深层的组织/技术债原因]
```

**3.3 扩大影响的原因**（为什么没有更早发现/更快恢复）
- 发现慢：[监控/告警缺失或不精准]
- 恢复慢：[回滚机制/应急预案的问题]
- 扩散广：[隔离/熔断机制的问题]

---

### 四、改革计划

📌**原则**：每一条改革措施必须和第三章的某个根因直接对应，不能有泛化的「加强X意识」「提升X规范」。

**4.1 紧急修复（已完成 / 本周内）**

| 措施 | 对应根因 | 负责人 | 完成时间 |
|------|---------|-------|---------|
| [具体措施] | [根因编号] | [Owner] | [日期] |

**4.2 短期改进（1个月内）**

| 措施 | 对应根因 | 负责人 | 完成时间 | 验收标准 |
|------|---------|-------|---------|---------|
| [具体措施] | [根因编号] | [Owner] | [日期] | [可验证标准] |

**4.3 长期建设（季度级）**

| 措施 | 对应根因 | 负责人 | 完成时间 | 验收标准 |
|------|---------|-------|---------|---------|
| [系统性改进] | [根因编号] | [Owner] | [日期] | [可验证标准] |

---

### 五、预防机制

**5.1 如何提前感知类似问题**
- 新增/优化监控项：[具体]
- 告警阈值调整：[具体]

**5.2 如何加快响应和恢复**
- 应急预案更新：[具体]
- 权限/工具准备：[具体]

**5.3 变更管控升级**（如适用）
- [具体的流程变更]

---

### 高层汇报版（VP/CTO 等）

**核心逻辑调整**：高层进入文档时，第一个问题不是「根因是什么」，而是「这件事有多严重、你们搞清楚了吗、改了什么」。因此高层版将「改革决心」前置，根因精简，细节后置为附录。

**结构**：

#### 一、事件摘要（对应内部版的事件概要，扩展为决策入口）

```
📌 事件级别：P[N]
📊 影响范围：[量化：受影响用户数/业务指标损失]
⏱️ 持续时长：[时长]
🔍 根本原因：[一句话结论，不展开]
✅ 当前状态：[已恢复 / 持续跟进中]
🚀 改革核心动作：[一句话说明最关键的改变是什么]
```

#### 二、我们对这次故障的判断

这个板块是高层版的核心差异——**先给判断，建立信任，再展开细节**。

> 「我们认为，这次故障暴露了[X机制缺失]。这不是偶发的个人失误，而是系统性问题。我们已确定了[N项]改革措施，核心是[最重要的1项改变]。」

**2.1 暴露了什么系统性问题**（精简根因，1-2句话）

**2.2 改革核心框架**（用一个闭环框架组织改革方向）
- 发现机制：[怎么更早发现类似问题]
- 防护机制：[怎么防止类似问题发生]
- 恢复机制：[怎么加快恢复速度]

**2.3 关键里程碑**（只列最重要的 2-3 个时间节点）

| 改革项 | 预计完成 | 负责人 | 验收方式 |
|-------|---------|-------|--------|
| [最重要改革项] | [日期] | [Owner] | [简明验收标准] |

#### 三、附录：完整根因分析与改革计划

将内部复盘版的「二、事件还原」「三、根因分析」「四、改革计划」「五、预防机制」完整放入附录，供高层需要深挖时查阅。

> ⚠️ **高层版陷阱**：
> - ❌ 先讲时间线——高层不需要还原过程，需要的是判断
> - ❌ 根因展开太细——高层只需要1句根本原因结论
> - ❌ 没有「我们的判断」板块——高层最想看到的是「你们有没有真正搞清楚」
> - ❌ 改革措施没有核心框架——列20条措施不如1个闭环框架

---

## 技法适配

故障复盘场景对通用技法有特定的适配方式。当你在帮用户撰写某个章节并需要决定技法使用方式时，读取 [技法适配参考](../references/technique-adaptation.md) 中「故障复盘」部分。不要在启动时加载。

如需了解某个具体技法的完整说明（含示例、适用受众、常见陷阱），读取 [技法详解](../report-planning/references/techniques.md) 中对应技法编号的内容。按需加载，不要一次性读完。

**常用技法参考编号**（复盘场景）：
- 技法2（辩证表达）— 根因分析中的辩证转折
- 技法3（闭环叙事弧）— 改革计划的闭环结构
- 技法4（分层度量与归因）— 改革验收标准
- 技法5（论证深度）— 5-Why 根因链路

---

## 常见陷阱

- ❌ 在事实还原中加入辩护语气（「由于当时情况紧急…」）
- ❌ 根因归咎于个人（「某人疏忽」）而不是机制
- ❌ 改革措施空泛（「加强X意识」「提升Y规范」），没有 owner 和验收标准
- ❌ 改革措施和根因没有对应关系（头痛医脚）
- ❌ 时间线不完整或有美化，留下「为什么响应这么慢」的疑问

## 参考文件

- [通用风格规范](../references/style-guide.md)
- [复盘文档模板](assets/templates/postmortem-template.md)