400-8615-123 最近有不少客户因为想了解 ITIL，注册了 Servicehot ITSM 系统。他们当中有的对 ITIL 已经很熟悉，有的还不太了解。这篇文章就请 Servicehot 的顾问，用通俗的方式把 ITIL 讲一讲。
很多企业在运维管理过程中都会遇到各种问题。比如觉得运维太乱，好像什么事都跟自己有关——这其实说明业务对运维的依赖已经形成，是好事，但“乱”肯定不是好事，需要梳理服务目录、制定事件分类。又比如机器太多管不过来，没时间盘点，也顾不上哪些设备过了维保，这就需要建立配置管理数据库，按资产属性搭建生命周期管理流程。ITIL 被称作运维管理的“圣经”，不是没有道理。
无论引入哪种管理方法，前期的观念转变都很重要。新理念要让人接受，需要实践去证明。体系设计时，总会有一些持怀疑态度的人，但恰恰这些人的参与对后续执行很重要。所以顾问在推动 ITIL 落地时，常常要和这些同事反复沟通。其实不必过于纠结，等体系真正跑起来一段时间，效果自然会说明问题。在此之前，只要先理解下面这五点，就容易达成共识。
第一，ITIL 是一种方法论。ITIL，即 IT 基础架构库，汇集了国际大公司在 IT 服务管理中的经验，是经过验证的 IT 服务计划和运营最佳实践框架。从上世纪 80 年代末至今，ITIL 已经推出三个版本，相关标准也从 BSI15000 发展到 ISO20000。运用 ITIL 时要注意两点：一是 ITIL 是实践总结出来的，不是僵化的教条，要结合企业实际情况建立适合自己的流程规范，而不是照抄照搬；二是 ITIL 体系庞大，不可能短期内全面实施，应该选取重点，逐步实施、逐步完善。简单说，做 ITIL 要实事求是，理解核心理念，结合企业现状解决关键问题。
第二，实践是检验真理的唯一标准。ITIL 理论必须和实际情况结合，注重流程细节的设计和优化。在制定工作流程时容易走两个极端：一是盲目照搬流程，结果流程不切实际、流于形式；二是把现有手工作业原封不动电子化，虽然符合现有习惯，但解决不了老问题。比如我们实施中遇到过“工单在部门之间重派”的情况：手工作业时，不属于本部门的工单要提交给负责人转派，目的是让负责人了解进度；建立系统后，负责人随时能查到处理状态，每次转派前的回复就成了无效工作，反而降低效率。所以把 ITIL 和实际结合、优化流程细节，是系统建设的关键。
第三，从被动服务转向主动服务。传统运维给人的印象是：故障发生前，维护人员好像没事做；故障发生后，又手忙脚乱。这就是被动服务的典型状态。新运维系统要改变这种模式，让运维人员主动监控系统变化，故障处理完成后主动做问题分析，对变更风险进行评估。日常运维中变更不可避免，比如系统出现安全漏洞需要打补丁，但补丁本身可能带来新的问题。没有风险防范手段，变更会带来大麻烦。因此要建立变更管理流程，变更方案先提交变更经理，由变更顾问委员会（CAB）做风险评估，通过后再实施。主动服务是一种理念，可以延伸到问题管理等更多流程，提前发现风险和隐患，减少突发事件。
第四，从平台管理延伸到业务管理。网络管理是运维系统的一部分，以往网管系统主要监控平台，但业务人员更关心业务系统。业务是建立在平台之上的，两者不能割裂，监控时要建立平台与业务的关联。比如某台交换机异常，除了看到交换机告警，还应该在业务拓扑图中看到哪些业务系统受到影响、影响程度如何，并用不同颜色直观展示。这样运维人员在故障发生时能快速定位关键部件，减少损失。
第五，绩效考核要以 KPI 为导向。KPI 直译是关键绩效指标，但更应把它当作建立压力层层传递的指标体系的方法。比如制定了变更管理流程，如果执行流于形式，风险防范就是空谈。所以需要建立科学的考核制度。考核不能就管理论管理，要从客户角度出发。假设用户投诉需要多部门协同处理，各部门互相推诿，虽然每个部门停留时间都没超承诺时限，但整体处理时间已经超了。要杜绝这种情况，就应该按用户视角对各部门处理时间分段计算，结果反映在每月故障处理统计报告中，并直接和各部门绩效考核挂钩。这样的机制既能调动员工积极性，也能提高工作效率和服务质量。
