管“事”的ITIL Service Support（更新版）

此篇为更新版。修改了一些内容并增加了ITILSS实施的两种方式。           

ITIL service Support，IT 服务管理的核心之一。一个职能和五个流程的服务结构为IT运维提供了行业最佳实践的指导，提供了一个客观、严谨、可量化的标准和规范，从而确保IT部门能够为企业的业务运作提供更好的IT技术支持。对企业来说，实施ITIL的最大意义在于把IT与业务紧密地结合起来了，从而让企业的IT投资回报最大化。对IT部门而言，实施ITIL Service Support的意义在于将IT日常运维管理过程中遇到的各种各样的“事”做了清晰梳理，从而使得IT运维过程变得有序连贯，有助于提高IT服务的能力和水平。 

 

 

 

图1 ITIL Service Support流程图

图1所展示的ITIL Service Support流程清晰地表达出一个认识：服务因事而起，因事而终。事件、问题、已知错误、变更、发布等等这些ITIL的术语虽然有着不同的含义，但从服务全局的角度看，它们只是“事”在不同阶段的不同身份。所以，管“事”的ITIL Service Support很形象地描述了IT运维的工作内容。

凡事皆有因。对IT运维来说，因自用户起，事自服务台入。服务台作为一项管理功能，它每天遇到的事儿最多：报修的，投诉的，咨询的，商业机会，甚至还有骚扰等等。没有服务台的时候这些都是混杂在一起进入IT运维的各个服务小组。有了服务台每一件事经过梳理、分配，然后站好队、排排位，该去哪里去哪里。作为IT运维流程的起点，服务台做事始终要将“下一个流程”的意识贯彻在自己的工作中，不能乱排位置，乱指挥。安排妥当之后“事”自服务台开始，流经事件管理、问题管理、变更管理、发布管理和配置管理等流程最后再由服务台负责收尾完成一件事的处理闭环。

事由服务台流转至事件管理流程都是披着“事件”的外衣。事件管理流程关注的“事”定义比较明确，该我管的事，我绝不推脱。超出管辖范围不该我管的事，升级成问题提交至问题管理。因此，事件管理需要解决的事都是属于已知的可控服务范畴。也可以理解为事件管理根据与问题管理协商而定的事件管理范围，识别、处理服务台转过来的“事”。之所以要强调事件管理是在一定范围内处理“事”，主要是在处理时间上有限制要求。事件管理其实就是响应速度的管理。响应时间短、处理速度快是事件管理的做事风格。但凡影响事件响应速度的“事”发生，事件管理需要做一个简要的分析和诊断，要么提出可行的快速解决方案或应急措施，要么在没有更好办法的情况下“事”被当作事件立即升级。

超出事件管理能力范畴并提请升级的“事件”在ITIL中称之为：问题。虽然“事”的性质在升级之后发生了变化，但事件管理里有关“事”的所有信息都将作为问题管理的参考依据，协助问题管理寻找问题发生的根源。同样，问题管理需要想办法尽快将“问题”转变为已找到问题根源的“已知错误”，提供应急措施或最终的解决方案以帮助事件管理尽快恢复用户的业务运行。

并不是每一个问题都需要走变更管理流程。但变更管理的目的是纠正错误、解决问题。从这一点看，变更管理是在纠正错误的“事”。一般而言，问题管理分析出已知问题，提交RFC到变更管理，变更管理进行解决。可是一旦变更管理控制不严，没有对发布进行充分的测试，那么对事件管理和问题管理又将是新事件、新问题的产生开始。

发布管理做什么？发布管理是对变更做实质性执行的流程。不仅要忠实地执行变更，而且还要考虑“将要安装的配置项、将要停止使用的配置项以及退出使用的配置项”，考虑到是变更对CMDB中配置项及其相关整体的影响。发布的成功与否，需要事件管理提供的错误记录来确认。由于发布事关重大，有计划、有步骤地做“事”是发布管理做事的特点。

配置管理是一项基础性的管理工作。配置管理做的“事”不比服务台少，而且做好了很容易被忽视，做的不好又很容易被发现。吃力不易讨好的做“事”是配置管理工作的真实写照。虽然有人认为ITIL Support中最重要的就属配置管理，它不仅仅是服务台和5个管理流程稳定运行的基础，而且一个及时、完整、准确的配置库将会给IT服务带来极大的自信：我之所以能够做到准确地提供IT服务是因为我有一个非常完备的配置库和运作良好的配置管理流程。

在ITIL框架下，一项IT服务已如工业化流水线上的商品，体验着IT运维流程化带来的高效率和高质量。流水化的服务生产引发的是对原有IT服务组织结构的调整。统一的服务台配合新的管理制度解决了客户直接调用工程师的弊病。不同的“事”接入经过服务台识别分配后，进入事件管理。随之“事”的身份变换为事件、问题、已知错误、变更、发布等，完成一项服务由事发到消除的生命周期。

实施ITIL Service Support对于IT部门来说最大的改变是做“事”的方法。从过去的忙乱过渡为井井有条，从过去的跨组协调变为一以贯之的流程间协作。效率的提高不用多说，最关键的是流程化的工作方式在慢慢改变着员工的工作思路。IT运维强调的是“服务”二字，相比职能化的管理模式流程协作更能体现出服务意识从而影响到员工的工作习惯进而达到：工作成习惯，习惯成自然的效果。

ITIL带给IT部门的好处自然让人心动，但如何实施ITIL是很多人心中的疑惑。是十个流程同时实施，还是一个一个流程实施，抑或是某些流程打包在一起先实施。如何通过实施ITIL最终实现IT运维的“可控”、“在控”和“能控”。具体的ITIL流程实施方式虽然没有统一的标准，但是根据这些年的经验来看，ITIL流程的实施基本上是两种方式：渐进式和爆发式。

    从图2中我们可以看到，渐进式实施ITIL是一个循序渐进的过程。它有三个阶段：初期、中期和远期。初期一般只实现服务台、事件管理和配置管理一个服务管理职能和两个ITIL Service Support流程。虽然这只是实现了一小部分的流程，但走好这一步不仅可以提高ITIL实施的信心，而且能够为以后的实施打下牢固的基础。

中期的目标是建立问题管理、变更管理、发布管理、安全管理、继续优化或强化配置管理以及ITIL Service Delivery中部分的管理流程。在完成初期和中期的ITIL流程实施之后，IT运维基本可以实现“可控”和“在控”。“可控”要求的是基础IT运维有流程，有职责；“在控”则是要求在“可控”的基础上进行扩展，完善ITIL Service Support流程同时建立ITIL Service Delivery部分管理流程。

最后阶段的ITIL实施就是要达到“能控”的目的。“能控”的意义在于IT运维不仅具备服务提供的能力，而且具有服务战略规划的能力。

 

图2 渐进式实施ITIL流程图

 

    第二种ITIL实施方式被称为爆发式。图3显示的情形也曾在一些IT部门使用过，但效果很差。其中有管理的问题，也有执行的问题，但最根本的原因在于当条件不成熟的时候，一锅端的实施方式不适合ITIL。

 

 图3 爆发式实施ITIL流程图