名称：事后分析描述：用于分析失败、停机、事故或负面结果，进行无责任事后分析，使用5个为什么或鱼骨图记录根本原因，识别纠正措施并指定所有者和时间线，从接近失误中学习，建立预防策略，或当用户提到事后分析、事件回顾、失败分析、RCA、经验教训或行动后回顾时使用。—

事后分析

目的

通过无责任事后分析，将失败转化为学习机会，记录发生了什么、为什么发生、影响量化、根因分析以及具有明确所有权的可操作预防措施。

使用时机

使用此技能当：

事件背景

生产停机、系统故障或服务降级发生
安全漏洞、数据丢失或合规违规发生
产品发布失败、项目错过截止日期或倡议表现不佳
影响客户的bug、质量问题或支持危机出现
可能造成严重危害的接近失误事件（主动事后分析）

学习目标

需要了解根本原因（不仅仅是症状）以防止再次发生
希望识别系统性问题与个体错误
必须为利益相关者或审计员记录时间线和影响
旨在基于失败洞察改进流程、系统或实践
建立组织学习文化（庆祝透明度，而非责备）

时间安排

事件解决后立即（在记忆新鲜时，48小时内）
定期回顾 对于重复性问题或长期问题
季度回顾 所有事件以识别模式
预事后分析 风格：在主要发布前，想象失败并写下事后分析

不要使用当：

事件仍在进行中（首先关注解决，其次是事后分析）
寻求分配责任或惩罚个体（与无责任文化相悖）
问题琐碎且无学习价值（保留给重要事件）

它是什么？

事后分析 是对失败的结构化、无责任分析，回答：

发生了什么？ 从检测到解决的事件时间线
影响是什么？ 量化的危害（受影响用户、收入损失、持续时间）
为什么发生？ 使用5个为什么、鱼骨图或故障树的根因分析
如何防止再次发生？ 具有所有者和截止日期的可操作项目
哪些方面做得好？ 事件响应的积极方面

关键原则：

无责任：关注系统/流程，而非个体。人类会犯错；系统应具有韧性。
可操作性：纠正措施必须具体、有所有权并被跟踪
透明性：广泛分享以促进组织学习
及时性：在记忆新鲜时进行（在解决后48小时内）

快速示例：

事件：数据库停机，2小时停机时间，5万用户受影响

时间线：

14:05 - 自动化部署开始（配置更改）
14:07 - 数据库连接池耗尽，错误激增
14:10 - 警报触发，值班人员被呼叫
14:15 - 工程师调查，识别错误配置
15:30 - 回滚启动（因不清楚的运行手册而延迟）
16:05 - 服务恢复

影响：2小时停机，5万用户无法访问，估计2万美元收入损失

根因（5个为什么）：

为什么停机？错误配置部署
为什么错误配置？连接池大小设置为10（应为100）
为什么值错误？配置模板不正确
为什么模板错误？新团队成员不熟悉生产值
为什么没有捕获？没有配置的暂存环境测试

纠正措施：

[ ] 添加配置验证到部署管道（所有者：Alex，截止日期：3月15日）
[ ] 创建类似生产负载的暂存环境（所有者：Jordan，截止日期：3月30日）
[ ] 更新运行手册，包括回滚步骤（所有者：Sam，截止日期：3月10日）
[ ] 入职清单：审查生产配置（所有者：Morgan，截止日期：3月5日）

哪些方面做得好：警报快速触发，团队在5分钟内响应，良好沟通

工作流程

复制此清单并跟踪进度：

事后分析进度：
- [ ] 步骤1：组装时间线并量化影响
- [ ] 步骤2：进行根因分析
- [ ] 步骤3：定义纠正和预防措施
- [ ] 步骤4：记录并分享事后分析
- [ ] 步骤5：跟踪行动项目至完成

步骤1：组装时间线并量化影响

收集事实：何时检测到、何时开始、关键事件、何时解决。量化影响：受影响用户、持续时间、收入/SLA影响、客户投诉。对于简单事件，使用资源/模板.md。对于具有多个原因或级联失败的复杂事件，研究资源/方法论.md获取高级时间线重建技术。

步骤2：进行根因分析

问“为什么？”5次以从症状到根因，或使用鱼骨图处理具有多个贡献因素的复杂事件。参见根因分析技术获取指导。关注系统失败（流程差距、缺失保障措施）而非人类错误。

步骤3：定义纠正和预防措施

对于每个根因，识别防止再次发生的措施。必须具体（非“改进测试”）、有所有权（指定人员）且有时间限制（截止日期）。分类为立即修复与长期改进。参见纠正措施框架获取框架。

步骤4：记录并分享事后分析

使用模板创建事后分析文档。包括时间线、影响、根因、措施、哪些方面做得好。广泛分享（工程、产品、领导层）以促进学习。在团队会议中呈现供讨论。归档到知识库。

步骤5：跟踪行动项目至完成

指定所有者，设置截止日期，添加到项目跟踪器。在站会或周会中审查进度。仅在所有措施完成时关闭事后分析。使用资源/评估器/事后分析评估表.json自评质量。最低标准：平均得分≥3.5。

常见模式

按事件类型

生产停机（系统故障、停机时间）：

时间线：检测 → 调查 → 缓解 → 解决
影响：受影响用户、持续时间、SLA违反、收入损失
根因：通常配置错误、部署问题、基础设施限制
措施：改进监控、运行手册、回滚程序、容量规划

安全事件（漏洞、脆弱性）：

时间线：漏洞发生 → 检测（通常延迟） → 遏制 → 补救
影响：数据暴露、合规风险、声誉损害
根因：缺失安全控制、访问管理差距、未修补脆弱性
措施：安全审计、访问审查、补丁管理、培训

产品/项目失败（发布、截止日期）：

时间线：规划 → 执行 → 发布/截止日期 → 结果与预期对比
影响：收入错失、用户流失、浪费努力、机会成本
根因：需求差、不切实际估计、不对齐、不足测试
措施：改进发现、估计、利益相关者对齐、验证流程

流程失败（运营、程序性）：

时间线：流程启动 → 故障点 → 影响认知
影响：延迟、质量问题、返工、团队挫折
根因：不清楚流程、缺失步骤、交接失败、工具差距
措施：记录流程、自动化工作流、改进沟通、培训

按根因类别

人类错误（表面原因，深入挖掘）：

不要停在“个人犯错”
问：为什么错误可能？为什么没有捕获？为什么没有保障措施？
措施：减少错误可能性（清单、自动化）、增加错误检测（测试、审查）、减轻错误影响（回滚、冗余）

流程差距（缺失或不清晰程序）：

症状：“不知道做X”、“不在运行手册中”、“第一次”
措施：记录流程、创建清单、形式化审批门、入职

技术债务（推迟维护）：

症状：“已知问题”、“脆弱系统”、“变通失败”
措施：优先处理技术债务、分配20%容量、重构、替换遗留系统

外部依赖（第三方失败）：

症状：“供应商下线”、“API失败”、“合作伙伴问题”
措施：添加冗余、断路器、优雅降级、SLA监控、供应商多样化

系统性问题（组织性、文化性）：

症状：“总是匆忙”、“没时间测试”、“压力发布”
措施：解决根本组织问题（不切实际截止日期、资源约束、激励不对齐）

根因分析技术

5个为什么：

从问题陈述开始
问“为什么发生？” → 回答
问“为什么发生？” → 回答
重复5次（或直到找到根因）
根因：可在组织/系统层面修复

示例：数据库停机 → 为什么？错误配置 → 为什么？错误值 → 为什么？模板错误 → 为什么？新团队成员不熟悉 → 为什么？入职中无配置审查

鱼骨图（Ishikawa）：

类别：人员、流程、技术、环境
头脑风暴每个类别的原因
识别最可能的根因供调查
适用于具有多个贡献因素的复杂事件

故障树分析：

顶部：失败事件（例如，“系统下线”）
门：AND（全部必需）与 OR（任一足够）
叶：基础原因（例如，“配置错误” OR “网络故障”）
从失败追踪到根因

纠正措施框架

措施类型：

立即修复：在几天内部署（热修复、手动流程、变通）
短期改进：在几周内完成（更好监控、更新运行手册、流程更改）
长期投资：在几个月内完成（架构更改、新系统、文化转变）

SMART措施：

具体：“添加配置验证”非“改进部署”
可测量：“将MTTR从2小时减少到30分钟”非“更快响应”
可分配：指定所有者，非“团队”
现实：给定容量和约束
有时间限制：明确截止日期

优先排序：

高影响、低努力：立即执行
高影响、高努力：作为战略项目安排
低影响、低努力：如果有空闲容量则执行
低影响、高努力：考虑跳过（成本 > 收益）

预防层次（从最有效到最不有效）：

消除：完全移除危险（例如，弃用风险功能）
替代：用更安全替代品替换（例如，使用托管服务而非自托管）
工程控制：添加保障措施（例如，速率限制、断路器、自动化测试）
管理控制：改进流程（例如，运行手册、清单、审查）
培训：教育人员（最不有效单独使用，结合其他）

指导原则

无责任文化：

❌ “工程师通过部署错误配置导致停机” → ✓ “部署管道允许错误配置到达生产环境”
❌ “PM未验证需求” → ✓ “需求验证流程缺失”
❌ “设计师犯错” → ✓ “设计审查流程未捕获问题”
关注：什么系统/流程失败？非谁犯错。

根因深度：

❌ 停在表面：“bug导致停机” → ✓ 深入分析：“bug部署因为测试差距、无暂存环境、发布压力”
❌ 单一原因：“数据库故障” → ✓ 多个原因：“数据库 + 无故障转移 + 警报延迟 + 不清楚运行手册”
规则：继续问“为什么？”直到达到可操作的系统改进

可操作性：

❌ 模糊：“改进测试”、“更好沟通”、“更小心” → ✓ 具体：“在4月1日前添加覆盖前10用户流的E2E测试套件（所有者：Alex）”
❌ 无所有者：“团队应记录” → ✓ 有所有权：“Sam在3月15日前记录事件响应运行手册”
❌ 无截止日期：“最终迁移” → ✓ 有时间限制：“在Q2结束前完成迁移”

影响量化：

❌ 定性：“许多用户受影响”、“显著停机时间” → ✓ 定量：“5万用户（基数的20%）、2小时停机、2万美元收入损失”
❌ 无指标：“糟糕客户体验” → ✓ 指标：“NPS从50降至30、100支持票、5流失客户（5万美元ARR）”

及时性：

❌ 等待2周 → 记忆淡忘，紧迫性丧失 → ✓ 在48小时内进行，当记忆新鲜
❌ 从不跟进 → 措施遗忘 → ✓ 跟踪措施，每周审查，完成时关闭

快速参考

资源：

资源/模板.md - 事后分析文档结构和部分
资源/方法论.md - 无责任文化、根因分析技术、纠正措施框架
资源/评估器/事后分析评估表.json - 事后分析的质量标准

成功标准：

✓ 时间线清晰，带时间戳和关键事件
✓ 影响量化（用户、持续时间、收入、指标）
✓ 根因识别（系统性，非个体责备）
✓ 纠正措施SMART（具体、可测量、可分配、现实、有时间限制）
✓ 无责任语调（关注系统/流程）
✓ 记录并在48小时内分享
✓ 行动项目跟踪至完成

常见错误：

❌ 责备个体 → 恐惧文化，隐藏未来问题
❌ 表面根因 → 不防止再次发生
❌ 模糊措施 → 实际上无改进
❌ 无跟进 → 措施从未完成，相同事件重复
❌ 延迟事后分析 → 细节遗忘，较不有用
❌ 不分享 → 无组织学习
❌ 防御语调 → 错过改进机会

事后分析技能Skill postmortem