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。
转播
分享
淘帖
()
