前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >运维CMDB建设思路

运维CMDB建设思路

作者头像
小小科
修改2019-11-18 17:28:08
7640
修改2019-11-18 17:28:08
举报
文章被收录于专栏:北京马哥教育北京马哥教育

在我们日常的运维工作中,面对着大量的基础设施和软件服务,该如何管理?这个管理的原则又是什么?粒度该如何控制?我们是否可以建立一个统一的标准模型来管理以上对象?管理过程中,如何降低人力成本?资源对象的生命周期管理如何实现?这么多的疑问,所有的运维人都会想到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的方法论,首先提炼业务场景,找到要管理的对象,然后进行对象的建模,模型实现之后,通过自动化管理的方法降低人为管理成本,根据生命周期的模型去控制配置项的变更。

好啦,今天的分享到这里就结束了,如果需要更多的技术性文章,可以访问马哥教育官网欧!

本文系转载,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文系转载前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档