首页 > 代码库 > CMDB反思4

CMDB反思4

CMDB模型设计2

http://blog.vsharing.com/xqscool/A1275233.html

估计大家看到破子的这两篇都有点晕哈,我也有点晕。
两篇对比来看。
 
第1处,属性部分新增了动态的内容。这也是我一直考虑的问题——毕竟咱是搞监控多年,监控的数据是否存放在CMDB中也考虑了很久。因为CMDB使用的更多应当是当前状态,如果要记录性能数据的话就需要记录历史情况,这样感觉将CMDB与监控打包在一起了。我这里还是只是提供接口,CMDB可以调用。再者,CMDB有这些属性,也必须有数据来源才行。因此,接口的引入确保有监控就有动态数据,没监控就没动态数据。
另外,虽然要对CMDB各项数据的历史进行记录,但这和动态数据是两回事,千万别搞错了。
 
第2处,CMDB的模型中将“动作”更换为了“业务”。反正是树形结构的,所以区别不大。其实个人认为CMDB的基本属性只要包含其他三块即可,即属性、分类和关系。而不论“动作”还是“业务”这两种虽然说也不可少,但是从某种角度来说不是必须的,当然,关键看你要从什么视角去看,从业务的视角就必然有“业务”,从运维的视角就必然有“动作”。
 
第3处,引入了业务之后,实施CMDB的过程就是自上而下的,而非之前自下而上了。从业务发起,进而到IT,之后到关系,最后才是属性。而且通过这种业务架构的展现,能够自上而下使公司对CMDB的实施充满信心。
 
第4处,引入业务之后,CMDB的故障影响中就直接可以查看到具体对业务的影响。
 
第5处,服务相关的内容中,服务级别被替换为了服务目录,其内容也从CMDB的部分迁移到了这里。但是实际上我认为两者必不可少:服务级别定义了提供什么样的服务,服务目录定义了提供的具体服务项目(项目进一步划分为动作序列)。
 
第6处,如此一来,真正作业的时候,我们就可以了解到CI在服务层面的影响。
 
在看了第二种模型设计,个人感觉CI模型设计上,CI可以有更多的维度,但是如何平衡设计和使用的复杂化问题?最红的效果固然是很不错的,但是必将带来前期开发及实施的困难程度。