红儿 发表于 2011-7-16 02:03:00

CMDB终极思考


CMDB终极思考
从目前的情况看,CMDB的应用与发展都难言成功,我相信国内国外的情况应该没有本质的区别,在这里我想把近期对CMDB的最终发展思考,做一个归纳总结,先说明一下我对CMDB应用方面的看法,然后再对CMDB本身的发展做一些分析与探讨。。
   一个发展不充分的事物,如果要分挥功用,就需花费更大的力气,如CMDB这类的东西,我认为它目前的自我进化状况是不足以成功支撑一个很好的应用的,但是不是目前大多数的CMDB产品就不能发挥一些应用的功用呢,我认为是可以的,但这非常依赖于咨询顾问的规划设计能力,更高度依赖于甲方客户的自我控制能力,在这里它是指,甲方对完美的追求,对咨询顾问意见的尊重,对项目本身的过程控制,一个无法自我控制的客户,再好的产品与顾问也以难以发挥效益。由于CMDB的被神化,无端拔高它的功用与效益,这使得在CMDB项目中,咨询顾问与甲方们不太考虑基础功用,而考虑一些花哨的建型,最终的结果是连基础功用都无法发挥,那看上去蛮漂亮的业务模型在经过一段时间后,就会发现价值不大,只是娱乐你的感官,我相信这是绝大多数CMDB项目最终的必然宿命。
   另一个问题目是CMDB在应用过程中,范围过于狭窄,象文档层一般都是没有在其中考虑的,这其实是在运维管理中一个非常重要的问题,在一个变更时,不但要知道哪一些维护对象是在影响范围之内的,还要知道哪一些文档手册是同样受到影响的。由于更多以系统的视角去建CI,这样导致一些基础架构或公共架构的东西,没有很好的组织进来,比如基础配电类的,与网络层的、存储层的,以服务为视角跟以系统为视角这是两个完全不同的概念,只要一个CMDB的建设以绝对的业务系统视角去构建,我觉得最终模型偏离现实的可能性会越来越大,现在的CMDB我们到底有哪一些运维对象没有纳入其中,这是在项目一开始时就需要把策略定清楚的,如果关键的运维对象不在其列,事实你的整体模型一定是残缺扭曲的。
对于业务模型的部份,我认为是目前应用上问题较大的,很早以前我也认为虚拟CI的存在的必要的,它会让结构更加工整,也可以让运维对象与服务对接上,但在后面我发现这个做法是有很大问题的,现在在一年多以前我就认为虚拟CI不应出现在CMDB中,虚拟CI会成为CMDB中一个极不稳定的因素,并最终导致CMDB的瓦解,所有的结构与计算,在这里都会成为一个要命的事情。许多公司会把服务作为CI管理起来,事实上这是一个概念上的错误,IT服务管理也好(ITSM),业务服务管理也好(BSM ),并不是要把服务虚拟成一个CI才叫服务管理,不把服务虚拟成一个CI也不并意味它不是服务管理,你可以看看把服务或系统(非软件)虚拟成CI的CMDB模型,在它的CMDB世界观中,是树形结构,每一个树都有一个起始点,即虚拟CI,这是一个严重的错误,IT架构从来没有一点出发点,它是一个网状结构,此是其一,其二,由于CMDB模型的限制,为串起每一个树形结构,关系很多时候是从虚拟CI进行传导,此时全面的CMDB模型已完全背离了现实。如无必要,勿增实体,这一句话对于CMDB非常适用,不要去虚拟出一些不存在的对象出来,那是你维护的结果,而不是维护的主体。CMDB的信息价值目前最重要的其实是跨系统的部份,一个系统本身的内部结构其实大家是清楚的,现在的做法是相反的。
CMDB的应用过程中,许多容易发生一个认知的错误,把CMDB的CI看成一个实体的存在,这样造成CI对应的真实对象与CI产生了分离,最终导致模型偏移越来越严重,甚至对CI信息本身的重视要超过对CI对应那个现实对象的重视,这种荒谬的情况你会在讨论中经常看到,当一个真实对象被变更之后,居然还需要它相对应的Ci的信息维护进行审批才能更新,对这个审批的动作的复杂度甚至超过了对真实对象变更时的复杂度,我们必须牢牢把握事物的本质,CMDB不是一个虚构出来的东西,它最终的意义是描述现实世界,建模的过程就是你理解现实世界的过程,我们现在的建模大多数是逻辑而非物理的,这非常可怕,我认为一个CMDB构建完后,如果连最终的整个物理架构都不能全面而正确的描述出来,这是很荒唐的,连物理的架构描述都没有弄明白,去谈逻辑架构,最终弄出来的东西必然是不伦不类的,因为逻辑视角,取决于看事物的人、方式、时间决定的,这存在太多的变量,看看历史上的哲学发展吧,你敢说哪一个哲学家是错的?我们现在的做法是,把大家都知道的用逻辑视角去表达出来了,大家都不知道的反而不表达出来,真正一个业务系统的内部架构,会没有人清楚吗?偏偏我们把IT人员当白痴,这是因为在做建模设计的管理人员们不接触实际业务,对信息强烈缺乏安全感所导致的,最后折腾完了,最多我们给使用CMDB的人员一个他们本已很清楚的东西,他们缺的部份比如横向的关联关系,他们在整体架构中的坐标位置,这些却没有提供给他们。
   再破除一个常见的错误,我们喜欢建漂亮的模型,甚至是漂亮而复杂的模型,好象不整出一个眼花寥乱的业务模型,那就不叫CMDB,如果应用者们真正静下心思考,你会发现许多正在追求的东西,只是娱乐你的感官,图形化的模型大家都觉得有视觉冲击力,CMDB的厂商们也更多关注展现层,而不研究底层的模型的进化。图形化的展示,并没有太多实质意义,其原因在于,一个简单的系统根本不需要图形展示,IT人员就会理解它,以现在的电脑屏幕及CMDB的构建复杂度而言,一个有五六台服务器的业务系统,如软件与数据库及操作系统弄成CI之后,结构就在一个屏幕上显示得挤挤的了,谁维护的时候需要这个图?如果一个系统管理工程师,去做变更时还需要这样一个的架构图才能理解这个系统,我认为他要么不称职,要么这个公司的分工与组织有严重的问题。一个复杂的系统图形化展示,比如几十台上百台服务器构成的业务系统,你认为此时图形展示有意义吗?把几百个黑点点用线连起来,能帮助你什么?全局?细节?。我并不排斥漂亮的应用,但我排斥以漂亮为目标的应用,CI的关系的构成结果的核心目的不是为了展示图形的,要控制为了漂亮、工整去把模型折腾来折腾去的。
上面说的都是CMDB在应用时的问题,事实上CMDB应用的问题与另一个问题有着很直接的关系,即CMDB的本身的模型问题,在最近的三四年中,我没有看到任何厂商对于CMDB的模型有原创性的突破与进化,CMDB本身的粗放式模型,就容易导致最终的信息与模型脱离事实,影响分析更是如此,所以厂商们把影响按百份比权重之类的进行细化,这都是没有模型突破时的权宜之举,早在三年前,我就意识到CMDB的模型需要扩展,不然会走向极端,影响计算永远在0和1之间选择。这里的核心问题其实在于:CI的定位与CI之间的关系只能基于CI级,比如有一个交换机的故障发生时,我做事件定位时,只能把故障定位于交换机这个CI上,但如果我想定位到某一个端口时,除非我把端口做为一个CI进行管理,这是带有强奸性质的,它是CMDB模型层就决定的,现在真的有一些公司会把端口作为CI进行管理,我们可以想象一下,如果我们可以定位到属性级,这个问题将突破到一个新的层次,事实上任何对象均是由一系列的特性(属性)所构成,属性是对这个对象的进一步描述与分解,当一个对象出现问题时,事实上是它的某一些特性出了问题,所以非常有必要可以对属性进行定位与关联,这样你的事件分析、变更统计将会突破CI这个颗粒度,更深层次的运维分析将可以进行。另一个问题是,当我们构建关系时,只能基于CI与CI,这同样是非常粗放的,当属性可以实现定位时,关系的构建将可以是基于属性对属性的,即一个CI的某个属性与另一个CI的某些属性进行对接,因为一个对象与另一个对象的关系并不是全面的对接,而是它的某个部份与另一个对象对接,或者它的某一个特性依赖或影响另一个对象的特性,这样的的描述将会从质上改变对IT架构的理解,而且关系的类型将可以高度抽象,不需要搞出一系列的关系类型出来,因为关系最终是为了满足计算,如果用一种关系可以满足计算与推理,那么就不需要N种关系的存在。所以最终CMDB模型必须突破CI这个颗粒度的限制,实现全面的属性级,这样计算可以更加精密,图形化展示只是基于CI级,它帮助人们理解架构,影响分析将完全依赖基于属性层的算法,它直接给出最终结果,放弃掉依赖工程师肉眼的依赖。而且我有预感,属性有可能需要进行分层并结构化,不再是单一的平面,在这样的CMDB世界观中,是没有虚拟的存在的,它是实体对象的存在,物理的存在,这样的基础才是坚实的,它不以人的意志为转移,因为它就是实在,你对它的应用可以采用多种视角,但它的内核不变。
  基于上面的观念,CMDB的模型需要全新的解构,这样的CMDB模型我认为可以在相当一个历史时间内是长存稳固,因为从数据的角度来说,它是终极的,不再需要也不再可能对CMDB产品本身做更深层的拓展,但这只是CMDB的内核部份,CMDB本身还有许多进化的可能性,下面我将从我的角度试着去说明它的未来:
 首先CMDB目前的作业模式,仍然是依赖人员维护为主,处于一种被动维护的状态,这造成高度依赖人,也高度依赖于强制性的制度,但我们从来没有德国人的严谨,我们从来没有强大的制度,这就导致CMDB信息最后必然失真,只要一个点开始信息失真,最后容易体系性崩溃,这里的关键问题在于:CMDB的信息其实是作业的结果,而不应该是维护的结果,这个问题的解决单单依赖什么人员培训与制度惩罚,我认为是没有太大出路的,这是我理解的CMDB的第一个进化阶段,即CMDB作为CI信息与CI之间关系信息的存储数据库,依赖人员主动维护。这也是大多数公司所处的状况,费时费力还不见成效,最后属性能少就少。
  在CMDB的第二进化阶段,也是一个非常关键的阶段,CMDB的信息将不再依赖于人类的维护,而是CMDB本身进行自动采集,它将与服务对象或监控软件实现互联,主动的采集信息进行自我存储,不管理软件的版本,还是硬件的制造商,甚至是CPU、内存、带宽情况这种高度动态的信息也可以实现采集,当人们对服务对象做了变更操作之后,CMDB将把最新的状态信息采集过来,此时CMDB将为成一个忠实的架构信息记录,它不再是一个维护者,而转变成一个记录者。此时信息在CMDB集大成,人们的维护工作量与时效性的问题都可以得到解决,大量的人力将从信息本身释放出来,专注于理解与应用的层面,这个阶段将是决定性的,没有突破将不可能进入下一个阶段,更难以构建更好的应用,它也是技术与整合难度最大的部份,需要做大量的标准化的动作,这种状况跟物联网的情况是类似的。
   CMDB的第三个阶段将是从收到放的过程,当所有服务对象的信息标准化后,CMDB与它们互联互通的问题也不复存在时,CMDB将从本质上转变职能,不再作为信息存储者的角色,CMDB不再需要将所有CI信息及CI关系存储于一个数据库中了,因为这是不经济的做法,也是容易出错的做法,信息一旦出现多个副本,就面临修正与传送的需要,还需要更复杂的机制去洞悉最初信息源的变动情况,比如一个主机的软件版本信息,以前的方式是需要扫描到它,然后把它复制到CMDB中,一旦这个软件的版本信息发生变化,需要把所有原来复制目的地的信息全部更新,而且为了信息的及时性,还需要高步频率的扫描这个软件版本信息,这会浪费许多计算资源与存储资源与网络资源,CMDB不需要记录这个软件版本信息,当查看请求时,直接去调用这个对象本身的信息即可,最合理的方式是每一个真实对象都记录了本身的信息,它包含属性信息与与它直接相邻一层的真实对象的连接信息。这样信息是分散于所有真实对象本身存储的,CMDB只需要做整体关模型调和及做全局的快照,当有用户需要调阅时,CMDB再从真实对象中调用信息进行组装用户界面,即CMDB本身不再需要存储CI信息与CI关系信息,刚转变成一个信息的组织者与呈现者。到了这一个阶段,才真正能解决CMDB与CI与它对应的真实对象分离的情况,CMDB成为一面镜子投影出现实世界,而不再试图去用自已的角度去描述它,这个投影的正确与否,取决于观察者的视角,但你永远不能再否认它的实在。
CMDB的第四个阶段将超越信息本身,记录、采集、调和中是它的基础工作,当所有现实架构信息无误,物理世界已真实呈现在CMDB中后,必然会需要对架构信息进行解读与理解,甚至开始进行真正意义的现实世界抽象,基于前面扎实的物理投影,构建对架构全新的逻辑理解与展示,不再局限于物理层,此时CMDB将会人们定义好的智能算法,去得出每一个作业的风险及架构的薄弱点,甚至对未来运维工作的方向与事务做出决策建议,此时CMDB将代表着人类对IT架构最高的理解,CMDB将在监控、调和、审计、分析上更加深入,图形化在这个阶段基本已失去意义,CMDB将直接给出你想要的分析结果,甚至告诉你怎么分析,你现在能想象到的监控画面与架构图都将消失,信息不再需要经由CMDB呈现出来后,由人们再做分析推理,然后得出行动建议,那太不可靠了,也太慢了,只要我们足够严谨,我们就能找到分析的逻辑,也就能找到算法,而运算,这是软件所专长的,让CMDB将直接给出行动建议,它在此时成为IT架构的大脑。
   CMDB的第五个阶段将发生质的变化,它将进一步从服务对象本身的信息层面与分析层面提升,具备控制职能,它将开始接管服务对象,IT自动化将开始实现,每一个服务对象的控制不能由其自身决定,而是由CMDB决定,这才是风险最小,也是效率最高的模式,当变更计划生效时,锁定CI不再意味着是对CI信息本身的锁定,而是对现实对象的锁定,以前变更审批只是在制度上约束工程师们,没有经理们的签字确认,不要去做变更,事实上他们要做还是可以做,比如一个软件版本的发布,此时的情况将转变成,变更单的经理没有点一个按钮,CMDB将控制着这个主机的无法做任何版本变动,甚至这个按钮可能不需要经理付出审批了,而是由CMDB审批,这是一种层面的控制,更深入的控制将直接对象本身进行操作,比如CMDB将控制所有windows的版本升级,由它直接分析是否需要升级,并下发补丁对升级服务器做强制安装操作。这需要厂商们更大的集成对接,将服务对象的控制指令形成标准化,CMDB通过信息的控制,来实现对机器的控制,通过对机哭的控制,来实现对架构的控制,CMDB在此时将是IT架构的大脑与神经。也只有在此时,天网与Matrix才有了一个物理与科学基础,未来现实的信息化、虚拟化才能成为可能。

PCer 发表于 2011-7-21 17:18:00

!"""沙发

咖啡 发表于 2011-8-1 21:33:00

随想 发表于 2014-4-18 16:21:04

撸过

孤独无败 发表于 2014-4-18 16:21:28

没人回帖。。。我来个吧
页: [1] 2
查看完整版本: CMDB终极思考