【深度好文】以应用为中心的CMDB究竟应该如何设计？

在过去5年，嘉为蓝鲸研发运维运营一体化方案已经在近300家企业中落地。企业类型涵盖了传统的制造、能源，也有互联网性质的互联网金融、游戏。那么，CMDB作为研运一体化方案中非常重要和基础的一环，它的设计理念应该是怎样的？

本文主要是从三个方面（Why、What、How）对应用CMDB的架构设计进行阐述。暂不涉及到维护运营等与人、流程相关的内容。

CMDB为什么要以应用为中心（Why）

在手工运维时代， CMDB主要服务于ITSM流程。此时CMDB纳管的是IT资产（比如鞋套机这种机房设施也在纳管对象中），在CMDB建设之初，其中的数据与线上环境的数据还比较一致，但CMDB的消费场景十分有限，其价值及维护愿望并不高，渐渐的CMDB中的数据与线上环境的数据偏差就越来越大了，渐渐沦落为一个边缘系统，甚至是一个运维负担。

在自动化运维时代，CMDB主要服务于各个运维系统如自动发布、监控、智能运维等。此时CMDB纳管的是IT资源（这里我们进一步缩小IT资源的概念为支撑应用系统的各种IT软硬件资源，如数据库、中间件、服务器、机柜等，此时并不会包括鞋套机）。随着IT运维系统和工具越来越多，CMDB中的数据作用越来越大，服务的运维消费场景也越来越丰富，此时CMDB的价值及维护诉求非常高。

因此，自动化运维、数据化运维催生出了新一代的CMDB。

不同的运维场景对CMDB有不同的消费诉求，但我们知道CMDB的落地一定不可以追求大而全，否则会把自己做死。那CMDB的边界是什么呢，或者说我们应该以什么为中心来建设CMDB呢？

答案当然是以应用为中心来建设CMDB！

随着数字化转型的发展，线下业务逐渐线上化，应用数量与日俱增，应用架构也趋于多样化和复杂化，而 IT基础设施逐步云化标准化并趋于稳定，因此运维的重心和价值渐渐聚焦于应用。另一方面，运维的发展必然走向数据化、智能化，如容量管理、根因定位、故障预测、辅助运营等，这些运维高级场景更多的也都指向了应用。因此，我们认为，CMDB应当以应用为中心进行设计，以满足各种运维场景对CMDB的消费需求。

什么是以应用为中心（What）

以应用为中心的CMDB，需要从以下两个点出发：

1.从应用的定义出发

这里的应用，是应用系统的简称，指对外提供特定业务服务的一组软硬件资源的有机组合。对外提供特定业务服务，意味着要从业务的视角；软硬件资源，对应着应用的组成实体；有机组合，则说明了实体之间存在着一定的关系。那么，CMDB既是以应用为中心，CMDB的能力需要能支撑起应用的这些特性。

2.从应用的运维场景对CMDB的消费需求出发

顶尖互联网公司的经验告诉我们，应用运维的未来是数据化运维、智能运维、辅助运营。而对于传统企业和正在转型中的企业来说，则要立足现在、谋划未来，建设一个适用于多种架构的、具备先进性基因的、可持续发展的应用运维平台：

CMDB是应用运维平台的基石，上层的应用部署管理场景，需要我们维护好应用拓扑、应用部署实例、以及应用与制品之间的关系才能做到持续快速交付。

应用运维管理，需要我们维护好应用基本信息、应用与基础资源之间的关系才能做到应用维度的监控和操作自动化。

应用性能管理，则需要将应用的调用关系和应用拓扑、部署资源结合起来，才能做到更深层次的分析，并且往容量管理、根因定位等智能化方向发展。

因此在各行各业的应用运维实践中深化运维场景，并且理解场景对配置信息的要求，也是CMDB设计的重要依据。

如何设计以应用为中心的CMDB（How）

1.应用CMDB中应该有哪些关键的数据

前面我们提到，应用CMDB需要从业务视角对一个应用进行描述，那么应用CMDB应该包含以下数据类型：

应用资源管理，包括应用的拓扑信息，应用的基本信息如程序包目录、启停脚本等，应用的部署信息如集群、环境、主机、进程等，以及应用与应用之间、应用与基础资源之间的调用信息等。

基础资源管理，应用是由各种基础资源构成的，需要支持各种基础资源的配置信息管理。

应用制品管理，一般而言，CMDB中不会纳管制品，但需要支持与外部制品库对接，对制品与应用之间的关系进行管理。

2.应用CMDB架构的十大关键设计要素

以应用为中心的CMDB想要在多样化的应用架构环境中落地，并满足各种运维场景的消费需求，设计时需要涵盖以下十个关键要素：

以应用为中心

CMDB需要以应用作为基本单元，而不是以资源对象、数据中心来进行划分。比如CMDB中的第一层级，应该是OA系统、电子商城、ERP系统等应用，而不是Windows服务器、数据库主机或者北京数据中心、广州数据中心。

使用服务树拓扑管理应用

服务树是对应用系统所提供的业务功能进行领域的划分。一般不要超过3层：

例如：

一般一个企业只定义一个服务树拓扑模板，所有应用的管理都沿用这个拓扑模板。

拓扑设计要同时支持传统应用架构和互联网应用架构

传统应用架构有几个特点，一是应用并未把模块划得很细，二是应用往往有独享的数据库、消息队列等基础资源，三是应用的架构相对比较简单，有时由两台Weblogic服务器+两台Oracle服务器就组成了整个应用系统。比如某保险集团的DBS系统，在三层服务树拓扑下，可以按照以下方式进行划分（此时模块是从基础资源的维度进行划分）：

支持多环境管理

应用是部署在不同环境中的，我们将应用在不同环境中的信息管理起来。

支持多集群管理

这里的集群指的是分布式的集群。每个集群都对外提供相同的业务服务，集群中包含着一个或多个模块。集群一般在互联网应用架构下出现的比较多。

支持模块与模块之间的调用关系管理

支持模块与制品（程序包、配置文件、SQL文件、镜像）之间的关联关系管理

支持对基础资源的模型自定义和实例管理

可自定义模型及模型属性：

实例管理：

支持模块与基础资源之间的调用关系管理

支持进程管理，满足传统非标准化进程管理的需求

模块部署后将会实例化进程，我们称之为服务进程，是一个应用系统非常关键的实体资源。在互联网架构下，进程相对比较标准，各台主机上的进程实例配置信息（端口、目录、启停脚本等）是一致的。

在传统应用架构下，进程可能并不标准，进程实例的配置信息在不同主机上可能是不一致的，甚至同一个主机上可能运行了该模块的两个进程实例。此时，需要应用CMDB能够提供灵活的进程管理能力来适配传统架构和互联网架构的需求。

总结

以应用为中心的CMDB，既要支撑得起传统的单体、SOA应用架构，也要支撑越来越广泛的分布式、微服务和云原生应用架构，既要满足当前自动化运维的需求，也要为数据化、智能化运维打下基础，既要以应用为中心，也要兼顾基础架构运维的需求。

企业可以参考上述的CMDB十大设计要素，并结合企业自身的业务特点建设CMDB，保证CMDB中的数据都是“活”的数据，才能让CMDB保持旺盛的活力，真正成为IT研发运维运营的基石。