incident-postmortem

事件复盘技能

此技能可生成符合行业标准格式的完整、无责备事件复盘文档。输出会始终采用无责备的表述——聚焦系统缺陷，而非个人失误——并推动制定具体、可关闭的行动项，而不是含糊的流程承诺。

不完全符合你的需求？ 如果事件是由 AI Agent 导致的（例如工具使用失控、发布了幻觉内容），请使用 agent-incident-postmortem。

提出行动项

行动项不必只留在文档中：可将其交给 action-runner，它会预览行动项（试运行并评估风险），仅通过已连接的 action MCP 执行你批准的操作，并将完成情况记录回知识库。常见做法：为每个行动项创建一个后续问题（🟡），指派给对应负责人并设置截止日期。此技能负责提出行动项；action-runner 负责把关并执行——绝不会静默操作。

在此流程中的位置——将事件转化为修复措施

这是事件响应主干流程中的第三环：/slo-error-budget（设定框架）→ /debugging-log-analyser → incident-postmortem → /oncall-runbook。它会接收来自 /debugging-log-analyser 的根因诊断（直接阅读，不要重新诊断），并将促成因素和优先级排序后的行动项 交给 /oncall-runbook——/slo-error-budget 中的错误预算则决定这些 行动的紧迫程度。无责备、根因与促成因素以及行动项均在 docs/craft/incident-response.md 中统一定义； 无责备是这一流程的核心原则。

流程

一旦复盘开始归咎于个人，就会失效——真实数据会随之枯竭，今后的事件也会被少报。第一阶段要先确立这一框架；后续一切都依赖于此。

1. 先确立无责备的框架。 开篇明确说明，复盘审视的是让胜任者做出该操作的系统，而不是个人。这并非出于礼貌——而是获得真实时间线的前提，而此技能的其余部分都需要这条时间线。 完成标准： 明确说明这一框架，文档中没有任何句子归咎于个人；问题应归因于系统缺陷。
2. 根据证据构建时间线。 使用真实时间戳（来自诊断和日志，而非记忆），还原事件的开始 → 检测 → 缓解 → 解决过程。检测、缓解和解决是不同的事件——分别记录。 完成标准： 时间线包含真实时间戳，并区分检测、缓解和解决；影响已量化（用户数、持续时间、范围）。
3. 找出根因和促成因素。 根因只有一个；促成因素则是让问题影响用户并持续存在的原因（例如缺少告警、跳过金丝雀发布、运行手册不清晰）。只写根因、不写促成因素的复盘，说明调查还不够深入。 完成标准： 至少列出关键的促成因素，每项都指向一个可修复的系统缺陷。
4. 制定有负责人和截止日期的行动项，并依据预算确定优先级。 将促成因素转化为具体行动项，每项都要指定负责人和日期；“改进监控”之类含糊的行动项会逐渐失效。根据错误预算为其排序（预算已耗尽 → 立即处理；预算健康 → 尽快处理）。 完成标准： 每项行动都有负责人和日期，并且 /oncall-runbook 能将检测和缓解方面的经验转化为条目，无需重新分析事件。

必填信息

根据已提供的信息开展工作。如果缺少以下任何信息，仍需生成完整输出：为每处缺失内容填入合理的假设，并标注为 (假设，需确认)，并在末尾列出这些假设。只有在核心主题本身缺失（没有可供撰写的内容）时，才先提问。

• 事件标题 / ID
• 严重程度（P1 / P2 / P3 或 SEV1 / SEV2 / SEV3）
• 事件日期和持续时间
• 发生了什么（可以是粗略笔记，技能会对其进行整理）
• 受影响的服务或系统
• 客户影响（受影响用户数量、哪些功能降级）
• 如何发现
• 如何解决
• 对根本原因的初步判断
• 已确定的行动项（可选）
• 响应人员（值班或响应人员——姓名或角色；用于编制时间线，不用于追责）
• 已发送的客户或外部沟通（可选——任何带时间戳的状态页更新、电子邮件或支持消息）

从 Brain 读取 / 写入 Brain

如果存在 professional-brain（brain/），请先查阅，再提问：

• **先读取：**受影响系统的 entities/ 文件，以及任何相关的既往 decisions/ 或过往事件（反复出现的根本原因是最需要揭示的内容）。
• **之后写入：**将行动项和决策记录到 decisions/，并将根本原因方面的经验教训记录到 knowledge/——将已验证的原因标记为 [data]，将推测的原因标记为 [hunch]，切勿反过来标记。

深入参考资料

• references/root-cause-digging.md——正确运用五个为什么（追问到可改变的系统属性为止，并分别梳理原因、检测和响应链路）、用于全面排查的促成因素分类法，以及将带有责备意味的表述改写为系统性表述的方法。撰写“根本原因”部分以及重新表述任何带有责备意味的输入笔记时，请使用此资料。
• templates/review-meeting-agenda.md——一份以文档为先的 45 分钟事后复盘会议议程，包含基本规则和行动项质量门槛。完成事后复盘后，请一并提供此议程。

输出格式

---

事件事后复盘：[事件标题]

事件 ID：[ID] 严重程度：[P1/P2/P3] 日期：[日期] 持续时间：[开始时间 → 解决时间 — 总持续时间] 状态：[已解决 / 监控中 / 进行中] 作者：[留空供用户填写] 最后更新：[日期]

---

执行摘要

[用 3–5 句话描述发生了什么、哪些人受到影响，以及采取了哪些措施来解决问题。面向非技术利益相关方撰写。不使用术语。不归咎于任何人。]

---

影响

维度	详情
受影响用户	[数量或百分比]
服务降级	[受影响服务列表]
业务影响	[收入、SLA 违约、支持工单等（如已知）]
持续时间	[从首次发现到完全解决的总时长]

---

时间线

按时间顺序列出事件。每个条目格式为：[HH:MM UTC] — [发生了什么。谁采取了什么行动。有什么变化。]

时间线条目规则：

• 使用被动语态或以系统为中心的表述——避免使用“X 犯了错”
• 包含：首个症状、发现、升级、已验证的假设、采取的修复措施、确认问题已解决
• 记录关键事件之间的时间间隔（例如“发现到升级相隔 22 分钟”）

时间线图——还需使用 Mermaid 甘特图呈现事件时间线，以便一目了然地查看间隔（例如：发现 → 升级）。该图会在 playground 中实时渲染，并可导出为 PNG。使用事件阶段作为条形；表述应避免责备，并以系统为中心：

gantt
    title Incident timeline (UTC)
    dateFormat HH:mm
    axisFormat %H:%M
    section Phases
        Undetected impact   :22:00, 18m
        Detection           :milestone, 22:18, 0m
        Investigation       :22:18, 22m
        Mitigation          :22:40, 15m
        Resolved            :milestone, 22:55, 0m

---

根本原因

主要根本原因： [用一句清晰的话说明。技术准确，但通俗易懂。例如：“部署配置错误导致……”]

促成因素：

• [因素 1 — 例如：缺少金丝雀部署，导致变更立即影响了 100% 的流量]
• [因素 2 — 例如：告警阈值设置过高，未能及时发现初期性能下降]
• [因素 3 — 根据实际情况补充]

为什么现有的防护措施未能阻止此问题？ [用一段诚恳的文字说明监控、测试或流程为何未能更早发现问题。此处最需要体现无责分析——重点关注系统缺陷，而非个人失误。]

---

检测

• 最初是如何检测到的？ [客户报告 / 自动告警 / 内部监控 / 人工观察]
• 从事件开始到检测到事件的时间： [X 分钟]
• 我们本应更快检测到吗？ [是 / 否 — 说明原因]

---

解决

是什么修复了问题？ [用一段话清晰描述实际修复措施] 为什么此方法有效？ [简要说明技术原理] 彻底解决问题前是否采取了临时缓解措施？ [是/否 — 如果是，请说明]

---

待办事项

#	行动	负责人	截止日期	优先级
1	[具体、可测试的行动]	[团队或人员]	[日期]	P1/P2/P3

待办事项规则：

• 每项行动都必须足够具体，能够判定为“已完成”或“未完成”——避免“改进监控”这类含糊的事项
• 区分以下类型：防止再次发生（修复根本原因）、改进检测（下次更快发现问题）、改进响应（下次更快解决问题）
• 指定实际负责人——可避免时，不要写“团队”或“TBD”
• 将 P1 事项标记为阻止事件被标记为完全关闭的事项

---

做得好的方面

[列出 3–5 条对响应过程的客观观察。包括：协作迅速、有效使用运行手册、升级处理得当、沟通清晰。本部分有助于增强团队信心并巩固良好习惯。]

---

经验教训

[列出 3–5 条值得分享给团队以外人员的事件重要启示。将这些内容写成可迁移的经验，例如：“我们的数据库故障切换运行手册未考虑只读副本延迟。所有涉及数据库故障切换的运行手册都应进行审查。”]

---

沟通记录

[可选 — 列出已发送的外部沟通：状态页更新、客户邮件、支持回复。注明时间戳。]

---

评分标准（0–40）

交付前请为此技能的任何输出打分；达到 32 分及以上即可交付。

维度	0	5	10
无责分析且实事求是	点名指责，或过度粉饰以致问题全貌不复存在	表述不带责备，但个人行动被模糊处理	在系统分析框架内如实陈述个人行动，既诚恳又安全
根因分析深度	止步于表面现象或“人为错误”	找到了系统缺陷，但只深入追问了一层“为什么”	根因和促成因素共同解释了系统为何允许问题发生，而不仅是指出哪里出错
时间线取证质量	内容稀疏、顺序混乱，或缺少从检测到解决的关键环节	内容完整，但没有时间戳或决策节点	标注时间戳，包含检测延迟、决策节点，以及实际尝试过但未奏效的方案
待办事项责任落实	改进措施含糊，没有负责人	已指定负责人，但事项无法建单或没有截止日期	每项都可建单，且有负责人和截止日期，并对应某个根因或促成因素

质量检查

• 时间线不包含归咎于个人的措辞
• 根本原因足够具体（不能是“人为错误”）
• 根本原因回答的是“为什么会发生？”，而不只是“发生了什么？”——要指出系统或流程上的缺口，而不是症状
• 促成因素解释了系统性缺口
• 每项行动都有负责人和截止日期
• “进展顺利之处”一节内容真实，而非敷衍
• 行动项不得使用“改进监控”“增强韧性”或“加强测试”等含糊措辞——每项都必须说明具体变更
• 执行摘要对非技术管理者来说通俗易懂

反模式

• 不要将责任归咎于个人——事后复盘必须聚焦于系统和流程故障
• 不要使用“改进监控”等含糊措辞撰写行动项——每项都必须说明具体且有明确负责人的变更
• 不要省略促成因素——只写根本原因会遗漏导致事件发生的系统性问题
• 不要省略检测时间线——检测耗时与解决耗时同样重要
• 在所有行动项都明确负责人和截止日期之前，不要将事后复盘视为已完成

使用示例

• “为 [事件名称] 服务中断撰写事后复盘”
• “帮我撰写一份 P1 事件报告”
• “为 [日期] [服务] 停机事件生成一份 RCA 文档”
• “根据这些笔记起草一份不追责的事后复盘：[粘贴笔记]”

示例触发短语

• “撰写一份事后复盘。”
• “撰写事件报告。”
• “撰写 P1 复盘。”
• “对这次服务中断进行根本原因分析。”