1.事故描述。
2.根本原因描述。
3.事件是如何稳定或修复的。
4.用于解决事故的行动的时间表。
5.事故是如何影响客户的。
6.纠正或改正动作。
前5项让有关各方对事实有共同的了解。很多事故重复发生，就是因为人们不理解到底发生了什么，以及问题是如何修复的。不同团队以及不同层级的管理者聚集在一起进行事后分析时，对到底发生了什么的理解是不同的。事后分析时，与事故明显有关的人员都要同时到场，对事故的真实情况作出共同的描述。对真实情况没有确实的描述，就无法明确及正确地采取行动，而这应该是事后分析的最大用处。
确定根本原因应该是做，而不是说。但我却无法告诉你，有多少次这样的事后分析会，与会者花了大量的时间争论每一个可能的纠正项或者有多少客户受影响，只是觉得他们在浪费时间，因为根本就没搞清真正的根本原因。
对于稳定步骤也是如此。往往在一次重大事故故的混乱中，有多个人会试图进行多次修复。要确定真正的根本原因以及采取的步骤，在继续之前要使系统稳定下来。注意，事件也有可能不需要修复就可以稳定下来。像重启服务器以解决内存泄漏这样的事件，不需要修复的，但要消除对客户造成的影响。尽管可以稳定一段时间，但如果没有找到真正的根本原因的话，服务器很快就会又发生内存不够的问题了。
确定事故多久能够修复的时间表是很重要的。同样，每个人对时间表的理解也各不相同。在动手修复之前，让每个人都列出自己所了解的修复项，会减少修复时间(Time to resolve-ttr)。要确保回答下面的问题:
● 事故什么时候开始影响客户的?(注:并非所有事故都对客户有影响)
● 公司中什么时候有人开始意识到发生问题了?
● 此人是如何意识到发生问题的?通过监控?客服团队?还是个人报告？
● 有关事故的情况到达最终解决问题的人，要花多长时间?
● 什么使得人们能够对错误进行早期诊断?(例如，更好的监控，能够被充分理解的排错指南，等等)
● 稳定步骤要花很长时间吗?能否将稳定步骤自动化，或者简化稳定步骤以加快速度?减少事故的TTR时间，就跟消除事故本身一样重要。最终，重要的是影响客户的总时间(TTRX受影响的客户数)。有些宕机是无法避免的，但假如能够保证快速恢复，则受益的还是客户。
在确定了客户所受影响之后，你可能需要对事件赋予一个严重级别。可以建立自己的严重程度的类别，或者使用这个例子:
严重级别1:网站宕机影响大批客户方。
严重级别2:网站降级运行、性能问题或很难应对的功能故障。
严重级别3:对客户影响不大或易于应对的其他服务问题。
对网站建设维护问题赋予严重级别，将帮助你按照轻重缓急来处理纠正项，而且对于活跃事件的评估也是有用的。在试图解决问题之前，可能已经对其赋予了一个严重级别，所以，就能够确定，当前事件是一个5级火警，从而需要全力以赴，还是仅仅是雷达上的一个小光点。
本文地址：//www.gogoparty.cc//article/3335.html
