开始之前，要准备好与根本原因、稳定步骤、时间表有关的事实材料，这对要采取的正确行动进行富有成效的讨论是必要的，而且也有助于平静人们敏感的神经，人们害怕这样的会议会变成政治迫害。
事实一旦清楚之后，就可以开始讨论为了使类似事情不再发生，需要做些什么。你要要明确地陈述事情的根本原因，但也要对尽快修复问题的各种方法(降低修复时间TR)进行讨论。纠正阶段也要考虑潜在的类似问题，例如，假如是一组服务器的空间用完了，就要给这些服务器增加空间，同时也要检查其他服务器是否也存在类似的潜在问题。
避免人身攻击。人类总会犯错误，如果是人为因素造成的问题，则直接讨论如何使人为因素不再产生影响，警如，检查过程，看是否存在能够加以自动化的机会，或进行更好的规划，或简化过程要确保相关各方对各自领域都能得出补救的办法。有时候人们会对其他小组或个人进行指责，不要指责，而是询问需要做什么才能使类似事件不再发生。如果有人轻描淡写或隐藏与自己有关的问题，要敢于询问一些尖锐的问题，直到问题得到合理的解释。这样得到的补救措施才是有意义的，也是值得努力花精力去做的。
最后的一点建议:有时候有些团队在进行事后分析时，过于尽力，以致有些矫枉过正。要避免近因效应，确保补救措施对整个业务都是有意义的。例如，不要把新软件的更新搞得太痛苦，过程搞得太严肃，以至于只是因为害怕宕机，而使业务最后都陷于停顿。要努力在速度和稳定性之间取得平衡。
一旦有了一套纠正措施，要将其记录在案，包括执行人以及完成日期。我见过太多这样的团队，他们设计出了成捆杰出的方案，但只是将其放在一边，而没有执行，因为出现了更为耀眼的目标，结果是，原来的问题一次又ー次地发生。
团队在救火的时候表现会非常杰出，但这种快速地跳转到某个新事情上的能力，却让他们无法集中精力修复已知需要修复的问题。事后分析的核心是得出纠正措施，但只有在花时间实现这些措施之后，才是网站建设维护有价值的。
本文地址：//www.xrqsnxx.com//article/3336.html
