在事件報告中使用 5 個為什麼分析 - Amazon CloudWatch
什麼是 5 個為什麼分析？事件報告的好處事件報告中的範例案例使用引導式 5 個為什麼工作流程處理具有多個原因的複雜事件有效 5 個為什麼分析的最佳實務

本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

在事件報告中使用 5 個為什麼分析

產生事件報告時，CloudWatch 調查可以執行 5 個為什麼根本原因分析，以系統性地識別操作問題的基礎原因。這種結構化方法透過更深入的洞察和可行的修復步驟來增強您的事件報告。

此功能使用 Amazon Q 提供對話式聊天。登入 的使用者AWS 管理主控台必須具有下列許可：

{ 
    "Sid" : "AmazonQAccess",
    "Effect" : "Allow",
    "Action" : [
       "q:StartConversation", 
       "q:SendMessage", 
       "q:GetConversation", 
       "q:ListConversations", 
       "q:UpdateConversation", 
       "q:DeleteConversation", 
       "q:PassRequest" 
     ],
    "Resource" : "*"
 }

您可以直接新增這些許可，或將 AIOpsConsoleAdminPolicy 或 AIOpsOperatorAccess 受管政策連接至使用者或角色。

什麼是 5 個為什麼分析？

5 個為什麼是根本原因分析技術，會重複要求「為什麼」從事件症狀向下切入基本原因。每個答案都會成為下一個問題的基礎，建立邏輯鏈來顯示真正的根本原因，而不只是表面層級症狀。

在事件報告產生期間，CloudWatch 調查會使用此方法來分析調查結果，並提供結構化根本原因分析，這些分析超出立即技術故障，以識別程序、組態或系統問題。

事件報告的好處

在事件報告中包含 5 個為什麼分析提供了幾個優點：

  • 全面的根本原因識別 - 超越立即的技術原因，以識別基礎程序或系統問題

  • 可行的補救措施 - 提供特定、有針對性的動作，以防止再次發生，而非暫時性修正

  • 組織學習 - 記錄完整的因果鏈，以供未來參考和團隊知識分享

  • 結構化分析 - 確保系統性調查，而不是臨時問題解決

事件報告中的範例案例

資料庫連線失敗事件

初始事件：電子商務應用程式遇到 500 個廣泛錯誤

  1. 為什麼 1：使用者為什麼會收到 500 個錯誤？ 應用程式無法連線至主要資料庫。

  2. 為什麼是 2：為什麼應用程式無法連線至資料庫？ 資料庫執行個體用完可用的連線。

  3. 為什麼 3：為什麼資料庫用完連線？ 批次處理任務會開啟許多連線，而不會正確關閉它們。

  4. 為什麼是 4：批次工作為何無法正常關閉連線？ 任務的錯誤處理不包含失敗案例中的連線清除。

  5. 為什麼 5：為什麼未實作適當的錯誤處理？ 程式碼檢閱程序不包含資源管理模式的特定檢查。

根本原因：資源管理的程式碼檢閱標準不足

建議的動作：更新程式碼檢閱檢查清單、實作連線集區監控、新增自動化資源洩漏偵測

效能降級事件

初始事件：在流量激增期間，API 回應時間從 200 毫秒增加到 5000 毫秒

  1. 為什麼是 1：為什麼回應時間會增加？ 所有應用程式執行個體的 CPU 使用率都達到 100%。

  2. 為什麼 2：為什麼不自動擴展會新增更多執行個體？ 已觸發自動擴展，但新的執行個體運作狀態檢查失敗。

  3. 為什麼是 3：為什麼新的執行個體未通過運作狀態檢查？ 應用程式啟動程序需要 8 分鐘，比運作狀態檢查逾時長。

  4. 為什麼 4：為什麼啟動需要這麼長的時間？ 每次啟動時，應用程式都會從 S3 下載大型組態檔案。

  5. 為什麼是 5：為什麼自動擴展組態中未考慮此啟動延遲？ 效能測試是使用預先暖機的執行個體完成，而不是冷啟動。

根本原因：效能測試方法無法反映生產自動擴展案例

建議的動作：包含冷啟動測試、最佳化應用程式啟動、調整運作狀態檢查逾時、實作組態快取

分行分析的複雜事件

初始事件：OpenSearch Serverless 客戶在 11 小時內發生 48.3% 的可用性降低

主要分析鏈：

  1. 為什麼 1：為什麼客戶遇到服務降級？ 由於不正確的 ingester 擴展，服務可用性下降至 48.3%。

  2. 為什麼是 2：為什麼 ingester 擴展不正確？ CortexOperator 將 ingester 從 223 減少至 174。

  3. 為什麼 3：CortexOperator 為什麼錯誤計算 AZ 平衡？ 升級 1.17 版之後，程式碼無法處理新的 Kubernetes 標籤格式。

  4. 為什麼 4 （分支 A - 技術）：為什麼程式碼不處理新的標籤格式？ 程式碼預期的 'failure-domain.beta.kubernetes.io/zone' 標籤，但 Kubernetes 1.17 已變更為 'topology.kubernetes.io/zone'。

  5. 為什麼 5 （分支 A)：為什麼未實作回溯相容性？ 標籤格式變更並未記錄在部署規劃期間檢閱的升級備註中。

分支 B - 程序分析：

  1. 為什麼 4 （分支 B - 程序）：為什麼這未在測試中產生？ 整合測試使用預先設定的叢集搭配舊標籤格式。

  2. 為什麼 5 （分支 B)：為什麼沒有測試包含標籤格式驗證？ 測試環境設定未反映生產 Kubernetes 版本升級序列。

已識別的根本原因：

  • 技術：缺少 Kubernetes 標籤格式變更的回溯相容性

  • 程序：測試方法不會驗證版本升級的影響

整合的修補計畫：實作標籤格式偵測邏輯、增強升級測試程序、新增自動化相容性驗證，以及建立版本變更影響評估程序。

使用引導式 5 個為什麼工作流程

CloudWatch 調查提供引導式 5 個為什麼分析工作流程，協助您解決遺漏的事實並強化您的事件報告。當系統識別增強根本原因分析的機會時，此功能會顯示為建議的工作流程。

互動式分析體驗

CloudWatch 調查中的 5 個為什麼分析使用互動式、以聊天為基礎的方法來引導您完成調查程序。此對話式方法有助於確保全面分析，同時維持問題之間的邏輯流程。

互動式體驗的主要功能：

  • 以事實為基礎的初始化 - 系統會預先呈現調查的相關事實，使用它們預先填入明顯的答案，並清楚指出以事實為基礎的建議與以推論為基礎的建議

  • 引導式探查 - 對於每個「為什麼」問題，系統會根據可用的事實建議答案、請求特定的額外內容，並引導您在繼續之前考慮重要層面

  • 分支管理 - 識別多個促成因素時，系統會清楚呈現分支選項、說明分支之間的關係，並協助排定平行調查的優先順序

  • 漸進式驗證 - 針對每個回應，系統會重新格式化答案以釐清、尋求確認、反白顯示關鍵洞見，並將調查結果連結至更廣泛的內容

此方法可確保您擷取所有相關資訊，同時保持專注於最關鍵的因果關係。

存取引導式工作流程：

  1. 在事件報告產生期間，檢閱右側面板中的事實需要注意區段。

  2. 在建議的工作流程下尋找引導式 5-Whys分析建議。

  3. 選擇引導我開始互動式 5 個為什麼程序。

  4. 遵循引導式提示，系統性地處理每個「為什麼」問題，從症狀到根本原因建立完整的因果鏈。

引導式工作流程透過引導您完成 5 個為什麼方法的每個步驟，協助確保您擷取完整的根本原因資訊。分析結果會自動納入您的事件報告中，提供事件後檢閱和組織學習的結構化文件。

您也可以透過聊天界面請求 5 個為什麼分析，方法是提出問題，例如「為此事件執行 5 個為什麼分析」或「使用 5 個為什麼方法的根本原因是什麼？」

處理具有多個原因的複雜事件

有些事件涉及需要平行分析路徑的多個促成因素。CloudWatch 調查支援分支分析，以確保識別和解決所有重要原因。

需要分支分析時：

  • 同時發生多個獨立故障

  • 不同的系統元件對相同的客戶影響有所貢獻

  • 技術和程序失敗都扮演重要角色

  • 串聯失敗會建立多個因果鏈

分支分析程序：

  1. 分支識別 - 系統識別多個導致收斂或分歧的點

  2. 平行調查 - 使用完整的 5 個為什麼方法分析每個分支

  3. 連線映射 - 分支之間的關係會記錄在案，以顯示它們的互動方式

  4. 整合解決方案 - 修復計劃解決所有已識別的根本原因及其互動

此全方位方法可確保複雜事件獲得徹底的分析，並在最終補救計畫中解決所有促成因素。

有效 5 個為什麼分析的最佳實務

若要最大限度地提高事件報告中 5 個為什麼分析的有效性，請遵循這些衍生自營運體驗的最佳實務：

問題公式準則

  • 從客戶影響開始 - 以面向客戶的問題開始每個分析，以保持專注於業務影響

  • 逐步提高技術深度 - 隨著問題進行，從業務影響轉移到技術詳細資訊

  • 維持邏輯持續性 - 確保每個答案自然地導致下一個問題，而不會有邏輯差距

  • 包含支援證據 - 參考特定指標、日誌或時間軸事件以驗證每個答案

分析驗證

使用以下條件驗證您的 5 個為什麼分析：

  • 邏輯流程 - 清除從症狀到根本原因的進展，沒有遺漏的步驟

  • 技術準確性 - 正確的術語、準確的系統行為描述和有效的元件互動

  • 完整性 - 此分析說明所有觀察到的症狀，並達到基本原因，如果解決此問題，將防止再次發生

  • 可操作性 - 識別的根本原因會導致特定、可實作的修補動作

要避免的常見陷阱

  • 在症狀時停止 - 不要在第一次技術故障時結束分析；繼續，直到您達到系統性或程序原因為止

  • 以責任為重心的分析 - 專注於系統和程序失敗，而不是個別動作

  • 單路徑思考 - 考慮多個促成因素，並在適當時使用分支分析

  • 證據不足 - 確保調查中的具體資料支援每個答案

與事件報告區段整合

5 個為什麼分析會與您的事件報告的其他區段整合，以提供完整的文件：

  • 時間軸相互關聯 - 每個「為什麼」問題都可以參考特定的時間軸事件，為因果關係提供時間內容

  • 指標驗證 - 顯示所述技術行為的指標和圖形支援答案

  • 影響評估一致性 - 第一個「為什麼」直接連接到影響評估區段中記錄的客戶影響指標

  • 經驗教訓基礎 - 透過 5 個為什麼分析找出的根本原因會直接通知經驗教訓和修正動作章節

此整合可確保事件報告的一致性，並為利益相關者提供從初始症狀到根本原因到修復計劃的完整一致敘述。