Last reviewed 2024-12-30 UTC
Google Cloud Well-Architected 架構的可靠性支柱中，這項原則提供相關建議，協助您在發生故障和事件後，有效進行事後檢討。
這項原則與可靠性的學習 重點領域相關。
原則總覽
事後檢討報告會記錄事件、影響、為減輕或解決事件而採取的行動、根本原因，以及為避免事件重演而採取的後續行動。事後檢討的目的是從錯誤中學習，而不是追究責任。
下圖顯示事後檢討的工作流程：
事後檢討工作流程包含下列步驟：
- 建立事後檢討報告
- 擷取事實
- 找出並分析根本原因
- 為將來做規劃
- 執行計畫
在重大事件和非重大事件 (例如以下事件) 發生後，進行檢討分析：
- 使用者可見的停機時間或效能降低程度超過特定門檻。
- 任何類型的資料遺失。
- 值班待命工程師的介入措施，例如回溯版本或重新導向流量。
- 解決時間超過定義的門檻。
- 監控失敗，通常表示需要手動發現事件。
建議
在事件發生前定義事後檢討條件，讓所有人都知道何時需要進行事後檢討。
如要有效進行事後檢討，請參考下列小節的建議。
以不互相責難的態度檢討
有效的結案報告會著重於程序、工具和技術，不會將責任歸咎於個人或團隊。檢討報告分析的目的是改善技術和未來，而不是找出罪魁禍首。犯錯在所難免，目標應是分析錯誤並從中學習。
以下範例顯示指責式回饋與無責式回饋的差異：
- 歸咎責任的意見：「我們需要重寫整個複雜的後端系統！過去三季以來，每週都會發生中斷問題，相信大家都很厭倦這種零星的修正方式。認真地說，如果我再收到一次呼叫，我就要自己重寫了…」
- 無責回饋：「重寫整個後端系統的行動項目，或許能實際防止這些網頁繼續發生問題。這個版本的維護手冊相當長，很難完全掌握。相信日後的值班工程師會感謝我們！"
確保所有目標對象都能看懂結案報告
針對您打算納入報告的每項資訊，評估該資訊是否重要且必要，有助於目標對象瞭解發生了什麼事。您可以將補充資料和說明移至報表的附錄。審查人員可以要求提供更多資訊。
避免使用複雜或過度設計的解決方案
開始尋找問題解決方案前，請先評估問題的重要性，以及問題再次發生的可能性。為解決不太可能再次發生的問題，在系統中增加複雜度可能會導致不穩定性增加。
盡可能廣泛分享檢討報告
為確保問題獲得解決，請向廣大目標對象發布事後檢討結果，並尋求管理階層的支援。事後檢討的價值與事後檢討後發生的學習成正比。當更多人從事件中學習，類似的失敗再次發生的可能性就會降低。