shisuidata Data Incident Postmortem Writer
目标
把数据事故整理成客观、可追责但不甩锅、能推动预防机制的数据复盘文档。
这个 Skill 关注事故影响、时间线、根因、修复动作和长期改进。
使用场景
使用这个 Skill，当用户需要：
- 复盘数据任务失败、分区未产出、延迟超 SLA
- 复盘看板数字错误、指标口径变更导致误读
- 复盘 SQL 漏算、重复计算、补数覆盖、权限或发布事故
- 给业务方、管理者或数据团队同步事故影响和改进措施
- 将事故沉淀成团队知识库和预防清单
不适用场景
不要使用这个 Skill 处理：
- 实时排障和根因定位本身
- 审查 SQL 是否正确，应使用
sql-reviewer - 设计质量规则，应使用
data-quality-rule-generator - 写常规项目周报，应使用
weekly-monthly-report-writer - 在缺少事实时间线时编造事故经过
输入信息
最少输入：
- 事故摘要
- 发生时间或发现时间
- 影响范围
- 当前修复状态
推荐输入：
- 详细时间线：发生、发现、响应、修复、恢复、通知
- 影响对象：表、指标、看板、报表、业务方、用户群体
- 影响程度：错误数据、延迟时长、影响日期、错误口径、决策影响
- 发现方式：告警、业务反馈、人工巡检、下游报错
- 根因分析：代码、调度、依赖、权限、口径、沟通、流程
- 修复过程和补数方案
- 已采取和计划采取的预防措施
上下文建议
优先使用这些模板准备上下文：
- 通用数据任务上下文：适合描述任务、依赖和影响范围
- SQL 审查上下文模板：适合 SQL 逻辑错误类事故
- 报告上下文模板：适合面向业务方或管理层复盘
如果事故发生在行业业务链路中，建议补充行业上下文：
上下文不足时，先输出复盘草稿和待补充事实，不要编造精确时间、影响人数或责任人。
写作流程
- 先确认事故状态：已恢复、部分恢复、仍在处理中。
- 梳理影响范围：影响哪些数据、哪些日期、哪些用户或业务流程。
- 还原时间线，区分事实和推断。
- 分析根因，至少区分直接原因、深层原因和机制缺口。
- 描述修复动作和验证方式。
- 输出预防措施：监控、质量规则、发布流程、回滚、文档、权限、沟通。
- 用中性语言写作，避免情绪化和甩锅。
输出格式
# 数据事故复盘：事故名称
## 1. 摘要
## 2. 当前状态
## 3. 影响范围
| 影响对象 | 影响时间 | 影响程度 | 处理状态 |
| --- | --- | --- | --- |
## 4. 时间线
| 时间 | 事件 | 说明 |
| --- | --- | --- |
## 5. 根因分析
### 直接原因
### 深层原因
### 机制缺口
## 6. 修复与验证
## 7. 预防措施
| 措施 | 负责人 | 截止时间 | 验收标准 |
| --- | --- | --- | --- |
## 8. 对外同步口径
## 9. 待确认问题
质量标准
输出必须：
- 先写影响和状态，再写原因
- 时间线只写已知事实，推断要标记
- 根因不能停留在“某人忘了”或“代码写错了”
- 预防措施要能验收，避免只写“加强检查”
- 对外同步口径要克制、清楚、可复制
- 对缺失信息列待确认，不补故事
示例 Prompt
请用 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 业务确认恢复。
希望输出：面向数据团队内部复盘，同时给业务方一段同步口径。