事故發生后如何進行無責事后分析
事故發生時，每個人都想知道故障點在哪里。這是人之常情——在 2024 年 CrowdStrike 事故中，我們都緊盯著新聞，尋找我們的 Windows 機器為何會出現 BSOD 的答案。然而，雖然事后分析是一個很好的工具，但它們很快就會變成一場指責游戲，重點是誰犯了錯誤，而不是錯誤是如何發生的。
這種事后分析會損害你的團隊文化。當員工知道他們犯錯會受到批評時，他們就會變得厭惡風險。當人們試圖逃避指責時，誠實、學習和責任感就會消失，因為承擔錯誤的責任會受到懲罰。這就是為什么一份好的事后分析必須始終是無可指責的。
在本文中，我將介紹如何進行無責事后分析、其應包含的基本組成部分以及您可以使用的有用模板。
什么是無責事后分析？
無責事后分析是一個結構化的過程，團隊會分析過去的事件，以記錄根本原因、業務影響、時間線、經驗教訓和行動項目。主要目標是從事件中吸取教訓并防止將來再次發生。無責事后分析強調流程改進而非個人過錯，鼓勵一種健康、開放的文化，讓工程師感到可以放心地承認錯誤。
無責事后分析對于事件響應至關重要
事后分析在包括事件管理（快速解決問題以限制業務影響的過程）在內的任何領域都很有用，而且幾乎總是從不責備中獲益。它通常在站點可靠性工程 (SRE) 中實施，但網絡安全和云計算等領域，甚至非技術領域（如應急響應、制造業甚至零售業）也受益于不責備的事后分析。
通常，如果您提供的服務需要在商定的服務水平目標 (SLO) 內運行，您希望該系統是可靠的。無責事后分析是幫助您實現這一目標的不可或缺的工具。
進行無責事后分析的其他原因
我們不去粉飾它——進行任何類型的事后分析都很少令人愉快。然而，有幾個好處讓它值得：
- 全面了解事件：事后分析提供事件的詳細說明，包括持續時間、用戶影響、財務影響、根本原因和預防措施。
- 根本原因分析：使用“五個為什么”之類的方法，事后分析可以發現系統中潛在的問題。
- 學習機會：事后分析可以幫助團隊反思哪些方面可以做得更好，從而促進持續改進。
- 預防措施：他們確定監測和其他預防措施中的差距。
- 責任：明確行動項目、責任主體和最后期限，確保改進工作的順利完成。
成功的事后分析的組成部分
我們已經介紹了為什么要進行事后分析。但如何進行事后分析呢？事后分析必須至少包含以下高級部分：
1. 執行摘要
執行摘要是一兩段簡短的文字，概括問題。您應避免涉及過多的技術細節，只需總結細節以便于推斷。以下是如果您是站點可靠性工程師，您可能會包含的內容的示例：
由于 10 月 15 日晚上 8:00 至 9:00 CDT 發布失敗，20% 的身份驗證微服務實例無法連接到后端，導致身份驗證服務調用失敗。身份驗證服務故障影響了交易門戶，導致 200 名用戶無法登錄交易系統。該問題已通過于 10 月 15 日晚上 11:15 CDT 更新失敗的身份驗證服務實例得到解決。我們已加強監控以在發布期間發現此問題。
2. 業務影響
您進行事后分析的全部原因是因為它破壞了您的理想運營狀態。用實際數字量化影響。如果有財務影響，請務必提及這一點。繼續我們的 SRE 示例，您可能會寫類似以下內容：
10 月 15 日晚上 8:00 至 11:15 之間，我們 2000 名交易用戶中有 10%（200 名）無法登錄。這些用戶仍然可以使用我們的手動交易處理系統下訂單。這不會對財務造成影響，而且我們在 4 周周期內仍保持著 SLO（服務水平目標）的水平。
3. 根本原因
每個人都想知道確鑿的證據！到底是什么導致了事件的發生？找到根本原因的一個經典方法是使用“五個為什么”方法。這需要問“為什么？”五次，每次都將當前的“為什么”引向前一個“為什么”的答案。第五個“為什么”應該揭示問題的根本原因。
讓我們在實踐中證明這一點：
20%的用戶在登錄交易門戶時看到“HTTP 500 內部服務器錯誤”。
為什么？
分析日志后發現，門戶在加載用戶配置文件時出現錯誤。
為什么？
調用“auth”微服務時，門戶收到“未知錯誤”。
為什么？
分析 auth 微服務日志后，我們發現它在連接后端 Postgresql 數據庫時出錯。此錯誤僅發生在部分 auth 微服務實例上。
為什么？
連接到后端 Postgresql 數據庫時，auth 微服務具有不正確的數據庫連接配置。
為什么？
昨晚，auth服務的代碼已發布以更新數據庫連接配置，但代碼發布未能更新某些微服務實例，從而導致這些實例的配置已過時。
因此，最終的根本原因是您的應用程序所依賴的遠程服務（身份驗證服務）上的代碼發布部分成功。
注意： 5 個為什么方法是確定根本原因的有效機制。但是，在某些情況下，這種方法可能不適用。例如，如果硬盤驅動器出現故障，您可能需要從五個“為什么”縮減為兩個或三個。
4. 時間線
又稱為“一系列不幸事件”。本節按時間順序介紹事件。時間線將幫助團隊發現任何未來的流程改進。
例如，如果你是一名站點可靠性工程師，你是否需要等待 25 分鐘才能讓數據庫團隊加入作戰室？如果是這樣，你可能會問自己將來是否可以并行執行特定任務。
5. 經驗教訓
如果你不吸取任何教訓，這種事件肯定會再次發生。本節中可能包含以下內容：
- 哪些方面進展順利？
- 什么地方進展不順利？
- 我們可以做些什么來避免將來再發生這種情況？
- 我們的監控是否在最終用戶報告問題之前就發現了問題？我們如何改進？
5. 行動項目
了解原因并對發生的事情更加明智是件好事，但您還需要制定行動計劃，說明應采取哪些步驟來阻止事件再次發生。每個行動項目都必須有負責人和目標日期。任務負責人還應負責在任務完成后更新事后分析。
培育無責備的事后文化
因此，我們討論了如何創建出色的事后分析，但如何才能使其“無可指責”呢？這在很大程度上取決于文化，而不是流程。您需要創建一個環境，讓您的員工始終如一地撰寫事后分析，同時克服時間限制和人們天生不愿承認錯誤等挑戰。以下是您可以使用的一些策略：
1. 高層領導的支持和參與
實施事后總結文化必須自上而下。如果領導者也在回顧自己的錯誤，那么它就會起到表率作用。此外，確保事后總結與高層領導一起審查。當領導者參與時，團隊通常更傾向于撰寫事后總結
2. 獎勵寫得好的事后分析
每個月或每季度對寫得好的事后分析報告進行評審，并獎勵撰寫這些報告的團隊。這將鼓勵其他團隊效仿。
3. 建立事后分析庫
所有事后分析報告都必須存儲在一個存儲庫中，以便于訪問——Github 是一個很好的選擇。隨著團隊積累了精心編寫的事后分析報告，他們將利用過去的事后分析報告來解決新問題。此外，擁有一個集中的事后分析報告存儲庫有助于提供更智能的解決方案（例如使用機器學習來幫助解決新問題）。
何時應進行事后分析？
并非所有事件都應進行事后分析。創建事件嚴重性級別，例如優先級一 (P1)、優先級二 (P2) 和優先級三 (P3)，其中 P1 對業務最為關鍵。在這種情況下，承諾對每個 P1 進行事后分析，并可能對某些 P2 和 P3 進行事后分析，具體取決于業務影響和團隊情緒。
以下是我確定是否必須進行事后分析的指導原則：
- 組織授權（例如，您已承諾對所有 P1 事件執行一項任務）
- 該事件導致數據丟失（或您所在行業特有的另一種形式的資源損失。例如貨幣）
- 對用戶/客戶產生了重大影響
- 該團隊認為他們應該深入挖掘以了解發生了什么。
我建議在五到七個工作日內，趁著你們的記憶還比較新鮮的時候，集體進行冷事后分析。
事后分析模板
正如您已經知道的那樣，事后分析報告的各個部分包含大量信息。一開始這可能令人望而生畏，但幸運的是，您不必從頭開始構建它們！創建事后分析報告的一種非常有效的方法是使用完善的模板。
有許多事后分析模板可用。我最喜歡的是來自 Google 的模板，但您可以隨意使用以下任何模板：
結論：無責事后分析值得投資
無責事后分析對于有效的事件管理至關重要。它們可以幫助團隊從事件中吸取教訓并防止將來再次發生。為了使事后分析有效，它們必須關注系統和流程，而不是個人。高層領導的支持和中央事后分析存儲庫進一步提高了它們的價值，從而實現了持續改進和創新。
請先 登錄后發表評論 ~