事後分析

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下降和反復發生事件,發布的可預測性和客戶信心不斷提高。