事故刚恢复的那一小时最难：手在抖，脑子里还是刚才的日志，而老板要交代、客户要说法。这时候最需要的不是安慰，是**把散落在群聊、告警和记忆里的碎片变成一份结构**。 复盘里唯一不能糊的是时间。把时间线丢进来，代码把它排序，并拆成三段：**开始→发现**（监控该不该更早报）、**发现→缓解**（预案与授权该不该更快）、**缓解→完全恢复**（数据修复与依赖）。哪一段最长，行动项就该往哪儿投——多数复盘把这三段混成一句「持续 4 小时」，于是行动项永远只能写「加强巡检」。 代码还会找出**时间线上最长的一段空白**。空白通常不是什么都没发生，是当时没人记，而它会变成复盘会上争论最多的地方。趁记忆还新去捞群聊、监控截图和操作日志——今天补要十分钟，一周后要两小时。 影响面也算：受影响请求量、以及按你的可用性目标算出的**错误预算消耗百分比**。这个数字比时长更能说明严重性，也是把讨论从「这次挺严重的」推到「所以下两个季度的可靠性投入要调整」的唯一办法。 然后模型接手：五问根因（不是找人，是找那个「如果当时不同就不会发生」的环节）、带责任人和日期的行动项、以及一份**能直接发给客户的对外版声明**——对外只写能核实的数字，估算值绝不外发。The hour after recovery is the worst one: your hands are still shaking, the logs are still in your head, and management wants an account while customers want a statement. What helps is not reassurance but **turning fragments scattered across chat, alerts and memory into a structure**. The one thing a post-mortem cannot be vague about is time. Paste the timeline and the code sorts it and splits it into three intervals: **start→detect** (should monitoring have fired earlier), **detect→mitigate** (should the runbook and authority have been faster), **mitigate→fully resolved** (data repair and dependencies). Whichever is longest is where the action items belong — most write-ups collapse all three into "a four-hour outage", and then the only action item anyone can write is "improve monitoring". The code also finds the **longest gap in the timeline**. A gap usually isn't nothing happening; it's nobody writing it down, and it becomes the most argued-over part of the review. Go pull chat logs, dashboard screenshots and deploy records now — ten minutes today, two hours next week. Impact is computed too: affected requests, and **the share of your monthly error budget this consumed**. That figure carries more than duration does, and it's the only way to move the conversation from "that was bad" to "so reliability investment changes next quarter". Then the model takes over: five-whys aimed at the link that would have prevented it, action items with owners and dates, and **a customer-facing statement** — where only verifiable numbers appear and estimates never do.
结构化复盘全文（时间线、影响面、五问根因、带责任人与日期的行动项、以及「这次做对了什么」）+ 对外版声明（客户口径，只用可核实的数字）+ 管理层版一页纸（三句话说清发生了什么、损失多少、下一步）。按次计费，一次事故用一次。The full write-up (timeline, impact, five whys, action items with owners and dates, and what went right), a customer-facing statement using only verifiable figures, and a one-page executive version that answers what happened, what it cost and what changes. Pay per incident.
影响面与错误预算均为**基于你填写的参数的估算**，不是从系统里统计出来的真实数字——真实数值请从日志与监控中取。**估算值不要写进对外文档**：对外只写能核实的数字，或只描述受影响的功能与时间段。本工具不接触你的任何系统，也不读取日志。请勿粘贴生产环境的密钥、内部主机名、客户身份信息或未脱敏的日志片段——复盘所需的只有时间与事件描述。对外声明的措辞可能涉及合同义务、SLA 赔偿与法律责任，**发出之前请经过你们内部的法务或负责人确认**，本工具不提供法律意见。你填写的内容不入库。Impact and error-budget figures are **estimates from the parameters you enter**, not measurements — take real numbers from your logs and monitoring. **Estimates must not appear in customer-facing documents**: publish only what you can verify, or describe the affected functionality and window instead. This tool touches no system of yours and reads no logs. Do not paste production credentials, internal hostnames, customer identifiers or unredacted log excerpts — only times and event descriptions are needed. Customer-facing wording can carry contractual, SLA and legal consequences: **have it reviewed internally before sending**. This is not legal advice. Nothing you enter is stored.