ITILv3与ITILv2的差异和其带来管理变革
ITILv3于2007年5月由OGC正式推出，意味着一直被奉为IT运维管理“Bible”的IT服务管理最佳实践和方法论进入了一个新的历史阶段。那ITILv3和一直风靡了很久的ITILv2有着什么样重要的差别，或者说是进步呢？ITILv3能给我们的IT运维管理带来怎样的变革呢？根据我这些年来对于IT运维管理领域的实践和对于ITILv3的学习，总结了以下几点，供同行参考。
1. 从整理架构上，ITILv3和ITILv2最大的改变是，ITILv2是条块化的模块架构，每个流程之间虽然都有关联，但总体是更加着重突出每个模块在IT运维管理中的职能，如变更管理、问题管理、突发事件管理和帮助台。而ITILv3是圆形的闭环架构，其强调的是生命周期的管理，也就是任何一个大模块，如服务战略、服务设计、服务转换和服务运营都是一个从建设到运营到持续改进的过程。各个子模块，如在服务战略中的服务组合设计、服务设计中的容量管理、可用性管理以及服务转换中的发布和变更管理每一个流程都是一个小的闭环，从设计到转换，到运营到改进。
2. 从流程模块和内容的分布上，ITILv2是大家所熟悉的最为经典的10个流程，包括IT支持领域的突发事件、问题、变更、发布、配置和IT交付领域的容量、可用性、服务持续性、服务级别管理以及财务管理。而ITILv3则根据每个模块在IT服务生命周期中的位置重新进行划分和补充。
a) ITILv3中的服务战略模块中包括了服务组合管理和财务管理。IT服务的组合管理，也就是根据企业业务的战略确定IT服务的组合和交付支持要求，这在ITILv2中是非常缺乏的。每个模块似乎都是独立生成，与业务要求没有密切关联。这也是导致很多IT服务流程的设计与业务脱节的重要原因。在ITILv3强调了从营销学的Mindset来考虑我们的IT服务的价值和战略：
What is our business?
Who is our customer?
What does the customer value?
Who depends on our services?
How do they use our services?
Why are they valuable to them?
如果能够很好的回答出上述的问题，其实IT的服务战略和服务组合就比较容易确定了，不再是孤立的，自我意识的。如何定义服务，ITILv3中又是从4P的角度的方法,他们分别是perspectives, positions, plans and patterns。其实，这部分是MBA课程里面经常会提到的管理学概念，在制定IT战略时，一样非常具有参考意义啊。
b) ITILv3种的服务设计模块中包括了服务目录管理、服务级别管理、风险管理、容量管理、可用性管理、IT服务持续性管理、IT安全管理、合规管理、IT架构管理和供应商管理。其中，服务目录管理从ITILv2的服务级别管理中独立出来，作为一个单独的子模块，其旨在突出服务目录独立于服务级别管理的特征。服务目录应当是完全根据用户的需求产生的，也就是反映用户对于系统原始的要求和想法。而服务级别的最终制定要根据IT系统的能力、服务目录、供应商的能力等一系列因素而定。同时，我们也看到，风险管理和IT安全管理分别被单独列出来，不再放在ITILv2的可用性管理中，这充分说明了风险管理和IT信息安全管理的独立性。
这两项都是贯穿于整个IT服务管理的重要管控流程，而不是只是和系统的可用性相关的流程。此外，大家可以看到IT的架构管理，这部分在ITILv2是未被提及的，如果服务组合管理一样，IT架构管理恰恰是IT运维管理到一定的成熟度之后必须配备的流程。最后，供应商管理也被ITILv3单独列出来，其实在ISO20000中，供应商管理和客户关系管理都是被作为13个审核流程中重要的一个模块被独立出来的，只是ITILv2并不包含这部分内容。虽然，在ITIL中4P作为IT服务管理最为经典的总结早就被同行广为传播，Process, Product, Partner, People，但Partner的管理直到ITILv3才被独立出来。此外，在我研读ITILv3时，我发现的最让我觉得印象深刻的地方，就是服务设计几乎把ITILv3种所有流程模块的策略、实施原则、实施方法、实施计划、测试标准、验收标准、运营规范、持续改进要求等都在设计流程中全部完成。因此，我们会发现，对于IT服务规划最为关键的部分起始就是服务设计模块，后期的流程只是执行。
c) ITILv3中的服务转换模块中包括了变更管理、发布管理、配置管理以及知识管理。我们不难发现，作为ITILv2和ISO20000中最为重要的服务控制模块的变更，发布被v3中独立成一个大模块。这个大模块旨在告诉和指导IT组织如何去来发布一项新的服务，如何将其从研发阶段转换到生产阶段，如何控制其中的风险，如何衡量转换的成功，如何让用户来了解，接受和验收这项服务。其中，整个发布特别提到了要用项目管理的方法去来运作，我们的发布经理通常是这个服务的项目经理，负责从设计、研发、测试到上线的所有过程。我又惊喜的发现，在v3中我们的变更管理不再只是一个RFC的概念，而是通过Change Proposal，基于7R的方式去来提出和审核一个变更。也就是我们的变更管理不再只是控制上线的那个动作，而是管理到变更的原因和变更上线后收益的整体过程。我个人认为这一点是v3重要的进步。
1. Who RAISED the change?
2. What is the REASON for the change?
3. What is the RETURN required from the change?
4. What are the RISKS involved in the change?
5. What RESOURCES are required to deliver the change?
6. Who is RESPONSIBLE for the build, test and implementation of the change?
7. What is the RELATIONSHIP between this change and other changes?
d) 而知识管理这部分，在ITILv3中也体现的特别淋漓尽致。大家都非常熟悉配置管理，其中每一项CI都会反映一个配置项的具体信息，包括和这个配置项相关的Incident，Problem，但基于这些信息，如何提炼出知识来指导我们的运营管理，越来越被IT服务管理领域的同行所关注。其实，近期我们在自行研发的IT智能运维管理平台是知识管理理念的最好体现。如果说我们原先使用的IT系统监控和管理平台是IT系统的ERP的话，那未来的智能数据分析平台就是IT系统的BI。如果没有这个BI平台，我们将面临运维管理信息分散，信息关联度差和设备的平均利用率低。根据专业机构评估报告：NT服务器的平均利用率<10%，UNIX服务器CPU的利用率<20%。如果通过数据挖掘，我们可以实现跨平台数据采集和多纬度的数据挖掘，如资源使用率的信息、故障和问题的统计、安全事件的统计、资产生命周期的展现等等。从而使我们对于IT系统的管理有更加明确的改进和优化的方向。相信这个理念是ITILv3所倡导的。
d) ITILv3中的服务运营模块中，包括了事件管理、故障管理、服务请求管理、访问管理、问题管理、IT运营管理和辅助设备管理。这个大模块中，我们熟悉流程的同行一下子就能看出来，原来在ITILv2中被合为一个子流程的事件（event），故障（incident）和服务请求（Service Request）现在被分成了3个子流程。我想这是管理进化的自然结果，从我接触ITILv2我就认为把不对服务产生影响的event和服务请求放在故障处理流程中去来统一管理，是有问题的。因此，很多企业早也已经在实际操作中，把这几个流程分拆。其次，访问管理原先在ITILv2中是可用性管理中安全管理的一部分。由于访问安全是运营管理中非常重要的一部分，因此v3将其单独拿出来。此外，辅助设备管理也是通常会被人忽略的IT机房保障的管理，在v3种这部分得以完善。同时，在v2中最主要的支持类流程全部在v3 的这个模块中体现。配置管理是贯穿于所有流程的，因此在v3中没有单独纳入服务运营模块。
e) 持续服务提升。这部分内容也是ITILv3最为精华的部分。包括定义监控需求、定义数据收集需求、内部达成共识、决定数据监控的频率、确定数据监控的方法、确定监控工具的使用、制定流程监控计划和实施监控计划。本质上就是PDCA（戴明环）的过程，就是Plan -〉Design -〉Check -〉Action。对于IT服务管理中涉及到的任何一个流程，都需要运用这个模块来进行持续改进，才能确保IT服务管理最为高效、实用和适用。在这个模块中，很多改进的工具被详细阐述，如6西格玛、 Cobit, PrinceII、CMMI、价值流映射（Value stream mapping）、完全质量管理（TQM）等等。在实际的流程改进过程中，很多企业其实都在做，只不过形式不同，比如以QA或者流程改进小组模式进行，每年确定流程改进计划，确保流程的完整性和可用性。当然，在具体的改进点的广度和深度上，我们要考虑IT服务战略、服务设计、服务转换和服务运维中所有的流程，同时需要运用更多的工具和方法，使其改进点的收益更加明显。
总体来说，随着ITILv3体系的问世，中国企业的IT运维管理体系也将随之产生很大的变革。从原来的更关注IT本身，转为更关注与业务的融合，通过体现业务的价值实现IT的价值；从原来对于服务管理流程的模块化管理，转为对于服务管理的生命周期管理，从而实现闭环式的持续优化；从原来重点关注运行维护，转为更加关注前期的设计和开发，从而实现从源头上管理和控制风险；从原来更加关注IT服务的功效（Utility），转为同时关注功效（Utility）和能效（Warranty）。 这些都将给IT服务管理的理念和实际操作带来巨大的变化。 撸过 我也是坐沙发的
页:
[1]