特别专题

ITIL源自英国，是一套IT服务管理的最佳实践方法，有对应的认证考试、认可度高。

ITIL在世界范围内被广泛采用，国内许多企业的IT运维流程和运维软件都依据ITIL作为标准。

一、目标背景

IT服务的目标是为企业和客户创造商业价值。

相应的，ITIL通过行之有效的办法提高IT服务质量和效率、降低成本和风险，从而实现上述目标。

随着业务对IT依赖性的不断增加，IT设施、技术和服务已经广泛的成为商业运作的载体和途径，因此“创造价值”并非空话。

遗憾的是很多企业还未意识到这一点。

其中固然有IT投资回报不好衡量的原因，更主要的还是观念上存在误区：

其一是不理解IT和业务的关系，把IT定位为只会花钱、没有产出的部门；

其二是认为IT服务（运维）只是接接电话、处理一下用户问题，却看不到配置、知识、可用性、安全等方面管理的重要性。

二、主要内容

身边不少朋友即使培训完、拿到证也不明白ITIL究竟说了什么，这里我有一个通俗的解释：

ITIL描述了任何一种IT服务从产生、运行到退役需要经历的阶段，各个阶段需要做的事（即流程），以及由什么人来做（即职能）。

ITIL的主要内容是流程，2011版的关键流程如下：

服务战略：IT服务战略管理、IT服务财务管理、服务组合管理、需求管理、业务关系管理；

服务设计：服务目录管理、服务级别管理、容量管理、可用性管理、IT服务连续性管理、信息安全管理、供应商管理、设计协调；

服务转换：变更管理、服务资产和配置管理、发布与部署管理、知识管理、服务验证与测试、变更评价、转换计划与支持；

服务运营：事件管理、故障管理、请求履行、访问管理、问题管理；

持续服务改进：七步改进流程。

三、实践启发

ITIL结构完整、内容丰富，涉及IT服务的方方面面。本文篇幅有限，仅从IT管理实践的角度谈谈几点启发。

1、关注一个库的建设。

这个库通常被称作“服务知识管理系统”或“知识库”，包括配置项（如软件、硬件、数据、文档、配置信息）、配置项关系、财务资产、信息（如背景资料）、知识（如经验、想法、决策）、智慧（如大数据分析）等。

如果一个企业的IT服务和业务经营紧密结合，那么这个库就会成为企业的核心资产。

2、关注性能、可用性、安全管理。

这三个指标在开发项目中统一称为“非功能性需求”。性能主要指快不快；可用性指服务可以正常使用的时间；安全性是指信息不被窃取、服务不会因恶意攻击而不可用。

事实上除非发生问题，用户通常不会意识到、也不会特别声明这些需求。开发团队和运维团队应当主动考量这三项指标，否则将对用户体验、业务运营造成不良影响。

企业实践中往往以运维团队为主承担相应的管理职责，原因如下：

其一是项目的临时性特点，项目完成后开发团队离场，以运维团队为主向用户提供服务；

其二要做好性能、可用性、安全性管理，需要在代码、中间件、操作系统、服务器、存储、网络设备、供电系统、机房、管理流程等多方面进行协同。

然而实际工作中缺乏经验的管理者常常会忽视性能、可用性、安全管理或重视不足。

3、开发团队、运维团队应紧密合作，共同为企业和客户创造价值。

ITIL描述了IT服务的全生命周期，其中许多流程（如需求管理、业务关系管理、供应商管理、变更管理、配置管理、发布管理等）和项目管理是一致的。

在如今敏捷、迭代开发背景下，项目建设和运营长期并行已成为现实，ITIL本身也加入了更多的项目管理思想。

IT服务的产生、更新、运行需要开发团队和运维团队的通力合作，但往往两个团队的目标并不一致。开发团队希望更多的交付，运维团队想要稳定的运行。

我见过最糟糕的做法是：尽管开发团队承担了大部分运维工作，运维团队仍然认为自己是“受害者”，要求“管理”开发团队，让开发团队汇报各项工作、获得运维批准并承担全部责任。

目前流行的DevOps是应对这一问题的有效方式。

DevOps是一种文化转变，它鼓励开发、测试、运维人员不再局限于自身的角度，而把焦点放在整个系统上，每个人都对系统负责并承担后果。

DevOps倡导采用理解工作流程、不向下游传递缺陷、自动化基础设施、自动化部署、快速试验和失败等思维和方法来加强开发、测试、运维人员间的沟通与协作。

需要注意的是，DevOps的实施需要从文化、制度等方面进行配合才可能成功。