[转贴征文] CMDB的终极思考
学习资料： ITIL培训基地专家讲堂直播 300期视频回放从目前的情况看，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才有了一个物理与科学基础，未来现实的信息化、虚拟化才能成为可能。
除了死亡，一切只是概率
转自破子人生
支持！ 鄙视楼下的顶帖没我快，哈哈 为保住菊花，这个一定得回复！
页:
[1]