8：50 我准时出现在公司门口。打卡、上楼梯、打开电脑。按以往的惯例我上班之前都要去服务台转转，了解最新的服务受理情况。但现在习惯变了，不是第一时间走到服务台了解服务受理，而是第一时间打开电脑查看ITSM系统的记录。通过ITSM系统，我可以及时了解最新的服务受理情况及其处理进度。即使我不在服务台也能够对IT服务做到心中有数。

昨晚至今早的服务受理基本正常。只有一个客户投诉、几个事件的处理超时和部分客户出现数据通讯故障需要进一步关注。“今天的开头不错。”我带着愉悦心情，迈着轻松的步子去服务台了解这些事件。

路走了一半，经过服务总监办公室门口时我被叫了进去。“昨晚试点发布新版本的客户在今早进行数据通讯时出故障了。”总监看来已经在ITSM系统中查阅了相关事件记录，“你尽快协调解决此事。另外，有一家客户投诉服务工程师的技能，你去查一查，尽快给我汇报。”“好的，我会尽快查明原因。”自从实施了ITSM工具之后，谁都可以在自己的权限范围之内实时了解IT服务状况。对我而言，有了工具减少了我的服务汇报工作，但同时也增大了工作压力。因为可以实时查阅事件记录，也就意味着我的工作不能出现一点点差错。

在之前很长一段时间里，我的工作没现在这么忙，这么累。因为服务台的工作只要求做好客户报修的记录并分配即可。问题由服务工程师处理，软件新功能的增加有开发人员负责，投诉由投诉专员负责。服务台只要做到服务受理的“分级、分类、不漏、不错”就万事大吉。但现在不一样了,自从年初实施了ITIL，不论是工作内容，还是管理范围都有了很大的调整。服务台开始转型要面向客户提供服务，不再是简单的记录事件，而是要将自己看作是事件的主人。对受理的每一个事件都要做到及时跟踪，负责到底。所以了解每一个事件的进展，监督事件处理，报告事件结果就成了我的日常工作。

“新版本发布引发的故障到目前为止有多少？都是软件的技术问题吗？”见到服务台的值班长，我向她了解了今早的报修。“昨晚发布新版本的客户已经报修了60%，估计还会继续增加。”值班长说：“他们进行数据通讯时会弹出英文的提示框，点击后，业务系统自动退出。从这种表现来看，我觉得是属于发布引发的问题，这个事件已经直接升级给开发部门。”“好，你中午之前再跟进此事，尽快督促他们解决。还有一家客户投诉工程师服务技能，你也同时跟进，了解具体情况2个小时内给我一个回复。”布置完任务，值班长开始忙碌起来，我也回到了办公室。

10：00我收到服务台值班长发来的投诉情况汇报。客户投诉的是一线工程师一周之内连续两次上门未能解决问题。上周客户报修但工程师上门未能解决。回来之后该事件作为问题升级至问题管理。问题管理找到解决方法之后向变更管理提交了变更请求，并已通过变更管理的审核。但由于方案需要的设备备件在采购环节上出现问题迟迟没有到货，所以发布管理无法对客户进行发布。目前仅能采用维修的方式临时处理，维持但不能保证客户的正常使用。事情的经过已经清楚，接下来服务台一方面需要安抚客户，告知他们我们会尽快解决这个问题；另一方面需要督促采购部门尽快完成设备备件的采购。因为按照ITSM系统的定义如果一个投诉事件超过一周未能关闭，该事件将自动发送至服务总监，由服务总监亲自过问。今天若不及时处理这个投诉事件，也就意味着投诉要升级至最高管理层。

11：30 例行检查ITSM系统的事件记录，当查询发布问题的处理进度时我发现这些事件的状态变为“已解决”。这时服务台打来电话告知开发部门提交的解决方案，经变更管理审核后，发布管理已经通过服务器发布新的软件补丁解决。原因是试点区域客户的配置信息出现错误，实际的硬件型号与配置库中的记录有出入，软件测试时采用了错误型号的硬件导致在实际发布时出错。原因找到了，问题解决了。虽然在配置管理出了点差错，但是整个事件处理的效率还是令人满意。

问题解决了，但服务没有结束。接下来需要安排服务台做一次电话呼出，对受到影响的试点客户进行解释并对此致歉，同时对客户的硬件配置信息做一次核实。核实之后我还要协调配置管理员对错误的硬件配置项信息进行修正。忙了一上午，发布问题和投诉事情有了处理结果，这样我也可以向服务总监汇报工作了。

13：30 汇报完工作，我继续在ITSM系统中巡视事件记录。几个处理超时的事件已经关闭。暂时没有发现异常的事件。每天下午的这个时间客户很少来麻烦我们，所以服务台也有了一天当中最清闲的时刻。

14：30 收到问题管理的mail。几天前的服务协调会上，针对雷雨季节客户设备的防雷击问题，我和事件经理、问题经理商量出一个方案，由问题管理出具一份如何防范雷击的注意事项，然后由服务台在雷雨季节来临之前制定防范雷击的呼出计划并提前通知到每一个客户。尽可能减少因为缺乏防范意识导致的突发性、大规模的客户报修，减轻事件管理的服务压力。这么操作虽然有些麻烦，但带来的好处也是显而易见的。我要做的就是让这份专业的技术指导变得易于客户理解。这时，服务台承担的就是客户与专业技术人员之间的翻译角色。

15：30 桌子上的电话想了起来。服务台值班长打来电话。“下午的服务器可能有问题，我们在半个小时之内接到20个客户电话报修无法与远程服务器建立链接。已经分配给最近一位空闲的一线工程师到机房做检查。”“好，我知道了。”听完值班长的汇报，我继续做自己的事情。这只是服务台按规定向我做的汇报，只要事态不进一步发展，服务台只需知会到我这个主管即可。

15：50 电话再次想起。“情况不妙了，主管。工程师到了机房没找到问题。现在又有十几个电话报修同样的问题。”电话那头的值班长有点担心：“有的客户开始着急了。”“小王呢？”“他今天请假。我觉得可以启动应急预案了。这次报修的影响范围大，而且是关键服务受到影响，符合启动应急预案的标准。”“好的，你启动应急预案，我来签发。”

15；55 有关服务器故障的应急状态正式启动。小王是负责服务器维护的二线工程师。虽然不巧今天请假不在，但是根据应急预案的要求服务器维护设计了A/B岗，小王是A岗，小林是B岗。

16：00 服务器故障的事情已经通知到服务总监、事件经理和问题经理。事件经理负责协调服务器维护人员，问题经理将作为后方的技术支持随时提供帮助。服务总监负责总体协调。“小林什么时候能够到机房？”应急会议上我简单通报了事情经过之后问了问事件经理。“估计需要一些时间。他现在其他客户那里处理问题，暂时还走不开。不过，我已经安排其他工程师过去接替他的工作。一旦有人接受，他马上赶去机房。”事件经理不紧不慢地回答我。“好，另外问题管理这边也回顾一下之前是否有类似的故障发生，争取在下班之前解决这个问题。”服务总监的指示让问题管理不敢怠慢。

在等待小林前往机房的途中，问题管理查找问题的过程里，又有客户的报修不断打进服务台。虽然受到影响的客户不断增加，但IT服务的节奏没有乱。一切在应急预案的指导下有条不紊的进行。我喜欢这种有序的节奏。因为可以摆脱过去“有事就乱、越忙越乱”的处理突发事件方式。

16：20 小林到达机房。问题管理员的电话也打了过去了解情况。经过大家的努力，很快找到了问题根源。半个小时后小林解决服务器无法链接故障。

17：00 服务台抽取部分客户进行回访确定故障得到解决。在随机抽取的10家客户100%得到业务恢复正常的反馈。

17：20 半个小时的时间内没有接到一个服务器无法链接的报修电话。我宣布应急状态结束并以email通知到服务总监、事件经理和问题经理。当然还有服务台值班长。

总算在下班之前结束了手里所有的事情。原以为是轻松的一天，没想到会过的如此“充实”。