七问CMDB [ZT FROM VSHARING BY 破子人生]
学习资料： ITIL培训基地专家讲堂直播 300期视频回放
ZT FROM: xqscool/A1267069.html
作者：破子人生
相比较CMDB的热闹而言，配置管理显得奇怪的冷清，这是一个很怪异的事情，近段时间我一直在思考，什么是配置管理，我在怀疑我们是否真正理解与把握了什么是配置管理，我越来越确信，中国所有CMDB项目基本上是失败的，成功需要太多的条件，而失败只需要其中任何一个就可以了，不能理解整个ITSM管理体系，就不可能理解配置管理，不能理解配置管理，就不可能理解CMDB，而我看到的是，许多公司与项目，就把CMDB视为一个独立的存在的，这从整个体系架构的层面就决定了它的失败，其次是在应用上大家都并不知道CMDB到底要干嘛，每一个做CMDB的公司的初始需求其实非常不明确，当没有一个明确的需求为中心的前提下，最后演化成依赖花哨的模型与讲CMDB的好处与价值来证明项目的成功，其结果是，CMDB没有真正解决什么问题，因为我们并不清楚问题是什么，这又形成另一层追问，当一个客户的需求并不明确时，我们过度的剌激它、引导它，让客户进行产品与项目消费，带来的可能是双输的结果。
最复杂的问题往往需要回到最基本的问题才能解答，这些显而易见的问题之下，其实藏着很多的不可知：
第1个问题是，到底我们要实施配置管理还是实施CMDB？，配置管理与CMDB是两个完全不能等同的事物，前者是流程，后者是工具，当我们不清楚怎样做我们的配置管理时，或者我们的配置管理到底是干什么的，要完成什么流程目标时，我们直接来实施CMDB，最后容易失去战略，最终演变成为为了CMDB而CMDB，所以我们有可能看到一个实施了CMDB的公司却没有配置管理程序，或者它的配置管理程序只是指导CMDB怎么操作的文档。以现在国内的IT服务管理水平而言，有没有ITSM系统会有管理上的差别，但有没有CMDB其实于作业与管理并没有多大差别，说到底，这一块并不是大家的痛点，正是这种客户没有明确问题需要解决的项目才是最难操作的，这也是CMDB为什么实施后得不到认可的一个原因。
第2个问题：什么是配置？。我们知道配置管理，那到底什么是配置呢？。从词面的本意看，配置意味着分配与设置之意，从大了讲，把一堆刀片服务器组成集群，这是配置，从小了讲，把一个操作系统的环境变量做一些参数调整，这是配置。配置是动作，IT架构是主体，当我们在讲IT架构时，如果我们在脑海之中只泛起那成百上千台各种IT设备，那是远远不够的，我们还需要在脑海中联想到这些机器上部署着的大量软件与数据库，但是这还是不够，我们还要进一步的意识到，这些每一个对象内部的配置以及外部的配置是什么，这才是构成一个IT架构的真正实在，如果有一个全息的复制技术，我们要地球的另一端完成的将一个IT架构映射出来，我们只需要两个东西，一个是配置，一个是资源，我们用这些资源通过配置搭建一个IT架构或IT架构的任何一个部份。
第3个问题，什么是配置信息，一个常见的误区是，我们以为CMDB的所有信息就是配置信息，这个观念是大家先天存在的，不能说它错，但是它不精确不全面，因为这里面暗含着一个逻辑是，不在CMDB中的信息就不是配置信息，这会直接导致一个极端，大家只关心CMDB的信息与是否变更与维护，但其实真正的配置信息以现在的CMDB技术发展而言，只有不到20%的配置信息记录着CMDB之中。到底什么是配置信息呢？，CMDB之中记录了一些CI，以及它们之间的属性，加上CI之间的关系信息，但对于现实的IT架构而言，这些信息的技术价值太低了，它在你重建与故障时只能给你有限的指导，我们有大量的配置信息是记录在各种手册之中的，大多数CMDB的做法是把这些手册当成CI，加一个版本属性，我们有更大量的配置信息是记录在架构本身的，比如一个软件的接口关系与访问关系，或者操作系统本身的设置信息，或者数据库的内部结构，所有的CMDB的做法同样是把这些当成一个CI，再加上几个属性了事。有一个设备是什么型号，这是配置信息，有一个软件是什么版本，这是配置信息，但这些都是粗放性，而且是偏管理性质的，真正的配置信息是更深入的，比如网络设备的ACL、软件内部的参数设置，这种层面的配置信息才是核心的，它分布于各种文档与对象本身中，从当前的CMDB而言，弄几个CI，加几个属性与关系，是根本无法将配置信息真正的管理起来的，这也是为什么CMDB一直难以发挥架构的控制与记录作用的关键因素，这是先天性的，这也是为什么所有的工程师最后觉得CMDB对他们的工作没有实际作用的原因，这现在的产品与实施方法都解决不了这一问题，以我目前的认知，只有云计算，才有可能让这一问题从根本上解决，但解决方式是另一个极端。
第4个问题，什么是配置项，如果我们先把大脑放空，清除现在的ITIL理论与现有的CMDB产品带给我们的条条框框，我们从根本上想一想什么是配置项，只有有一个项次需要进行配置，它就是配置项，不管它大到一个设备，还是小到一个程序的参数，讲一个通常的例子，比如windows中的语言时区设置，如果它对一个应用系统的运行存在影响，那么这个语言时间设置就是一个配置项，我们现在一谈到配置项，就想到CMDB中的CI与属性，但这里其实是受到当前的CMDB产品的影响，我有时会怀疑，当前的CMDB产品通过CI+属性这种简单的数据结构是否能满足我们描述IT世界，因为这种数据结构的制约，我们在做配置规划与设计时，不断需要考虑什么当成CI，什么当成属性，又什么当成关系，这应该并不是一种最佳的方式，比如刚刚这个例子，对于操作系统的语言时区设置，从理论上，我们会意识到这是一个配置项，但要实施CMDB时，我们多半会放弃它，不会把它做成一个CI，也不太可能会把它做成一个属性，因为如果把它当成属性，它会与操作系统的版本或厂商之类的平行，显得非常怪异，因为属性无法再分层，如果我们用这种模式来描述一个人，只通过属性的方式，我们会发现弄一大堆的属性字段，最终我们还是对此人一无所知，它太单一了，又不够结构化，这就是现在CMDB产品本身在设计上的困境，这困境通过复杂与花哨的模型都无法解决，必须改变它的内核才行。
第5个问题，什么是配置管理，有时我会觉得CMDB这个概念与产品的出现，带来的问题比解决的问题要多得多，最严重的一个问题是，让我们在思考与管理时，把现实与现实的投影弄错位了，所以我们会经常看到许多人非常重视控制CMDB的CI信息的变化与维护，这种在管理流程层面的重视程度要超过对现实架构改变的重视度，好象大家在思维时，会把CMDB这个CI信息，当成了现实中的IT对象，这让整个管理哲学出现扭曲。回到问题，配置管理到底是管什么呢？，它是管配置信息吗？还是管现实的IT架构的配置呢？前者是面向信息，后者是面向对象，本质上我们在管理与实施时，其实最后都异化成了面向信息，我们最后都会强调CMDB的数据要维护，要控制，要精确，真正的IT架构中的设备的配置状况，反而我们并没有花精力在管理与思考，这种状况就好比，事件管理只是为了让事件的信息精确与记录完整，而不真正关心事件本身，这样说，大家可能觉得不可能，但如果我们真正冷静的思考与观察，我们会发现这种管理哲学的扭曲广泛存在于我们的日常活动之中。所以我一直认为，我们并没有真正理解配置管理本身真正要做什么，这种问题的最始本源有两个方面，一个是ITIL理论的本身构建不足够严谨，设计者们缺乏哲学家的思维，二个是CMDB的概念与产品的泛化与炒作，加剧了这一实施层面的扭曲，不能整体上考虑一个管理体系，或不能从整体上考虑一个ITSM系统，是很难发现这一问题有多么严重的。
第6个问题：什么是CMDB，我们先不要背诵什么CMDB是存储记录着IT架构的配置项，以及配置项与配置项之间关系信息的数据之类的话。我们先要来问一问，CMDB的管理范围到底是什么，我们经常会看到，把服务当成CI，把人当成CI，把组织当成CI，然后CMDB之中还有可能存着事件派单时需要派给谁之类的规则数据，这种做法又在扩散配置项的含义，一个大厦的建立需要基于标准的尺寸的器件，一套管理体系同样是如此，我认为我们很有可能将CMDB异化了，CMDB只是IT架构的投影，别无其它，象服务、人员、组织之类的数据需要存储，但那只是存储在ITSM系统之中，而不是存在CMDB之中，这些东西不属于配置管理的范围，这些也不是我们现在谈的配置，严格来讲，现在我们讲的CMDB其实是CMS（配置管理系统），我们不会把一个事件管理系统叫成IMDB，但是我们会把一个配置管理系统叫做CMDB，CMS只是配置管理的实施工具，CMDB只是CMS的数据库，我们现在说CMDB，好像CMS与配置管理这些概念都不存在一样，这些名词与本身的含义都出现了混乱。
第7个问题，什么是配置模型，现在的CMDB产品，你如果没有整出几个天花乱坠的模型出来，你都不好意思叫CMDB，我一直强调模型本身的价值很低，尤其是现有的CMDB产品的模型表达，只是为了愉悦不接触与管理IT架构的管理者们，目前大家对模型的过度重视，导致的一个结果是，会基于模型的需要去构建关系，这样的结果是模型引发了巨大的争议性，不同的团队不同的角色提出不同的批评，只要根据模型去做关系构建，这种结局就是必然的，什么是模型，模型只是抽象后的世界表达，配置模型的本质是关系数据的展现，它是数据的，它是视角的，有视角有角度，就一定有限制性，我们描述任何事物，需要用多种视角去描述它，这叫视图，就比如我们为了说清楚一个系统时，一样会画多张图出来。当我现在坐在21层高的房间里，看着下面的世界，人来人往，车流奔涌，集市的拥齐与街灯的明亮，我们会从人文的视角分析它，我们会从科学的视角去分析它，我们会从政治的视角去分析它，我们会从经济的视角去分析它，但是这个世界，还仍是如此的运作，不管什么角色的人用什么样的视角去分析它理解它，它不观察者的角度与意志为转移，所以最稳固的方式是尽可能真实的去描述你的世界，只有真实，才是不可破的，基于这种真实所构建的数据关系，再来做模型抽象，才有可能做出多种视图，满足不同的需要。一定要切记，我们看模型只是通过那十几英寸的屏幕，一个复杂的系统，展示出来只是一堆黑点加一堆线条，一个简单的系统是不需要抽象就可以理解的，而且有了关系数据，计算是可以有结果的，用肉眼去看模型的实质价值其实非常有限。
最后我们再回到第1个问题，到底是实施配置管理还是CMDB，其实我们要实施的是配置管理，只是通过CMDB这个工具去实现，如果我们不能切实回答我们的配置管理的目标与内容，工具永远没有灵魂，这种简单的问题是如此重要，又是如此之难把握，在作业之中，我们经常会迷失。我在想，如果我有一家企业，我一定会先去建整个管理体系，让每一个流程的使命清晰化，从单一个流程出发去实施，最终是很难控制框架的合理性的，何况是从一个流程工具去出发，这种结果就好比我们先去做一块块不规则的砖头，我们怎么能期望能建立一栋大厦。
貌似我们比较多的在使用CMDB，而不是真正的实施配置管理流程。实际上的配置信息，和CMDB记录的已经相差甚远…… 徒具其形的CMDB很多 学习。。。 数据库和数据管理，哪个又能独立存在呢？
页:
[1]
2