技能 postmortem-writing
📝

postmortem-writing

安全

编写无指责事后分析报告

也可从以下获取: wshobson

将事件转化为组织学习机会,无需指责。创建结构化的事后分析报告,识别根本原因并防止再次发生。

支持: Claude Codex Code(CC)
🥉 75 青铜
1

下载技能 ZIP

2

在 Claude 中上传

前往 设置 → 功能 → 技能 → 上传技能

3

开启并开始使用

测试它

正在使用“postmortem-writing”。 帮我写一份事后分析。支付服务在部署 v2.3.4 后中断 47 分钟。根本原因是数据库连接池耗尽。

预期结果:

生成完整的事后分析报告,包含:带有影响指标的执行摘要、带时间戳的详细时间线表格、使用 5 Whys 的根本原因分析、检测部分(涵盖有效内容和漏洞)、响应评估、影响评估(客户、业务、技术)、经验教训,以及带有优先级和负责人的行动事项表格

正在使用“postmortem-writing”。 对以下情况进行 5 Whys 分析:缓存刷新后 API 延迟飙升

预期结果:

提供结构化的 5 Whys 分析,从问题陈述开始,然后通过每个为什么深入挖掘并提供证据,识别根本原因(缺少缓存预热、无部分失效机制),以及带有预防和检测策略的系统性改进方案

安全审计

安全
v1 • 2/24/2026

Static analysis flagged 34 patterns that are all false positives. The backtick patterns are Markdown code block delimiters, not shell command execution. The URLs are reference links to external documentation, not network calls. This skill contains only documentation and templates for writing postmortems.

1
已扫描文件
389
分析行数
0
发现项
1
审计总数
未发现安全问题
审计者: claude

质量评分

38
架构
100
可维护性
87
内容
50
社区
100
安全
100
规范符合性

你能构建什么

事件后审查

在解决生产事件后,使用此技能构建事后分析文档,包含时间线、影响评估和根本原因分析。

事件响应培训

使用模板和指南培训新团队成员,学习有效的事件文档编写和无指责审查实践。

组织学习

创建标准化的事后分析报告,可在团队间共享,以预防类似事件并传播经验教训。

试试这些提示

基础事后分析创建
帮我编写一份事后分析报告,记录 [DATE] 发生的事件。服务 [SERVICE NAME] 中断了 [DURATION],影响了 [NUMBER] 用户。问题原因是 [BRIEF DESCRIPTION]。生成一份包含执行摘要、时间线和初步根本原因分析的事后分析文档。
5 Whys 分析
对此事件进行 5 Whys 分析:[INCIDENT DESCRIPTION]。从问题陈述开始,通过至少 5 层为什么问题深入挖掘以识别根本原因。
事后分析会议主持
我正在主持 [INCIDENT SUMMARY] 的事后分析会议。创建一份会议议程,包含时间分配、关键讨论问题,以及在审查期间保持无指责环境的技巧。
行动事项生成
基于此事件分析 [PASTE ANALYSIS],生成优先排序的行动事项。每个事项应包括:优先级、具体行动、建议负责人角色、预计时间线,以及它是预防、检测还是缓解未来发生。

最佳实践

  • 在 24 小时内开始编写事后分析报告,此时记忆仍清晰
  • 关注导致失败的条件,而非谁犯了错误
  • 为每个行动事项指定具体负责人和截止日期

避免

  • 将个人指名为事件原因
  • 创建没有负责人或截止日期的行动事项
  • 跳过对揭示模式的轻微事件进行事后分析

常见问题

哪些事件需要编写事后分析报告?
建议对以下事件编写事后分析报告:SEV1/SEV2 事件、超过 15 分钟的面向客户的停服、数据丢失或安全事件、具有高严重性潜力的未遂事件,以及揭示新风险的 novel 故障模式。
如何保持无指责文化?
将问题聚焦于导致失败的条件,而非谁犯了错误。使用中性语言。记住,人们犯错误是因为系统允许他们犯错。目标是学习,而非惩罚。
何时应召开事后分析会议?
在事件发生后 3-5 天安排会议。这样有时间起草文档并收集事实,同时记忆仍清晰。会议通常需要 60 分钟。
谁应该参加事后分析会议?
包括所有参与事件响应的人员:值班工程师、事件指挥官、相关服务负责人和利益相关者。保持小组规模足够小以便进行有效讨论,通常为 8-12 人。
什么是好的行动事项?
好的行动事项应具体、可实现且可追踪。它们有明确的负责人、截止日期和工单引用。关注系统性改进而非一次性修复。按影响和优先级排序。
我们应该对未遂事件进行事后分析吗?
是的。可能引发严重事件的未遂事件通常与实际事件揭示相同的系统性问题。它们提供学习机会,而无需承受实际停服的压力。

开发者详情

文件结构

📄 SKILL.md