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更穩定，復發風險更低，用戶和監管者的信心更高。