学习资料： ITIL培训基地专家讲堂直播 300期视频回放
转：破子xqscool/
CMDB真言
1、 现在开始讲解CMDB
2、 CMDB是指记录服务的对象的配置信息的数据库
3、 CI是指一个服务对象
4、 服务至少由服务指标、服务主体、服务客体、服务目录、服务对象5个要素所构成
5、 缺少5个要素中的任何一个，都无法真正定义一个服务。
6、 通过定义服务5个要素，服务的范围、深度、水平、成本、资源得到明确
7、 服务的主体与服务客体不应做IT与业务的二元对立
8、 服务是管理体系的第一单位
9、 管理体系是流程的总和
10、 服务是流程的管理对象
11、 流程是服务的过程定义
12、 当服务无法被定义时，服务管理无法成立。
13、 当服务无法被测量时，服务管理无法成立。
14、 服务指标是指服务质量的度量参数
15、 服务主体是指接受服务的人或组织
16、 服务客体是指提供服务的人或组织
17、 服务目录是指满足服务主体的特定需要的一系列活动
18、 服务对象是指支撑服务的实体
19、 配置信息是指服务对象的描述信息
20、 一个服务至少包含一个服务对象
21、 一个服务对象至少属于一个服务
22、 服务的范围与CMDB的范围成正比
23、 运维能力与CMDB的颗粒度成正比
24、 类池、属性池、关系池、状态池是CMDB的基础数据
25、 类池是指所有服务对象的分类的数据总和
26、 属性池是指所有服务对象的属性种类的数据总和
27、 关系池是指所有服务对象的关系种类的数据总和
28、 状态池是指所有服务对象的生命期类种的数据总和
29、 类池、属性池、关系池、状态池应可手工维护
30、 任何一个类均会从属性池中分配特定的属性
31、 任何一个类均会从关系池中分配特定的关系
32、 任何一个类均会从状态池中分配特定的状态
33、 类、属性、关系、状态之间的分配应可手工维护
34、 CI是服务对象在CMDB中的投影
35、 任何一个CI都必然只属于一个类
36、 一个CI有哪几个属性、哪几种关系、哪几种状态是由它的类决定的
37、 结构化的类池会有利于统计分析，但需要考虑数据继承问题
38、 在一个结构化的类池中，只有叶节点的类才允许被分配给CI
39、 类是CMDB基础的基础，调整的成本及风险最大。
40、 类是第一选择，因为它比属性更容易实现数据统计、展现及分析
41、 应优先用两个类而不是用属性来区分两个属性集相同的不同分类
42、 类的设计需要全面，节省类而用属性区分，会为以后带来隐患
43、 叶节点的类与类之间不应有父子的关系
44、 将一个实体对象分拆成多个对象后，原有的对象将不复存在
45、 将一个实体对象分拆成多个对象后，观念的扭转将是困难的
46、 当一个类无法被界定时，需要考虑是否保留
47、 当一个CI无法被定位时，需要考虑是否保留
48、 当一个状态无法被追踪时，需要考虑是否保留。
49、 当一个属性无法被查验时，需要考虑是否保留
50、 当一个关系无法被调整时，需要考虑是否保留
51、 配置项的状态不等同于配置项的生命周期
52、 将每个类之间的关系定义完成后，即完成CMDB的关系图谱，它决定了展示模型
53、 先设计每一个分类的关系及状态，最后设计分一个分类的属性
54、 在结构化的分类树中，每个层级都可能会有专有属性
55、 分层级继承的属性分配模式会带来查询与统计上的优势
56、 公共属性可以是事先设计定义好，然后进行强制分配给每一个类
57、 可以先定义好每一个类的所有属性，然后做分析共性来定义公共属性
58、 即便是两个不同分类的信息完全一致，在数据库层面仍需要分表存放
59、 不经分析而夸大配置维护的工作量是常见的误区
60、 估算出每一个分类的CI数量状态属性关系的变更频率与耗时，即可知维护成本
61、 CI的查询需要有一个统一而强大的搜索界面
62、 搜索条件可根据分类、关系、状态、属性、关联服务、关联单据、维护情况
63、 CI的维护需要一个统一而强大的作业界面
64、 查询与维护画面的不统一会引发日后维护的问题
65、 业务影响是基于关系进行的计算，而不是基于业务影响设计关系
66、 CMDB的模型可以根据关系、类显示与过滤
67、 CMDB的模型的CI信息可以根据任意的属性名称标记
68、 CMDB的模型的每一种CI分类可以设定特定的图例
69、 具体画面、清单列表、模型表达是CMDB三种信息表达方式
70、 凡是输入CMDB的数据应同样可以输出
71、 应可根据类、属性、状态、关系、服务进行配置项的数量统计
72、 应可根据类、属性、状态、关系、服务进行配置项的维护次数与频率统计
73、 应可根据类、属性、状态、关系、服务进行配置项的空置率统计
74、 应可根据类、属性、状态、关系、服务进行配置项的服务作业统计
75、 应可将CMDB信息与服务作业信息进行整合分析
76、 配置审计是数据质量最后一种保障手段
77、 CMDB的建设目标首先需要服从配置管理的流程目标
78、 配置管理的流程目标需要服从服务管理体系的管理方针
79、 忽略配置管理的目标而考虑CMDB对其它流程的支持往往会失败
80、 CMDB只是现实服务对象的投影，而不是现实对象本身
81、 配置信息不仅仅只存在于CMDB之中，所以配置管理只着眼于CMDB是不全面的
82、 配置信息是变更的作业结果，而不是变更的作业目标
83、 真实描述现实服务对象，是建设CMDB的第一原则
84、 对于构建一个CMDB而言，构建的思想比工具要更加重要
85、 人们常常无法区分CMDB与CMS的差别，同时又混淆CMS与ITSMS的边界
86、 天下模型，无所不破，唯真不破
87、 变更的作用是控制现实对象本身，而不是CI
88、 配置信息可能包括IT架构信息与服务管理信息
89、 变更控制的精细度应与配置管理的CI颗粒度保持一致
90、 配置信息维护往往是由于人们不愿维护，而不是错误维护
91、 配置信息维护策略以方便、提醒、审计为主，而不是限制
92、 业务需求调研的结果应侧重于数据层面而不是功能层面
93、 当需要CMDB的企业不清楚什么需要被满足时，其结果必然是不满足的。
94、 CMDB的失败多数是因为不清楚目标，导致没有焦点与判定成功的标准。
95、 CMDB理论上的价值不能等同于企业的业务需求。
96、 在一个实施周期内追求更多的功能、CI、属性、模型，是不受控制的结果。
97、 为领导做CMDB，而不是为工程师做CMDB的现象难以长久。
98、 追求模型，轻视数据是一种本末倒置的现象
99、 本质上，模型是没有意义的，它只能愉悦感官。
100、 合格的工具、优秀的顾问、严谨的管理是CMDB实施成功的必要条件
除了死亡，一切只是概率
|
转播
分享
淘帖
()
