REL12-BP02 執行事件後分析 - 可靠性支柱

REL12-BP02 執行事件後分析

審查影響客戶的事件,並識別成因和預防性行動項目。使用此資訊來開發緩解措施,以限制或防止事件再次發生。制定可快速有效回應的程序。適當地傳達成因和為目標受眾量身打造的糾正措施。建立一種可以根據需要將這些原因傳達給其他人的方法。

評估現有測試找不到問題的原因。如果測試尚未存在,請為此案例新增測試。

預期成果:您的團隊擁有一致且商定的方法來處理事件後分析。其中一個機制是錯誤糾正 (COE) 程序。COE 程序可幫助您的團隊識別、了解和解決事件的根本原因,同時還能建置機制和防護機制,以限制相同事件再次發生的可能性。

常見的反模式:

  • 尋找成因,但未繼續深入尋找其他潛在問題和減輕方法。

  • 僅確定人為錯誤原因,不未嘗試可防止人為錯誤發生的任何培訓或或自動化。

  • 專注於追究責任,而不是了解根本原因,造成恐懼文化並阻礙開放的溝通

  • 無法分享見解,只讓一小群人知道事件分析調查結果,讓其他人無法從學到的教訓中受益

  • 沒有機制可擷取機構知識而失去寶貴的見解,因為組織不會以更新過的最佳實務形式保存所學到的教訓,並導致重複發生相同或類似根本原因的事件

建立此最佳實務的優勢:進行事件後分析並分享結果可讓其他實作了相同成因的工作負載減輕風險,並讓工作負載能夠在事件發生前實作減輕措施或自動復原。

未建立此最佳實務時的風險暴露等級:

實作指引

良好的事件後分析提供了機會,為系統中其他地方使用的架構模式問題提出通用解決方案。

COE 程序的基石是記錄和解決問題。建議您定義標準化方式來記錄關鍵的根本原因,並確保加以檢視和解決。為事件後分析程序指派明確的擁有權。指定負責監督事件調查和後續跟進的團隊或個人。

鼓勵專注於學習和改進的文化,而不是追究責任的文化。強調目標是預防未來的事件,而不是懲罰個人。

開發用於進行事件後分析的明確定義程序。這些程序應概述要採取的步驟、要收集的資訊,以及要在分析期間解決的關鍵問題。徹底調查事件,跳脫出直接原因以找出根本原因和成因。使用五個為什麼之類的技術深入了解基礎問題。

維護事件分析所學教訓的儲存庫。此機構知識可以作為未來事件和預防工作的參考。分享事件後分析的調查結果和見解,並考慮舉行公開邀請的事件後檢討會議,以討論學到的教訓。

實作步驟

  • 在進行事件後分析時,請確保事件後分析不會讓相關人員受到責備。這可讓事件中的相關人員平心靜氣看待建議的糾正措施,並促進誠實地自我評估與跨團隊合作。

  • 定義標準化方式來記錄重要問題。這類文件的範例結構如下:

    • 發生了什麼?

    • 對客戶和您的業務有什麼影響?

    • 根本原因是什麼?

    • 您擁有什麼可以提供支援的資料?

      • 例如,指標和圖表

    • 對關鍵支柱的影響有哪些 (尤其是安全性)?

      • 建立工作負載的架構時,您可依照業務環境,在各支柱之間作出權衡。這些業務決定可主導您工程設計的優先順序。您可以選擇在開發環境中以可靠性作為代價最佳化成本,或者針對關鍵任務解決方案,以較高成本達到可靠性的最佳化。安全始終是首要工作,因為您必須保護客戶。

    • 您獲得了什麼教訓?

    • 您正在採取什麼糾正措施?

      • 動作項目

      • 相關項目

  • 建立用於進行事件後分析的明確定義標準作業程序。

  • 設定標準化的事件報告程序。全面記錄所有事件,包括初始事件報告、日誌、通訊,以及事件期間採取的行動。

  • 請記住,發生事件時不見得會有中斷情形。事件也可能是幾乎錯過的情況,或是系統雖以意想不到的方式執行,卻仍可履行其業務功能。

  • 請根據意見回饋和學到的教訓,持續改善事件後分析程序。

  • 擷取知識管理系統中的關鍵調查結果,並考慮任何應新增至開發人員指南或部署前檢查清單的模式。

資源

相關文件:

相關影片: