前5项让有关各方对事实有共同的了解。很多事故重复发生，就是因为人们不理解到底发生了什么，以及问题是如何修复的。不同团队以及不同层级的管理者聚集在一起进行事后分析时，对到底发生了什么的理解是不同的。事后分析时，与事故明显有关的人员都要同时到场，对事故的真实情况作出共同的描述。对真实情况没有确实的描述，就无法明确及正确地采取行动，而这应该是事后分析的最大用处。

　　确定根本原因应该是做，而不是说。但我却无法告诉你，有多少次这样的事后分析会，与会者花了大量的时间争论每一个可能的纠正项或者有多少客户受影响，只是觉得他们在浪费时间，因为根本就没搞清真正的根本原因。

　　对于稳定步骤也是如此。往往在一次重大事故故的混乱中，有多个人会试图进行多次修复。要确定真正的根本原因以及采取的步骤，在继续之前要使系统稳定下来。注意，事件也有可能不需要修复就可以稳定下来。像重启服务器以解决内存泄漏这样的事件，不需要修复的，但要消除对客户造成的影响。尽管可以稳定一段时间，但如果没有找到真正的根本原因的话，服务器很快就会又发生内存不够的问题了。

　　确定事故多久能够修复的时间表是很重要的。同样，每个人对时间表的理解也各不相同。在动手修复之前，让每个人都列出自己所了解的修复项，会减少修复时间(Timetoresolve-ttr)。要确保回答下面的问题:

　　● 稳定步骤要花很长时间吗?能否将稳定步骤自动化，或者简化稳定步骤以加快速度?减少事故的TTR时间，就跟消除事故本身一样重要。最终，重要的是影响客户的总时间(TTRX受影响的客户数)。有些宕机是无法避免的，但假如能够保证快速恢复，则受益的还是客户。

　　对网站建设维护问题赋予严重级别，将帮助你按照轻重缓急来处理纠正项，而且对于活跃事件的评估也是有用的。在试图解决问题之前，可能已经对其赋予了一个严重级别，所以，就能够确定，当前事件是一个5级火警，从而需要全力以赴，还是仅仅是雷达上的一个小光点。