今天我们分享的主题是:有了 CMDB,为什么还需要应用配置管理?
你不妨先停下来,思考一下这个问题。
我抛出的观点是: CMDB 是面向资源的管理,应用配置是面向应用的管理。
请注意,这里是面向“资源”,不是面向“资产”,资源 ≠资产。
CMDB 是面向资源的管理,是运维的基石
我们一起来梳理一下,在建设运维的基础管理平台时通常要做的事情。
第 1 步,把服务器、网络、IDC、机柜、存储、配件等这几大维度先定下来;
第 2 步,把这些硬件的属性确定下来,比如服务器就会有 SN 序列号、IP 地址、厂商、硬件配置(如 CPU、内存、硬盘、网卡、PCIE、BIOS)、维保信息等等;网络设备如交换机也会有厂商、型号、带宽等等;
第 3 步,梳理以上信息之间的关联关系,或者叫拓扑关系。比如服务器所在机柜,虚拟机所在的宿主机、机柜所在 IDC 等简单关系;复杂一点就会有核心交换机、汇聚交换机、接入交换机以及机柜和服务器之间的级联关系;
第 3.5 步,在上面信息的梳理过程中肯定就会遇到一些规划问题,比如,IP 地址段的规划,哪个网段用于 DB,哪个网段用于大数据、哪个网段用于业务应用等等,再比如同步要做的还有哪些机柜用于做虚拟化宿主机、哪些机柜只放 DB 机器等。
以上信息梳理清楚,通过 ER 建模工具进行数据建模,再将以上的信息固化到 DB 中,一个资源层面的信息管理平台就基本成型了。
但是,信息固化不是目的,也没有价值,只有信息动态流转起来才有价值(跟货币一样)。接下来我们可以做的事情:
第 4 步,基于这些信息进行流程规范的建设,比如服务器的上线、下线、维修、装机等流程。同时,流程过程中状态的变更要同步管理起来;
第 5 步,拓扑关系的可视化和动态展示,比如交换机与服务器之间的级联关系、状态(正常 or 故障)的展示等,这样可以很直观地关注到资源节点的状态。
至此,从资源维度的信息梳理,以及基于这些信息的平台和流程规范建设就算是基本成型了。这个时候,以服务器简单示例,我们的视角是下面这样的: