良好事件後檢閱的特性和元件
- 4 分鐘
您現在知道事件後檢閱是什麼、其在事件回應程式中的角色，以及何時應該進行。 在本單元中，您將更深入了解哪些細節能使事後檢討發揮最大效益。
因為事件不同，事件後檢閱的確切構成也可能不同。 然而，一篇好的評論具有一些常見的特點和要素，可以為您提供進行此過程的堅實基礎。
哪些不是
在您能夠了解良好的事件後檢閱需具備哪些特性之前，您應該考慮哪些不是需具備的特性。
- 這不是檔或報表。 很容易將「檢閱」視為書面摘要，事實上，摘要報告通常會遵循事件后檢閱。 不過，這些是事件回應生命週期分析階段的兩個不同的不同部分。
- 這不是因果關係的決定。 您的檢閱將探討導致失敗的因素，但目的不是找出罪魁禍首（特別是不是單一根本原因;複雜系統幾乎一律會因為一組促成因素而失敗）。 而是思考並分享事件各方面的資訊，以便學習與改進。
- 這不是動作項目的清單。 根據您在檢閱中學到的結果，您可能最終會得到這樣的清單，但這並不是重點。 如果您收到的故障單佇列中沒有項目清單，或錯誤報告系統中沒有錯誤報告，但您比以前更了解自己的系統，這就代表檢閱成功。
事件審查，最重要的，就是 一場對話。 這是一個明確的空間，讓你的團隊回顧當時所知道與現在所知，並探索並更深入了解系統各部分，包括人類部分，如何在問題中協同運作或不合作。
特性和元件
無可指責
正如我們在上一單元提到的，事件審查必須 是無辜的。無責 並不代表「沒有人要負責」或「我們假裝錯誤沒發生」。這表示你刻意將 理解 事件的工作與 歸咎 的工作分開。 在無可指責的審查中，你會假設所有參與者都是出於善意，並盡力利用當時可用的資訊、工具和背景盡力而為。 目標是揭示 人們當 下為何所採取的行動對他們來說合理，讓你了解系統，包括其人類部分，實際上是如何運作的。
雖然你需要檢視系統中人類部分如何與它互動，但你做這件事並不是為了給任何人貼上「過錯」標籤。焦點應該放在技術和流程的失敗，而非人。
框出您的問題以反映此問題，例如：
- 我們的監控中缺乏什麼，導致無法為鍵盤上的人員提供做出正確決定所需的背景資訊？
- 為什麼工具中有 「終結整個資料庫」選項？
- 或者，更好的是：為什麼工具在執行此函式之前沒有要求確認？
當事情出錯時，責怪他人可能很誘人。 不過，您必須記住此重點：
您無法透過開除人員來達到可靠性。
羞辱和指責或以調查為目的，尋找並解僱「負責任的人」，不會創造更可靠的系統。 反而導致缺乏經驗甚至空虛的作戰團隊和人員，害怕行動。
將審查視為對知識和脈絡的探索，而不是尋找誰做了什麼並對此作出反應。
雖然審查是針對技術失敗，但這不是一個技術過程，更像是一個人員的過程。 與事件相關的人對話（更重要的是傾聽）。 保持開放心態。 不同的人有不同的觀點，並非每個人都同意，這種多元的觀點對學習過程非常寶貴。
事件後審查是一個誠實的調查。 因此，它採用這些重要元件：
- 討論
- 論述
- 異議
- 探索
這個「4D」是一種幫助記憶的實用方法，提供事後檢討應具備的心態。 4D 為您建立起可供檢討用的框架，幫助您打造更可靠的系統，以及更具生產力的合作團隊。
在下一個章節中，我們將進一步討論您可以遵循的流程，以建立有效的事件後檢討。