ITIL的局限性(ISO20000)
由于公司建设ITSM系统的需要,开始接触ITIL理论,学习的来源多来自于一些文档、书籍及网上的资料,随着理解的深入,越发觉得ITIL有相当的局限性。尤其当公司人人对ITIL奉为圣旨时,就更加担心我们自身会走入一个误区,我总相信没有一种管理理论可以为一个公司带来质的飞跃。
对所谓的流行理论,我个人一直抱有相对冷淡的立场,比如近来喊得比较多的蓝海战略之类,其实本没有任何新意。德鲁克在五十年前就已提出来了,一个公司卓越的管理不会来自于外部,而只会来自身,无论GE还是微软,亦还是新近的GOOGLE,他们的管理并非产自外部的理论与顾问,而是务实科学的看待自身,同时具备永争第一的创新的精神。
ITIL的产生根源是英国的国家电信局的IT服务水平不高,所以英国人找了一大帮顾问与专家来寻找方案,最后ITIL这个副产品就诞生了,如果说ITIL是最佳实践,我仍是抱有怀疑,我相信,就在这一刻,2007年英国的国家电信局的IT服务水平并非如人们想象的那么高。
管理上一直有这样一个问题,一个企业成功后,人们可以总结分析出一种模式与要素,或者得出一个理论,应该说个理论就是实践中得来的吧。但是如果你用这个理论去应用在别的企业上面,往往是失败的,这与很多企业与个人想复制成功经验而失败的道理是一样的,象举世闻名的波特矩阵,有任何一个企业是依靠它而发展壮大的么?
我怀疑,我想戴尔在大学宿舍组装电脑时,比尔盖茨在决定创办软件公司时,他们是不知波特矩阵为何物的,但是奇怪的是很多企业的成功用波特的矩阵去解释,是很有道理的,这也是为什么现在这么多所谓的顾问整天在电视上瞎掰的原因。所以这是一种奇怪的现象,许多管理的理论都是事后解释的作用,无法起到指导功能的作用,这方面的,我严重同意明茨伯格的观点,管理很多时候是不可复制的,它是许多个人、经验、科学、智能混合物,它不是科学,甚至连应用科学也算不上,但它绝对有着不少的科学成分在内。
在每一份畅销的时尚杂志背后,都有着不少商业品牌在背后,它们提供着资金,让这些杂志虚夸出一种时尚明亮的生活方式,让全世界追求浪漫的女人们梦幻地向往着,然后这些象征着这种生活方式的物品,被源源不断从商场运回家,这些东西意味着身分、品位,满足着人们的心理需求。而这些心理需求却是由提供这些物品的公司所营造出来的,而一切运作又是那么的和谐。
举这个例子是因为它足够典型,我们再想想现在的一大批的顾问公司,那些在网上、书籍、现实中不断鼓吹ITIL理论或其它理论的,都是可以提供这种服务的人,有时他们甚至不如那些时尚品的公司,因为自己的产品有时都没有搞清楚,我相信,在中国能把ITIL的核心并联系实务讲明白的人不会超过20人,但ITIL的繁荣却是蒸蒸日上,一如九几年的ISO9000。说这些并非是说我们不应该以ITIL为指引去改进我们自身,ITIL将成为一种标准这是大势所在,当IBM、HP、Microsoft这些庞然大物在造势搅局时,我们能做的是非常有限的,只顺应大势,ITIL也有相应的正面作用可以调用,只是我们得冷静克制的看待这些背后的东西,不能一骨脑儿全扎进去了。
对于ITIL我认为最大的作用,就是标准的作用,无论是这个标准多好还是多坏,它是标准了,这就会带来许多正面的作用,标准的作用在于,它规范了交流沟通的语言与定义,让全世界能操着同一种术语进行交流改进,它规范了一些常见的流程,让全世界的ITIL服务者用同样的方式去作业,这对于人才的交流与整体知识的提升是非常重要的,这种标准如果应用得好,会让每一个ITIL服务公司的组织架构与岗位设立大同小异,人员的要求与知识构成也是如此,这对世界而言是一件大大有益的事情。
ITIL其它的好处我就不一一叙述了,因为太多的资料有着类似的说明,我更愿意探讨是ITIL的局限性或者说缺陷有哪一些,以便我们日后在引入时如此吸其精华,弃其糟粕。
一、配置管理
配置管理涉及IT基础架构中所有组件,以及各组件之间的关系,配置管理需要对它们进行标示、记录、报告、审计等活动,包括软件、硬件和相关文档,配置管理是通过规划CI项及定义CI项之间的关系而实现管理的,但是这些CI项如何规划?这样CI项的关系又如何定义却ITIL没有进行相应说明,当连那些所谓的ITIL专家都在为配置管理抓头时,就需要思考是否是理论本身存在残缺了。
CI项如何进行规划的一个悖论在于,它的“颗粒”度过大,则达不到管理的需求,比如只是单单的把一台服务器作为一个CI项进行管理,这种管理是没有现实意义的,如果“颗粒”度过小,又需要付出极大的代价去负责收集与维护,因此而换来的收益是却是有限的,比如将服务器内的每一个软件组件都作为CI项进行管理,然后需用构建每一个CI项的关系,在CMDB中20%的是记录CI项的信息,其余80%是记录CI项之间的关系,可以想象当配置管理的“颗粒”度过小时,需要构建这些关系是多么不现实,现实中没有什么事情是不可能的,只要投入足够多的资源是可以做到的,我们这里说的不现实是投入的资源会严重超过收益。
通过在 CMDB 中创建配置项目关联的方式对 IT 组件之间的关系进行建模。每当建议对某个配置项目进行调整时,即可利用这些关联分辨出将会受到变更影响的配置项目,最终制定出足以涵盖所有可能性的自动识别规则,做到事前与事后的分析,事前分析:倘若某个 DNS 服务器的 Internet 协议(IP)地址发生变化,就应对依靠这台服务器执行名称解析的所有客户端的 DNS 解析程序设置做相应调整。如果 DNS 服务器与其客户端之间的关系未被存储于 CMDB ,那么,某些客户端便有可能被遗漏,并因此无法访问网络资源。如果“颗粒度”足够细,我想在一台服务器上加载一个JAVA小程序,CMDB都可以告诉我,可以还是不可以,但因此我需要在CI项规划及关系建模时,还有日后的变更维护付出巨大的代价。
在现实中,尤其是当软件项目较多时,并且与网络及桌面业务交*时,配置管理将是一种极具挑战的事情,先不说关系的构建多么复杂,光是软件项目的CI项规划都是非常困难的事情,在许多的运维项目中,尤其是软件项目,通常的做法是把整个项目当成一个CI进行管理,这样的配置是没有多少管理及统计意义的,但如果要深入进行管理,软件项目组件包括相应的硬件(服务器),包括各种程序接口,包括各个分布在不同物理位置或组织的服务器、主程序、接口程序、数据库,这些都只是一级比较大颗粒度的组件,如何再进行细化才能做到当事件发生时自动分析预警?有没有怎样的原则及要求?每一个CI项的关系到底有多少种?需要如何的角度构建?这些统统是ITIL留下的巨大理论空白。
当没有不知配置如何规划,关系如何构建时,配置就是空谈,由于这种现状,我们公司基本上是独立完成这些工作,尤其在配置的结构与关系上,做了比较大胆的尝试,由于目前软件尚未布署,具体的功效还没有得到有效的验证,比较让人失望是中国ITIL业内的所谓专家与顾问公司,我们也接触了两家号称中国顶尖的ITIL咨询公司,但与专家交流后,让人失望,当前以国内顾问公司的专业水平与职业操守,我敢断言,明天的ISO20000咨询现状将会成为现在的ISO9000。
|