什么是網站維護中的事后分析?

發布：2018-06-23 14:43:12 瀏覽：3455

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

1.事故描述。

2.根本原因描述。

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

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

5.事故是如何影響客戶的。

6.糾正或改正動作。

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

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

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

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

●事故什么時候開始影響客戶的?(注:并非所有事故都對客戶有影響)

●公司中什么時候有人開始意識到發生問題了?

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

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

●什么使得人們能夠對錯誤進行早期診斷?(例如，更好的監控，能夠被充分理解的排錯指南，等等)

●穩定步驟要花很長時間嗎?能否將穩定步驟自動化，或者簡化穩定步驟以加快速度?減少事故的TTR時間，就跟消除事故本身一樣重要。最終，重要的是影響客戶的總時間(TTRX受影響的客戶數)。有些宕機是無法避免的，但假如能夠保證快速恢復，則受益的還是客戶。

在確定了客戶所受影響之后，你可能需要對事件賦予一個嚴重級別。可以建立自己的嚴重程度的類別，或者使用這個例子:

嚴重級別1:網站宕機影響大批客戶方。

嚴重級別2:網站降級運行、性能問題或很難應對的功能故障。

嚴重級別3:對客戶影響不大或易于應對的其他服務問題。

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