Root Cause Analysis

1）什么是RCA，为什么需要

根原因分析（Root Cause Analysis）-确定事件根源的结构化过程,以排除重复。中心是事实，因果关系和系统改进（过程，体系结构，测试），而不是寻找罪魁祸首。
目标：预防复发，降低MTTR/事件发生率，改善SLO，建立监管机构和合作伙伴的信心。

2）原则（Just Culture）

没有指控。我们不是惩罚人，而是惩罚风险行为。
事实。仅可验证的数据和工件。
E2E外观。从客户到后端和提供商。
假设的可验证性。任何断言-通过测试/实验。
CAPA闭包。对业主和时机采取纠正和警告措施。

3）入口文物和准备

UTC时间线：T0检测→ T+活动→ T+恢复。
可观察性数据：标志，度量（按队列排列），步道，合成，状态页面。
更改：版本，幻灯片，configs，提供程序事件。
环境：版本，工件散列，SBOM，基础架构标签。
事件基础：影响描述（SLO/SLA，客户，营业额），做出决定，工作场所。
Custody的链：谁以及何时收集/修改证据（对于合规性很重要）。

4）RCA技术： 何时

1.5 Why-快速找出狭隘问题的因果链。风险：将复杂系统"折迭"到生产线。
2.石川图（Fishbone）-按类别分解因子：People/Process/Platform/Policy/Partner/Product。起初很有用。
3.故障树分析（FTA）-从事件到原因集（AND/OR）的演绎。对于基础设施和"木头"故障。
4.Causal图形/事件链是具有概率和贡献权重的依赖性图。对微服务和外部提供商有好处。
5.FMEA（失败模式和效果分析）-预防：故障模式，严重程度（S），频率（O），可检测性（D），RPN=S × O × D。
6.Change Analysis-比较"原样/原样"（diff configs，schema，版本）。
7.《人类因素评论》是人们决策的背景（过度疲劳，糟糕的花花公子，过热）。

推荐韧带：Fishbone → Change Analysis → Causal Graph/FTA → 5 Why在关键分支上。

5） RCA分步过程

1.启动：指定RCA所有者，确定发布报告的期限（例如5个工作日），组装命令（IC，TL，Scribe，提供商代表）。
2.收集事实：时间线，图形，发行版，徽标，文物；提交版本并控制金额。
3.绘制影响图：哪个SLI/SLO受影响，哪些队列（国家，提供商，VIP）。
4.构建假设：主要的，替代的；现在可以检查哪些。
5.检验假设：在牛排/模拟/金丝雀上播放，跟踪分析，故障喷射。
6.确定根源和促成原因：技术、流程、组织。
7.形成CAPA：纠正（修复）和警告（防止）；成功指标和时机。
8.同意并发布报告：内部知识库+，必要时为客户/监管机构提供外部版本。
9.验证效果：14/30天后检查点；关闭行动。

6）什么被认为是"根源原因"

• 弱测试/幻灯片、缺失限制/警报、模煳文档、不正确的默认、脆弱的体系结构。
• 它通常是因素的组合（配置×没有门×负载×提供商）。

7） CAPA： 纠正和警告措施

• 伪码/伪码，回滚模式，更改限制/定时器，添加索引，复制/缓存，重新分配流量，更新证书。

• 测试（合同，混沌桉例），Alerta（燃烧率，合成法定人数），发布政策（金丝雀/蓝绿色），GitOps on configs，培训/支票单，提供商重复，DR教学。

每个动作：所有者、截止日期、预期效果、验证度量（例如,更改失败率降低X%,不重复90天）。

8）假设和效果的验证

实验：fault injection/chaos, shadow流量,A/B config,负载与真实的配置文件。
成功指标：SLO恢复，p95/p99稳定，没有错误率激增，MTTR减少，burn-rate趋势和零重现30天。
检查点：D+7，D+30，D+90-审查CAPA的执行和影响。

9） RCA报告模板（内部）

1.简短摘要：当发生了什么，谁受到影响。
2.影响：SLI/SLO，用户，区域，营业额/罚款（如果有）。
3.时间线（UTC）：主要事件（Alerts，解决方案，发行版，小说）。
4.观察和数据：图形，标志，跟踪，configi（诽谤），提供者状态。
5.假设和验证：接受/拒绝，引用实验。
6.根源原因：技术、流程、组织。

7.促成因素： "为什么没有注意到/停止。"

8.CAPA计划：包含所有者/时限/指标的操作表。
9.风险和残余漏洞：还有什么需要监测/测试。
10.附录：工件，链接，图形（清单）。

10）示例（简短，广义）

事件：下午7时05分至7时26分（SEV-1）付款成功率下降35％。
影响：e2e-SLO 21枚地雷被违反，3个国家受到影响，退还/赔偿。
原因1 （thes）：卡验证器的新版本将潜伏期提高到1。2从→时间表到提供商。
原因2（%）："A"提供商没有金丝雀,发布立即通过100%。
原因3 （org）：业务SLI的警报阈值不涵盖特定的BIN范围（VIP队列）。
CAPA：返回旧版本的验证器；引入金丝雀1/5/25%；通过BIN队列添加业务SLI；为"B"提供商谈判30％的失败率；溷沌桉例"缓慢上游"。

11） RCA流程成熟度量标准

按时执行CAPA（%在30天内关闭）。
Reopen rate（90天重新开放的事件）。
前后更改失败率。
发现系统原因的事件比例（而不仅仅是"人为错误"）。
通过RCA的新脚本测试覆盖。
报告发布时间（发布的SLA）。

12）受监管域的功能（fintech/iGaming等）

向外报告：报告的客户端/监管版本，没有敏感细节，但有防止重播的计划。
审核日志和不可变性：存储工件、签名报告、绑定到字幕、CMDB、发布日志。
用户数据：在日志示例中去人格化/掩蔽。
通知时间：与合同和规范挂钩（例如，初始通知的N小时）。

13）反模式

"Vasya的罪魁祸首"是在没有系统性原因的情况下停止人类因素。
缺乏假设检查是直觉推论。
过于普遍的RCA（"服务超载"）-没有具体更改。
没有CAPA或没有所有者/截止日期-报告是为了报告。
隐藏信息-失去信任,无法培训组织。
使用SLO/Business SLI不捆绑的指标过热。

14）工具和做法

带有元数据的RCA存储库（wiki/知识库）：服务，SEV，原因，CAPA，状态。
模板和机器人：从事件生成报告框架（时间线、图形、版本）。
因果关系图：构造事件因果映射（例如,基于逻辑/跟踪）。
混沌目录：用于在牛排中播放过去事件的脚本。
Dashboards "RCA之后"：单独的小部件，支持CAPA效应。

15）支票清单"准备出版"

• 时间线和文物完整且经过验证。
• 通过测试/实验确定并证明了根源原因。
• 根和促因分开。
• CAPA包含所有者，时限，可测量的效果度量。
• 在14/30天内有验证计划。
• 已准备好外部摊贩版本（如果需要）。
• 报告通过了那些/％评论。

16）结果

RCA不是为了形式而回顾性的，而是系统的学习机制。当事实收集时，因果关系得到证明，CAPA被封闭在指标上并通过实验进行验证，组织每次都变得更稳定：SLO更稳定，复发风险更低，用户和监管者的信心更高。