|
大多数企业在运维管理的过程中会遇到这样那样的问题，比如：运维太杂乱了，感觉任何事情都跟自己有关！这就对了，说明用户对运维组织的依赖性已经存在了，这是好事！但是杂乱显然不是好事，所以需要我们梳理服务目录以及制定事件分类。
再比如：这么多机器要管，我哪有时间去做盘点，还要时刻关注有没有过了维保的设备。这就需要我们建立配置管理数据库，根据配置的资产属性搭建资产的生命周期管理流程，结合数据库这项技术自身的特点，汇总统计分析也就不在话下......相信世界的实践，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（Key Performance Indicator）的直译确实是关键绩效指标。但我们更愿意把它当做一个方法，一个建立压力层层传递的指标体系的方法。
假设：我们制定了变更管理流程，但是，变更管理没有被很好地执行，而只是流于形式，则风险的防范也只能是停留在理论上的空谈。所以，在运维系统建设过程中，建立了一整套科学的考核制度，以激励运维人员更有效地提高服务质量和服务水平，是至关重要的。
对运维人员的考核，并不能就管理论管理，应该从客户服务的角度出发，以客户满意为前提，进行考核。例如，根据每个部门的服务水平，制定了服务时限。假设，某个用户投诉，需要多个部门协同进行处理。在处理过程中，各部门互相推托，虽然工单在各部门的停留时间没有超过部门承诺的时限，而整体处理时间已经超过了运营商对该用户承诺的处理时间。为了杜绝这种现象的出现，我们应该从用户的角度出发，进行各部门处理时间的分段计算。计算结果将反映在每月故障处理情况的统计报告中，而这些报告直接与各部门、各单位的绩效考核挂钩。
通过这样的考核机制，形成对员工日常工作的科学评价，既调动了员工积极性，又提高了工作效率和服务质量。
同样，考核机制的建立也需要依据实际出发，并不能一味考虑指标，更重要的是设计出来的指标能不能起到改善提升的作用。
以上，是一些在ITIL实施之前，或者说我们需要做ITIL之前的一些基本的思想观念，也是在实际中总结出来的一些经验，个人认为值得与大家分享，更愿意以此引发讨论。
不管ITIL到底是什么，对于大多数企业而言，它的必要性显而易见：它能够帮助IT部门提高用户的满意度和运行效率，“有了ITIL后，我们能够在任何时间点评估我们的成果。”（ITIL之家） | 
转播
分享
淘帖
()