估计大家看到破子的这两篇都有点晕哈，我也有点晕。

两篇对比来看。

 

第1处，属性部分新增了动态的内容。这也是我一直考虑的问题——毕竟咱是搞监控多年，监控的数据是否存放在CMDB中也考虑了很久。因为CMDB使用的更多应当是当前状态，如果要记录性能数据的话就需要记录历史情况，这样感觉将CMDB与监控打包在一起了。我这里还是只是提供接口，CMDB可以调用。再者，CMDB有这些属性，也必须有数据来源才行。因此，接口的引入确保有监控就有动态数据，没监控就没动态数据。

另外，虽然要对CMDB各项数据的历史进行记录，但这和动态数据是两回事，千万别搞错了。

 

第2处，CMDB的模型中将“动作”更换为了“业务”。反正是树形结构的，所以区别不大。其实个人认为CMDB的基本属性只要包含其他三块即可，即属性、分类和关系。而不论“动作”还是“业务”这两种虽然说也不可少，但是从某种角度来说不是必须的，当然，关键看你要从什么视角去看，从业务的视角就必然有“业务”，从运维的视角就必然有“动作”。

 

第3处，引入了业务之后，实施CMDB的过程就是自上而下的，而非之前自下而上了。从业务发起，进而到IT，之后到关系，最后才是属性。而且通过这种业务架构的展现，能够自上而下使公司对CMDB的实施充满信心。

 

第4处，引入业务之后，CMDB的故障影响中就直接可以查看到具体对业务的影响。

 

第5处，服务相关的内容中，服务级别被替换为了服务目录，其内容也从CMDB的部分迁移到了这里。但是实际上我认为两者必不可少：服务级别定义了提供什么样的服务，服务目录定义了提供的具体服务项目（项目进一步划分为动作序列）。

 

第6处，如此一来，真正作业的时候，我们就可以了解到CI在服务层面的影响。

 

在看了第二种模型设计，个人感觉CI模型设计上，CI可以有更多的维度，但是如何平衡设计和使用的复杂化问题？最红的效果固然是很不错的，但是必将带来前期开发及实施的困难程度。