把事故记录整理成复盘报告

发生了什么写清楚，
没确认的绝不补。

把监控告警、群聊记录和时间线碎片整理成一份复盘报告：时间线、影响范围、根因分析、改进项与负责人占位。不编造时间、影响范围、损失金额与根因结论，不写追责表述，未确认项一律标为待核实。

时间有据结论不臆断不写追责

审阅复盘结果

结果会显示在这里

系统将按记录顺序整理事件经过，区分已确认事实与待核实项，把根因与推测分开写，并给出带负责人占位的改进项清单。

示例结果

你会拿到的输出，长这样。

下面是对上方演示原文的完整输出示例：完整度评分、逐条整理说明、被标为待核实的部分及原因，以及整理后的复盘报告。示例为演示用途，不是客户案例。

示例

复盘结果（示例）

完整度评分88/100

+50

把模糊时间改成待核实项

原文“昨晚八点多”无法作为时间线依据。改为待核实条目，并保留“重启后恢复”这一有记录支撑的动作。

把估算数字改为暂无数据

“大概几千人”“损失估计不小”都没有统计来源。拆成受影响用户数与资金损失两项，各自标注暂无数据并列入待核实。

把未证实的判断降级为推测

“应该是数据库那边的问题”被移到推测小节，并补充需要调取的日志与指标，避免它作为结论进入正式报告。

整理后的复盘报告

# 故障复盘报告（草稿）

## 概述
服务在某日晚间出现不可用，具体起止时间待核实。

## 时间线
- 待核实：故障开始的具体时间（原文为“昨晚八点多”）
- 待核实：发现与上报的时间
- [已记录] 恢复方式：重启后服务恢复
- 待核实：恢复的具体时间与总持续时长

## 影响范围
- 受影响功能：页面无法打开（来源：用户反馈，具体接口范围待核实）
- 受影响用户数：原文记为“大概几千人”，未经统计，待核实
- 资金损失：原文记为“损失估计不小”，未提供金额与口径，待核实

## 根因分析
- 推测（未经证实）：原文提到“应该是数据库那边的问题”，暂无日志或指标支撑
- 待核实：需补充数据库监控、慢查询与错误日志后再定结论

## 改进项
- 补充监控告警：负责人 [待填写]，完成时间待定
- 待核实：重启是临时措施还是最终修复

## 待核实清单
- 故障起止时间与持续时长
- 受影响用户数与统计口径
- 是否有资金损失及计算方式
- 数据库在故障期间的指标与日志

整理做什么

复盘的价值在事实，不在措辞。

时间线只按证据排

只写有记录支撑的时间点。缺时间戳的地方标为待核实，不用“大概八点多”“过了一会儿”去补。

影响范围分项写

受影响的用户量、功能范围与持续时长各自独立成项。没有数据就写暂无数据，不做估算。

根因与推测分开

已验证的原因与推测分节写。推测标为待核实，不能写成结论。

为什么值得做

复盘写歪一次，同样的故障还会有第二次。

错的时间会带错结论

时间线差十分钟，根因判断可能完全相反。不确定的时间点宁可标为待核实。

编出来的损失收不回来

“估计损失几万”一旦写进报告，就会出现在下一次汇报里，而它从未被统计过。

追责语气会让信息停下

写成“某某误操作”之后，没人再愿意补充细节，复盘也就到此为止。

说明：事故复盘的常见做法是先重建事实时间线，再讨论原因与改进项，并强调对事不对人。不同团队对报告格式、严重级别与影响口径有各自定义。本站只做文档整理，不核实监控数据，也不构成运维或安全管理方面的专业建议。

整理演示

同一段事故记录，整理后的样子。

整理前

昨晚八点多服务挂了，很多用户反馈打不开，应该是数据库那边的问题，影响了大概几千人，损失估计不小。后来重启了一下就好了。后面要加监控，让小王跟进，尽快完成。

整理后

# 故障复盘报告（草稿）

## 概述
服务在某日晚间出现不可用，具体起止时间待核实。

## 时间线
- 待核实：故障开始的具体时间（原文为“昨晚八点多”）
- 待核实：发现与上报的时间
- [已记录] 恢复方式：重启后服务恢复
- 待核实：恢复的具体时间与总持续时长

## 影响范围
- 受影响功能：页面无法打开（来源：用户反馈，具体接口范围待核实）
- 受影响用户数：原文记为“大概几千人”，未经统计，待核实
- 资金损失：原文记为“损失估计不小”，未提供金额与口径，待核实

## 根因分析
- 推测（未经证实）：原文提到“应该是数据库那边的问题”，暂无日志或指标支撑
- 待核实：需补充数据库监控、慢查询与错误日志后再定结论

## 改进项
- 补充监控告警：负责人 [待填写]，完成时间待定
- 待核实：重启是临时措施还是最终修复

## 待核实清单
- 故障起止时间与持续时长
- 受影响用户数与统计口径
- 是否有资金损失及计算方式
- 数据库在故障期间的指标与日志

演示样例：把“大概”“估计”全部改成待核实，把未证实的根因写成推测，改进项留负责人占位而不编造截止时间。在工作台提交你的记录即可得到针对你的版本（需登录，每次消耗 1 次额度）。

为什么可以放心

我们把“不编事实”写进了产品原则。

时间和数字一律不补

起止时间、持续时长、影响用户数、损失金额，素材里没有就写暂无数据，并列入待核实。

根因只写有支撑的结论

未经验证的判断标为推测，与已确认原因分节写，不混在一起。

不写追责表述

只描述动作与系统行为。原文里的指责会被改写为可观察的事实描述。

正文不留存

提交的内容仅用于本次 AI 处理，本站不主动保存正文；详见隐私政策。

常见问题

付费前，你可能想问。

会帮我估算影响用户数和损失吗？

不会。影响用户数、持续时长与损失金额必须由监控或财务口径统计得出。素材里没有，我们写“暂无数据”并列入待核实，不做任何估算。

根因还没查清能整理吗？

可以。未证实的判断会写成推测并与已确认原因分节，同时把需要补充的日志与指标列入待核实，不会替你下定论。

会写成谁的责任吗？

不会。复盘只描述动作与系统行为，不写追责表述。原文中的指责会被改写为可观察的事实描述。

一次整理消耗什么？耗时多久？

一次整理消耗 1 次额度，通常十几秒完成，输出复盘报告、整理说明与待核实清单。

额度会过期吗？

不会。额度永不过期，本次没用完的部分会自动累积到下一次，不会清零。

支持批量处理或 API 吗？

目前每次处理一篇内容，不提供批量上传或 API，额度按次消耗。如你有大量自动化需求，请先邮件说明场景。

我的内容会被保存吗？

不会主动保存。正文仅用于本次 AI 处理，详见隐私政策。

适合哪些内容？

监控告警截图整理、值班群聊记录、故障时间线碎片、复盘会议笔记——任何需要变成正式复盘报告的事故素材。

简单透明的价格

先验证价值，再决定是否升级。

Starter

$9/ 月

适合发布频率较低的轻量使用者。

50 次优化额度，每月续费发放
完整 GEO 分析
中英文输出
Markdown 导出

Pro

Advanced

$79/ 月

含最高月度额度，适合最高频的深度使用者。

1,000 次优化额度，每月续费发放
完整 GEO 分析
中英文输出
Markdown 导出

额度永不过期：未用完的额度会累积到下一次，不会清零。额度仅在当前站点有效，不与其他站点通用。

标价为美元基准价；最终币种、税费与折扣由 Paddle 按结账所在地确定。