学习资料： ITIL培训基地专家讲堂直播 300期视频回放
本文出自 转载等请务必保留此出处
多数企业的IT支持部门一直因为企业内部层出不穷的技术故障而疲于奔命，这种状况降低了IT支持部门工作的技术含量，使得他们更象一支“救火队”。不仅如此，人手的短缺、时间的紧迫也一直困扰着这个部门。那么，IT支持部门能够摆脱“体力活”的桎梏吗？他们有可以依靠的省力法则吗？答案是肯定的。在ITIL 中，事故管理作为一个核心流程而存在，是解放IT支持部门最有效的法则。本期的“服务管理”栏目将向您介绍事故管理的相关知识。
如果要描述目前大部分IT部门所处的状况，用得最多的恐怕是将他们形容为“救火队”，整天疲于奔命，解决各种各样的问题。
比如，某家单位有一次碰到的问题是有两台关键的邮件服务器出现阻塞故障，短短2个小时，数十万封邮件被延迟转发。技术人员接到报告后立刻进行故障分析。虽然这种系统已经做过几次“定制化开发”，从技术上说可能问题不是很大，但真正排除起来，也费了一番工夫。
笔者也曾听到过某跨国连锁企业在华公司的IT部门负责人抱怨，他们这个部门30多号人管理着全国各个分店的IT支持工作。服务台的3到4个人，一天到晚在不停地接电话，然后把接的电话不停地转给后台支持人员。由于人手不够，他这个当领导的也在不停地帮忙解决各种事故。结果整个部门看起来都在干“体力活”！
那么，有没有办法解决此类问题呢？有！那就是实施事故管理流程。
所谓事故（Incident），是指任何不符合标准操作且已经引起或可能引起服务中断和服务质量下降的事件（Event）。
事故管理的目的就是在出现事故的时候，能够尽可能快地恢复服务的正常运作，避免业务中断，以确保最佳的服务可用性级别。
可以说，事故管理流程为那些干着“体力活”的IT部门提供了一整套省时省力的方法。重点是下面三条:
1.
省力措施之一：将事故进行初步归类
一般来说，当出现事故时，首先是服务台记录与事故有关的客户和用户的信息，如姓名、工作地点和联系电话等，而有关事故信息的详细记录是由事故处理小组完成的。但事故处理小组在记录相关信息和确认事故后，接下来要做的并不是立即解决事故，而应该是先对事故进行“初步归类”，然后再进行初步处理。
这里的“初步”包含两层含义：一是根据已有的知识和经验对事故的性质进行大致的划分，以便采取相应的措施；二是这里采取的措施和行动不以根本上解决事故为目标，主要目的是确保用户的持续运作。如果不能较快找到根本性解决方案，事故管理小组就要尽量找到临时性的解决办法。
“归类”就是发现事故原因，以便采取相应行动。
那么如何进行事故初步归类呢？可以采用如表所示的事故分类系统。
2. 省力措施之二：区分事故优先级
在对事故进行归类后，如果没有成功地将事故与问题或先前知名错误进行匹配，下一步就是确定事故的优先级，以确保支持小组给予事故必要的注意。
当IT服务提供方必须同时处理数个事故，但受时间、资源和人力等的限制而无法实现时，他就要排定处理的先后次序，即确定每个事故的优先级。
优先级一般是由服务台综合考虑用户和服务级别协议的要求及其它因素后确定的。但当出现事故后，没有用户会说他的问题可以放到以后解决。相反，他们总是认为自己的问题才是最需要优先解决的。因此，服务台最好根据一些量化的指标来决定优先级。
确定事故处理优先级及相应所需的资源需要综合考虑事故对业务的影响情况、恢复服务对业务的紧迫性、事故的大小、范围和复杂程度以及当前可供事故处理的资源。我们可以用一个公式来计算优先级：优先级＝影响度×紧迫性。
其中，影响度是衡量事故影响业务大小程度的指标，通常相当于事故影响服务质量的程度。它一般是根据受影响的人或系统的数量来确定的；紧迫性是评价事故和问题危机程度的指标，是根据客户的业务需求和事故或问题的影响而制定的；而优先级是根据影响程度和紧急程度而制定的事故和问题的处理顺序。
3. 省力措施之三：建立事故升级机制
当一线支持人员在规定的时间内不能解决或没有解决某个事故时，就需将这个事故的处理任务交给更有经验和（或）有权限的支持人员，这叫事故升级。
升级是根据上面讨论的优先级和事故解决时间确定的。升级方式通常有两种。一种是职能升级（Functional Escalation），另一种是层次升级（Hierarchical Escalation）。前者又称水平升级，指安排更多的专家或授予更多的特权（技术方面的）以解决事故；后者又称垂直升级，出现在所需的权限（组织方面的）和资源不够的时候。
在一般情况下，我们应该优先使用职能升级。只有在某些关键时间内事故不能即及时解决时才考虑使用层次升级。如果是后一种方式，最好尽可能早于服务级别协议规定的时间开始有关行动，比如外聘专家。
恰当和有效的事故升级机制对事故的成功处理至关重要，同时也对服务支持能力的有效提高相当关键。如果升级太迟或者升级层次不够，就有可能导致IT服务延迟，不能满足服务级别的要求。另一方面，如果升级过快或过度，又可能导致服务支持资源的浪费，同时减少设立一线支持、二线支持和三线支持的作用（如图）。
图 一线支持、二线支持和三线支持
4. 一切因规范而简约
通过上述三条措施，一方面可以减少IT部门所需做的“体力活”，另一方面即使在IT部门做必要的“体力活”时，也可以做到有条不紊、不慌不忙。
具体来说，对客户和用户而言，一是减少了事故对业务的影响，提高了效率；二是化被动为主动，改进了业务系统；三是获得更多有用的管理信息，加强了管理。而对IT部门而言，既提高了绩效评价的准确性、有关服务质量的信息的质量，又提高了服务人员的工作效率、避免了误将某些情形当成事故，最终提高了客户满意度。
表 事故分类系统
事故类型
| 一级分类
| 二级分类
| 优先级
|
| 软件
| 文字处理系统
| 2 |
|
| 电子表格软件
| 2 |
|
| 业务应用系统
| 1 | 故障
| 硬件
| 大型机
| 1 |
|
| 工作站
| 1 |
|
| 桌面电脑
| 2 |
| 其它．．．．．．
|
|
|
| 重置密码
|
| 1 |
| 更换墨盒颜色
| 3 |
| 服务请求
| 用户帮助
| 办公软件
| 3 |
|
| 业务应用系统
| 2 |
| 其它．．．．．．
|
|
| 
转播
分享
淘帖
()
