本帖最后由 monicazhang 于 2015-10-22 10:43 编辑
20151022 淡然 续上
8.5 流程执行原则8.5.1 常规原则 n 配置管理数据库将为所有IT运行及服务管理流程提供所需信息，特别是针对事件和变更管理流程；所有事件、问题、变更、发布流程触发后，均需要判断是否涉及到配置项信息的变化，如果涉及，则需要根据配置管理流程维护其信息和CMDB信息的一致性 n 所有配置项信息必须存储在一个数据库管理系统中 ITSS考试 n CMDB准确反映当前已知的IT架构状态 n 应该每半年对流程进行回顾，回顾内容包括流程关键衡量指标、流程执行效率和流程支持工具的有效性，以改进配置管理流程
8.5.2 所有权原则 所有权原则用来确保配置管理每类活动都有适当的人员负责。下表是配置管理中各角色在各活动中承担不同责任的RACI模型。 [td][td]
| | | | | 配置管理策略的制定
| | | | | 配置项定义和标识
| | | | | CMDB初始化
| | | | | CMDB控制和维护
| | | | | CMDB审核和回顾
| | | | | 定期生成配置管理报告
| |
| | | RACI模型说明 A: 负全责; R: 有义务; C: 提建议; I: 需知会
|
8.5.3 流程关联原则 ITSS认证 n 和变更管理的关联 Ø 变更主管在变更计划阶段必须制定配置项更新计划，对计划修改的配置项进行说明 Ø 变更实施完后，由变更主管汇总相应的配置项修改的情况，并通知相应的配置管理员，配置管理员接收到配置项修改请求后，与CI实体进行核对，核对无误后方可修改CI属性以及关系 Ø 对于风险等级为高和重大的变更，CAB中应该包括配置经理，以确保对CMDB的适当控制 Ø CI应与变更记录建立关联，从而对CI的变化情况进行记录 n 和发布管理的关联 Ø 发布主管在制订发布计划阶段必须制定配置项更新计划，对计划修改的配置项进行说明 Ø 在发布实施完成且得到确认并关闭后，由变更主管汇总相应的配置项修改的情况，并通知相应的配置管理员，配置管理员接收到配置项修改请求后，与CI实体进行核对，核对无误后方可修改CI属性以及关系 n 和事件管理、问题管理的关联 Ø CI应与事件记录、问题记录建立关联，从而确保对CI维护工作的统计和分析
8.5.4 控制原则 n 所有有关生产环境配置项的更改都需要通过变更管理流程进行控制 n 只有得到授权的人员（配置管理员）才能对CMDB中的配置项信息进行修改，修改之前需要对物理CI的属性进行核实 n 任何设备进机房前或系统投入使用前必须启动配置管理流程，以确保配置项信息与物理环境的一致 n 其他流程会引发对配置项的修改，日常使用中发现的配置项信息的不正确需要相应的修改，CMDB审核也会引发对配置项的修改，以上均需要通过变更管理流程的控制，发起配置项修改需求的人将作为变更请求者，通过变更管理流程进行相应的审批，实现对CI信息的修改控制（在变更结束阶段通知相关的配置管理员修改配置项）。 n 在CMDB建设的初期，由于数据仍然处于调整中，可以由配置经理定义一个时间段，该时间段内的数据调整可以不经过变更管理流程控制 n 当确认配置项信息不需要在CMDB中保留时，进行配置项的删除，配置项的删除不在CMDB中进行物理删除，通过删除状态属性来标识其被删除与否。 n 需要至少每季度通过计算配置项的“服务到期日期”来对配置项是否过保进行预警
8.5.5 审核原则 n 配置管理流程必须每半年对IT环境进行审核、跟踪监测，以保证CMDB的信息收集准确、完整，并与实际IT环境的状态高度统一。该工作由配置经理负责 n 应该定期根据变更的执行情况对变更引发的配置项的修改情况进行审核 ITSS培训8.6 流程相关定义 配置项属性参见《资源管理分册》。
| 
转播
分享
淘帖
()