[原创]数据通讯故障拷问IT服务应急方案

昨天公网的服务器硬盘出现故障，逻辑卷Offline导致客户的数据通讯无法操作。

7：00 服务台一上班就开始接到客户的报修电话，在其后的时间里服务台电话铃声此起彼伏，仿佛令人置身于战时指挥部。话务员忙的都无暇他顾；

8：20 运维部的主管将此问题通知到负责服务器维护的主管；

8：30 服务器维护人员远程维护无效；

8：45 维护人员到达现场处理，发现硬盘故障无法运行。采用的是更换备份机的方式；

10：30 解决服务器故障；

13：30 发现数据通讯之后存在1月9日的配送信息。问题管理开始着手解决此项问题；

14：00 客户的报修明显减少。

从7：00至14：00故障的解决持续了7个小时。全市3000多家客户因为此次的硬盘故障问题都无法进行数据通讯。

幸运的是我们没有这方面的考核，否则不知道会不会因为这个故障和处理的时间而影响到年底的服务考评。

事件得到控制，虽然不能说是及时，但也没造成严重后果。回顾这次意外，听到最多的是：这次硬盘故障无法预料。技术上的无法预测在所难免，但换个角度想：凡事没有无因之果。和维护人员聊了之后，他也说了几个可能导致此次故障的因素： 

1. 大量频繁的读写操作导致磁盘当机
2. 磁盘本身的问题
3. 系统本身的问题
4. 机房的环境

且不论技术方面的细节，从这些因素看出根据故障产生的原因进行识别和控制才是IT服务人员应该具备的态度。而不是习惯性地认为这些问题根本没法预测或者提前发现。虽然也不能完全通过控制故障原因来达到控制故障的目的，但是至少我们可以通过多方面的控制降低故障发生的几率。

故障发生了，而且很紧急。从管理上应该启动应急方案，这是管理保障。也许在此需要再延伸一下对应急方案的思考。方案有了还不够，一定要演练！愈是责任大的应急方案，愈是要演练。对维护人员形成一个处理的条件反射，防止突发事件发生时紧张带来的手足无措。

最近我们内部也搞一个留单超标的应急方案，自从审批通过之后，就束之高阁。看来也需要拿出来适当地“晒晒太阳了”。

 

推荐到鲜果： 查阅更多相关主题的帖子: IT服务管理 IT应急方案 ITIL连续性 ITIL可靠性 ITIL可用性