CMDB属性及分类问题思考

定义的烦恼

在某一次系统监控的讨论会议上，我随便提出了个问题：“如何定义一个系统？”，结果答案就五花八门起来了，会议也跑题了。

为什么问这个问题，是因为某些同事觉得某个系统比较大，就往下分为子系统、组件等，往上分业务群等。有时候仔细一看，什么业务群，明摆着就是一个大的系统而已。当然，我随便说说，我也没有对这个问题有明确的定义。我想说的就是，包括系统、组件、子系统等等，这些定义我们从来没想过——流程也是这样，区别是，我们想过，但是只是凑合着用而已，定义并不清晰。

这些属于那种只可意会不可言传的东西，这就导致外部公司常常将我们“以为”的一个系统拆分为多个系统进行收费……

当然，这个问题至今仍为明确，我提出过，但是大家都认为没必要搞清楚这个问题。

 

CMDB分类

和上面一样，CMDB的分类也是这样。

我举个例子：有人问过，服务器为啥不是网络设备……我觉得这个问题其实还是不太好回答的。

CMDB的分类，最好能够穷尽但又不交叉，你不能让一个CI同时属于两个分类。

 

----------中断一下，我再提个问题，如何定义CI，什么是CI，什么不是？----------

 

我需要回顾一下现在收集到的类别。

环境：

建筑、机房

动力设备：配电柜、列头柜、UPS、PDU、机柜

空调设备：空调

消防设备：现在没有，以后会有的

门禁设备：现在没有，以后会有的

 

网络：

线路：互联网线路、广域网线路、局域网线路

资源：IP、域名、数据接口

网络设备：路由器、网络交换机、无线设备、安全设备

网络设备配件：现在没有，以后会有的

 

通信：

通信设备：语音设备

 

虚拟化：

虚拟资源池、虚拟机

 

计算机相关：

计算机整机：PC服务器、刀片服务器、小型机、中型机、大型机、工控机

计算机配件：现在没有，以后会有的

存储设备：磁盘阵列、集中存储、磁带库、光纤交换机

专用设备：刀片机箱

其他设备：现在没有，以后会有的

 

软件：

业务群、系统群集、应用群集、数据库群集、业务系统

中间件：Tomcat、IIS、Apache、Jboss、Weblogic、Websphere

数据库实例：DB2、Sybase、Oracle、MySQL、MSSQL

 

总感觉实体资源中的建筑和机房不应该放在这里来，虽然确实互为实体，但是属性好像不同，所以先移除了。

----------继续----------

 

CI就是CI，做好业务系统的定义，而具体与服务挂钩的地方则在服务管理的部分去处理。

对于CI来说，状态只有两种，正常和故障，正如数字0和1的区别。

刚才思考的时候也绕到百分比影响传递的问题上了，这一块的内容扔到服务里面去处理。

 

CI中记录的是静态信息，动态的信息从监控来，展示时调用接口即可。

 

分类与属性挂钩，必然某些分类会有具体的属性集。

属性定义-->属性集定义-->属性与分类挂钩

 

在考虑之后，我认为服务的模型的建立应当从基本服务（即与某CI直接相关的最小服务）开始，在服务管理中应该可以引入服务相关的概念，这样可以简化CMDB本身的功能。而业务的模型则是直接展示CI和服务。

 

CMDB本来就是一个比较悬的概念，不能让过度复杂的功能让它雪上加霜了。