学习资料： ITIL先锋论坛专家讲堂直播 300期视频回放
一项应急方案的执行是人按照流程运用技术来处理故障，以达到尽快恢复服务的目的。通过演练强化人对流程的熟悉，对技术的运用，到实战时脑子就不会一片空白了。
6：30，一阵mp3音乐响起。昨晚加班到今天凌晨1：00才休息的丁磊迷迷糊糊地伸手想去关掉闹钟，手指在手机的触摸屏上摸索着。摸了一圈，伴着振动的音乐还在响着。迷糊中丁磊忽然明白这是一个电话。“丁磊，我今天的数据通讯无法操作。”一个相熟的客户打来报修电话。服务台7点才上班，估计是客户一着急就打到了丁磊的手机上。“噢，你再多做几次。”“试过了可就是不行。”“再试试，如果还不行7点以后你直接打800电话报修。”丁磊还没有完全清醒。
数据通讯故障一般都会在故障发生后重复做几次就能解决，客户很多时候会大惊小怪。所以丁磊没有将此放在心上继续合上眼又眯了一会才懒懒地起床洗漱。
7：00，话务员小林今天值早班，一踏进服务台的门就听见里面的电话响个不停。“今天这是怎么了，电话都响了。看来又是数据通讯故障。”小林根据自己的经验判断只有公网服务器出现故障才会在这么早有这么多的电话。
“您好，工号648为您服务，请问有什么可以帮您？”小林先接起一个电话。
“你好，我今天早上的数据通讯一直无法做成功。这是怎么回事？”
果然不出所料，小林按照规定的问题处理脚本对客户进行操作辅导。一步步操作下来没有任何问题，数据通讯依然无法操作成功。小林有些着急，客户的故障没有解决，旁边的电话还在响个不停。无奈之下，小林只好答应客户将会派工程师上门处理。
接了几个电话都是相同的问题。小林知道应该是服务器出了故障，按照以往的经验，此类故障只需要服务维护工程师重启服务器即可解决。因此，小林在辅导客户的时候就会告知1到2个小时后再做数据通讯，不再承诺派工程师上门服务。
7：20，丁磊吃完早餐正准备出门换鞋，兜里的手机响了。又是数据通讯的问题，丁磊依旧让客户再试几次如果还不行，就直接报修。接完电话之后，丁磊换好鞋出门。刚走到电梯口，手机又响了。还是相同的问题，丁磊依葫芦画瓢应付了过去。
7：30，服务台的话务员开始多了起来。但增加的人手很快被淹没在此起彼伏的报修电话之中。过去的半个小时里小林马不停蹄地接了几十个电话，水都来不及喝一口。
7：50，丁磊已经在公交车上接了10个报修电话。这是不正常的现象，丁磊离开工程师的岗位之后一般不会再接到客户的报修电话。打到他手机的报修多是很紧急的问题或者是投诉之类。丁磊觉察到一丝的不安。于是，他拨通了服务器工程师的手机。
8：00，服务器工程师小周开始远程连接服务器检查运行情况。“又是例行公事，重启服务器。”小周已经对类似的故障习以为常。昨天晚上他还远程登陆过服务器没有任何问题。但是，很显然今天的故障不同于以往。小周发现连过去之后硬盘无法读写。“出问题了。”小周抄起背包打了Taxi就赶到电信机房。
8：45，小周重新启动服务器，发现硬盘逻辑卷显示为OFFLine。“完了，服务器硬盘坏了。”小周心里一阵阵地紧张。全市3000多家门店的商品配送信息都是依靠这台服务器完成传递。他感觉到自己手心有些湿。这是他第一次遇到这么严重的事故。
9：00，三位话务加两名二线工程师全部到岗。服务台此时就象一个战时的指挥部，所有的人都在紧张地工作着。放下一个电话再接起另外一个电话，不断地重复解释数据通讯为何不能操作。丁磊隔着玻璃窗看着里面忙碌的景象，若有所思。没想到上个月讨论有关IT服务连续性管理的内容，今天就派上了用场。
已经过去一个小时了，小周还没有打电话过来通知具体的故障原因，丁磊于是联系小周询问现场的情况。当得知是服务器硬盘损坏的故障，丁磊更加庆幸上个月及时讨论了如何确保IT服务连续性这个问题。由于事先对类似的故障做了规划，制定了应急方案。按照方案的设计，故障可以在1小时内解决，因此丁磊对这次事故的控制心里比较有底，加之应急方案制定之后一直没有演练过，正好也可以利用这次难得的故障检验应急方案。
10：30，故障排除。小周按照预定的处理方案，先联系了服务器支持厂商。在厂商的支持仍然没有解决问题之后，小周只好采用备用机替换的方式来尽快恢复服务器的工作，期间还要恢复一些数据。这么一折腾处理时间超出应急方案规定的恢复时间达45分钟。
12：00，小周回到公司向丁磊汇报工作。
“领导，我来认错了。”小周见到丁磊的第一句话就是作自我检讨。“为什么？因为恢复服务的时间超时？”“这是一个原因吧，但不是最主要的。”小周喝了口水，坐在丁磊的对面开始聊起这次的故障处理。
“说句实话，我到了现场发现服务器硬盘损坏时，心里真的很慌。”小周不好意思地笑了笑，“幸好上个月我们刚讨论过这个应急方案。我就按照应急方案的步骤开始操作，本来按照方案处理1个小时是可以解决问题。但在替换备份机的时候有一个备份脚本没找到，这时候有点紧张然后怎么找就是找不到。最后没办法，备用机替上去后台的一些目录只好通过手工去建立，耽误了不少时间。等我恢复好服务器工作之后居然又找到了那个备份脚本。真让人郁闷！”
“没关系，虽然这次处理的时间长了点，但是好在问题已经解决。也检验了我们制定的应急方案是正确的。”丁磊知道小周做事一向很谨慎。这次没有找到的备份脚本，其实就是小周自己写的脚本，每周一次将服务器上的目录打包发送到备用机上，而且做了三地备份。从技术上讲，小周已经做到了充分准备。这45分钟的超时让丁磊看到IT服务连续性管理中没有强调，但是很容易忽略的一个步骤。
IT服务连续性管理的措施就是要求事先规划，做好应急计划。当客户业务遭到中断后，IT服务方必须提供根据事先规划好的IT服务连续性应急计划来支持客户业务最低需求的能力。相对于应付日常操作及日常危机的IT服务可用性管理，有人将IT服务连续性管理戏称为“B计划”以作区别。
丁磊认识到自己在识别IT服务风险，制定应急方案方面花费了不少的时间和精力。重心都放在了如何在技术上应付突发的风险，却忽视了人在应急方案中的弱点。重压之下，人在没有做好充分准备的情况时很难做到气定神闲。出错也将在所难免，无形之中也增加了新的风险。
沉着冷静。丁磊决定在应急方案中增加这样一项非技术步骤，而且是放在第一条的位置。人不能冷静下来，再好的技术处理步骤都将变得面目全非。如何在重压之下依然能够保持冷静？丁磊想到了小区公告栏里贴出的在9月15日全民国防教育日这一天要鸣响空袭警报的通知。通知写明了鸣放的时间，范围和形式。目的是为了检验空袭警报设备的可用性和可靠性，同时也在演练空袭警报的流程。
丁磊不是没有想到演练，只是制定应急方案的时间和这次故障的时间间隔太短，他还没有来得及进行演练就被拉上“战场”来了一次实战。实战的结果让他对演练更加看重。一项应急方案的执行是人按照流程运用技术来处理故障，最终达到尽快恢复服务的目的。正所谓：养兵千日，用兵一时。如果不通过演练来强化人对流程的熟悉，对技术的运用，那么真到了实战的那一天也许脑子有的只是一片空白了。
|
转播
分享
淘帖
()
