對于任何 IT 團隊來說，事件解決后的那一刻可能是最放松的。當您的系統最終正常運行時，它會讓整個組織放心，但最艱巨的任務尚未到來：根本原因分析 (RCA)。類似于足球隊觀看以前的比賽以查明改進領域，根本原因分析通過數據并找出最初導致事件的原因。

分析問題的根本原因對組織來說是一項獨特的挑戰?？赡苡性S多因素使這個過程變得更加困難，從太多的警報到缺乏文檔。也許最有害的是沒有一個固定的程序。許多組織的事件計劃都缺少這一關鍵步驟。任何好的事件計劃都包括一個用于根本原因分析的過程，而不僅僅是一個要求。

請注意，在開始根本原因分析過程之前，在事件解決期間可以做一些事情。這些任務使根本原因分析更容易；例如分配和定義角色、建立最佳實踐以及利用可用工具。雖然，每個企業都會根據其功能和規模的不同而有不同的需求。通過明確定義每個角色的角色、功能和范圍來避免重大事件。以下是每個組織應具備的幾個關鍵角色：

組織中有效根本原因分析的關鍵角色

事件線索

事件負責人將充當隊長，因為每個事件應該只有一個事件負責人。擁有強大的指揮技能和事件管理經驗至關重要。他們還應該能夠理解問題的診斷和解決方法。他們的一般知識應該從系統監控和診斷工具擴展到應用程序和基礎設施組件，以及可用的工程工具。 他們會將資源引導到最需要的地方，并根據需要推動所有問題解決行動。由于這是有效負責的角色，他們將負責收集最終根本原因分析所需的數據。

服務主管

服務主管將幫助指導恢復工作，并根據他們對業務重要性的了解確定優先級。他們應該是經驗豐富的工程師或經理，了解受影響服務的系統方面和交付要求。他們還應該熟悉并能夠指導服務恢復例程和程序。 服務負責人會知道必須考慮和解決的潛在下游影響。 此外，他們必須知道必須與哪些業務部門和聯系人合作，以最大程度地減少事故處理期間的影響。

技術主管

技術主管是專家或主題專家。這通常是對生產環境有充分了解的高級高級工程師。他們的工作是在他們的組件領域（例如存儲、網絡、DBMS 等）診斷并領導解決問題的工作。整個組織的技術主管必須相互協調和溝通，以解決可能存在于組件區域之間或之外的問題。

根本原因分析的最佳實踐

現在已經定義了所有角色，重要的是概述團隊在事件解決過程中應遵循的一些最佳實踐，以使根本原因分析 (RCA) 更容易。

• 如果根本原因無法追溯，這是最常見的原因之一。如果您有多個團隊同時進行更改，則很難評估哪個團隊解決了問題。事件負責人必須仔細跟蹤團隊修復系統的內容、時間和順序。
• 在恢復過程中，首要也是唯一的優先事項應該是解決事件并記錄可能的根本原因。大多數根本原因分析 (RCA) 工作都是在服務恢復后很久才進行的，并且有了適當的文檔，它可以使過程變得更加容易。
• 系統文檔的一部分應該是配置信息。能夠查看是否有可能導致錯誤的更改非常重要。以及監視哪些更改解決了問題。這對于防止未來可能發生的事件很重要。解決問題的最快方法是恢復到上次已知的穩定配置。您可以使用配置管理工具來檢測計劃外的更改并評估更改的內容和時間。正向設計解決方案可能很誘人，但它不應該是您唯一的選擇，因為巨大的變化可能會導致無法預料的問題。
• 建立明確的指揮線并確保執行。業務方最好不要參與技術電話。技術數據可能是壓倒性的，并可能導致誤解。
• 在合理和可能的情況下并行工作。這應該包括產生并行活動以工作多個合理的解決方案或備份。但是，重要的是要記住在實際執行時“一次更改”的做法。

管理警報

警報過多會使根本原因分析變得更加困難。有一些方法可以減少可能掩蓋事件根本原因的警報噪音量。一般的經驗法則是確?；顒泳瘓髢H針對可操作的項目。

• 如果通知沒有使您立即采取行動，則不應向您發出警報。例如，關于 CPU 使用率或內存空間的警報。如果你一直忽視警報，很可能有一天一個重要的警報會從裂縫中溜走。更有幫助的是接收每日報告，為您提供一般系統指標，以便您知道如何處理以防止事件發生。
• 自動化報告使日常流程變得更容易，因此不會遺漏 任何事情，也不會因為不緊急的事情而引發警報。

利用操作系統

確保您以最佳方式使用您的工具是加快事件解決和根本原因分析的關鍵。

• 與通知管理器集成可以簡化待命安排，并提供一種不依賴于內部郵件基礎設施的警報分發方式。
• 如果您正在使用 ServiceNow 或 RemedyForce 等票務或 ITSM 系統，則應確保您的計劃包括將這些系統與您的監控和警報系統以及事件管理流程集成。

結論

根本原因分析對于更快地解決未來事件并防止它們再次發生非常重要。通過在您的解決計劃中實施上述內容，它將使組織更加高效和優化。通過其自動報告和集成平臺為您提供了輕松實現這一目標的關鍵。