用途
该技能用于创建「无问责」的事后复盘报告（blameless incident postmortem），帮助团队将运维中断转化为学习机会，聚焦系统故障与流程缺陷，而非追究个人责任，从而实现持续改进并防止事故复发。
核心原则
- 无问责：关注系统，而非人。问「为什么会发生」，而非「谁搞砸了」。
- 心理安全：团队成员必须能在不恐惧的情况下讨论根因。
- 数据驱动：基于日志、指标与事实，而非假设。
- 行动导向：每个发现都要引向可执行的改进。
- 学习文化：把事故视为宝贵的学习事件，而非失败。
- 透明：广泛分享发现，沟通变更以预防类似事故。
主要能力
时间线重建
以表格形式按时间顺序记录事件：时间（UTC）、谁、做了什么、证据、背景。时间线模板节点包括：T+0（告警，首次检测）、T+X（检测，事故被确认）、T+Y（沟通，通知相关方）、T+Z（缓解，事故负责人采取行动）、T+N（解决，系统恢复正常），以及持续时间（从检测到解决的总时间）。示例中列出了 2024-02-15 从 14:32 部署缺陷版本到 15:30 根因会议的具体过程。
根因分析（5 Whys）
通过连续追问「为什么」找到系统性问题。示例：
- Why 1：网站为什么宕机？答：部署 v2.1.3 包含缺陷，导致认证服务无限循环。
- Why 2：缺陷为什么进入生产环境？答：代码审查遗漏，测试套件未捕获。
- Why 3：测试套件为什么没捕获无限循环？答：负载/压力测试只偶尔运行，不在标准 CI 流程中。
- Why 4：为什么负载测试不是 CI 的强制项？答：历史上较慢，团队优先考虑速度而非可靠性。
- Why 5：为什么团队优先优化部署速度而非测试？答：快速发布功能的压力，没有书面的测试严格度标准。
根因：流程缺口——CI 中没有强制负载测试；发布压力。
应避免：过早停止（「操作员没注意到错误」）、把人因当作根因（「开发者犯了错」）、系统性问��不清晰。应关注：流程失败、监控缺口、沟通中断、知识缺口、工具局限、架构弱点。
贡献因素（瑞士奶酪模型）
大多数事故涉及多个失败叠加。示例中列出 7 项因素：周五下午匆忙部署、无自动回滚能力（手动流程）、值班工程师对新代码了解不足（入职 3 周）、认证服务变更无负载测试覆盖（技术债）、监控告警阈值设得过高（错过早期预警）、部署未分阶段直接上生产（流程缺口）、无变更咨询委员会审批（治理缺口）。单一项不会导致事故，组合起来造成 28 分钟中断。
近因与根因
- 近因（直接原因）：认证代码中的无限循环、本不该发生的部署、缺失的监控告警。
- 根因（系统性失败）：对关键变更的代码审查流程不足、部署流程缺少分阶段/金丝雀部署、测试策略不含压力测试、值班团队对近期变更存在知识缺口。
复盘应聚焦根因，而非近因。
行动项
结构为：[优先级] | [做什么] | [为什么] | [负责人] | [截止日期] | [状态]。分三类：
- 立即行动（0-7 天）：例如「为无限循环部署热修复」（CRITICAL，负责人 Sarah，2024-02-15，已完成）、「记录代码变更影响」（HIGH）、「向客户发送事故后沟通」（MEDIUM）。
- 短期行动（1-4 周）：例如「实现自动金丝雀部署」（HIGH，DevOps，2024-03-01）、「将认证负载测试加入 CI 流程」（HIGH，QA）、「让新值班工程师了解近期变更」（MEDIUM，Tech Lead，2024-02-28）。
- 长期行动（1-3 个月）：例如「实现自动回滚能力」（MEDIUM，架构，2024-04-15）、「审查变更咨询委员会流程」（LOW，运维，2024-05-01）、「为关键服务安排季度负载测试」（LOW，性能，2024-06-01）。
行动项须符合 SMART：具体、可衡量、可指派、现实、有时限。
预防措施
- 流程变更：对关键服务实施分阶段/金丝雀部署；对认证服务变更增加代码审查要求；关键路径变更需通过负载测试。
- 监控与告警：降低错误率告警阈值（早期预警）；为认证服务增加 CPU/内存告警；增加金丝雀端点合成监控。
- 自动化：错误率 >2% 时自动回滚；CI 流程中的负载测试门禁（强制而非可选）；每周自动混沌工程测试。
- 文档与培训：记录认证服务架构；创建认证服务事故运行手册；为值班团队安排知识转移会议。
- 组织层面：消除截止日期压力，不在周五下午部署；让值班工程师参与关键服务代码审查；建立事故 SLA：P0 事故从检测到解决 <15 分钟。
模板结构
包含：事故 ID、日期、持续时间、影响、严重级别；事故摘要；时间线；根因分析（主要根因、5 Whys、贡献因素）；影响分析（受影响客户、持续时间、收入影响、声誉影响、数据丢失）；检测与响应（检测时间、响应时间、解决时间、响应质量）；做得好之处（配结果，认可优秀工作）；待改进之处（配后果）；行动项；预防措施；附录（脱敏错误日志、客户沟通、事件期间监控图表、架构图、相关历史事故）。
复盘会议引导
无问责会议原则：以背景而非责备开场；使用中立语言（「代码发生了变更」而非「代码被弄坏了」）；问好奇的问题（「你屏幕上看到了什么」而非「你为什么不查日志」）；鼓励讲述；捕捉假设（「我假设……」揭示知识缺口）；无层级（值班工程师与 CTO 的观察同等重要）；记录决策（为何选择回滚而非修复）；记录学习收获。
参与者：值班工程师（事故响应者）、服务负责人、DevOps/基础设施团队、产品/业务负责人、引导者（有经验的中立方）。会议时长最多 30-60 分钟。召开时机：事故解决后 48 小时内（细节仍清晰时）。
分发与跟进
广泛分享：复盘是内部学习工具，与整个工程组织分享。给领导层一页纸执行摘要。对客户保持透明。每月审查未完成的行动项。每季度做趋势分析——是在预防事故类别还是只在救火。
防止类似事故
事故类别跟踪：认证失败、数据库性能退化、内存泄漏、配置错误、依赖失败、部署失败。同一类别发生两次：升级预防措施。同一事故发生三次：组织级升级（管理层审查）。
使用方式
按模板结构撰写报告：先记录事故基本信息与摘要，再按时间线重建事件过程，然后用 5 Whys 与贡献因素做根因分析，接着评估影响与响应表现，总结做得好与待改进之处，最后列出分优先级的 SMART 行动项与预防措施，并按无问责原则组织复盘会议、分发报告与跟进行动项。
适用场景
适用于工程团队（尤其 SRE、DevOps）在运维事故、服务中断或部署失败后进行的系统性复盘与持续改进。
限制
本资料未提供该技能的具体收费、价格、平台支持情况或安装命令等信息，暂未提供。