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


应用配置管理是面向应用的管理，是运维的核心
上面说明了CMDB的基础信息部分，如果从传统的SA运维模式，这些信息已经足够，但是从应用运维的角度，这些就远远不够了。
这时我们就需要一个非常非常重要的句柄：应用名，或者叫应用标识。至此，应用运维里面最最重要的一条联系也就产生了：“应用名-IP“的关联关系（这里也可以是定义的其它唯一主机标识，如主机名、容器ID等等，因为我们使用的方式是IP，所以这里就以IP示例）。
之所以说“应用名”和“应用名-IP关联关系”非常重要，是因为它的影响力不仅仅在运维内部，而是会一直延伸到整个技术架构上。后面我们会介绍到的所有平台和系统建设，都跟这两个概念有关。
CMDB是IP为标识的资源管理维度，有了应用名之后，就是以应用为视角的管理维度了。首先看一下应用会涉及到的信息：
- 应用基础信息，如应用责任人、应用的Git地址等；
- 应用部署涉及的基础软件包，如语言包（Java、C++、GO等）、Web容器（Tomcat、JBoss等）、Web服务器（Apache、Nginx等）、基础组件（各种agent，如日志、监控、系统维护类的tsar等）；
- 应用部署涉及的目录，如运维脚本目录、日志目录、应用包目录、临时目录等；
- 应用运行涉及的各项脚本和命令，如启停脚本、健康监测脚本；
- 应用运行时的参数配置，如Java的jvm参数，特别重要的是GC方式、新生代、老生代、永生代的堆内存大小配置等；
- 应用运行的端口号；
- 应用日志的输出规范；
- 其他。
上面的梳理过程实际就是标准化的过程。我们梳理完上述信息后就会发现，这些信息跟CMDB里面的资源信息完全是两个维度的东西。所以从信息管理维度上讲，把资源配置和应用配置分开会更清晰，解耦之后也更容易管理。
好了，按照上面CMDB说的套路，梳理完成后，就是要进行信息的建模和数据的固化，这时就有了我们的“应用配置管理”。再往后，就是基于应用配置管理的流程规范和工具平台的建设，这就涉及到我们经常说的持续集成和发布、持续交付、监控、稳定性平台、成本管理等等。
从应用的视角，我们配置管理，应该是下面这样一个视图（简单示例，不是完整的）：

好了，有了资源配置信息和应用配置信息，这两个信息应该怎么统一管理起来呢。直接看图：
至此，CMDB和应用配置管理的分层分解就完成了，应用名关联着应用配置信息，IP关联着资源信息，二者通过“应用名-IP”的对应关系，联系到一起。
总结
CMDB是运维的基石，但是要发挥出更大的价值，只有基础是不够的，我们要把更多的精力放到上层的应用和价值服务上，所以我们说应用才是运维的核心。
你可以看到，如果仅仅基于CMDB的资源信息作自动化，最多只能做出自动化的硬件资源采集、自动化装机、网络-硬件拓扑关系生成等资源层面的工具，这些工具只会在运维层面产生价值，离业务还很远，就更谈不上给业务带来价值了。
但是基于应用这一层去做，就可以做很多事情，比如持续集成和发布、持续交付、弹性扩缩容、稳定性平台、成本控制等等，做这些事情带来的价值就会大大不同。
以上就是我抛出的观点，CMDB是面向资源的管理，应用配置是面向应用的管理。希望能够抛砖引玉，听到更多你的观点和反馈。
如果今天的内容对你有用，也希望你分享给身边的朋友，我们下期见！
- foxracle 👍（4） 💬（1）
对于公有云的CMDB的建设，总感觉是重复建设，动力不是那么足，只是说考虑到今后混合云的可能，做一层抽象层来解耦。公有云的CMDB的构建有什么特别的地方么？
2018-01-05 - gaofubin 👍（3） 💬（3）
赵老师您好，我想构建cmdb，可是目前的基础资源都是Kubernetes平台，我得怎么把应用和基础资源关联起来呢？请您能提供个想法，多谢
2020-02-24 - 兵戈 👍（3） 💬（1）
请教赵老师，CMDB和应用配置管理也是持续集成和发布系统的基石，但如果现状是没有应用配置管理，该如何做好持续发布系统？对于持续发布这一块您有什么好的实践吗？
2018-01-06 - 竹影 👍（0） 💬（3）
读了前面几篇文章后回顾了自己的工作经历，包含应用信息的cmdb也尝试做过，最后公司没有继续投入资源。这个东西真的很重要，梳理清楚记录在册，变更登记，会给工作带来很多方便。问题是要投入多少时间和资源做这个事比较经济呢？
2020-03-17 - 杨陆伟 👍（0） 💬（1）
老师的思路很开阔，方案很大，请问下在老师的公司实现了吗？
2019-03-30 - 可爱(๑• . •๑) 👍（5） 💬（1）
推荐文章： https://www.processon.com/view/link/5829a24be4b00c4fc8a221b1?pw=51reboot#map https://mp.weixin.qq.com/s?src=11×tamp=1627880171&ver=3227&signature=OL2etre4VppMqag1jn1V6vup74DvOcIvjaQ*e7t1SCIM6gKrt5OhY1NAgRvTU6LFul7YEwd80WrIdr6nenXYJae6EvbQArR1B-4B4GZJqmhznpMjx*PH5zarLdVFQsS7&new=1
2021-08-02 - 怀揣梦想的学渣 👍（1） 💬（0）
看了本文，对资源梳理有疑惑，是按照个人经验去梳理资源的属性，还是业界有标准可以参考的总分类，或者公司领导关注哪些，我就统计哪些。
2022-02-19 - kevinsu 👍（0） 💬（0）
老哥，运维降低成本有啥好的思路吗？
2023-03-07 - 梧桐秋雨 👍（0） 💬（0）
主机列表对应的应该是上流量IP（一般是VIP），但针对整个集群模型，包括L4、L7、Real构建起来的模型，要如何管理呢？如何才能做到，相关的IP有问题时，或者全网分布式的集群上线时，可快速剔除故障机或快速上线。
2021-04-06 - 技术修行者 👍（0） 💬（0）
CMDB 是面向资源的管理，应用配置是面向应用的管理。 言简意赅！在微服务体系下，更应该加强应用配置的管理。
2020-05-28 - 牧野静风 👍（0） 💬（0）
看了几个开源的CMDB，做的很是粗糙，听了赵老师一番话，觉得确实梳理的比较透彻，现在这些信息我都是用EXECL管理，太离散了
2019-07-24 - kevinsu 👍（0） 💬（0）
太棒了，听君一席话 胜读十年书
2019-01-22 - sotey 👍（0） 💬（0）
后悔没有第一时间来追老师的剧，老师写完专栏才来。读了前面几篇就已经如获至宝了，多年的运维积累感觉可以有可能被串起来抽象化平台化了。按耐住一口气读完的冲动，细细品味反复实施。
2018-11-29 - 昨夜东风吹南山 👍（0） 💬（0）
请教下赵老师，有开源的同时支持资源配置和应用配置的cmdb开源软件吗？
2018-06-02