開始事后分析的時候，首先要做的事情就是明確基本規(guī)則，要明確告知參與事后分析的相關各方，事后分析不是指責誰，主要目的是為了使類似事件不再重復發(fā)生?？焖侔l(fā)展的互聯網站，問題是不可避免的，重要的是我們能夠從錯誤中學到教訓。

開始之前，要準備好與根本原因、穩(wěn)定步驟、時間表有關的事實材料，這對要采取的正確行動進行富有成效的討論是必要的，而且也有助于平靜人們敏感的神經，人們害怕這樣的會議會變成政治迫害。


事實一旦清楚之后，就可以開始討論為了使類似事情不再發(fā)生，需要做些什么。你要要明確地陳述事情的根本原因，但也要對盡快修復問題的各種方法(降低修復時間TR)進行討論。糾正階段也要考慮潛在的類似問題，例如，假如是一組服務器的空間用完了，就要給這些服務器增加空間，同時也要檢查其他服務器是否也存在類似的潛在問題。

避免人身攻擊。人類總會犯錯誤，如果是人為因素造成的問題，則直接討論如何使人為因素不再產生影響，警如，檢查過程，看是否存在能夠加以自動化的機會，或進行更好的規(guī)劃，或簡化過程要確保相關各方對各自領域都能得出補救的辦法。有時候人們會對其他小組或個人進行指責，不要指責，而是詢問需要做什么才能使類似事件不再發(fā)生。如果有人輕描淡寫或隱藏與自己有關的問題，要敢于詢問一些尖銳的問題，直到問題得到合理的解釋。這樣得到的補救措施才是有意義的，也是值得努力花精力去做的。

*后的一點建議:有時候有些團隊在進行事后分析時，過于盡力，以致有些矯枉過正。要避免近因效應，確保補救措施對整個業(yè)務都是有意義的。例如，不要把新軟件的更新搞得太痛苦，過程搞得太嚴肅，以至于只是因為害怕宕機，而使業(yè)務*后都陷于停頓。要努力在速度和穩(wěn)定性之間取得平衡。

一旦有了一套糾正措施，要將其記錄在案，包括執(zhí)行人以及完成日期。我見過太多這樣的團隊，他們設計出了成捆杰出的方案，但只是將其放在一邊，而沒有執(zhí)行，因為出現了更為耀眼的目標，結果是，原來的問題一次又ー次地發(fā)生。

團隊在救火的時候表現會非常杰出，但這種快速地跳轉到某個新事情上的能力，卻讓他們無法集中精力修復已知需要修復的問題。事后分析的核心是得出糾正措施，但只有在花時間實現這些措施之后，才是網站建設維護有價值的。