如果分类在存储和展示上都能够自定义而且有足够的空间的话，确实如破子所说，分类是不应该吝啬的。

很好奇破子公司所用的CMDB里面的数据结构是怎么设计的，我近期在这个方面上一直存在问题，总是担心过于灵活的话会影响到性能，毕竟最终使用起来上万条记录的相互关联和查找还是会很费数据库性能的。

 

分类是最简单的，无限分类，最多加个图片和说明，其他的就没什么了。

 

属性集的设计和破子所想的是一样的，因为如果开发像HP SD的那种过度灵活的功能反而导致系统配置异常负责，而且很容易由于某些微不足道的问题使系统功能受到影响。

属性集中的各个属性可能拥有自己的功能，比如维保信息的属性集，可能有开始日期、结束日期、续保历史、续保文件等，而且可以设置在结束日期多少天之前进行提醒。

每类属性还需要有对应的说明文本（不一定只是文本），来指导用户进行填写。

 

CI与CI之间的关系也是我最头大的问题，N多类CI的关系都被大家称作为“安装”，而且由于用户前期参与不够，所以大家都期待能够在系统研发完成后定义和限制，比如当服务器关联某个软件的时候，只会有自动选择一种关系，那就是安装，当服务器关联某个网络设备时，只会自动选择一种关系，那就是连接等等，当然，上述的例子举得比较简单。上述的关系时给予分类的，并且要有关系说明。关系是需要提前整理出类-类关系矩阵的，这样后期直接根据当前类和目标类就可以确定可选的关系了（不过话说确定的类与类之间应当只有一种关系）。连接说明这个很好理解，至少也可以将物理连接的编号填写进来啊~

让我比较头疼的是“可用性传递”这种关系，比如说在可用性计算的时候，影响可能是单向或双向的，而且不同方向还具有百分比。“可用性传递”、“连接”、“调用”等不同的关系貌似应该通过不同的模块来实现。

物理连接关系如果称为“硬”关系，那么软件之间调用关系就是“软”关系了，“硬”关系铁定会对“软”关系产生影响。

想到这里，又想起一个问题，连接、调用在监控的角度来看又是会产生影响的，晕。

关系的穷尽在公司里面比较难搞，头疼中。

 

在看破子的CMDB模型时，感觉动作这一块很有意思。因为按照我的想法设计的架构图中，作业这一块是由单独的系统控制，并与CMDB相关联。

这两天思考了一下，如果在CMDB中就能够定义动作，那么确实有助于服务的标准化，但是动作记录在哪里呢？按照文中的意思，应当是一系列的操作？我的理解是，在CMDB中定义动作只是为了与其他系统保留一个接口，适时的将动作与其他系统的作业进行关联，从而实现标准化或者自动化？或许自动化是后期的事情，那么前期的这些动作如何与流程、工单相关联？如何准确记录时间，这些都是问题。标准化动作如果要配备相应的资料，那么就需要考虑不同品牌、不同型号的问题，当然，通过资料库进行相应的匹配技术上来说没什么难度。

 

看到破子的服务和CMDB结合的想法，确实给了我不少启示。某些一直以来没想明白的问题感觉有些明了了。

 

服务对象的部分，之前公司内一直将其作为一个CI管理，然后每个系统又要分子系统和组件，每个系统又会和其他系统组成系统群……当然，前一个是因为方便计算可用性，后一个纯粹是蛋疼且讨好客户用的。

你能想象一个系统群掌握在一个人手里是什么感觉么？所以业界说惹怒了SA小心使出必杀技。

服务对象应当划分到服务管理中，CMDB中就别搞什么服务了，看着就头疼。

如果这样，那么像PC服务，服务对象中应当直接包含客户所有的PC——我估计说到这里管理层就会头疼了，因为他们认为这个不归我们管理，客户就该乐了，因为他们认为这个该我们管。这个问题还有待考虑。

 

一直以来，如何精确定位事件的影响面，是最让领导们纠结的问题之一。服务主体的概念需要按照每一个服务来确定，而我司一般签框架协议，业务系统的运维服务一般都是一股脑的叫过来。加入服务主体的概念后，签协议就需要用户配合确定服务主体是谁，明确这些信息之后，影响面基本上也就确定了。

哦，我们这里单独管理机构，所以服务主体可以直接使用机构信息——不过这机构成天变来变去的，我看悬啊……

 

服务*这一块我先思考一下。服务在我们这里或许会有服务主管。但是*中指定的角色映射其实不是固定的，这就导致实际上需要给一个员工分配很多角色，甚至是只用一次的角色。如果能够自动映射……我想多了。

 

服务级别的定义需要和客户所签订的内容一致，这样在接近或低于的情况下就可以自动产生告警。而且各类工单的时限要求也可以取自服务级别中，倒计时的方式给人更强的紧迫感，对于系统中所涉及到的人员也会从全局了解自己所背负的责任。

 

最后有些纠结，破子的想法确实不错，但是最终开发出这么复杂的系统，我还真担心部门内部是否有人会用会配置？需要了解的内容太多了。

最最后说一句：我靠，破子你研究得太深入了。