定义的烦恼
在某一次系统监控的讨论会议上，我随便提出了个问题：“如何定义一个系统？”，结果答案就五花八门起来了，会议也跑题了。
为什么问这个问题，是因为某些同事觉得某个系统比较大，就往下分为子系统、组件等，往上分业务群等。有时候仔细一看，什么业务群，明摆着就是一个大的系统而已。当然，我随便说说，我也没有对这个问题有明确的定义。我想说的就是，包括系统、组件、子系统等等，这些定义我们从来没想过——流程也是这样，区别是，我们想过，但是只是凑合着用而已，定义并不清晰。
这些属于那种只可意会不可言传的东西，这就导致外部公司常常将我们“以为”的一个系统拆分为多个系统进行收费……
当然，这个问题至今仍为明确，我提出过，但是大家都认为没必要搞清楚这个问题。
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本来就是一个比较悬的概念，不能让过度复杂的功能让它雪上加霜了。