良好事件後檢閱的特性和元件

您現在知道事件後檢閱是什麼、其在事件回應程式中的角色，以及何時應該進行。 在本單元中，您將更深入地研究能讓事件後檢閱發揮最大效果的細節。

因為事件不同，事件後檢閱的確切構成也可能不同。 然而，一篇好的評論具有一些常見的特點和要素，可以為您提供進行此過程的堅實基礎。

哪些不是

在您能夠了解良好的事件後檢閱需具備哪些特性之前，您應該考慮哪些不是需具備的特性。

• 這不是檔或報表。 很容易將「檢閱」視為書面摘要，事實上，摘要報告通常會遵循事件后檢閱。 不過，這些是事件回應生命週期分析階段的兩個不同的不同部分。
• 這不是因果關係的決定。 您的檢閱將探討導致失敗的因素，但目的不是找出罪魁禍首（特別是不是單一根本原因;複雜系統幾乎一律會因為一組促成因素而失敗）。 這是要思考並分享事件所有層面的資訊，以便學習和改進。 這不是動作項目的清單。 根據您在檢閱中學到的結果，您可能最終會得到這樣的清單，但這並不是重點。 如果您收到的故障單佇列中沒有項目清單，或錯誤報告系統中沒有錯誤報告，但您比以前更了解自己的系統，這就代表檢閱成功。

事件檢閱更多的是一種交流。 這是一個特定的空間，讓您的小組可以檢驗他們當時和現在所了解的情況，探索並更深入地理解系統的各個部分，包括人為元件，如何協同或未能協同處理問題。

特性和元件

正如我們在上一個單元中所提到的，事件審查必須 無可指責。 雖然您需要檢查系統的人類部分如何與其互動，但您不會這樣做，以便將任何人標記為「發生錯誤」。重點應該是技術失敗和過程，而不是人們。

框出您的問題以反映此問題，例如：

• 我們的監控中缺乏什麼，導致無法為鍵盤上的人員提供做出正確決定所需的背景資訊？
• 為什麼工具中有 「終結整個資料庫」選項？
• 或者，更好的是：為什麼工具在執行此函式之前沒有要求確認？

當事情出錯時，責怪他人可能很誘人。 不過，您必須記住此重點：

您無法透過開除人員來達到可靠性。

羞辱和指責或以調查為目的，尋找並解僱「負責任的人」，不會創造更可靠的系統。 相反，這將導致一個缺乏經驗，甚至空蕩蕩的運營團隊和人員誰害怕採取行動。

將審查視為對知識和脈絡的探索，而不是尋找誰做了什麼並對此作出反應。

雖然審查涉及技術的失敗，但其本質上是一個以人為本的流程，而非技術過程。 與參與事件的人員交談，更重要的是傾聽。 保持開放心態。 不同的人有不同的觀點，而不是每個人都會同意，這種觀點的混合對學習過程是無價的。

事件後審查是一個誠實的調查。 因此，它採用這些重要元件：

• 討論
• 論述
• 異議
• 探索

這些“4 Ds”會建立一個架構，您可以在其中進行事件後檢討，以產生更可靠的系統和更具生產力且團結合作的團隊。

在下一個章節中，我們將進一步討論您可以遵循的流程，以建立有效的事件後檢討。