Eric Siegler是PagerDuty公司DevOps的負責人，他在上個月于倫敦舉辦的Velocity大會上發表了一份報告，分析了來自125個不同組織在六個月的時間內的1000份事故分析（post-mortems）【譯注1】。他分析出的主要的趨勢包括：無可非議的事故分析的普遍性；僅有1/100的事故分析源于“人為錯誤”；以及對事件生命周期的分析可以提供對事件響應過程中相關弱點的深入見解。

由于信息是經由PagerDuty的事故分析構建器功能從客戶端處匿名收集(并保存)的，Sigler挖掘了這些數據，尋找常見的人名，結果發現一半的事故分析中都沒有出現人名。Sigler強調說，另外的一半數據中出現了人名也并不一定意味著存在一種指責文化，因為數據可能會以其他方式被曲解；例如，事故分析報告中提及了一個名為“Bob”的服務器（這種情況下，“Bob”也會被識別成人名，但其實是服務器的名字）。

至于明確提到的“人為的錯誤”，它作為事故被審查的一種可能的原因，經由Sigler調查，他發現幾乎沒有證據可以證明事故分析的原因源于“人為錯誤”（只有1%的事故分析與“人為錯誤”有關）。Sigler以去年3月的AWS S3的故障為例強調了這一點，該事件的事故分析并沒有聲明人為錯誤是導致故障的一個原因，但媒體的報道卻泛泛地將其原因歸咎于個人。

收集到的數據還表明，許多組織花費了大量的精力來詳細說明事件的時間線（并且很多事故分析都不包含任何關于其他方面的文本信息）。Sigler警告說，盡管了解被審查的事故是一項有用的練習，但跟蹤常見事件的狀態轉換（啟動、自檢、改進、解決）可以得到更好的見解以改善整個響應過程。例如，在啟動狀態和自檢狀態之間的不斷重復就對我們的監測和儀器的正確性提出了疑問。在啟動狀態和自檢狀態之間的不斷重復可能表明在組織中的知識共享和職責分配方面存在瓶頸，或者僅僅是因為積累了太多的技術債務導致了系統的失敗。

Sigler的另一發現是，大多數的組織平均每月進行事故分析的次數不足一次。有三分之一的組織會在事故后的24小時內進行事故分析，還有三分之一的組織會在事故后的一星期內進行事故分析，剩下的那部分在一周后才會進行分析（這樣通常很難能克服選擇性遺忘）。

Sigler還強調說，這只是一個小型的數據集，所以分析出結果可能會偏向于一些已經具有完備事故分析過程的組織，因次它們的運營看起來似乎更為成熟。

最后，Sigler給觀眾提供了許多建議。首先，事故分析對于檢查過程改進是否有助于消除系統中的錯誤很有幫助，另外，如果我們反復遇到相同的問題，事故分析也能起到很好的作用。其次，事故分析可以發現組織問題，因此，對事故分析結果的應用不能僅僅局限于技術改進。

想要了解更多關于建立事故分析過程的信息，請參考PagerDuty關于事故分析過程以及事故分析模板

譯注1：post-mortems，事故分析，又稱事故復盤。當任何生產系統發生嚴重停機或類似事故時，所涉及的人員都必須寫一份事故分析文檔。文檔描述事故，包括標題、摘要、影響、時間表、根本原因、什么工作/什么沒有和行動項目。文檔的重點是問題本身，以及如何在未來避免他們，而不是針對人或分攤責任。

查看英文原文：Post-Mortems Trends and Behaviors