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

# 產生事件報告
<a name="Investigations-Incident-Reports"></a>

事件報告可協助您更快速且輕鬆地撰寫有關事件調查的報告。您可以使用此報告向管理層提供詳細資訊，或協助您的團隊從事件中學習，並採取動作來防止未來發生這種情況。報告的結構是以這些報告類型的產業標準為基礎，並且可以複製到其他儲存庫以進行長期保留。

當您使用 AWS 管理主控台 在 CloudWatch 調查中建立*調查群組*資源時，會為群組建立 IAM 角色，以在調查期間授予資源存取權。產生 CloudWatch 調查事件報告需要將額外的許可授予您的調查群組。新的 受管政策`AIOpsAssistantIncidentReportPolicy`提供必要的許可，並自動新增至 2025 年 10 月 10 日 AWS 管理主控台 之後使用 建立的調查群組。如需詳細資訊，請參閱[AIOpsAssistantIncidentReportPolicy](managed-policies-cloudwatch.md#managed-policies-QInvestigations-AIOpsAssistantIncidentReportPolicy)。

**注意**  
如果您使用的是 CDK 或 SDK，則必須明確新增調查群組角色，並指定角色政策或該角色的同等內嵌許可。如需許可的詳細資訊，請參閱 [CloudWatch 調查功能的安全性](Investigations-Security.md) 

這些報告會以結構化格式擷取調查結果、根本原因、時間軸事件和建議的修正動作，可輕鬆與利益相關者共用並用於組織學習。

所有 CloudWatch 調查使用者都會免費加入事件報告產生，並與您的調查工作流程無縫整合。

**事件報告的運作方式**

1. 對您的事件執行調查。

1. 接受至少一個假設。報告會考慮您接受的每個假設。假設不需要 100% 準確。

1. 選擇**事件報告**。在調查期間，AI 會剖析為調查收集的資料和衍生的事實。事實是關於您事件的原子資訊片段，構成產生報告的基礎。事實擷取可能需要幾分鐘的時間。

1. 當事實擷取完成時，您可以檢閱下列領域中可用的事實：

   1. **事件概觀** – 事件的高階概觀，包括其嚴重性、持續時間和操作假設。

   1. **影響評估** – 與事件對客戶、服務職能和業務營運的影響相關的指標和分析。

   1. **偵測與回應** – 與如何及何時偵測到事件以及您如何回應事件相關的指標和分析。

   1. **根本原因分析** – 根據調查假設詳細分析基礎原因。

   1. **緩解和解決** – 與緩解步驟和解決措施相關的指標和分析，以及事件緩解和解決的時間測量。

   1. **學習和後續步驟** – 團隊要考慮的建議動作清單，會自動從調查結果產生。這些建議可能包括針對類似事件的預防措施，以及監控和回應程序的建議改進。

1. 檢閱事實後，選擇**產生報告**以建立事件的完整分析。雖然選取的事實做為關鍵參考點，但報告會從調查期間收集的所有可用資訊中提取。此程序需要幾分鐘的時間。

1. 產生報告之後，您就可以：
   + 依原樣使用報告：
     + 視需要將其複製以在外部編輯器中編輯
     + 儲存它以供日後參考
   + 透過新增更多資料來增強報告：
     + 選擇**新增事實** （建議的方法） 以輸入其他文字型內容，例如事件票證或自訂敘述。AI 會分析此內容，以增強現有的事實或推斷新的事實。
     + 直接編輯事實 （謹慎使用） - 手動編輯的事實可能會與調查時間表產生不一致。只有在**新增事實**未達到所需的結果時，這才應該用作最後手段。
   + 選擇**重新產生報告**，以使用更新的資訊產生新的報告。

**Topics**
+ [了解事件報告中 AI 衍生的事實](Investigations-IncidentReports-ai-facts.md)
+ [事件報告術語](Investigations-IncidentReports-terms.md)
+ [從調查產生報告](Investigations-IncidentReports-Generate.md)
+ [在事件報告中使用 5 個為什麼分析](incident-report-5whys.md)

# 了解事件報告中 AI 衍生的事實
<a name="Investigations-IncidentReports-ai-facts"></a>

AI 衍生的事實構成 CloudWatch 調查事件報告的基礎，代表 AI 系統根據 AWS 環境的全面分析而認為客觀或高度可能的資訊。這些事實會透過複雜的程序出現，將機器學習模式辨識與系統化驗證方法結合，為事件分析建立健全的架構，以維護生產環境所需的操作嚴格性。

了解 AI 衍生事實的開發方式，可協助您評估其可靠性，並在事件回應期間做出明智的決策。此程序代表一種混合方法，其中人工智慧增強了人類的專業知識，而不是取代它，確保產生的洞察是全面且值得信任的。

## AI 衍生事實的開發程序
<a name="Investigations-ai-facts-development"></a>

從原始遙測資料到可操作 AI 衍生事實的旅程從模式觀察開始，CloudWatch 調查 AI 會使用複雜的機器學習演算法分析大量 AWS 遙測。AI 會同時檢查多個維度的 CloudWatch 指標、日誌和追蹤，識別人類運算子可能不會立即顯現的重複模式和關係。此分析包含時間模式，可顯示事件發生的時間及其持續時間特性、顯示故障案例期間不同 AWS 服務互動方式的服務關聯、事件之前或隨附的指標異常，以及指出特定故障模式的日誌事件序列。

例如，考慮 AI 如何在您的環境中觀察到，Amazon EC2 執行個體 CPU 使用率在應用程式回應時間超過可接受的閾值前約 15 分鐘持續遽增至超過 90%。當在多個事件中觀察到時，這種時間關係會成為值得進一步調查的重要模式。AI 不僅會記下相互關聯性，還會測量關係的統計意義，並考慮可能影響模式的各種干擾因素。

根據這些觀察到的模式，AI 會進入假設產生階段，並針對其探索到的關係制定潛在解釋。此程序涉及建立多個競爭假設，並根據支援證據的強度，依機率進行排名。當 AI 在回應時間降級之前觀察到 CPU 峰值時，可能會產生幾個假設：由於運算容量不足而導致資源耗盡、記憶體流失導致 CPU 額外負荷增加，或由特定輸入模式觸發的效率低落演算法。每個假設都會根據其解釋觀察資料的程度來接收初步的可信度層級，並與已知 AWS 的服務行為保持一致。

這些假設的人工驗證和驗證可確保這些 AI 產生的洞察符合操作標準，然後再成為事件報告中的事實。此程序涉及將 AI 衍生的模式與已建立 AWS 的服務行為模型相互關聯、檢查事件回應與產業最佳實務的一致性，以及針對類似環境的歷史事件資料進行驗證。AI 必須證明其調查結果在不同分析方法和時段之間可重現、符合營運決策的統計顯著性要求、符合 AWS 服務行為的實證觀察，並提供可行的洞見，以解決或預防事件。

在整個過程中，AI 面臨了在解譯 AI 衍生事實時應了解的幾個固有挑戰。相互關聯和因果關係之間的差異仍然是基本的挑戰；雖然 AI 可能會識別網路流量激增和事件發生之間的高度相互關聯，但建立直接因果關係需要額外的調查和領域專業知識。存在於 AWS 遙測範圍之外的隱藏變數，例如第三方服務相依性或外部網路提供者問題，可能會影響事件，而不會在 AI 分析中被擷取。AI 衍生事實的品質完全取決於基礎 CloudWatch 資料的完整性和準確性，因此全面監控涵蓋範圍對於可靠的洞見至關重要。

新事件模式帶來另一個挑戰，因為 AI 訓練資料中不存在這些挑戰，AIs 通常難以解譯不熟悉的失敗模式。此限制強調了人類專業知識在解釋 AI 衍生事實時的重要性，並補充了領域知識和內容理解。

## 在事件回應中套用 AI 衍生的事實
<a name="Investigations-ai-facts-practical-application"></a>

AI 擅長識別大型資料集之間不切實際的模式，以便人類手動分析，提供可大幅加速事件診斷和解決的洞見。AI 與人類專業知識結合，可提供內容、驗證結論，以及識別可能無法在遙測資料中擷取的因素時，效果最佳。

最有效的方法包括將 AI 衍生的事實視為高度明智的調查起點，而不是明確的結論。當 AI 識別諸如「資料庫連線集區耗盡事件前 8 分鐘」之類的事實時，這提供了寶貴的潛在客戶，可以透過資料庫指標和應用程式日誌的目標分析快速進行驗證。事實為您提供了特定的調查時間範圍和潛在的根本原因，相較於手動搜尋所有可用的遙測，可大幅減少識別問題所需的時間。

資料品質在 AI 衍生事實的可靠性中扮演重要角色。全面的 CloudWatch 監控涵蓋範圍提供 AI 存取，以便分析完整且準確的資訊。監控中的差距可能會導致不完整或誤導的事實，因為 AI 只能使用可用的資料。使用包括詳細指標收集、全方位記錄和分散式追蹤的全面可觀測性實務的組織，更有可能在其事件報告中擁有準確且可行的 AI 衍生事實。

# 事件報告術語
<a name="Investigations-IncidentReports-terms"></a>

CloudWatch 調查事件報告中會使用下列詞彙：

AI 衍生的事實  
根據 AWS 服務中的可用資料、遙測、日誌和歷史模式，AI 系統視為客觀或高度可能的資訊或觀察片段。這些事實衍生自演算法分析和機器學習模型，雖然系統將其視為可靠，但它們應該進行人工驗證，尤其是在關鍵決策環境中。AI 衍生的事實可能包括事件、異常偵測或系統行為推論之間的關聯，人類運算子可能不會立即發現這些關聯。

更正動作  
CloudWatch 調查建議的特定可行步驟，以根據 AWS 最佳實務和受影響資源的特定內容，解決事件的根本原因並防止其再次發生。

Fact 類別  
事件相關資訊的結構化分組，例如影響指標、偵測詳細資訊和緩解步驟，用於組織產生報告的資料。

影響評估  
從 CloudWatch 指標和其他新增至調查 AWS 的服務資料衍生，對事件對系統效能、使用者體驗和業務操作的影響進行量化和定性評估。

事件報告產生  
根據 CloudWatch 調查調查期間收集的資料，建立營運事件完整文件的自動化程序，包括其時間表、影響、根本原因和解決步驟。

調查摘要  
CloudWatch 調查調查中接受的觀察、假設和使用者新增備註的時間顯示，做為調查進度和調查結果的主要記錄。

經驗教訓  
透過事件調查程序自動產生洞見和改進機會，旨在增強整個組織的系統可靠性、營運效率和事件回應功能。

報告評估  
自動評估產生的事件報告，識別潛在的資料差距或需要額外資訊的區域，以改善報告完整性和品質。

根本原因分析  
一種系統化程序，用於識別操作問題的基本原因，利用 CloudWatch 調查 AI 驅動的假設和跨多個 AWS 服務的相互關聯。

建議索引標籤  
CloudWatch 調查中的一項功能，會根據系統遙測分析和日誌，呈現 AI 產生的觀察和有關潛在原因或相關問題的假設。

時間軸事件  
事件期間重大事件的時間順序，會自動從 CloudWatch 日誌、指標和其他 AWS 服務資料擷取，以提供事件進展的清晰概觀。

# 從調查產生報告
<a name="Investigations-IncidentReports-Generate"></a>

您可以從進行中或已完成的調查產生事件報告。調查初期產生的事件報告可能不會包含關鍵事實，例如根本原因和建議的動作。調查處於作用中狀態時，您可以編輯可用的事實，以額外資訊補充調查。調查結束後，您無法編輯或新增事實至調查。

**先決條件**

在產生事件之前，請確認符合下列要求：
+ 確保調查群組使用所需的 KMS 金鑰，並將適當的 IAM 政策連接到其角色，以從 AWS 服務解密資料。如果您的 AWS 資源使用客戶管理的 KMS 金鑰加密，您必須將 IAM 政策陳述式新增至調查群組角色，以授予 CloudWatch Investigations 解密和存取此資料所需的許可。
+ 調查群組角色已獲得下列許可：
  + `aiops:GetInvestigation`
  + `aiops:ListInvestigationEvents`
  + `aiops:GetInvestigationEvent`
  + `aiops:PutFact`
  + `aiops:UpdateReport`
  + `aiops:CreateReport`
  + `aiops:GetReport`
  + `aiops:ListFacts`
  + `aiops:GetFact`
  + `aiops:GetFactVersions`
**注意**  
您可以將這些許可新增為調查群組角色的內嵌政策，或將其他許可政策附加至調查群組角色。如需詳細資訊，請參閱 [產生事件報告的權限](Investigations-Security.md#Investigations-Security-IAM-IRG)。  
新的 受管政策`AIOpsAssistantIncidentReportPolicy`提供必要的許可，並自動新增至 2025 年 10 月 10 日之後建立的調查群組。如需詳細資訊，請參閱[AIOpsAssistantIncidentReportPolicy](managed-policies-cloudwatch.md#managed-policies-QInvestigations-AIOpsAssistantIncidentReportPolicy)。

**產生事件報告**

1. 透過 [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/) 開啟 CloudWatch 主控台。

1. 在左側導覽窗格中，選擇 **AI 操作**、**調查**。

1. 選擇調查的名稱。

1. 在調查頁面的**摘要**下，接受任何其他相關假設，並在調查中新增任何其他備註。
**注意**  
產生報告需要調查至少有一個已接受的假設。

1. 在調查頁面頂端，選擇**事件報告**。等待調查的相關事實收集並同步。

1. 在**事件報告**頁面上，檢閱用於產生報告的事實。事實可在右側窗格中取得。使用左右箭頭瀏覽事實類別索引標籤，或展開窗格以查看所有類別。

   1. 在事實面板上選擇**編輯**，以手動新增或編輯該類別中的資料。

   1. 選擇在事實面板上**檢視詳細資訊**，以查看 AI 助理收集的支援證據和事實歷史記錄。您也可以在事實詳細資訊視窗中選擇**編輯**。

   1. 如果您想要提供調查的其他內容，例如外部事件或情有可原的情況，請選擇**新增事實**。

1. 選擇**產生報告**。

   CloudWatch 調查將分析調查資料並產生結構化報告。此程序可能需要一些時間。

1. 在預覽窗格中檢閱產生的報告。報告將包含：
   + 自動擷取時間軸事件
   + 根據已接受的假設進行根本原因分析
   + 從調查遙測衍生的影響評估
   + 遵循 AWS 最佳實務的建議修正動作和經驗教訓

1. 若要將報告的副本保留在不同的位置，您可以選擇複製報告的文字並將其貼到您想要的位置。

1. 選擇**報告評估**以檢閱報告中的資料差距清單。您可以使用此資訊來收集報告的其他資料，然後相應地更新事實並重新產生報告。

# 在事件報告中使用 5 個為什麼分析
<a name="incident-report-5whys"></a>

產生事件報告時，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](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AIOpsConsoleAdminPolicy.html) 或 [AIOpsOperatorAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AIOpsOperatorAccess.html) 受管政策連接至使用者或角色。

## 什麼是 5 個為什麼分析？
<a name="5whys-overview"></a>

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

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

## 事件報告的好處
<a name="why-5whys-incidents"></a>

在事件報告中包含 5 個為什麼分析提供了幾個優點：
+ **全面的根本原因識別** - 超越立即的技術原因，以識別基礎程序或系統問題
+ **可行的修補計畫** - 提供特定、有針對性的動作，以防止重複執行，而非暫時修正
+ **組織學習** - 記錄完整的因果關係，以供未來參考和團隊知識分享
+ **結構化分析** - 確保系統化調查，而不是臨時問題解決

## 事件報告中的範例案例
<a name="5whys-incident-examples"></a>

### 資料庫連線失敗事件
<a name="example-database-outage"></a>

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

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

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

1. **為什麼是 3：**為什麼資料庫沒有連線？ 批次處理任務開啟了許多連線，但未正確關閉它們。

1. **為什麼是 4：**批次任務為何未正確關閉連線？ 任務的錯誤處理不包含失敗案例中的連線清除。

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

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

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

### 效能降級事件
<a name="example-auto-scaling"></a>

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

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

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

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

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

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

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

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

### 分行分析的複雜事件
<a name="example-complex-branch"></a>

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

**主要分析鏈：**

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

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

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

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

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

**分支 B - 程序分析：**

1. **為什麼是 4 （分支 B - 程序）：**為什麼沒有在測試中發現？ 整合測試使用預先設定的叢集搭配舊標籤格式。

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

**已識別的根本原因：**
+ 技術：缺少 Kubernetes 標籤格式變更的回溯相容性
+ 程序：測試方法不會驗證版本升級的影響

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

## 使用引導式 5 個為什麼工作流程
<a name="accessing-5whys"></a>

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

### 互動式分析體驗
<a name="interactive-analysis"></a>

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

**互動體驗的主要功能：**
+ **以事實為基礎的初始化** - 系統會預先呈現調查的相關事實，使用它們預先填入明顯的答案，並清楚指出以事實為基礎與以推論為基礎的建議
+ **引導式探查** - 對於每個「為什麼」問題，系統會根據可用的事實建議答案、請求特定的額外內容，並引導您在繼續之前考慮重要層面
+ **分支管理** - 識別多個促成因素時，系統會清楚呈現分支選項、說明分支之間的關係，並協助排定平行調查的優先順序
+ **漸進式驗證** - 針對每個回應，系統會重新格式化答案以釐清、尋求確認、反白顯示關鍵洞見，並將調查結果連結至更廣泛的內容

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

**存取引導式工作流程：**

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

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

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

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

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

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

## 處理具有多個原因的複雜事件
<a name="branch-analysis"></a>

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

**需要分支分析時：**
+ 同時發生多個獨立故障
+ 不同的系統元件對相同的客戶影響有所貢獻
+ 技術和程序失敗都扮演重要角色
+ 串聯失敗會建立多個因果鏈

**分支分析程序：**

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

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

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

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

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

## 有效 5 個為什麼分析的最佳實務
<a name="5whys-best-practices"></a>

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

### 問題公式準則
<a name="question-formulation"></a>
+ **從客戶影響**開始 - 以面向客戶的問題開始每個分析，以保持專注於業務影響
+ **逐步提高技術深度** - 隨著問題進行，從業務影響轉移到技術詳細資訊
+ **維持邏輯持續性** - 確保每個答案自然地導致下一個問題，沒有邏輯差距
+ **包含支援證據** - 參考特定指標、日誌或時間軸事件以驗證每個答案

### 分析驗證
<a name="validation-criteria"></a>

使用以下條件驗證您的 5 個為什麼分析：
+ **邏輯流程** - 清除從症狀到根本原因的進展，沒有遺漏的步驟
+ **技術準確性** - 正確的術語、準確的系統行為描述和有效的元件互動
+ **完整性** - 此分析說明所有觀察到的症狀，並達到基本原因，如果解決此問題，將防止再次發生
+ 可**操作性** - 識別的根本原因會導致特定、可實作的修補動作

### 要避免的常見陷阱
<a name="common-pitfalls"></a>
+ **停止症狀** - 請勿在第一次技術故障時結束分析；繼續，直到您達到系統性或程序原因為止
+ **以責任為重心的分析** - 專注於系統和程序失敗，而不是個別動作
+ **單路徑思考** - 考慮多個促成因素，並在適當時使用分支分析
+ **證據不足** - 確保調查中的具體資料支援每個答案

### 與事件報告區段整合
<a name="5whys-integration"></a>

5 個為什麼分析會與您的事件報告的其他區段整合，以提供完整的文件：
+ **時間軸相互關聯** - 每個「為什麼」問題都可以參考特定的時間軸事件，為因果關係提供時間內容
+ **指標驗證** - 顯示所述技術行為的指標和圖形支援答案
+ **影響評估一致性** - 第一個「為什麼」直接連接到影響評估區段中記錄的客戶影響指標
+ **經驗教訓基礎** - 透過 5 個為什麼分析找出的根本原因會直接通知經驗教訓和修正動作區段

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