发布时间：2022-09-27 00:00   您所在的位置： 网站首页 > 新闻资讯 > 经验杂谈

事后剖析至少要包含这些信息:

1.事故描述。

2.根本原因描述。

3.事件是如何稳定或修复的。

4.用于解决事故的行动的時间表。

5.事故是如何决定客户的。

6.纠正或纠正动作。

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



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

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

确定事故多久可以修复的時间表是很重要的。一样，每个人对時间表的理解也各不相同。在动手修复以前，让每个人都列出自个所清楚的修复项，会减少修复時间(Timetoresolve-ttr)。要确保回答下边的问题:

● 事故什么时候开始决定客户的?(注:并不是所有事故都对客户有决定)

● 公司中什么时候有人开始意识到发生问题了?

● 此人是如何意识到发生问题的?通过监控?客服团队?还是个人报告？

● 有关事故的情况到达最终解决问题的人，要花多长時间?

● 什么使得人们可以对错误开展早期诊断?(例如，更好的监控，可以被充分理解的排错指南，等等)

● 稳定流程要花很长時间吗?能否将稳定流程自动化，或者简化稳定流程以加迅速度?减少事故的TTR時间，就跟消除事故自身一样重要。最终，重要的是决定客户的总時间(TTRX受决定的客户数)。有一些宕机是无法防止的，但假如可以确保迅速恢复，则受益的还是客户。

在确定了客户所受决定之后，你可能必须要对事件赋予一个严重级别。可以建立自个的严重水平的类别，或者使用这样的例子:

严重级别1:网站宕机决定大批客户方。

严重级别2:网站降级运行、性能问题或很难应对的基本功能故障。

严重级别3:对客户决定不大或易于应对的其他服务问题。

对网站开发维护问题赋予严重级别，将赞助你依照轻重缓急来处置纠正项，而且相对活跃事件的评估也是有用的。在试图解决问题以前，可能已经对其赋予了一个严重级别，故此，就可以确定，当前事件是一个5级火警，从而必须要全力以赴，还是仅仅是雷达上的一个小光点。

本文章由新概念互动原创，如没特殊注明，转载请注明来自：http://www.jianzhan0.com/jingyand/72178.html

上一篇：网站数据库怎么进行容量规划？

下一篇：怎么进行网站的真实用户监控(RUM)？