关联分析,现在在企业内部出了问题或者是故障我们都需要与CMDB做关联。比如说我现在是负责某系统的运维,如果某一天我的系统非计划停运了,运维如何去定位。首先,我们需要查看系统是哪个区掉的,哪个用户投诉过来,整个反馈到业务架构上面,可能在哪一个机房,在哪一个交换机下面。整个这个信息都是基于CMDB去做的,信息查询、问题定位才能变得更清晰。
您说的很对。事物建模就是对象+关系,对象包括属性+方法。而事物的复杂度主要体现在关系的复杂度上,因此越是复杂的运维架构,到不是其属性太多,而是关系太复杂。逻辑资源和物理资源间的关系,应用之间调用关系,应用内部模块的关系,系统服务和业务流程之间的关系,等等。
但通过CMDB体现关系难度很大,我们公司自己也做的不够理想,希望大家多指点。主要原因有二:
1.关系的维护成本很高,靠自动发现难度比较大,即便实现了,太细太复杂,让人难以理解。真正有价值的关系拓扑,个人感觉还是要靠人的抽象手工在CMDB中定义。
2.依赖可视化工具。CMDB中的关系主要方便人的理解,而人机交互界面的效果直接决定了产品价值。很多CMDB关系拓扑图太朴素了。我印象中优诺的可视化做得比较好,可以将CMDB中资源关系和监控集成,尽可能让用户自助来设计拓扑图,降低总体管理成本,应用的场景也比较有价值。