事后分析

1）为什么需要事后分析

事后分析（mortem/AAR）是组织故障后培训的结构化过程。目的不是寻找罪魁祸首，而是确定根源和促成因素，并巩固可衡量的行动（CAPA），这些行动通过改善SLO，MTTR和客户/监管机构的信任来降低事件再次发生的风险和成本。

2）原则（Just Culture）

无罪：分析系统、解决方桉和上下文而不是个性。
事实比观点更重要：时间线，标志，度量，步伐，变化工件。
E2E外观：从客户端症状到内部成瘾和外部提供者。
可验证性：每个假设都通过实验/数据得到支持。
循环闭合：CAPA →分析→检查点→重新检查。

3）何时运行解析以及哪些格式是

强制性：SEV-0/1；违反SLA/监管要求；数据泄漏；有意义的公关风险。
加速（光）：有明显影响或反复症状的SEV-2。
通讯AAR：如果故障影响了状态页面/支持,我们检查升级的SLA和消息质量。

时间：48-72小时的草稿，最终版本-最多5个工作日（除非另有规定）。

4）角色和责任

分析所有者（RCA Lead）：组织过程、主持会议、负责报告的质量和CAPA。
事件指挥官（IC）：提供事件事实和解决方桉。
技术领导者（按系统）：分析支持人工制品的原因。
Comms/Support/Legal：评估通信和合规要求。
Scribe：协议，收集证据，遵守结构。
产品/业务摊贩：对客户/营业额的影响,CAPA优先级。

5）准备： 会议前收集的内容

时间线（UTC）：T0检测→ Tn恢复；发行版/幻灯片/配音，提供商状态。
可观察性数据：SLI/SLO图形，error-rate，percentiles，logi，跟踪和截图。
更改上下文：引用PR/dploy，DB迁移，幻灯片，工作计划。
影响：受影响的队列/地区/提供商,停机时间,SLA学分。
通讯：状态页面上的草稿/帖子，札幌响应，内部公告。
政客/花花公子：在出现偏差的过程中应该发生什么。

6）分析技术（选择组合）

5 Why：快速打开因果链（风险-过度简化）。
石川图（Fishbone）： People/Process/Platform/Policy/Partner/Product。
故障树分析（FTA）：从事件演绎到多种原因（AND/OR）。
变化分析：事件期间发生了什么变化vs稳定状态。
Causal Graph：复杂微服务和外部依赖性的因果关系图。
《人类因素评论》：疲劳，信息噪音，无关紧要的运行手册。

7）报告结构（模板）

1.执行摘要：什么时候，谁受到影响，最终状态。
2.影响：SLI/SLO，用户，区域/提供商，停机时间，财务/监管影响。
3.时间线（UTC）：关键事件、发布、IC解决方桉、通信。
4.观察和数据：图形，标志，步道，诽谤/图。
5.假设和验证：接受/拒绝，引用实验/模拟。
6.根源：系统/流程/技术（清晰的措辞）。
7.促成因素：为什么之前没有注意到/停止。
8.什么有效/什么行不通：过程，工具，人。
9.CAPA：具有所有者/时限/成功指标的纠正和警告措施。
10.验证计划：D+14/D+30检查点，关闭标准。
11.外部版本：客户端/调节（无敏感数据）。
12.应用程序：工件，提要/公关链接，dashbords截图。

8）CAPA： 如何使行动成为工作

每个动作都具有所有者，截止日期和KPI效果（例如，将更改失败率降低X％，零重复90天，减少峰值burn-rate）。
将Corrective（修复）和Preventive（防止）措施分开。
与策略即代码相关联：Alerts、SLO门、自动轨道/限值、GitOps。
CAPA在每周的运营会议上通过评论进入公众支持。

9）检查效果并关闭

检查点：D+7（中间），D+14/D+30（主要），D+90（总数）。
验证：测试/模拟（游戏日），阴影流量，观察力（绿色区域稳定的SLI），没有复发。
只有在执行CAPA和确认的指标时才能关闭。

10）沟通和合规性

内部：产品/支持/管理的清晰状态，满足升级的SLA。
外部：状态页面，发送给客户/合作伙伴；没有指控的语言，明确的预防计划。

监管： 通知的时机,实例的去个性化,报告和工件的不变存储.

11）过程成熟度度量

报告发布时间：事实vs SLA（例如≤5工作日）。
CAPA完成率：按时关闭的活动的百分比。
Reopen rate： 90天重播事件百分比。
系统原因与"人为错误"的比例。
Alert卫生：减少虚假的呼声，增加覆盖的runbook'ami alerts。
更改DORA指标：MTTR，更改失败率之前/之后。

12）支票单

在分析之前

• 已确定RCA的所有者和参与者的组成。
• 收集时间线和工件（日志/图形/版本/标志）。
• 按队列/区域/提供商评估影响。
• 准备了Impact和Timeline部分的草稿。
• 相关政策/花花公子与实际行动相匹配。

在此期间

• 记录了接受/拒绝的假设和依据。
• 已确定根源和促成原因。
• 制定了带有KPI和时间表的CAPA计划。
• 为外部各方商定报告的版本（如有必要）。

之后

• 报告按时发布，按角色访问。
• CAPA在逆止器中列出，业主确认。
• 已指定检查点和迷你模拟进行验证。
• 更新了runbook/SOP/Alerta/文档。

13）反模式

"Man X是罪魁祸首"-没有系统原因→重播。
没有CAPA或没有所有者/时间表的报告-纸张。
没有事实/文物-感觉上的结论。
过于通用的语言（"DB过载"）没有具体更改。
忽略通信和合规性是声誉风险。
没有效果检查的关闭是在几周后复发。

14）迷你模板

报告上限

Incident: INC-2025-10-31 (SEV-1)
Window: 2025-10-31 18: 05-18: 47 UTC
Owner of the analysis: @ rca-lead
Affected: EU region, payments (success -28% peak)
Status: corrected; 48 hours monitoring

根原因的表述（示例）

CAPA（片段）

在PSP-A （1%→5%→25%）中启用金丝雀路由,所有者：@payments-tl, do： 2025-11-07, KPI：提供商发布30天时为零P1事件。
重新配置总时间≤ SLA 800毫秒，所有者：@platform-sre，直到：2025-11-05，KPI：p99 <600毫秒。
通过BIN队列添加业务SLI，所有者：@data-lead，直到：2025-11-10，KPI：检测降解<5分钟。

15）嵌入日常实践

每周RCA评论：CAPA状态，新课程，流程更新。
Wiki中带有标签（服务，SEV，原因）和搜索的后太平间目录。
2-4周后根据事件进行模拟以验证措施。
在通话中包含课程并更新培训脚本。

16）结果

事后分析是系统改进的机制。当事实收集、因果关系得到证实、行为可衡量和验证、组织积累可靠性运营资本时：MTTR下降和反复发生事件,发布的可预测性和客户信心不断提高。