专栏首页互联网运维杂谈运维CMDB建设思路

运维CMDB建设思路

在我们日常的运维工作中,面对着大量的基础设施和软件服务,该如何管理?这个管理的原则又是什么?粒度该如何控制?我们是否可以建立一个统一的标准模型来管理以上对象?管理过程中,如何降低人力成本?资源对象的生命周期管理如何实现?这么多的疑问,所有的运维人都会想到ITIL中的CMDB。的确CMDB在ITIL中应该算是一个核心概念,以它为基础,才能构建起相关的其他运维活动,因为所有的活动都需要与这个CMDB平台交互。在CMDB构建的过程中,都会碰到如上的问题。

记得我刚刚做运维去建设CMDB的时候,觉得非常的轻松。这源于刚工作时候的一份经历,负责电信资源管理系统的开发,电信的资源非常多,从我们日常开通一个电话,电信分配了哪个端子、哪个端口、哪个交换机,他们之间的级联关系,使用了哪个号码都需要完整的记录下来。后续新的业务办理(比如说移机),也需同步记录这些占有资源的变化,可以说这个系统就是一个非常强大的CMDB的系统。这都源于电信背后一套成型的体系----NGOSS(见下图)。

NGOSS是下一代运营支持系统(New Generation Operations System And Software)的缩写,他从业务流程、系统信息模型构建到技术架构实现再到运行管理都提供了一整套的体系框架,他们分别对应四个不同的子系统----业务视图、系统视图、实现视图、部署视图。每个子系统又有一套指导框架,比如说业务视图框架eTOM;系统视图框架是以统一信息实例(SID)来指导;架构框架是TAF的等等。这个模型整体解决思路是从业务活动视图导出信息模型再导出技术实现方案,依此类推。其中尤其以前面两个视图最为重要。

NGOSS的业务视图,它吧电信内部的业务活动按照领域模型分成了不同子欲,在每一个子域中不断向下细分,最后得出各个明确的业务框架和活动视图。整体业务视图框架【见eTOM模型规范】如下:

在如下下图中,我们可以看到左边的系统模型视图如何映射到右边的活动视图上【来自于CTG-MBOSS规范】:

我们在构建CMDB的时候,其实也可以完全遵循这套方法论,我们首先一定要搞清楚,我们日常的运维场景中有哪些活动?比如说服务器申请、回收、IP地址分配回收、进程的上下线等等,这是我们建设CMDB的首要原则,不要臆想我们要管理哪些资源,比如说glibc的版本库。通过活动的识别,去导出管理的资源对象。当我们已经明确要管理的目标对象(CMDB中叫配置项)时候,剩下就是模型构建该干的事情了。此时的资源对象涉及两个方面的问题:第一、我们管理的对象资源范围是?第二、每个对象需要管理的数据粒度是?

第一个问题可以简单些理解,从我们面对要管理的对象来说,可以把它们划分成物理对象和逻辑对象。物理对象你可以理解实际存在的物理实体,比如说服务器、交换机、机架等等;逻辑对象可以理解成非物理存在的实体,比如说IP资源、操作系统以及资源之间的关系。这个里面的方法可以完全遵循面向对象的分析方法,实体之间有继承、实体之间有引用等等。第二个问题----资源对象粒度是什么?首要取决于当前管理的成本收益比。比如说在一个完全手工的环境中,如果你想管理机器上的硬件配置信息,此时代价非常高昂,个人也就不建议这么做,如果有一定的自动化工具辅助管理,这可以考虑对象粒度更细致一些。其次我们要看这个管理到底反向支撑到的运维作用是什么(质量、安全、效率、平台工具等等)。

但我们确定了管理的资源对象之后,此时可以借助一些建模工具来快速实现模型,这个模型完全是可扩展的。此时取决于实现的方法,比如说在数据库字段中预留一定的空余字段来做配置项属性的扩充,因为配置项一定是随着运维阶段而动态变化的。

系统实现之后,此时我们有了一个CMDB基础,我们需要同步考虑的是,如何降低配置项的管理成本?这个时候我们想到了配置项的自动发现机制,特别是服务器上的一些配置信息,比如说进程、硬件配置和IP信息等等,尽量减少人工维护的工作量,只有在现网配置和机器配置产生冲突的时候,此时通过异常报告的形式让人为参与纠正。自动发现机制的引入可以大大降低人力成本。

随着CMDB越来越庞大,我们需要考虑配置准确性,特别有很多资源是动态变化的,比如说服务器的上下线、IP资源的分配回收等等,此时需要有一个生命周期的概念来管理这些对象。对于每一个资源对象,我们需要了解他的状态变迁,最好有个变迁图(变更控制),每个状态变迁的驱动主体是谁(权限控制)。我个人主张复杂的变更控制场景化,最好都固化到一个变更管理系统中,做好清晰的流程设计和功能实现,把配置项的状态日志记录下来归档。

总结来说,结合NGOSS的方法论,首先提炼业务场景,找到要管理的对象,然后进行对象的建模,模型实现之后,通过自动化管理的方法降低人为管理成本,根据生命周期的模型去控制配置项的变更。

本文分享自微信公众号 - 互联网运维杂谈(waynewang_ops),作者:老王

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2019-06-09

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 如何理解CMDB的套路

    前几天在对一个项目进行总结,编写CMDB的配置管理规范,发现还是有很多套路,本文就是老王总结的CMDB套路!

    用户1593318
  • 长文 | 重构CMDB,避免运维之耻

    CMDB,几乎是每个运维人都绕不过去的字眼,但又是很多运维人的痛,因为CMDB很少有成功的,因此我也把它称之为运维人的耻辱。那么到底错在哪儿了?该如何去重构它?

    用户1593318
  • 技术干货 | 微服务架构下的运维平台构建

    3月12日,优维科技与又拍云联合举办的Open Talk No.29《云上运维与研发最佳实践》在上海顺利举行,优维科技CTO黎明带来了《微服务架构下的运维平台构...

    用户1593318
  • 运维CMDB建设思路

    ? ? 在我们日常的运维工作中,面对着大量的基础设施和软件服务,该如何管理?这个管理的原则又是什么?粒度该如何控制?我们是否可以建立一个统一的标准模...

    小小科
  • 运维CMDB建设思路

    在我们日常的运维工作中,面对着大量的基础设施和软件服务,该如何管理?这个管理的原则又是什么?粒度该如何控制?我们是否可以建立一个统一的标准模型来管理以上对象?管...

    小小科
  • .NET/C# 建议的异常处理原则

    发布于 2017-12-03 08:20 更新于 2018-02...

    walterlv
  • 谈谈对于企业级系统架构的理解—李平

    原文地址:http://www.cnblogs.com/liping13599168/archive/2011/05/11/2043127.html

    Edison Zhou
  • 谈谈对于企业级系统架构的理解

    在我们刚开始学习架构的时候,首先会想到分层的概念,分层架构比较经典的是三层架构,那么,什么是三层架构呢?它包括表现层,业务层,数据访问层;而对于一个新手来说,从...

    Edison Zhou
  • 政策解读:《智能硬件产业创新发展专项行动(2016-2018年)》(上)

    镁客网
  • MSCI扩容知多少

    5月6日,MSCI在官网宣布,五月份半年度指数审议结果将于5月13日公布,届时将公布纳入和剔除的个股名单。

    量化小白

扫码关注云+社区

领取腾讯云代金券