有了CMDB,为什么还要应用配置管理

CMDB翻译过来,Configuration Management DataBase,其实也是配置管理的意思,但从实际情况看,CMDB的概念定义已经出现了很大的局限性,之前老王也专门写过一篇文章《如何理解CMDB的套路》来阐述过这个观点,今天我从我们团队自己的实践过程中的理解和角度再来呼应下,因为这一点理解不清楚,基础打不好,后续的自动化也好,DevOps也好,等等等等,都将无从谈起。

先抛观点: CMDB是面向资源的管理,应用配置是面向应用的管理。

注意:是资源,不是资产,资源 ≠资产

一、CMDB面向的是资源层面的管理,是运维的基石

通常,我们在建设运维的基础管理平台时,通常要做的事情:

1、把服务器、网络、IDC、机柜、存储、配件等这几大维度先定下来;

2、这些硬件的属性确定下来,比如服务器就会有SN序列号、IP地址、厂商、硬件配置(如CPU、内存、硬盘、网卡、PCIE、BIOS)、维保信息等等;网络设备如交换机也会有厂商、型号、带宽等等;

3、以上信息之间的关联关系,或者叫拓扑关系。比如服务器所在机柜,虚拟机所在的宿主机、机柜所在IDC等简单关系,复杂一点就会有核心交换机、汇聚交换机、接入交换机以及机柜和服务器之间的级联关系,这个就相对复杂一些

4、其实应该是3.5步,在上面信息的梳理过程中肯定就会遇到一些规划问题,比如,IP地址段的规划,xx网段用于DB,xx网段用于大数据、xx网段用于业务应用等等,再比如同步要做的还有xx机柜用于做虚拟化宿主机、xx机柜只放DB机器等等。

以上信息梳理清楚,通过ER建模工具进行数据建模,再将以上的信息固化到DB中,一个资源层面的信息管理平台就基本成型了。但是,信息固化不是目的,也没有价值,只有信息动态流转起来才有价值(跟货币一样)。接下来我们可以做的事情:

1、基于这些信息进行流程规范的建设,比如服务器的上线、下线、维修、装机等流程。同时,流程过程中状态的变更要同步管理起来。

2、拓扑关系的可视化和动态展示,比如交换机与服务器之间的级联关系、状态(正常or故障)的展示等,这样可以很直观的关注到资源节点的状态。

至此,从资源维度的信息梳理,以及基于这些信息的平台和流程规范建设也算是基本成型了。这个时候,以服务器简单示例,我们的视角是下面这样的:

二、应用配置管理是面向应用的管理,是运维的核心

上面说明了CMDB的基础信息部分,如果从传统的SA运维模式,这些信息已经足够,但是从应用运维的角度,这些就远远不够了。这时我们就需要一个非常非常重要的句柄——应用名,或者叫应用标示。这时,应用运维里面最最重要的一条联系也就产生了——“应用名—IP“的关联关系。(注:这里也可以是定义的其它的唯一主机标示,如主机名、容器ID等等,因为我们使用的方式是IP,所以这里就以IP示例)

之所以说应用名和应用名-IP关联关系非常重要,是因为它的影响力不仅仅在运维内部,而是会一直延伸整个技术架构上,后面的文章,我们介绍到的所有的平台和系统建设,都会跟这两个概念有关。

CMDB是IP为标示的资源管理维度,有了应用名之后,我们后面就是以应用为视角的管理维度了。首先看一下应用会涉及到的信息:

1、应用基础信息,如应用责任人、应用的Git地址等

2、应用部署涉及的基础软件包,如语言包(Java、C++、GO等)、Web容器(Tomcat、JBoss等)、Web服务器(Apache、Nginx等)、基础组件(各种agent,如日志、监控、系统维护类的tsar等)

3、应用部署涉及的目录,如运维脚本目录、日志目录、应用包目录、临时目录等

4、应用运行涉及的各项脚本和命令,如启停脚本、健康监测脚本

5、应用运行时的参数配置,如Java的jvm参数,特别重要的是GC方式、新生代、老生代、永生代的堆内存大小配置等

6、应用运行的端口号

7、应用日志的输出规范

8、。。。。。。。

我们梳理完上述信息后就会发现,这些信息跟CMDB里面的资源信息是完全两个维度的东西,所以从信息管理维度上讲,资源配置和应用配置分开会更清晰,解耦之后也更容易管理。

好了,按照上面CMDB说的套路,梳理完成后,就是要进行信息的建模和数据的固化,这时就有了我们的——应用配置管理。再往后,就是基于应用配置管理的流程规范和工具平台的建设,这就涉及到我们经常说的持续集成&发布&交付,监控、稳定性平台、成本管理等等。

从应用的视角,我们配置管理,应该是下面这样一个视图(简单示例,不是完整的):

三、CMDB和应用配置管理的关系

有了资源配置信息和应用配置信息,这两个信息应该怎么统一管理起来呢。直接上图:

至此,CMDB和应用配置管理的分层分解就完成了,应用名关联着应用配置信息,IP关联着资源信息,二者通过应用名-IP的对应关系,联系到一起。

CMDB是运维的基石,但是要发挥更大的价值,光有基础是不够的,我们要把更多的精力放到上层的应用和价值服务上,所以我才会讲应用才是运维的核心。我们可以看到,如果仅仅基于CMDB的资源信息作自动化,最多只能做出自动化的硬件资源采集、自动化装机、网络-硬件拓扑关系生成等资源层面的工具,这些工具只会在运维层面产生价值,离业务还很远,就更谈不上能给业务带来什么价值了。但是基于应用这一层去做,就可以做很多事情,比如持续集成和发布、持续交付、弹性扩缩容、稳定性平台、成本控制等等,这些事情,带来的价值就会大大不同,这些后续会一个个介绍出来。

原文发布于微信公众号 - Forrest随想录(forrest_thinking)

原文发表时间:2017-07-03

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

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏挖掘大数据

国家电网推进全业务数据中心建设

2016年10 月9 日,习近平总书记在中共中央政治局第三十六次集体学习时强调,要深刻认识互联网在国家管理和社会治理中的作用,以推行电子政务、建设新型智慧城市等...

4400
来自专栏程序你好

混合持久化让微服务如虎添翼

1213
来自专栏DevOps时代的专栏

神聊《DevOps HandBook》:DevOps 集成安全的技术实践

作者简介: ? 韩方 欢聚时代(YY直播) 安全中心总监 公司T4技术专家,10年以上安全领域的攻防研究和设计开发工作,对于平台安全、应用安全、业务安全等安...

2629
来自专栏架构师之路

从IDC到云端架构迁移之路(GITC2016)

大家好,很高兴来到GITC2016的舞台,我是来自58到家的沈剑,今天我分享的主题是《58到家从IDC到云端架构迁移之路》。 机房迁移是一个很大的动作: 15年...

3675
来自专栏视频加密

BT技术是如何实现高速下载节省带宽的?

bt具有哪些优势呢?使得bt在游戏、影音、大文件分发领域的应用越来越广泛,下面小编就来扒一扒,小编团队做大文件分发传输已经10年+了,在优化节省带宽方面,bt技...

1321
来自专栏云加头条

做弹性的云—腾讯云弹性伸缩

现如今,云计算已成为IT领域标配,甚至有趋势作为基础服务成为未来IT领域的水和电。当业务规模蓬勃增长,面对数以万计的请求量,庞大的业务流量,高并发的数据访问量,...

7391
来自专栏EAWorld

基于统一开发平台的微服务架构转型升级之路 | 某国有大型银行案例

某银行是一家国有大型银行,从2016年开始采用了我们的SOA开发平台作为基础Java开发平台。

2332
来自专栏软件测试经验与教训

自动化测试实施方案

7566
来自专栏北京马哥教育

从零起步做到Linux运维经理,你必须管好的23个细节

不想成为将军的士兵,不是好士兵-拿破仑 如何成为运维经理?成为运维经理需要什么样的能力?我想很多运维工程师都会有这样的思考和问题。 如何成为运维经理。一般来说,...

7045
来自专栏程序员的知识天地

提升 Web 应用的代码质量【干货持续输出】

Web 应用的质量提升,是一个非常有意思的话题。我们明知道有一系列的手段可以提升代码质量,但是限于多种原因,我们并不会去做。在我工作的第一个项目里,由于大家都是...

731

扫码关注云+社区