事后分析至少要包含這些內(nèi)容:

1.事故描述。
 
2.根本原因描述。

3.事件是如何穩(wěn)定或修復(fù)的。

4.用于解決事故的行動的時間表。

5.事故是如何影響客戶的。
 
6.糾正或改正動作。

前5項讓有關(guān)各方對事實有共同的了解。很多事故重復(fù)發(fā)生，就是因為人們不理解到底發(fā)生了什么，以及問題是如何修復(fù)的。不同團隊以及不同層級的管理者聚集在一起進行事后分析時，對到底發(fā)生了什么的理解是不同的。事后分析時，與事故明顯有關(guān)的人員都要同時到場，對事故的真實情況作出共同的描述。對真實情況沒有確實的描述，就無法明確及正確地采取行動，而這應(yīng)該是事后分析的最大用處。



確定根本原因應(yīng)該是做，而不是說。但我卻無法告訴你，有多少次這樣的事后分析會，與會者花了大量的時間爭論每一個可能的糾正項或者有多少客戶受影響，只是覺得他們在浪費時間，因為根本就沒搞清真正的根本原因。

對于穩(wěn)定步驟也是如此。往往在一次重大事故故的混亂中，有多個人會試圖進行多次修復(fù)。要確定真正的根本原因以及采取的步驟，在繼續(xù)之前要使系統(tǒng)穩(wěn)定下來。注意，事件也有可能不需要修復(fù)就可以穩(wěn)定下來。像重啟服務(wù)器以解決內(nèi)存泄漏這樣的事件，不需要修復(fù)的，但要消除對客戶造成的影響。盡管可以穩(wěn)定一段時間，但如果沒有找到真正的根本原因的話，服務(wù)器很快就會又發(fā)生內(nèi)存不夠的問題了。

確定事故多久能夠修復(fù)的時間表是很重要的。同樣，每個人對時間表的理解也各不相同。在動手修復(fù)之前，讓每個人都列出自己所了解的修復(fù)項，會減少修復(fù)時間(Time to resolve-ttr)。要確保回答下面的問題:

● 事故什么時候開始影響客戶的?(注:并非所有事故都對客戶有影響)
 
● 公司中什么時候有人開始意識到發(fā)生問題了?

● 此人是如何意識到發(fā)生問題的?通過監(jiān)控?客服團隊?還是個人報告？

● 有關(guān)事故的情況到達最終解決問題的人，要花多長時間?

● 什么使得人們能夠?qū)﹀e誤進行早期診斷?(例如，更好的監(jiān)控，能夠被充分理解的排錯指南，等等)
 
● 穩(wěn)定步驟要花很長時間嗎?能否將穩(wěn)定步驟自動化，或者簡化穩(wěn)定步驟以加快速度?減少事故的TTR時間，就跟消除事故本身一樣重要。最終，重要的是影響客戶的總時間(TTRX受影響的客戶數(shù))。有些宕機是無法避免的，但假如能夠保證快速恢復(fù)，則受益的還是客戶。

在確定了客戶所受影響之后，你可能需要對事件賦予一個嚴(yán)重級別?？梢越⒆约旱膰?yán)重程度的類別，或者使用這個例子:

嚴(yán)重級別1:網(wǎng)站宕機影響大批客戶方。

嚴(yán)重級別2:網(wǎng)站降級運行、性能問題或很難應(yīng)對的功能故障。

嚴(yán)重級別3:對客戶影響不大或易于應(yīng)對的其他服務(wù)問題。

對網(wǎng)站建設(shè)維護問題賦予嚴(yán)重級別，將幫助你按照輕重緩急來處理糾正項，而且對于活躍事件的評估也是有用的。在試圖解決問題之前，可能已經(jīng)對其賦予了一個嚴(yán)重級別，所以，就能夠確定，當(dāng)前事件是一個5級火警，從而需要全力以赴，還是僅僅是雷達上的一個小光點。