首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

使用ITIL,思想先行

大多数企业在运维管理的过程中会遇到这样那样的问题,比如:运维太杂乱了,感觉任何事情都跟自己有关!这就对了,说明用户对运维组织的依赖性已经存在了,这是好事!但是杂乱显然不是好事,所以需要我们梳理服务目录以及制定事件分类。

再比如:这么多机器要管,我哪有时间去做盘点,还要时刻关注有没有过了维保的设备。这就需要我们建立配置管理数据库,根据配置的资产属性搭建资产的生命周期管理流程,结合数据库这项技术自身的特点,汇总统计分析也就不在话下......相信世界的实践,ITIL被誉为运维管理的圣经,并非浪得虚名。

如何实施和搭建ITIL的体系,我们会在以后逐步去讨论交流,今天倒是想说一说运维管理实施前思想需要统一这件事。事实上,无论哪一种管理被导入到一个企业的前期,思想都是最重要的一个环节。一种新的理念要被相信,是需要实践去证明的,在我们做体系设计时,一些“异己分子”总是抱着怀疑的态度和眼光,但往往能参与设计的“异己分子”却是体系执行时比较重要的环节,所以大部分咨询顾问在做ITIL实施落地时,需要与这些同事你来我往,唇枪舌剑。其实大可不必,在体系真正落地之后运转一段时间,真理即被检验!可是在这之前,不管是咨询顾问还是ITIL小白,其实只需要知道以下五点,就可能让我们达成共识。

一、ITIL是一种方法论而已

IT基础架构库(ITIL-ITInfrastructureLibrary),被誉为IT服务管理的圣经,其中包含了总结国际大公司在IT服务管理中的经验并得到证明的IT服务计划和运营的最佳实践框架。从20 世纪80 年代末期至今,ITIL已推出3个版本,从相关标准上,也从BSI15000发展到ISO20000,它的指导意义毋庸置疑。

作为众多国际大型企业成功实践的积累,ITIL使我们找到了解决运维流程规范的方式和方法。可是,如何更好地运用ITIL这一经典的方法论呢?我们认为应该注意两点:

ITIL是从实践中得来的精髓,不是僵化的教条,应该结合实际情况去运用ITIL,建立更加适合企业自身的流程规范,而不是照抄照搬。

由于ITIL理论博大精深,不可能在短期内在企业中全面实施。应该根据实际情况,选取实施重点,逐步实施,逐步完善。

实际上,只是强调一点,我们做ITIL应该讲究实事求是,结合企业的实际情况,理解、运用ITIL的核心理念,结合企业现状,解决核心和关键问题,逐步实现对运维的科学管理。

二、实践是检验真理的唯一标准

ITIL理论必须要与实际情况相结合,注重工作流程细节的设计和优化,是体系建设的关键。理顺工作流程、提高服务效率是新运维系统建设的主要内容之一。

在工作流程的制定过程中,容易陷入以下两个极端。

盲目照搬流程。作为方法论的ITIL,本身含有大量的成功实践框架。但是,正如前面所说的,ITIL是从实践中得来的精髓,不是僵化的教条,盲目照搬,只能使得工作流程不切合实际,并流于形式,对系统的贯彻和执行产生不好的影响。

完全遵照现有流程,实现其电子化。虽然这样更符合目前的工作习惯,可能容易为运维人员所接受,但是,仍然解决不了目前运维所存在的一些问题。例如,我们在项目实施中曾遇到“工单在部门之间的重派”的问题。在当前手工作业的工作模式中,各单位将不属于本单位处理范围的工单,或部门需要其他部门配合的工单,均提交给故障处理的负责人,由该负责人向其他单位进行转派和重派。这种处理方式,主要便于手工作业条件下负责人及时了解项目处理状况。在建立运维系统后,负责人可以通过运维系统随时了解到故障的处理状况,每次重派和转派之前,对负责人的回复变成了一种无效的工作,大大降低了事件的处理效率。如果仅仅将目前的手工作业电子化,那么故障处理的效率仍然没有得到有效的提高。

因此,将ITIL理论与实际情况相结合,注重工作流程细节的设计和优化,是系统建设的关键。

三、从被动向主动的转变

从被动向主动式的运维一直是所有运维团队共同的愿望。在现行的运维工作中,我们经常遇到这样的情况:一方面是运维部门疲于应付各种突发事件,加班加点处理各种重复事件,工作繁重,身心疲惫;一方面是客户代表不断抱怨和投诉“技术人员服务水平太低”。二者不可调和的矛盾,是新运维系统要解决的重要问题。

传统的运维方式给人的印象是:故障发生前,维护人员似乎无所事事;故障发生后,则是手忙脚乱。这就是被动服务给人们留下的印象,运维人员是在被动地等待故障的发生。在新的运维系统中,我们必须改变原有的运维方式,变被动服务为主动服务。

在主动服务模式下,运维人员主动地监控系统的变化,对日常工作及故障处理完成后主动进行问题分析,对系统的变更风险进行评估。在新运维管理模式中,可以通过种种技术措施,使得运维工作从被动服务转移到主动服务,如:增加变更管理流程以防范变更风险。

在日常运维工作中,变更工作是在所难免的。例如,新的系统安全漏洞被公布,为了保证系统安全,就需要安全系统补丁,而这种变更给系统带来的风险则是难以估计的。例如在安装补丁后,有时会产生大量莫名其妙的问题。这么一个简单的例子已经可以说明,如果没有很好的风险防范手段,系统变更将给我们的日常运维工作带来大量的问题,后果往往是难以想象的。在新系统中,我们可增加变更管理流程。在变更管理流程中,变更方案需提交变更经理,由变更经理组织由专家组成的变更顾问委员会(CAB)对变更进行风险评估,在评估通过后才能够进入变更的实施过程。变更管理是防范变更风险的最好办法。

当然,主动服务是一种理念,在这种理念下,我们可以定义更多的流程,如问题管理流程,对系统中存在的隐患问题进行挖掘,防患于未然。总之,我们应该树立这样一个理念,在各流程的定义中进行运用,主动地提早发现系统存在的风险和隐患,减少突发事件的发生。

四、从平台到业务的全面管理

网络管理是运维系统的组成部分。对系统的监控也是运维的主要业务之一。以往网管系统实现了对平台的监控,可是在实际运维工作中,平台往往只有少数的几个系统管理员负责,大多数业务人员更多地是面对业务系统。对于业务的监控和管理,是业务人员更加关心的问题。因此,在网管系统中,应加入业务监控的内容。

需要注意的是,业务是建立在平台的基础之上的,而不是孤立存在的。因此,监控中,应强调业务监控与平台监控密不可分的联系,从业务的角度出发,建立平台与业务的关联关系。在故障发生时,应能够即时描述对业务的影响程度,能够描述故障的影响范围。

例如:采集源的某台交换机产生异常,除了可以看到交换机告警外,我们还应该能够在业务拓扑图中直观看到,还有哪些基于这些网络的业务系统受到影响,同时采集、预处理、分拣等相关业务也不同程度受到影响。其影响程度,能够通过不同的颜色直观地展示出来。

只有这样才能够更加直观而全面地反映系统的运行状态,反映业务的运行情况。能够帮助运维人员在故障发生时,快速修复关键部件,减少故障带来的损失。

五、绩效应以KPI为导向

提到KPI,不仅仅是工程师,甚至很多管理者都会误入考核的误区。好吧,KPI(Key Performance Indicator)的直译确实是关键绩效指标。但我们更愿意把它当做一个方法,一个建立压力层层传递的指标体系的方法。

假设:我们制定了变更管理流程,但是,变更管理没有被很好地执行,而只是流于形式,则风险的防范也只能是停留在理论上的空谈。所以,在运维系统建设过程中,建立了一整套科学的考核制度,以激励运维人员更有效地提高服务质量和服务水平,是至关重要的。

对运维人员的考核,并不能就管理论管理,应该从客户服务的角度出发,以客户满意为前提,进行考核。例如,根据每个部门的服务水平,制定了服务时限。假设,某个用户投诉,需要多个部门协同进行处理。在处理过程中,各部门互相推托,虽然工单在各部门的停留时间没有超过部门承诺的时限,而整体处理时间已经超过了运营商对该用户承诺的处理时间。为了杜绝这种现象的出现,我们应该从用户的角度出发,进行各部门处理时间的分段计算。计算结果将反映在每月故障处理情况的统计报告中,而这些报告直接与各部门、各单位的绩效考核挂钩。

通过这样的考核机制,形成对员工日常工作的科学评价,既调动了员工积极性,又提高了工作效率和服务质量。

同样,考核机制的建立也需要依据实际出发,并不能一味考虑指标,更重要的是设计出来的指标能不能起到改善提升的作用。

以上,是一些在ITIL实施之前,或者说我们需要做ITIL之前的一些基本的思想观念,也是在实际中总结出来的一些经验,个人认为值得与大家分享,更愿意以此引发讨论。

最后

不管ITIL到底是什么,对于大多数企业而言,它的必要性显而易见:它能够帮助IT部门提高用户的满意度和运行效率,“有了ITIL后,我们能够在任何时间点评估我们的成果。”

ServiceHot ITSOM基于ITIL流程框架打造服务流程管理功能,能够满足企业对事件管理、问题管理、变更管理、发布管理、配置管理、服务级别管理的各种需求,帮助企业实现对运维服务质量、过程、技术和资源的全方位管理。结合企业的实际情况,ServiceHot理解、运用ITIL的核心理念,帮助其解决核心和关键问题,逐步实现企业对运维的科学管理。

  • 发表于:
  • 原文链接http://kuaibao.qq.com/s/20180321A0JIQR00?refer=cp_1026
  • 腾讯「腾讯云开发者社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 cloudcommunity@tencent.com 删除。

扫码

添加站长 进交流群

领取专属 10元无门槛券

私享最新 技术干货

扫码加入开发者社群
领券