论文部分内容阅读
通过实施IT服务管理的核心流程，作为服务台主管的我已经初尝甜头，不再像以前有事就救火，没事就闲着，我们的IT服务已实现了“被动管理”向“主动管理”的转变。请看我轻松而有序的一天。
8：50，我准时出现在公司门口。打卡、上楼梯、打开电脑。按以往的惯例，我上班之前都要去服务台转转，了解最新的服务受理情况。但现在习惯变了，不是第一时间走到服务台了解服务受理，而是第一时间打开电脑查看ITSM系统的记录。通过ITSM系统，我可以及时了解最新的服务受理情况及其处理进度。即使我不在服务台，也能够对IT服务做到心中有数。
正常报警处理
昨晚至今早的服务受理基本正常。只有一个客户投诉、几个事件的处理超时和部分客户出现数据通信故障需要进一步关注。“今天的开头不错。”我带着愉悦的心情，迈着轻松的步子去服务台了解这些事件。
路走了一半，经过服务总监办公室门口时，我被叫了进去。“昨晚试点使用新版本的客户在今早进行数据通信时出故障了。”总监看来已经在ITSM系统中查阅了相关事件记录，“你尽快协调解决此事。另外，有一家客户投诉服务工程师的技能，你去查一查，尽快给我汇报。”
“好的，我会尽快查明原因。”自從实施了ITSM工具之后，谁都可以在自己的权限范围内实时了解IT服务状况。对我而言，有了工具减少了我的服务汇报工作，但同时也增大了工作压力。因为领导可以实时查阅事件记录，也就意味着我的工作不能出现一点点差错。
在之前很长一段时间里，我的工作没现在这么忙，这么累。因为服务台的工作只要求做好客户报修的记录并分配即可。问题由服务工程师处理，软件新功能的增加由开发人员负责，投诉由投诉专员负责。服务台只要做到服务受理的“分级、分类、不漏、不错”就万事大吉。但现在不一样了，自从年初实施了ITIL，不论是工作内容，还是管理范围都有了很大的调整。服务台开始转型要面向客户提供服务，不再是简单的记录事件，而是要将自己看作是事件的主人，对受理的每一个事件都要做到及时跟踪，负责到底。所以了解每一个事件的进展，监督事件处理，报告事件结果就成了我的日常工作。
“新版本使用引发的故障到目前为止有多少？都是软件的技术问题吗？”见到服务台的值班长，我向她了解今早的报修情况。“昨晚60%使用新版本的客户已经报修，估计还会继续增加。”值班长说，“他们进行数据通信时会弹出英文的提示框，点击后，业务系统自动退出。从这种表现来看，我觉得是属于使用新版本引发的问题，这个事件已经直接升级给开发部门。”“好，你中午之前再跟进此事，尽快督促他们解决。还有一个客户投诉工程师服务技能，你也同时跟进，了解具体情况，两个小时内给我一个回复。”布置完任务，值班长开始忙碌起来，我也回到了办公室。
10：00，我收到服务台值班长发来的投诉情况汇报。客户投诉的是：一线工程师一周之内连续两次上门却未能解决问题，回来之后该事件作为问题升级至问题管理。问题管理找到解决方法之后向变更管理提交了变更请求，并已通过变更管理的审核。但由于方案需要的设备备件在采购环节上出现问题，迟迟没有到货，所以发布管理无法对客户进行发布，目前仅能采用维修的方式临时处理，维持但不能保证客户的正常使用。事情的经过已经清楚，接下来，服务台一方面需要安抚客户，告知他们我们会尽快解决这个问题；另一方面需要督促采购部门尽快完成设备备件的采购。因为按照ITSM系统的定义，如果一个投诉事件超过一周未能关闭，该事件将自动发送至服务总监，由服务总监亲自过问。今天若不及时处理这个投诉事件，也就意味着投诉要升级至最高管理层。
11：30，例行检查ITSM系统的事件记录，当查询发布问题的处理进度时，我发现新版本使用引发故障这个事件的状态变为“已解决”。这时服务台打来电话告知开发部门提交的解决方案，经变更管理审核后，发布管理已经通过服务器发布新的软件补丁解决。原因是试点客户的配置信息出现错误，实际的硬件型号与配置库中的记录有出入，软件测试时采用了错误型号的硬件，导致在实际使用时出错。原因找到了，问题解决了。虽然在配置管理中出了点差错，但是整个事件处理的效率还是令人满意的。
问题解决了，但服务没有结束。接下来需要安排服务台做一次电话呼出，对受到影响的试点客户进行解释并对此致歉，同时对客户的硬件配置信息做一次核实。核实之后我还要协调配置管理员对错误的硬件配置信息进行修正。忙了一上午，发布问题和投诉事情有了处理结果，这样我也可以向服务总监汇报工作了。
紧急事故处理
13：30，汇报完工作，我继续在ITSM系统中巡视事件记录。几个处理超时的事件已经关闭。暂时没有发现异常的事件。每天下午的这个时间，客户很少来麻烦我们，所以服务台也有了一天当中最清闲的时刻。
14：30，收到问题管理的E-mail。几天前的服务协调会上，针对雷雨季节客户设备的防雷击问题，我和事件经理、问题经理商量出一个方案，由问题经理出具一份如何防范雷击的注意事项，然后由服务台在雷雨季节来临之前制定防范雷击的呼出计划，并提前通知到每一个客户，尽可能减少因为缺乏防范意识导致的突发性、大规模的客户报修，减轻事件管理的服务压力。这么操作虽然有些麻烦，但带来的好处也是显而易见的。我要做的就是让这份专业的技术指导变得易于客户理解。这时，服务台承担的就是客户与专业技术人员之间的翻译角色。
15：30，桌上的电话响了起来。服务台值班长打来电话。“下午的服务器可能有问题，我们在半个小时之内接到20个客户电话报修，无法与远程服务器建立链接，已经分配给最近一位空闲的一线工程师到机房做检查。”“好，我知道了。”听完值班长的汇报，我继续做自己的事情。这只是服务台按规定向我做的汇报，只要事态不进一步发展，服务台只需通知到我这个主管即可。
15：50，电话再次想起。“情况不妙了，主管。工程师到了机房没找到问题。现在又有十几个电话报修同样的问题。”电话那头的值班长有点担心：“有的客户开始着急了。”“小王呢？”“他今天请假。我觉得可以启动应急预案了。这次报修的影响范围大，而且是关键服务受到影响，符合启动应急预案的标准。”“好的，你启动应急预案，我来签发。”
15：55，有关服务器故障的应急状态正式启动。小王是负责服务器维护的二线工程师。虽然不巧今天请假不在，但是根据应急预案的要求，服务器维护设计了A/B岗，小王是A岗，小林是B岗。
16：00，服务器故障的事情已经通知到服务总监、事件经理和问题经理。事件经理负责协调服务器维护人员，问题经理将作为后方的技术支持随时提供帮助。服务总监负责总体协调。“小林什么时候能够到机房？”应急会议上我简单通报了事情经过之后，问了问事件经理。“估计需要一些时间。他在其他客户那里处理问题，暂时还走不开。不过，我已经安排其他工程师过去接替他的工作。一旦有人接替，他马上赶去机房。”事件经理不紧不慢地回答我。“好，另外问题经理这边也回顾一下之前是否有类似的故障发生，争取在下班之前解决这个问题。”服务总监的指示让问题经理不敢怠慢。
在等待小林前往机房的途中，问题经理查找问题的过程里，又有客户的报修不断打进服务台。虽然受到影响的客户不断增加，但IT服务的节奏没有乱。一切在应急预案的指导下有条不紊地进行。我喜欢这种有序的工作节奏。因为可以摆脱过去“有事就乱、越忙越乱”的处理突发事件方式。
16：20，小林到达机房。问题管理员的电话也打了过去了解情况。经过大家的努力，很快找到了问题根源。半个小时后，小林解决服务器无法链接故障。
17：00，服务台抽取部分客户进行回访确定故障解决情况。在随机抽取的10个客户中，100%得到业务恢复正常的反馈。
17：20，半个小时的时间内没有接到一个服务器无法链接的报修电话。我宣布应急状态结束，并以E-mail通知到服务总监、事件经理和问题经理，当然还有服务台值班长。
8：50，我准时出现在公司门口。打卡、上楼梯、打开电脑。按以往的惯例，我上班之前都要去服务台转转，了解最新的服务受理情况。但现在习惯变了，不是第一时间走到服务台了解服务受理，而是第一时间打开电脑查看ITSM系统的记录。通过ITSM系统，我可以及时了解最新的服务受理情况及其处理进度。即使我不在服务台，也能够对IT服务做到心中有数。
正常报警处理
昨晚至今早的服务受理基本正常。只有一个客户投诉、几个事件的处理超时和部分客户出现数据通信故障需要进一步关注。“今天的开头不错。”我带着愉悦的心情，迈着轻松的步子去服务台了解这些事件。
路走了一半，经过服务总监办公室门口时，我被叫了进去。“昨晚试点使用新版本的客户在今早进行数据通信时出故障了。”总监看来已经在ITSM系统中查阅了相关事件记录，“你尽快协调解决此事。另外，有一家客户投诉服务工程师的技能，你去查一查，尽快给我汇报。”
“好的，我会尽快查明原因。”自從实施了ITSM工具之后，谁都可以在自己的权限范围内实时了解IT服务状况。对我而言，有了工具减少了我的服务汇报工作，但同时也增大了工作压力。因为领导可以实时查阅事件记录，也就意味着我的工作不能出现一点点差错。
在之前很长一段时间里，我的工作没现在这么忙，这么累。因为服务台的工作只要求做好客户报修的记录并分配即可。问题由服务工程师处理，软件新功能的增加由开发人员负责，投诉由投诉专员负责。服务台只要做到服务受理的“分级、分类、不漏、不错”就万事大吉。但现在不一样了，自从年初实施了ITIL，不论是工作内容，还是管理范围都有了很大的调整。服务台开始转型要面向客户提供服务，不再是简单的记录事件，而是要将自己看作是事件的主人，对受理的每一个事件都要做到及时跟踪，负责到底。所以了解每一个事件的进展，监督事件处理，报告事件结果就成了我的日常工作。
“新版本使用引发的故障到目前为止有多少？都是软件的技术问题吗？”见到服务台的值班长，我向她了解今早的报修情况。“昨晚60%使用新版本的客户已经报修，估计还会继续增加。”值班长说，“他们进行数据通信时会弹出英文的提示框，点击后，业务系统自动退出。从这种表现来看，我觉得是属于使用新版本引发的问题，这个事件已经直接升级给开发部门。”“好，你中午之前再跟进此事，尽快督促他们解决。还有一个客户投诉工程师服务技能，你也同时跟进，了解具体情况，两个小时内给我一个回复。”布置完任务，值班长开始忙碌起来，我也回到了办公室。
10：00，我收到服务台值班长发来的投诉情况汇报。客户投诉的是：一线工程师一周之内连续两次上门却未能解决问题，回来之后该事件作为问题升级至问题管理。问题管理找到解决方法之后向变更管理提交了变更请求，并已通过变更管理的审核。但由于方案需要的设备备件在采购环节上出现问题，迟迟没有到货，所以发布管理无法对客户进行发布，目前仅能采用维修的方式临时处理，维持但不能保证客户的正常使用。事情的经过已经清楚，接下来，服务台一方面需要安抚客户，告知他们我们会尽快解决这个问题；另一方面需要督促采购部门尽快完成设备备件的采购。因为按照ITSM系统的定义，如果一个投诉事件超过一周未能关闭，该事件将自动发送至服务总监，由服务总监亲自过问。今天若不及时处理这个投诉事件，也就意味着投诉要升级至最高管理层。
11：30，例行检查ITSM系统的事件记录，当查询发布问题的处理进度时，我发现新版本使用引发故障这个事件的状态变为“已解决”。这时服务台打来电话告知开发部门提交的解决方案，经变更管理审核后，发布管理已经通过服务器发布新的软件补丁解决。原因是试点客户的配置信息出现错误，实际的硬件型号与配置库中的记录有出入，软件测试时采用了错误型号的硬件，导致在实际使用时出错。原因找到了，问题解决了。虽然在配置管理中出了点差错，但是整个事件处理的效率还是令人满意的。
问题解决了，但服务没有结束。接下来需要安排服务台做一次电话呼出，对受到影响的试点客户进行解释并对此致歉，同时对客户的硬件配置信息做一次核实。核实之后我还要协调配置管理员对错误的硬件配置信息进行修正。忙了一上午，发布问题和投诉事情有了处理结果，这样我也可以向服务总监汇报工作了。
紧急事故处理
13：30，汇报完工作，我继续在ITSM系统中巡视事件记录。几个处理超时的事件已经关闭。暂时没有发现异常的事件。每天下午的这个时间，客户很少来麻烦我们，所以服务台也有了一天当中最清闲的时刻。
14：30，收到问题管理的E-mail。几天前的服务协调会上，针对雷雨季节客户设备的防雷击问题，我和事件经理、问题经理商量出一个方案，由问题经理出具一份如何防范雷击的注意事项，然后由服务台在雷雨季节来临之前制定防范雷击的呼出计划，并提前通知到每一个客户，尽可能减少因为缺乏防范意识导致的突发性、大规模的客户报修，减轻事件管理的服务压力。这么操作虽然有些麻烦，但带来的好处也是显而易见的。我要做的就是让这份专业的技术指导变得易于客户理解。这时，服务台承担的就是客户与专业技术人员之间的翻译角色。
15：30，桌上的电话响了起来。服务台值班长打来电话。“下午的服务器可能有问题，我们在半个小时之内接到20个客户电话报修，无法与远程服务器建立链接，已经分配给最近一位空闲的一线工程师到机房做检查。”“好，我知道了。”听完值班长的汇报，我继续做自己的事情。这只是服务台按规定向我做的汇报，只要事态不进一步发展，服务台只需通知到我这个主管即可。
15：50，电话再次想起。“情况不妙了，主管。工程师到了机房没找到问题。现在又有十几个电话报修同样的问题。”电话那头的值班长有点担心：“有的客户开始着急了。”“小王呢？”“他今天请假。我觉得可以启动应急预案了。这次报修的影响范围大，而且是关键服务受到影响，符合启动应急预案的标准。”“好的，你启动应急预案，我来签发。”
15：55，有关服务器故障的应急状态正式启动。小王是负责服务器维护的二线工程师。虽然不巧今天请假不在，但是根据应急预案的要求，服务器维护设计了A/B岗，小王是A岗，小林是B岗。
16：00，服务器故障的事情已经通知到服务总监、事件经理和问题经理。事件经理负责协调服务器维护人员，问题经理将作为后方的技术支持随时提供帮助。服务总监负责总体协调。“小林什么时候能够到机房？”应急会议上我简单通报了事情经过之后，问了问事件经理。“估计需要一些时间。他在其他客户那里处理问题，暂时还走不开。不过，我已经安排其他工程师过去接替他的工作。一旦有人接替，他马上赶去机房。”事件经理不紧不慢地回答我。“好，另外问题经理这边也回顾一下之前是否有类似的故障发生，争取在下班之前解决这个问题。”服务总监的指示让问题经理不敢怠慢。
在等待小林前往机房的途中，问题经理查找问题的过程里，又有客户的报修不断打进服务台。虽然受到影响的客户不断增加，但IT服务的节奏没有乱。一切在应急预案的指导下有条不紊地进行。我喜欢这种有序的工作节奏。因为可以摆脱过去“有事就乱、越忙越乱”的处理突发事件方式。
16：20，小林到达机房。问题管理员的电话也打了过去了解情况。经过大家的努力，很快找到了问题根源。半个小时后，小林解决服务器无法链接故障。
17：00，服务台抽取部分客户进行回访确定故障解决情况。在随机抽取的10个客户中，100%得到业务恢复正常的反馈。
17：20，半个小时的时间内没有接到一个服务器无法链接的报修电话。我宣布应急状态结束，并以E-mail通知到服务总监、事件经理和问题经理，当然还有服务台值班长。