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 的资源信息作自动化，最多只能做出自动化的硬件资源采集、自动化装机、网络 - 硬件拓扑关系生成等资源层面的工具，这些工具只会在运维层面产生价值，离业务还很远，就更谈不上能给业务带来什么价值了。但是基于应用这一层去做，就可以做很多事情，比如持续集成和发布、持续交付、弹性扩缩容、稳定性平台、成本控制等等，这些事情，带来的价值就会大大不同，这些后续会一个个介绍出来。
（赵成原创）

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 的资源信息作自动化，最多只能做出自动化的硬件资源采集、自动化装机、网络 - 硬件拓扑关系生成等资源层面的工具，这些工具只会在运维层面产生价值，离业务还很远，就更谈不上能给业务带来什么价值了。但是基于应用这一层去做，就可以做很多事情，比如持续集成和发布、持续交付、弹性扩缩容、稳定性平台、成本控制等等，这些事情，带来的价值就会大大不同，这些后续会一个个介绍出来。
（赵成原创）