# Data Incident Postmortem Writer

> Use when writing a data incident postmortem for failed partitions, wrong dashboard numbers, metric definition changes, SQL logic bugs, backfill mistakes, SLA misses, or data pipeline incidents.

- Skill: `shisuidata/data-incident-postmortem-writer` (Agent Skill)
- Install (CLI): `npx skillmds@latest add shisuidata/data-incident-postmortem-writer`
- Raw SKILL.md: https://api.skillmd.com/api/skills/shisuidata/data-incident-postmortem-writer/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: DevOps & Infra
- Author: shisuidata (https://skillmd.com/u/shisuidata)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/shisuidata/data-incident-postmortem-writer

---


# Data Incident Postmortem Writer

## 目标

把数据事故整理成客观、可追责但不甩锅、能推动预防机制的数据复盘文档。

这个 Skill 关注事故影响、时间线、根因、修复动作和长期改进。

## 使用场景

使用这个 Skill，当用户需要：

- 复盘数据任务失败、分区未产出、延迟超 SLA
- 复盘看板数字错误、指标口径变更导致误读
- 复盘 SQL 漏算、重复计算、补数覆盖、权限或发布事故
- 给业务方、管理者或数据团队同步事故影响和改进措施
- 将事故沉淀成团队知识库和预防清单

## 不适用场景

不要使用这个 Skill 处理：

- 实时排障和根因定位本身
- 审查 SQL 是否正确，应使用 `sql-reviewer`
- 设计质量规则，应使用 `data-quality-rule-generator`
- 写常规项目周报，应使用 `weekly-monthly-report-writer`
- 在缺少事实时间线时编造事故经过

## 输入信息

最少输入：

- 事故摘要
- 发生时间或发现时间
- 影响范围
- 当前修复状态

推荐输入：

- 详细时间线：发生、发现、响应、修复、恢复、通知
- 影响对象：表、指标、看板、报表、业务方、用户群体
- 影响程度：错误数据、延迟时长、影响日期、错误口径、决策影响
- 发现方式：告警、业务反馈、人工巡检、下游报错
- 根因分析：代码、调度、依赖、权限、口径、沟通、流程
- 修复过程和补数方案
- 已采取和计划采取的预防措施

## 上下文建议

优先使用这些模板准备上下文：

- [通用数据任务上下文](../../context/templates/data-task-context.md)：适合描述任务、依赖和影响范围
- [SQL 审查上下文模板](../../context/templates/sql-review-context.md)：适合 SQL 逻辑错误类事故
- [报告上下文模板](../../context/templates/report-context.md)：适合面向业务方或管理层复盘

如果事故发生在行业业务链路中，建议补充行业上下文：

- [电商行业上下文](../../context/industries/ecommerce.md)
- [SaaS 行业上下文](../../context/industries/saas.md)
- [内容社区行业上下文](../../context/industries/content-community.md)

上下文不足时，先输出复盘草稿和待补充事实，不要编造精确时间、影响人数或责任人。

## 写作流程

1. 先确认事故状态：已恢复、部分恢复、仍在处理中。
2. 梳理影响范围：影响哪些数据、哪些日期、哪些用户或业务流程。
3. 还原时间线，区分事实和推断。
4. 分析根因，至少区分直接原因、深层原因和机制缺口。
5. 描述修复动作和验证方式。
6. 输出预防措施：监控、质量规则、发布流程、回滚、文档、权限、沟通。
7. 用中性语言写作，避免情绪化和甩锅。

## 输出格式

```markdown
# 数据事故复盘：事故名称

## 1. 摘要

## 2. 当前状态

## 3. 影响范围

| 影响对象 | 影响时间 | 影响程度 | 处理状态 |
| --- | --- | --- | --- |

## 4. 时间线

| 时间 | 事件 | 说明 |
| --- | --- | --- |

## 5. 根因分析

### 直接原因

### 深层原因

### 机制缺口

## 6. 修复与验证

## 7. 预防措施

| 措施 | 负责人 | 截止时间 | 验收标准 |
| --- | --- | --- | --- |

## 8. 对外同步口径

## 9. 待确认问题
```

## 质量标准

输出必须：

- 先写影响和状态，再写原因
- 时间线只写已知事实，推断要标记
- 根因不能停留在“某人忘了”或“代码写错了”
- 预防措施要能验收，避免只写“加强检查”
- 对外同步口径要克制、清楚、可复制
- 对缺失信息列待确认，不补故事

## 示例 Prompt

```text
请用 data-incident-postmortem-writer 写一份数据事故复盘。

事故：电商经营看板 2026-05-20 的 GMV 比真实值少算约 18%。
发现方式：运营在 2026-05-21 10:20 反馈看板与订单后台不一致。
影响范围：经营日报、渠道 GMV 看板、类目 GMV Top 10，影响 2026-05-20 分区。
原因初步判断：订单明细表新增 pay_status = partial_refund 状态，但看板 SQL 只统计 success。
修复状态：已在 2026-05-21 13:40 修复 SQL 并补数，14:10 业务确认恢复。
希望输出：面向数据团队内部复盘，同时给业务方一段同步口径。
```