CMDB建设如何建立后续生命周期管理体系?如果与各类管理和运维平台对接?

新建CMDB如果规划?如何建立后续生命周期管理体系?如果与各类管理和运维平台对接?

3回答

jason2006xujason2006xu  技术经理 , 昆仑银行
老同志lawso赞同了此回答
目前资源的生命周期管理流程基本都在运维中心建设,实现资源生命周期管理的集中化与电子化,是一项长足的进步。在形成规范的电子化流程后,需要进一步细化资源生命周期场景,继续细化资源的操作,实现资源的到货接收、上架加电、资源测试、资源上线、资源维护、资源下线、资源报废...显示全部

目前资源的生命周期管理流程基本都在运维中心建设,实现资源生命周期管理的集中化与电子化,是一项长足的进步。在形成规范的电子化流程后,需要进一步细化资源生命周期场景,继续细化资源的操作,实现资源的到货接收、上架加电、资源测试、资源上线、资源维护、资源下线、资源报废等操作,
提高资源管理的管理水平,保障资源的消费。在资源的上线,下线和应用的各类操作中,通过监控管理系统,ITIL等各个系统,实现了对资源的全生命周期管理。在资源的生命管理中,提供资源数据服务和资源状态统一管理服务,与资源流程紧密结合完成资源的生命周期管理。
生命周期流程服务,配置管理流程属性分类增加
要求继续使用原来定义的配置管理流程,在新建配置管理流程时,可选择配置管理流程的分类字段:到货接收、上架加电、资源测试、资源上线、资源维护、资源下线、资源报废等。
生命周期数据服务,在资源的到货接收、上架加电、资源测试、资源上线、资源维护、资源下线、资源报废等资源操作中,提供统一的资源数据支撑服务。
【功能要求】
选择不同的资源操作,提供各种类别的资源数据模版,实现各个流程的资源数据的录入和修改工作。
为资源各个流程,提供资源数据校验功能,并将资源信息校验结果反馈给调用的系统。
为资源各个流程,提供资源数据入库功能,并将资源信息入库成功失败消息反馈给调用的流程。
【功能要素】
输入要素:操作类型、资源ID,资源名称,资源类型;
内部要素:资源ID、资源名称、资源类型、配置管理员;
输出要素:资源模版,资源信息;
在资源的全生命周期管理中,建立统一的资源状态管理系统,完成资源数据变化情况的统一管理,资源系统与外部系统的状态交互。

收起
 2019-12-11
浏览1286
aixchina 邀答
eximbankeximbank  系统架构师 , 某金融企业
1, CMDB 一定是将业务应用需求-->设计-->开发代码-->服务运营-->服务运维及系统运维, 持续改进等所有业务-应用服务 与 资源的全链路管理,这个 CMDB 就有价值,也是应该按照这个思路的u规划设计;2,IT 系统本身运营来说,就是不断从运营模型化、抽象化、粒度...显示全部

1, CMDB 一定是将业务应用需求-->设计-->开发代码-->服务运营-->服务运维及系统运维, 持续改进等所有业务-应用服务 与 资源的全链路管理,这个 CMDB 就有价值,也是应该按照这个思路的u规划设计;
2,IT 系统本身运营来说,就是不断从运营模型化、抽象化、粒度化和数字化展示的过程,因此需要持续增加管理模型、覆盖 DataCenter 中的所涉及的全部模型来汇聚管理力度,这个过程持续,则会将CMDB或者所建的生命周期体系管理得更加完善;
3,对接平台一定是吸收管理粒度、增减管理链路、精细化管理对象的升华过程,但是对接多少、吸收多少对象、粒度数据要多少,就需要 CMDB 的架构和技术持续升级改造来支撑,因此,规划 CMDB 需要这种可扩展、便捷性和灵活性的需求。

收起
 2019-12-24
浏览701
aixchina 邀答
老同志lawso老同志lawso  售前产品总监 , 富通云腾
CMDB项目落地的思考,欢迎讨论: 项目之初要有对应的生产场景,这样落地之后才会有人去用,没人用就废了,例如针对业务系统、网络、操作系统、硬件维护、数据库、中间件等业务场景设定服务目录和CMDB的内容,这样建立之后,对维护人员有价值,这样当CI对象出现变化时,维护人员才会有...显示全部

CMDB项目落地的思考,欢迎讨论:

  • 项目之初要有对应的生产场景,这样落地之后才会有人去用,没人用就废了,例如针对业务系统、网络、操作系统、硬件维护、数据库、中间件等业务场景设定服务目录和CMDB的内容,这样建立之后,对维护人员有价值,这样当CI对象出现变化时,维护人员才会有动力进行CMDB的更新,保证CMDB的准确性

  • 项目过程中,要根据场景考虑CI的颗粒度,颗粒度越细意味着CMDB的维护工作量也会很大。例如对应业务维护的场景,业务系统的CI项需不需要到端口,如果到端口,那么后期业务做任何变更的时候都要把端口的关系写清楚才可以去变更,否则不行

  • 项目完成时,应该有亮点,否则怎么体现项目的价值,并为下期项目做铺垫,建议在展示上下功夫

  • CMDB的建设过程:

       ○ 一期 根据业务场景,建立CMDB,根据CMDB能够实现业务模型的可视化,手工绘制业务模型也可以

       ○ 二期 利用CMDB,根据运维业务场景,自动建立点对点业务可视化模型,例如业务模型可以分为三层:交易层、业务层和基础架构层,然后将性能数据和告警事件与CI项进行关联,当业务出现故障时,不同的维护人员查看不同的可视化拓扑,共同进行故障场景的故障根源性分析。当CMDB发生改变时,可视化模型自动进行更新。

       ○ 三期 进行AI运维智能化建设,利用二期故障根源性分析积累的经验,在整体运维故障场景中进行AI智能化故障根源性分析,建立AI大脑,由人工向智能发展
    CMDB与其他运维平台的对接:

  • 与云管平台的联动:

    这个实例实际上也是CMDB与运维流程的联动例子:

       ○ 用户提交创建申请给云管平台

       ○ 云管平台根据申请,准备创建工作,创建工作中有CMDB的CI项,如IP地址,则从CMDB IP项中找未用的IP给云管平台

       ○ 开始创建工作

       ○ 创建工作后,对CMDB需要的CI项进行信息汇总,然后发送到CMDB中进行更新,例如IP地址、虚机的相关配置数据等

  • 与网络的联动
    网络维护作为CMDB建设的重要场景,实现网络与CMDB的联动,保证网络相关CI和CI关系的实时性和准确性,虚拟化以vmware为例:
    网络设备相关CI:

       ○ 网络设备

       ○ 网络设备板卡

       ○ 虚拟网络设备(虚拟交换机、虚拟分布式交换机、宿主机物理网卡、虚拟网卡)

       ○ 虚拟网络(Portgroup)

       ○ 物理网络设备的网络端口
    CI属性信息:

       ○ CI固有属性(品牌、型号、位置、维护人员等)

       ○ CI配置需要的信息(名称、IP地址、CPU、内存等信息)

       ○ CI资产管理需要的信息(所属人员、厂商、入库时间、报废时间等)

       ○ 财务管理需要的信息(价格、折旧等)

       ○ CMDB管理所需的信息(CI名称、分类、描述等)
    网络设备相关关系

       ○ 服务器连接端口

       ○ 网络设备包含端口

       ○ 网络设备包含板卡

       ○ 板卡包含端口

       ○ 虚拟交换机连接物理交换机端口

       ○ 虚拟交换机包含物理网卡

       ○ 虚拟网络连接虚拟交换机

       ○ 虚拟网卡连接虚拟网络

       ○ 虚拟分布式交换机连接物理交换机端口

       ○ 虚拟分布式交换机包含物理网卡

       ○ 虚拟网络连接虚拟分布式交换机
    CI的属性

       ○ 类型

       ○ 子类型

       ○ CI编号

       ○ CI名称

       ○ 说明

       ○ 生命周期状态

       ○ 创建时间

       ○ 创建人

       ○ 更新时间

       ○ 更新人
    CMDB网络信息维护部门:

       ○ 网络部门

       ○ 虚拟化部门

  • 与网络的联动:

       ○ 网络设备采购后,通过工单的形式入资产管理帐与CMDB,在CMDB中状态可以为『新入库』,意思是已进入CMDB库,但是还未投入使用,投入 使用后,状态可以变更为『生产中』

       ○ 网管软件将网络设备的最新状态自动更新至CMDB,包括新增和修改,可以设置为定时轮询,定时轮询的数据可以去CMDB的数据进行比对校准

      ○ CMDB通过接口为网络变更单提供最新的CMDB信息,当变更单状态为『实施』时,触发程序,将变更内容更新至CMDB

  • 与监控系统之间的联动:
       ○ 监控系统为CMDB提供CI数据,保证CI的自动实时更新

       ○ CMDB为监控系统处理故障提供配置支持

    通常自动更新率是CMDB很重要的考核指标,自动更新可以让监控系统来实现,无论是有agent的方式,还是通过SSH等方式都可以获取CMDB需要的CI信息:

       ○ 主机名

       ○ IP地址

       ○ 操作系统版本

       ○ 数据库版本

       ○ 中间件版本

       ○ CPU信息

       ○ 内存信息

       ○ 磁盘信息

       ○ 逻辑盘信息等

    在CMDB建设时,能够通过监控获取的数据尽量通过监控来获取,同时获取的数据可以和各个运维维护组手里的配置库进行比对,查漏补缺,确保数据的正确性。在CMDB维护期,可以通过变更单来保证CI的准确性,也可以用监控获取的数据来做数据的校准,保证CMDB不成为『垃圾库』。

    对于运维来说,要保证『安全生产』,而监控系统是维护业务稳定的重要手段,所以CMDB建设过程中也必须考虑对监控的支持,这种监控上的支持也应该能够成为CMDB建设的亮点。例如:

       ○ 故障处理过程中,需要查询故障相关的配置情况以帮助判断问题

       ○ 故障处理过程中,CMDB支持以拓扑视图的方式展现故障发生时的形态,例如故障的根源判断、故障的影响范围。

  • 与自动化部署的联动:
       ○ 自动化部署工作通常是通过部署在被管理机上的agent进行,所以通过agent可以获取主机的配置数据,当然具体的自动化部署软件的不同,获取的配置数据是不同的(文章最后是通过ansible获取centos6.5的配置数据文件),这些数据可以被取出发送到CMDB库中进行更新。
       ○ 自动化部署工作在部署之前需要获取主机列表、操作系统版本及补丁情况、应用软件、应用端口。。。等,只有符合部署条件的主机才能进行部署工作,这些检查工作可以借助CMDB的数据进行,检查结束后进行部署,部署完毕后,将部署的内容对CMDB的相关内容进行更新,以保证CMDB的准确性。

  • 与容灾备份的联动:
    容灾备份在企业中也很普遍,保证业务的可用性和连续性。那么容灾备份与CMDB如何联动呢?可以从下面几个方面来进行考虑:
       ○ 灾备系统能够在发生问题时顺利切换,首先要保证主备双方的基础运行环境:操作系统版本、系统补丁版本、应用软件版本、软件运行环境参数等顺利切换的条件要满足,CMDB可以对这些选项进行检查,保证条件的满足
       ○ CMDB也要保证可以采集并自动更新这些这些灾备切换所需要的CI项,并可以对这些CI项的属性进行检查,不满足灾备切换条件时,进行告警
       ○ CMDB除了CI项,还有CI之间的关系,从业务的角度来说,实际上是业务的架构拓扑视图,以及业务之间的关联拓扑,所以当出现故障时,也可以很方便的掌握这次故障的影响范围。这种故障影响范围也可以通过监控系统的业务拓扑来完成,业务拓扑的绘制可以根据CMDB来进行绘制。。。。,这是另一个讨论话题了
       ○ 可以利用监控系统对灾备系统CI的运行状态进行监控,CI出现问题时进行报警

  • 与故障告警之间的联动:
    从故障解决的角度上说,需要了解故障相关的:
    ○ 故障点的详细配置数据 (CMDB可以提供)
    ○ 故障点的业务拓扑结构,以方便了解故障的影响范围和判断故障 (CMDB可以提供)
    ○ 故障点的基础架构拓扑图,以方便了解故障点与上下架构之间的关联关系,判断问题的根源 (CMDB可以提供)
    ○ 故障点最近的变更记录,以了解变更对于故障的影响程度 (CMDB可以与变更管理互相联动)
    ○ 故障点的运行数据和历史告警事件 (CMDB可以与监控系统联动)
    ○ 故障点的联系人信息 (CMDB可以提供)

收起
 2019-12-11
浏览1130
aixchina 邀答

提问者

itjava系统工程师, 某保险

CMDB选型优先顺序调查

发表您的选型观点,参与即得50金币。

问题状态

  • 发布时间:2019-12-10
  • 关注会员:5 人
  • 问题浏览:3821
  • 最近回答:2019-12-24