标题: ITIL的局限性
学习资料： ITIL培训基地专家讲堂直播 300期视频回放
ITIL的局限性
由于公司建设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。
二、服务级别管理
ITIL的两个最核心的基石一个是配置管理，另一个是SLA管理，这是唯一度量指导我们服务水平的一个温度计。它是可以将我们的服务水平量化为数字，与客户进行商谈及交付。但是SLA的设立是基于什么原则？它与运维对象的关系是怎样的？它与服务目录的关系是怎样的？这些ITIL没有明确告诉我们。
SLA的设立在软件项目将是最为复杂的，目前比较流行的方式，是SLA根据关键的业务影响去定义，比如一个汽业系统销售管理系统的一个关键业务影响就是整车销售，整车销售这一业务影响又是由多种现象组成，如4S经销商无法采购，但是导致经销商采购不了车辆的因素众多，比如一个专营店的仓位设置有问题，或者车型分配有问题，单据设定有问题，分配设置出现问题都会导致此结果，采购在系统中只是一个流程中一个点，它又与众多的基础数据存在关联，又与其它的软件项目（银企）存在关联，它更多时间是一个结果，而不是一个表象，在这个结果出现前就会有许多的事件爆发，这些事件如何关联SLA时间？每一个事件可能导致多个业务影响，比如仓库基础数据设置出现了问题，即影响采购，又影响验收，又影响最终销售，此又是如何取舍？没有功能点是孤立的，它都会与众多的流程与业务应用有关系，事件发生时更多时候客户是无法预见最终的影响的，尤其是在用户群庞大时，这样会导致一个结果就是具体的事件无法与现在有的SLA进行关联，或者只能错误关联，最终会导致SLA是100%（即对时间约束性强的SLA不起作用），或者SLA的满足率很低（即将事件错误引导到业务影响之上），这样都无法真实反映服务水平，这样SLA就会失去原来的作用与意义
我相信一个真正聪明而认真的客户，我们作为软件提供商去商讨SLA最后会极难达成一致的，因为这里头有太多的东西是经不起推敲的，一旦客户较真起来，SLA会紧紧捆绑住软件提供商，软件提供商将面临SLA水平很低的局面，这样最终的结果是软件提供商在将事件关联SLA时故意弱化等级以抬高SLA，这里面有许多的空间与手脚可以去做。这里并非是客户的问题或者是服务提供商的问题，而是这一模式本身是不严谨的，逻辑上也不够周密，服务最终建立一个完成量化的基础上是不切实际的，所以才会造成如此之多的漏洞与空间，同时以国内的企业的成熟度，真正可以严格探讨SLA的制定的客户少之又少，是可以对客户进行培育及引导，但我严重怀疑这一培育是否方向错误或根本不可培育。追求客户满意度，这更多不是一个数字游戏，而是一个感官及管理问题。我们目前与客户达成的SLA协议，严格意义上不是市场行为，是不具备指导意义的，一旦双方是一种客观的商业关系，SLA的谈判会漫长而久远，所花费的工时量会相当可观，它要基于一系列的逻辑，同时对业务的细节了解深入。
三、能力管理
能力管理也被叫做“容量管理”，ITIL这一部份的愿景是，当今大多数的IT组件（设备）现实中存在着巨大的空闲与浪费，比如通过调查全世界计算机的CPU的计算能力70-80%是空闲的没有被利用的，这对众多的公司造成许多的浪费，于是如何榨干现有的IT组件的能力，抑制每年递增的高昂IT投资成了热点，说简单些，就是将每一家公司的所有IT组件构建成一个集群，让存储空间与计算能力与网络能力可以共享，以避免一台服务器的CPU负载过大，而又需要重新投资去购买新设备，因为可以通过能力管理调用它处的性能。这样一听起来是足够激动人心的，真正可以通过一系列的手段与流程让物尽其用，但是我认为这一美好的目标，是构建在流沙之上的。
首先设备的性能不能孤立的看待，不能将它们当一个个CUP与内存条或硬盘，计算机是一个整体，当主板、CUP、内存、硬盘、网卡这些组成一台机器时，性能是这些的集合，而且相辅相成，加上各种软件与操作系统的特性，对各部的使用都处于一种活跃的状态，目前是没有有效手段可以将其中一部份性能抽离出来的，强制组成集群带来的风险的损失将可能远远超过省下一台机器的价格，比如某一天，我们发现一个管理软件（汽车销售系统）的服务器的CPU负荷过高，我们能否将运行在此服务器的一些计算任务分流到另外一个管理软件（二手车）的服务器上进行？这里第一是技术手段的问题，第二是将配置的难题与风险大幅度推高的问题，这还是一方面；另一方面，这一理论严重忽略一个事实，即高峰期的问题，一年之中，可能有80%的时间汽车销售管理系统的服务器的CPU负荷是50%左右，我们是否认为这是一种浪费呢？在其它的20%时间内，可能是业务高峰需要调用所有的性能，而这种业务高峰是随机性的，随时哪一天开始促销，哪一天汽车召回，哪一天发布一项什么新政策，这些是不可预计的，CUP的性能不是为最低需求情况准备的，而是为最高需求情况准备的，这不能叫做浪费，就如每一个人的力气可以负重50KG，平时有几个人每时每刻的极限的使用这些吗？我们的电器，比如一个电饭堡一次可以煮10个人的饭，平时我们只两个人吃饭，是不是对这个电器造成浪费呢？我想答案是否定的，另外有一点很重要，计算机的发展，性能以每GHz的单价而言，就算浪费，这也是一种便宜的浪费，因这种便宜而进行风险较大的尝试努力，我认为不是一种经济的行为，无论是对于IT还是生命，安全稳定才是第一需要，而不是价格。
四、应用软件
ITIL的理论产生英国的国家电信局，虽然随着这些年的发展，但是对于软件领域的服务涉及甚少，我相信目前世界上没有太多的关于项目型软件的服务应用ITIL的成功案例，软件的服务相比较网络与硬件这些物理的实体的服务更加难以把握，一旦深入研究软件，尤其是项目型的软件，对作业的流程与配置管理、服务级别管理都会带来居多的冲击，我相信ITIL是否完全适用软件运维业务是值得讨论的，因为一开始这一理论本身就没有包容深入的软件服务管理，更多是着眼于桌面与网络，或者是标准的软件。这也是为什么我们公司的SLA与配置管理一直迟迟不能成型的原因，我想我们目前做的工作就是在触摸着世界的脉搏，在探索一个没有多少人开垦的疆土。
在这篇文章说ITIL的局限性，一方面是说世界范围内ITIL局限性，另一方面是说在公司自身业务上应用ITIL的局限性，在最初规划设计我们的ITSM系统时，我们就产生过想法，希望将软件业务剥离出来，专门针对软件运维业务开发服务支持系统，我相信就桌面与网络而言应用常态的ITIL问题还不大，一旦纳入软件项目，情况就复杂许多，我们公司作为服务提供商应用ITIL有两个根本的问题，一方面是ITIL多是基于大型公司的视角去实施的，而不是基于服务提供商去实施的，这也是为什么是大的公司上REMEDY的原因，另一个方面是我们公司的运维业务，软件领域占有绝大多数比重，这里有一很大的兼容问题。
如果在我们公司最终导入ITIL成功，并将众多的软件项目纳入管理，这将会有极大的示范意义，事实上我们业务的复杂，足够作为一个完美的试验品与标本去提升ITIL，如果那些顾问公司足够远见，完全应该低价介入帮助我们实施，最后他们得到的将是很好的项目经验与一次规划能力的飞跃，可惜目前中国的顾问公司仍如以前浮于水面，不着眼于实际，这一任务落在我们自己身上了。
五、资源管理
由于视角的不同，常态的ITIL应用者，他们主要资源就是众多的IT组件，但对于公司，作为服务提供商，尤其是软件服务提供商，我们的主要资源除了众多的IT组件外，还有一项更重要的资源，人，我们一大批的工程师，想管好每一个IT组件，必须也需要将人这一核心资源纳入管理，因为许多时候，真正的问题不是出自机器，而是来源于人，对于服务的管理，除了品质之外，第二重要就是成本，我们的成本主要来自于人力的成本，这一大批的工程师的工作时间，就是一笔庞大资源，我们如果能控制这些资源的使用，就能很大程度上控制我们的成本，所以基于公司自身的特色，我们还需要突破ITIL在资源管理上的这一局限，就是对服务资源的管理与控制
六、岗位设立
每一种管理的理论或标准，需要相应的组织架构去进行对应，ITIL也不例外，它定义出了在服务过程中，需要设立哪一些的角色，并定义了这些角色的职能与分工，因此带来的一个问题是，我们现在已有的组织需要如何调适与对应，哪一些是事件分析员，哪一些是事件经理，哪一些又是变更经理或变更实施者，还有问题分析员、问题经理、配置管理员等在用利用实务分析过程中，发现按ITIL的职责分工，许多人需要担负上述数种角色，尤其是在软件运维领域的人员，事实上严格按ITIL的分工是会有问题的，因为一名具体作业人员既需要进行事件分析、问题分析、还要做扮演变更申请者与实施者，同时起到服务台的作用。这样的角色与分工一旦泛泛后，就失去了管理的意义，就如我们在分配一个系统的使用权限时，赋予每一个人员几种角色的话，这只能意味着两点：要么人员的现实分工是有问题的，要么是定义的角色是错误或不合理的。这种现象在REMEDY应用中也是同样存在的，目前REMEDY的应用还未真正成熟，一旦严格用RMEEDY执行考核与管理时，这一弊端就会体现出来。
对于这种现象，是完全脱离于实际情况，虚拟出一堆无法直接应用的角色，这是一种比较大的缺失，会给引入此标准或理论的企业单位，无谓带来实施的难题与风险，如果哪一天我们真的按ITIL的标准改组人员岗位的设立，那么第一个问题是，这一些扮演多种角色的人员到底算什么职位呢？拿哪一种岗位的工资呢？第二个问题是，如果按严格分工，只会造成组织的无端膨胀，增大运营成本，同时作业效率会受到负面影响。这一问题在日后的ITSM系统实施上线时，是需要认真探讨与解决的。不然整个运维组织会受到影响，这与绩效考核等都会有着关系，不可能长期几年后，在公司一名人员叫运维工程师，然后在作业系统中又扮演着其它几种岗位，必须需要进行统一，以便于沟通交流、管理
以上对于ITIL的一些看法与意见，只是基于粗浅的一些认识，可能其中的一些观点与看法是片面的或错误的，但希望这些能够有助于日后公司对ITIL的应用，也可以当是闲文交流，让大家能够冷静自信的看待一些东西，我总想相信，只要我们踏实的着眼我们的业务，抱有客观科学的精神，是能够把自已的业务搞好的，对一些标准与理论，不需要仰视，也不能全盘照搬，而是着眼自身，去引入一些精华加以消化，不能期待一个理论能够带来质的飞跃。
边撸边过 边撸边过
页:
[1]