如何用5段话把 ITIL 讲清楚
学习资料：IT运维管理社区专家讲堂直播300期视频回放大多数企业在运维管理的过程中会遇到这样那样的问题，比如：运维太杂乱了，感觉任何事情都跟自己有关！这就对了，说明用户对运维组织的依赖性已经存在了，这是好事！但是杂乱显然不是好事，所以需要我们梳理服务目录以及制定事件分类。
再比如：这么多机器要管，我哪有时间去做盘点，还要时刻关注有没有过了维保的设备。这就需要我们建立配置管理数据库，根据配置的资产属性搭建资产的生命周期管理流程，结合数据库这项技术自身的特点，汇总统计分析也就不在话下......相信世界的实践，ITIL被誉为运维管理的圣经，并非浪得虚名。
无论哪一种管理被导入到一个企业的前期，思想都是最重要的一个环节。一种新的理念要被相信，是需要实践去证明的，在我们做体系设计时，一些“异己分子”总是抱着怀疑的态度和眼光，但往往能参与设计的“异己分子”却是体系执行时比较重要的环节，所以大部分咨询顾问在做ITIL实施落地时，需要与这些同事你来我往，唇枪舌剑。其实大可不必，在体系真正落地之后运转一段时间，真理即被检验！在这之前，不管是咨询顾问还是ITIL小白，只需要知道这五点，就可能让我们达成共识。
一、ITIL是一种方法论而已
IT基础架构库（ITIL-ITInfrastructureLibrary），被誉为IT服务管理的圣经，其中包含了总结国际大公司在IT服务管理中的经验并得到证明的IT服务计划和运营的最佳实践框架。从20世纪80年代末期至今，ITIL已推出3个版本，从相关标准上，也从BSI15000发展到ISO20000，它的指导意义毋庸置疑。
作为众多国际大型企业成功实践的积累，ITIL使我们找到了解决运维流程规范的方式和方法。可是，如何更好地运用ITIL这一经典的方法论呢？我们认为应该注意两点：
1.ITIL是从实践中得来的精髓，不是僵化的教条，应该结合实际情况去运用ITIL，建立更加适合企业自身的流程规范，而不是照抄照搬。2.由于ITIL理论博大精深，不可能在短期内在企业中全面实施。应该根据实际情况，选取实施重点，逐步实施，逐步完善。
实际上，只是强调一点，我们做ITIL应该讲究实事求是，结合企业的实际情况，理解、运用ITIL的核心理念，结合企业现状，解决核心和关键问题，逐步实现对运维的科学管理。
二、实践是检验真理的唯一标准ITIL理论必须要与实际情况相结合，注重工作流程细节的设计和优化，是体系建设的关键。理顺工作流程、提高服务效率是新运维系统建设的主要内容之一。
在工作流程的制定过程中，容易陷入以下两个极端。
1.盲目照搬流程。作为方法论的ITIL，本身含有大量的成功实践框架。但是，正如前面所说的，ITIL是从实践中得来的精髓，不是僵化的教条，盲目照搬，只能使得工作流程不切合实际，并流于形式，对系统的贯彻和执行产生不好的影响。2.完全遵照现有流程，实现其电子化。虽然这样更符合目前的工作习惯，可能容易为运维人员所接受，但是，仍然解决不了目前运维所存在的一些问题。例如，我们在项目实施中曾遇到“工单在部门之间的重派”的问题。在当前手工作业的工作模式中，各单位将不属于本单位处理范围的工单，或部门需要其他部门配合的工单，均提交给故障处理的负责人，由该负责人向其他单位进行转派和重派。这种处理方式，主要便于手工作业条件下负责人及时了解项目处理状况。在建立运维系统后，负责人可以通过运维系统随时了解到故障的处理状况，每次重派和转派之前，对负责人的回复变成了一种无效的工作，大大降低了事件的处理效率。如果仅仅将目前的手工作业电子化，那么故障处理的效率仍然没有得到有效的提高。
因此，将ITIL理论与实际情况相结合，注重工作流程细节的设计和优化，是系统建设的关键。
三、从被动向主动的转变从被动向主动式的运维一直是所有运维团队共同的愿望。在现行的运维工作中，我们经常遇到这样的情况：一方面是运维部门疲于应付各种突发事件，加班加点处理各种重复事件，工作繁重，身心疲惫；一方面是客户代表不断抱怨和投诉“技术人员服务水平太低”。二者不可调和的矛盾，是新运维系统要解决的重要问题。
传统的运维方式给人的印象是：故障发生前，维护人员似乎无所事事；故障发生后，则是手忙脚乱。这就是被动服务给人们留下的印象，运维人员是在被动地等待故障的发生。在新的运维系统中，我们必须改变原有的运维方式，变被动服务为主动服务。
在主动服务模式下，运维人员主动地监控系统的变化，对日常工作及故障处理完成后主动进行问题分析，对系统的变更风险进行评估。在新运维管理模式中，可以通过种种技术措施，使得运维工作从被动服务转移到主动服务，如：增加变更管理流程以防范变更风险。
在日常运维工作中，变更工作是在所难免的。例如，新的系统安全漏洞被公布，为了保证系统安全，就需要安全系统补丁，而这种变更给系统带来的风险则是难以估计的。例如在安装补丁后，有时会产生大量莫名其妙的问题。这么一个简单的例子已经可以说明，如果没有很好的风险防范手段，系统变更将给我们的日常运维工作带来大量的问题，后果往往是难以想象的。在新系统中，我们可增加变更管理流程。在变更管理流程中，变更方案需提交变更经理，由变更经理组织由专家组成的变更顾问委员会（CAB）对变更进行风险评估，在评估通过后才能够进入变更的实施过程。变更管理是防范变更风险的最好办法。
当然，主动服务是一种理念，在这种理念下，我们可以定义更多的流程，如问题管理流程，对系统中存在的隐患问题进行挖掘，防患于未然。总之，我们应该树立这样一个理念，在各流程的定义中进行运用，主动地提早发现系统存在的风险和隐患，减少突发事件的发生。
四、从平台到业务的全面管理网络管理是运维系统的组成部分。对系统的监控也是运维的主要业务之一。以往网管系统实现了对平台的监控，可是在实际运维工作中，平台往往只有少数的几个系统管理员负责，大多数业务人员更多地是面对业务系统。对于业务的监控和管理，是业务人员更加关心的问题。因此，在网管系统中，应加入业务监控的内容。
需要注意的是，业务是建立在平台的基础之上的，而不是孤立存在的。因此，监控中，应强调业务监控与平台监控密不可分的联系，从业务的角度出发，建立平台与业务的关联关系。在故障发生时，应能够即时描述对业务的影响程度，能够描述故障的影响范围。
例如：采集源的某台交换机产生异常，除了可以看到交换机告警外，我们还应该能够在业务拓扑图中直观看到，还有哪些基于这些网络的业务系统受到影响，同时采集、预处理、分拣等相关业务也不同程度受到影响。其影响程度，能够通过不同的颜色直观地展示出来。
只有这样才能够更加直观而全面地反映系统的运行状态，反映业务的运行情况。能够帮助运维人员在故障发生时，快速修复关键部件，减少故障带来的损失。
五、绩效应以KPI为导向提到KPI，不仅仅是工程师，甚至很多管理者都会误入考核的误区。好吧，KPI（KeyPerformanceIndicator）的直译确实是关键绩效指标。但我们更愿意把它当做一个方法，一个建立压力层层传递的指标体系的方法。
假设：我们制定了变更管理流程，但是，变更管理没有被很好地执行，而只是流于形式，则风险的防范也只能是停留在理论上的空谈。所以，在运维系统建设过程中，建立了一整套科学的考核制度，以激励运维人员更有效地提高服务质量和服务水平，是至关重要的。
对运维人员的考核，并不能就管理论管理，应该从客户服务的角度出发，以客户满意为前提，进行考核。例如，根据每个部门的服务水平，制定了服务时限。假设，某个用户投诉，需要多个部门协同进行处理。在处理过程中，各部门互相推托，虽然工单在各部门的停留时间没有超过部门承诺的时限，而整体处理时间已经超过了运营商对该用户承诺的处理时间。为了杜绝这种现象的出现，我们应该从用户的角度出发，进行各部门处理时间的分段计算。计算结果将反映在每月故障处理情况的统计报告中，而这些报告直接与各部门、各单位的绩效考核挂钩。
通过这样的考核机制，形成对员工日常工作的科学评价，既调动了员工积极性，又提高了工作效率和服务质量。
同样，考核机制的建立也需要依据实际出发，并不能一味考虑指标，更重要的是设计出来的指标能不能起到改善提升的作用。
以上，是一些在ITIL实施之前，或者说我们需要做ITIL之前的一些基本的思想观念，也是在实际中总结出来的一些经验，个人认为值得与大家分享，更愿意以此引发讨论。
不管ITIL到底是什么，对于大多数企业而言，它的必要性显而易见：它能够帮助IT部门提高用户的满意度和运行效率，“有了ITIL后，我们能够在任何时间点评估我们的成果。”（ITIL之家）
页:
[1]