2007-9-14 9:21:30
[原创]ITSM系统_CMDB设计_业务要件
这段时间忙得可以，一边要搞ISO20000，一边要搞一款ITSM系统，配置模型汇报了无数次，CMDB的构想也是一次次的讲，有时你想得清楚一件事情并不难，难的是如何推销你的想法，让哪一些想得清楚或者想不清楚的人同意你的做法去做，这个难度更大，虽然个人很不喜欢做这种事情，但没有办法，还是硬着头皮一次次上，折腾好几回了，总算拍板定下来搞了
关于整个配置管理模型与CMDB的规划构想，其实在去年底就差不多成型了，但困于项目，无法尽快展到拖到现在，这过程中也与很多人做过交流，不过基本上是越发让我坚定想法了，看来去年底的思考还是对的，前段时间一个美国的公司过来跟我们交流ITSM工具，这家公司在中国在美奥软件，英文名叫MO（ManagedObjects)，他们号称是BSM（业务服务管理）领域的领跑者，我看了他们的软件演示，也听他们介绍了理念，还不错，个人觉得跟我的想法差别不大，模型与技术实现没有问题的情况下，最终成败就取决于应用了。
下面这人东西不知道有多少人可以看得懂，如果有跟我们一样处于想做CMDB的同行，应该还是有一些参考意义的，也可以启迪一些对配置本身的思考。以前我就是拼命想找这种资料结果找不到，最终自已从来到尾，一穷二白的重建。
欢迎大家发表一些意见与展开讨论。。。。。。。。。
| 配置管理业务要件 | ||||||||
| 业务模块 | 序 | 要点描述 | 必要画面 | 输出表单/报表 | ||||
| 配置管理 | 业务定义 | 属性池：CMDB中所有属性的集合 | ||||||
| 属性值：具体一个属性对应的值 | ||||||||
| CI：具体一个配置项，也叫CI实例 | ||||||||
| CI分类：根据物理形态把CI划分为某一个种类 | ||||||||
| CI结构：描述CI之间的构成、连接、需要关系 | ||||||||
| 构成 | 从逻辑层面或物理层面，一个或多个CI构成另一个CI，称为构成，象当于指向父节点，构成是关系的第一法则 | |||||||
| 连接 | 连接是一种物理上硬连接，表示一个CI与另一个CI物理上的连接，连接是关系的第二法则 | |||||||
| 需要 | 当一个CI的运行，依赖于另一个CI正常运行时，称为需要，需要是关系的第三法则 | |||||||
| 构建方法 | 构建关系的方法是遵守鱼群原则，注意构成与需要是单向关系，连接是双向关系 | |||||||
| 性能定义 | 界面打开时间（包括所有弹出窗口）：从点击到界面元素完全呈现，要求在1-1.5秒钟内 | |||||||
| CI清单查询：100个CI内的查询，从点击到完成查询，要求在2秒钟内 | ||||||||
| CI结构查询：树状目录层层展开，每一层的展开时间要求在1秒钟内，一次性全部展开节点的时间要求在3秒钟内 | ||||||||
| 操作时间：任何作业画面中点击保存的等待需要控制在2秒以内 | ||||||||
| 报表统计：控制在3秒钟内 | ||||||||
| 结构审计：可以控制在5秒内 | ||||||||
| 界面刷新：要求在作业过程中，不能存在对整个作业界面进行刷新的现象,整个作业界面的刷新控制度作业操作结束时 | ||||||||
| 1 | 属性管理 | 属性管理负责维护管理CMDB中的属性池 | ||||||
| 1.1 | 增加属性 | 属性池中可以随时增加一条属性，主要有三个信息，一是ID（数据库分配），二是属性名称（用户定义），三是属性说明(用户定义，用来描述此属性名称的含义，以利于调用） | 属性管理作业画面 | |||||
| 1.2 | 修改属性 | 属性池的属性名称与属性说明是可以被修改的，一旦修改属性名称或属性说明后，已调用此属性的所有分类的所有CI的信息应该得到更新 需给出重点提示，告诉用户有多少CI分类，多少个CI实例引用了此属性，并且有多少个CI实例已有属性值的存在。 | 属性管理作业画面 | |||||
| 1.3 | 停用属性 | 属性池的属性可以被停用，一旦停用后，原来被分配到此属性的CI信息中会被剔除此属性的显示，同时此属性在此状态下将不可被调用 需给出重点提示，告诉用户有多少个CI实例引用了此属性，并且有多少个CI实例已有属性值的存在。 | 属性管理作业画面 | |||||
| 1.4 | 删除属性 | 如果一个属性在没有被引用的情况下（没有任何一个CI类或一个CI实例此用），可以直接删除此属性 | 属性管理作业画面 | |||||
| 1.5 | 公用属性定义 | 如果一个属性属于公用属性可以直接被标识，这样所有CI实例都会引用到此属性，注意如果用户想取消公用属性的标识需要给出重点提示： 告诉用户有多少个CI实例引用了此属性，并且有多少个CI实例已有属性值的存在。 | 属性管理作业画面 | |||||
| 2 | 约束管理 | 约束管理负责对属性池的每一条的属性的填写进行约定、限制、指导 | ||||||
| 2.1 | 数据类型 | 每一个属性的属性值的数据类型进约定，共有三种类型，字符型、数值型、日期，每个属性的属性值必须且只能对应一种 | 约束机制作业画面 | |||||
| 2.2 | 输入方式 | 每一个属性的属性值的填写有二种方式，一种是手工输入，一种是界面选取，手工输入表示由用户直接录入，界面选取表示需要有基础数据的维护。需要对每一个属性的属性值进行规定输入方式，必须且只能选择一种 | 约束机制作业画面 | |||||
| 2.3 | 数据维护 | 如果输入方式是界面选取，需要对属性值进行基础数据维护，比如属性“品牌”，需要先维护好所有品牌数据，然后才界面中进行选取 注：责任人，服务目录、客户组织这个属性的数据从其它模块调入数据 | 约束机制作业画面 | |||||
| 2.4 | 单位维护 | 如果某一个属性的属性值是数值型时，需要选取一个单位 | 约束机制作业画面 | |||||
| 2.5 | 填写示例 | 对于字符型的属性值需要维护一个填写示意，以便后续CI实例的创建与维护 | 约束机制作业画面 | |||||
| 3 | 分类管理 | 建立与管理CI的分类体系，并维护管理分类与属性的关系信息 | ||||||
| 3.1 | 增加分类 | 分类是可以增加，无论是一级分类、二级分类、三级分类，在数据库设计层面要考虑未来扩充的可能性，在2年内联友的应用，CI分类不会超过三级 注意分类名不能重复 | 分类管理作业画面 | |||||
| 3.2 | 分类属性定义 | 增加一个分类后，可以从属性池中分配对应的属性给此分类，前提是此属性没有被此分类的父分类引用，一个分类可以拥有多个属性，注意公用属性不能被分类引用 | 分类管理作业画面 | |||||
| 3.3 | 修改分类 | 对分类的修改分为对分类名的修改； 对分类的父类归属修改，比如将二级分类程控交换机的对应一级分类是通讯设备，现在把它的对应一级分类改为网络设备； 对修改分类对应的属性进行修改，一旦为某一个分类添加了一个新属性时，已引用此分类的所有CI实例都需要增加此属性 如果为某一个分类減少一个属性时，需要检验所有引用此分类的CI实例的这个属性是否存在属性值，如果存在则不充许减少；如果没有值，则可以减少此分类的属性 | 分类管理作业画面 | |||||
| 3.4 | 停用分类 | 一个分类可以停用，一旦一个一级分类停用，其所有二级三级分类都会被停用； 停用分类的前提是： 没有CI实例引用此分类或其子分类 所有属于要停用分类的CI实例全部处于停用状态，此时可以对这个分类进行停用处理； 停用分类后，此分类将不可再被引用； 停用分类操作时，一定要给出足够醒目的提示信息 | 分类管理作业画面 | |||||
| 3.5 | 删除分类 | 分类可以被删除，删除的前提是： 1、此分类没有子分类 2、没有CI实例此用此分类或其子分类 一定要给出足够醒目的提示信息 | 分类管理作业画面 | |||||
| 4 | CI管理 | CI的创建与维护，同时CI结构在此进行构建与维护，日后的CI报废与停用等都在此作业管理 | ||||||
| 4.1 | 4.1.1 | 增加CI | 每一个CI实例都有一个唯一性的编码， 增加一个CI实例时可以手工操作，也可以直接复制CI实例的属性信息（结构信息、客户组织、责任人、服务目录这个属性信息除外），然后进行编辑或保存 | CI管理作业画面 | ||||
| 4.1.2 | CI分类确定 | 增加一个CI时，首先决定其分类，必须选取到最低层分类（即不能定位到一个仍有子分类的分类上） | CI管理作业画面 | |||||
| 4.1.3 | CI属性填写 | 选取CI的分类后，此时需要带出对应分类的所有属性，此时需要按照属性的约束机制进行录入或选取相应的属性值，注意要带出相关的属性说明及填写示例以利于用户理解及操作 | CI管理作业画面 | |||||
| 4.1.4 | CI结构维护 | CI结构维护时，有三种结构类型（构成，连接，需要），先选择结构类型，然后与选择对应的CI，此种的查询功能尤其重要，应可以根据类、编码、属性值进行检索需要进行关联的CI清单 注意： 在任何一个由构成关系的结构树中，一个CI只能在某个节点出现一次，否则会循环错误，程序需要建立校验机制 一个CI的构成父节点只能有一个，一个CI的构成子节点是多个注：当一个A-CI在构成关系中选择了B-CI,A-CI就是B-CI的子CI，B-CI就是A-CI的父CI 连接与需要的关系类型，是不会产生树状结构的，只是单层连接，显示也可能是一层的，不用逐层推演。 两个CI之间的关系类型只能有一种，且只能构建一次，不能双向构建。 | CI管理作业画面 | |||||
| 4.2 | 修改CI | 修改CI的属性值，当要对某一个CI的属性值进行修改时，首先要查询到这个CI，然后对在列出这个CI的所有属性值进行修改保存 修改CI的结构，连接、需要的结构改变，无需考虑影响，如果修改一个CI的构成（父节点时）需要做如下处理:新父节点在统计业务单据时会包含出此CI的关联业务单据（业务单据需要随着CI一同迁移） | CI管理作业画面 | |||||
| 4.3 | 停用CI | 只有当这个CI及其所有子CI与其它的任何CI没有连接与需要关系时才可以被停用，当一个CI被停用后，其所有子CI也会被停用，这样此CI及其所有子CI都不可再被定位与变更 | CI管理作业画面 | |||||
| 4.4 | 删除CI | 只有当CI及其子CI没有关联的业务单据时，同时此CI处于停用状态时，CI才可能被删除，一个CI删除后，其所有子CI将也会被删除 | CI管理作业画面 | |||||
| 4.5 | 虚拟CI | 虚拟CI的产生是因为管理与统计的需要，只是逻辑上的实体而非物理上的，在程序逻辑上与其它CI没有区别 | CI管理作业画面 | |||||
| 5 | 结构管理 | 把CI的结构维护功能用更图形化、更方便的操作维护，以便于使用过程的CI的结构维护 | ||||||
| 5.1 | 结构查看 | 采用树形目录方式查看CI结构信息，用户选定具体CI进行展示结构，构成的结构类型需要完成全部可以展开，连接与需要的结构类型只需要展一层即可 | CI结构管理作业画面 | |||||
| 5.2 | 结构维护 | 可以在树状目录中选定某一个节点(具体CI）进行结构维护（即属性值更改） 也可以直接在树状目录中增加一个CI节点，作业逻辑参考CI结构维护 结构维护作业界面需要考虑拖曳功能，即在界面右边的CI清单中直接拖入一个目录节点，即自动完成结构构建 | CI结构管理作业画面 | |||||
| 5.3 | CI更换 | 选定某一个节点（具体CI），然后进行CI更换，原有CI本身的父节点信息需要被新CI复制，而被更换的CI（含其所有子CI）全部脱离树状目录，被新CI（含其子全部CI）替代 被更换下来的CI将的状态默认为“停用” | CI结构管理作业画面 | |||||
| 6 | 基线管理 | CI的基线维护管理，实现基线打印及快照功能 | ||||||
| 6.1 | 快照生成 | 用户随时可以对某一个CI进行快照(即把这个CI及其子CI的所有属性信息及结构信息记录下来），如果此CI（含其子CI）在变更在处理过程中，需要给予提示，提示有多少变更作业在处理中，是否要生成快照 每做一次快照需要进行说明 | CI基线管理作业画面 | |||||
| 6.2 | 快照查询 | 先查询出某一个CI，然后列出此CI的快照记录，由用户选择某一次的快照进行查阅（需要调出树状目录） | CI基线管理作业画面 | |||||
| 6.3 | 快照打印 | 把某一个CI的全部快照信息，根据A4张打印出来 | CI基线管理作业画面 | |||||
| 7 | 变更操作 | 临时纳入CMDB功能的变更管理功能，提供一个用户界面，以便实现对CMDB数据维护的控制，日后此功能会移至变更管理中 | ||||||
| 7.1 | 变更申请 | 查询出某一个CI，调出本身及其子CI的所有属性信息及结构信息，列出当前值，用户填写变更值（用户可以把当前值复制到变更值中），用户需要填写变更单号以及变更说明，然后提交（如果一个CI的变更申请提交成功后，这个CI将处于锁定状态，即在此变更申请终结前，不得对此CI进行维护，这样可以有效避免CI调用冲突或快速定位事故诱发点） | 变更作业画面 | |||||
| 7.2 | 变更审批 | 对变更申请进行审批(需要列出变更申请的所有信息），只有通过或不通过，如果通过，则更新CMDB，不通过无需处理 | 变更作业画面 | |||||
| 8 | 批量维护 | 大批量的对CI进行维护管理 | ||||||
| 8.1 | 批量新增 | 只能批量新增同一个分类的CI，这批CI的所有属性信息是一样的，结构信息也是一样的，用户决定新增的数量，程序复制完成 另外提供批量导入功能，用户来决定分类，程序生成模版，用户完全根据程序模版实现导入（此功能需要有独立的权限控制） | CI批量维护画面 | |||||
| 8.2 | 批量维护 | 批量维护适用于相同分类的CI，并且这些CI的属性信息是完全一致，结构信息也是完全一致的。程序只需列出其中某一个CI的所有属性信息与结构信息（当前值），用户输入变更值（用户可以把当前值复制到变更值）,最后保存更新 批量维护的另一个作用是根据属性名称维护，用户查出所有含有这个属性名称的CI（可以根据分类查询，或根据父节点，或者属性值不为空，属性值的范围），系统只列CI编码信息、CI分类信息、还有就是这个属性信息，用户在输入变更值（用户可以把当前值复制到变更值），最后保存更新 | CI批量维护画面 | |||||
| 9 | 预警管理 | CI使用安全提醒功能 | ||||||
| 9.1 | 使用预警 | 根据出厂日期与使用年限进行计划，告诉用户哪一些CI已超过使用年限，哪一些一个月到使用年限，用户可以查询根据月数查询最晚12个月到使用年限的CI。注意已过使用年限的CI需要标红处理，建议形成看板（用户可以输入具体日期） | CI预警作业画面 | |||||
| 9.2 | 保修预警 | 根据起起保日期与出保日期与当前日期进行匹配，列出已过保，哪一些未来一个月即将过保的CI，用户可以查询根据月数查询最晚12个月过保的CI。注意已过保的CI需要标红处理，建议形成看板（用户可以输入具体日期） | CI预警作业画面 | |||||
| 10 | 审计管理 | 无论是哪一些类型的审计，只要用户产出清册后，再点击执行审计动作，此时可以在清册界面上，直接更新清册信息（用户可以复制原数值到审计值中）即属性值，最后点击结束审计，则完成审计动作 | ||||||
| 10.1 | 分类审计 | 用户可以根据某个分类（注意一级分类也可以是二级分类，也可以是三级分类）自行决定审计的比率或数量，然后生成审计的CI清单，可以根据A4纸打印，用户根据清册进行审计活动（需要空出一行由用户填写审计的结果） | CI审计作业画面 | |||||
| 10.2 | 属性审计 | 根据某一个属性的值范围（大于或等于，或包含）进行查询，把属于范围内的CI生成审计的CI清单，可以根据A4低打印，用户根据清册进行审计活动（需要空出一行由用户填写审计的结果） | CI审计作业画面 | |||||
| 10.3 | 结构审计 | 可以查找有多少有子CI但最上层父节点不是虚拟CI的CI，还可以根据CI的状态属性来减少查找范围（有报废的电脑），用此方法阶段性的审计结构，把游离CI清查出来 | CI审计作业画面 | |||||
| 10.4 | 随机审计 | 用户决定随机审计的数量，并不做任何限制，在所有CI中随机挑选出CI，列出清单 用户决定天数（多少天内发生变更的CI），在这个时间范围内发生过变更的CI中输入审计数量，随机挑选CI抽查守计 | CI审计作业画面 | |||||
| 10.5 | 固定审计 | 用户根据分类或属性值范围进行审计，审计的对象是范围内的全部CI | CI审计作业画面 | |||||
| 10.6 | 清册打印 | 清册需要根据A4纸打印，列出所有的CI属性信息 | CI审计作业画面 | |||||
| 11 | 清单查询 | 查询具体的CI实例信息 | ||||||
| 11.1 | 分类查询 | 根据CI的分类（一级、二级、三级都可以查询）来进行查询CI清单 | CI清单查询画面 | |||||
| 11.2 | 属性名称查询 | 根据CI的属性名称查询CI清单，比如查询包含某个属性的CI有哪一些 | CI清单查询画面 | |||||
| 11.3 | 属性值查询 | 根据CI属性值范围查询（等于，不等于，大于或等于，大于或小于，大于，小于，包含，不包含，空）再加上与和或的逻辑运算。 | CI清单查询画面 | |||||
| 11.4 | 节点查询 | 查一个CI有哪一些子CI（构成） 查一个CI的所有父CI（构成） 查一个CI的连接CI有哪一些CI（连接） 查一个CI的需要CI有哪一些CI（需要） 查一个CI的被需要CI有哪一些CI(需要） | CI清单查询画面 | |||||
| 12 | 结构查询 | 树状目录必须从某一个CI为作根节点展开，列出所有构成的子CI（注意根据类名称显示,一个父节点下面在构成是一百台台式机，但在树状目录上显示是/父节点/台式机/001，002，003。如此便于用户阅读目录） 连接、需要的只列出跟这个CI连接与需要的CI（同样中间用类名称作为中间桥接） 点击某一个节点时，需要列出此节点（CI）的所有属性信息 | CI结构查询画面 | |||||
| 13 | 报表管理 | CMDB的各类报表管理 | ||||||
| 13.1 | 分类信息统计分析 | 统计当前的分类个数，一级分类的有几种，二级分类几种，三级分类几种，总数多少种 | ||||||
| 13.2 | 属性信息统计分析 | 把属性池的利用情况做一次分析，有多少属性被引用，引用的次数是多少，有多少属性的值为空， | ||||||
| 13.3 | CI数量统计分析表 | 可以根据结构（项目）、属性值范围（客户组织、运维团队），统计分析当前CI的数量分布情况，根据CI分类列出来，要有图表 | ||||||
| 13.4 | 变更活跃度分析 | 根据CI分类，或者根据结构（项目），统计变更发生的次数，变更的信息可以分为结构变更与属性变更（查询出来的画面，点击数字后，直接进入每日变更统计表） | ||||||
| 13.5 | 变更统计 | 按日期变更次数需要有统计数据，点击次数的数字后需要列出具体的变更记录列表 | ||||||
| 13.6 | 审计统计分析 | 统计每次审计的CI总数，发现问题的CI总数（有更新CI信息的CI），得到正确率 | ||||||
| 14 | 日志管理 | 查询动作不必记录，需要记录所有数据操作记录，把直接在CMDB中进行数据操作的人员与操作内容记录下来，在备查验 | 操作日志查看画面 | |||||
| 制作人： 流程经理审核： 运维部长审核： | ||||||||
2
推荐到鲜果： 查阅更多相关主题的帖子: IT服务管理 IT治理 IT规划案例 ITSM系统 CMDB ITIL
评论
发布者 ewaysun
2007-9-14 16:12:23
发布者 匿名用户
2007-9-26 19:47:21
to:“CI分类：根据物理形态把CI划分为某一个种类”
当应用程序的模块，以及模块里的进程都是我们需要运维的时候，那CI的分类不仅应该考虑软件本身，更应该考虑软件的构成。 对于硬件来说，CI的关系是比较清晰的，但是对于负责的应用程序来说，这种CI的关系就非常复杂了(模块和模块之间的调用，进程和进程之间的关系，以及随时都有三者插入进来改变两个CI的现有关系等等)。
发布者 fatfatfish
2007-9-29 9:40:41
1） 关注你的文章很久，也提了一个问题；
2） “配置管理业务要件”是你提出来的吗？
3） “配置管理业务要件”是MO公司提出来的吗？
4） “配置管理业务要件”我认为更像是一个产品功能需求？
5） “配置管理业务要件”能指导开发吗？
不吝赐教！谢谢！
发布者 chenhe1968
2007-10-4 16:40:34
发布者 破子
2007-10-8 8:32:47
1） CI确认的标准？不是构成，也不是分类。
2） CI属性确认标准？CI关系中“构成”能够进行属性继承吗？
3） CI关系中“使用”的具体说明？
谢谢！
发布者 chenhe1968
2007-10-8 16:37:50
1、你说的CI确认是指如何认知一个CI吗？构成只是一种CI间的关系类型，分类是指CI的属于哪一类的东西，比如如果说我们硬盘与一台电脑的关系是构成，但硬盘本身是属于一个CI分类的（存储设备）
2、CI的属性是为了描述CI本身的信息的，比如上面说的硬盘的例子，这个硬盘是哪个品牌的，转速多少，空间多大，保修年限多长，这些就是属性信息；构成是关系类型，不是属性，所以不会继承（事实上是没有必要继承，如果你把关系信息当成属性的一种，也是可以的）
3、CI关系的作用，事实就是为了展现整个基础架构，然后进行一些推演功能，在我们的应有中，是利用关系把CI串在一起的，然后在做事件定位时，会非常方便，而且便于工程师理解基础架构的现状。
注：关于1与2，如果你问的意思是，CI的颗粒度是怎样确认，CI的属性信息怎么确认有哪一些，我的回答跟顾问们一样：由你的管理需求决定，没有硬性标准。这要考虑到你的管理需求与运维能力的。
发布者 破子
2007-10-9 8:32:58
"两个CI之间的关系类型只能有一种，且只能构建一次，不能双向构建。" 这个规定是否能符合“节点查询”功能要求？
发布者 nastar
2007-10-9 15:13:27
发布者 破子
2007-10-18 16:18:45
发布者 jbanner
2007-11-8 14:18:10
发布者 hu_nick
2008-6-30 11:39:17
配置管理就像ITSM，没有相应的软件平台支持，都无法实现。
破子的CMDB做得很棒，很佩服！
发布者 Rusca
2009-2-9 15:23:21
发布者 chuwei_01
2009-6-25 16:10:29
发布者 匿名用户
2009-8-13 10:49:07
发布者 acho01
2009-9-17 21:43:36
发布者 rnjiang7412
2009-11-23 16:16:53