目前资源的生命周期管理流程基本都在运维中心建设,实现资源生命周期管理的集中化与电子化,是一项长足的进步。在形成规范的电子化流程后,需要进一步细化资源生命周期场景,继续细化资源的操作,实现资源的到货接收、上架加电、资源测试、资源上线、资源维护、资源下线、资源报废等操作,
提高资源管理的管理水平,保障资源的消费。在资源的上线,下线和应用的各类操作中,通过监控管理系统,ITIL等各个系统,实现了对资源的全生命周期管理。在资源的生命管理中,提供资源数据服务和资源状态统一管理服务,与资源流程紧密结合完成资源的生命周期管理。
生命周期流程服务,配置管理流程属性分类增加
要求继续使用原来定义的配置管理流程,在新建配置管理流程时,可选择配置管理流程的分类字段:到货接收、上架加电、资源测试、资源上线、资源维护、资源下线、资源报废等。
生命周期数据服务,在资源的到货接收、上架加电、资源测试、资源上线、资源维护、资源下线、资源报废等资源操作中,提供统一的资源数据支撑服务。
【功能要求】
选择不同的资源操作,提供各种类别的资源数据模版,实现各个流程的资源数据的录入和修改工作。
为资源各个流程,提供资源数据校验功能,并将资源信息校验结果反馈给调用的系统。
为资源各个流程,提供资源数据入库功能,并将资源信息入库成功失败消息反馈给调用的流程。
【功能要素】
输入要素:操作类型、资源ID,资源名称,资源类型;
内部要素:资源ID、资源名称、资源类型、配置管理员;
输出要素:资源模版,资源信息;
在资源的全生命周期管理中,建立统一的资源状态管理系统,完成资源数据变化情况的统一管理,资源系统与外部系统的状态交互。
1, CMDB 一定是将业务应用需求-->设计-->开发代码-->服务运营-->服务运维及系统运维, 持续改进等所有业务-应用服务 与 资源的全链路管理,这个 CMDB 就有价值,也是应该按照这个思路的u规划设计;
2,IT 系统本身运营来说,就是不断从运营模型化、抽象化、粒度化和数字化展示的过程,因此需要持续增加管理模型、覆盖 DataCenter 中的所涉及的全部模型来汇聚管理力度,这个过程持续,则会将CMDB或者所建的生命周期体系管理得更加完善;
3,对接平台一定是吸收管理粒度、增减管理链路、精细化管理对象的升华过程,但是对接多少、吸收多少对象、粒度数据要多少,就需要 CMDB 的架构和技术持续升级改造来支撑,因此,规划 CMDB 需要这种可扩展、便捷性和灵活性的需求。
CMDB项目落地的思考,欢迎讨论: