事后分析至少要包含這些內容:

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

3.事件是如何穩定或修復的。

4.用于解決事故的行動(dòng)的時(shí)間表。

5.事故是如何影響客戶(hù)的。
 
6.糾正或改正動(dòng)作。

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



確定根本原因應該是做，而不是說(shuō)。但我卻無(wú)法告訴你，有多少次這樣的事后分析會(huì )，與會(huì )者花了大量的時(shí)間爭論每一個(gè)可能的糾正項或者有多少客戶(hù)受影響，只是覺(jué)得他們在浪費時(shí)間，因為根本就沒(méi)搞清真正的根本原因。

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

確定事故多久能夠修復的時(shí)間表是很重要的。同樣，每個(gè)人對時(shí)間表的理解也各不相同。在動(dòng)手修復之前，讓每個(gè)人都列出自己所了解的修復項，會(huì )減少修復時(shí)間(Time to resolve-ttr)。要確?；卮鹣旅娴膯?wèn)題:

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

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

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

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

在確定了客戶(hù)所受影響之后，你可能需要對事件賦予一個(gè)嚴重級別?？梢越⒆约旱膰乐爻潭鹊念?lèi)別，或者使用這個(gè)例子:

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

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

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

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