在过去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究竟应该如何设计?_第1张图片

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

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

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

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


如何设计以应用为中心的CMDB(How)

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

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

以应用为中心的CMDB究竟应该如何设计?_第2张图片

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

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

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


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

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

以应用为中心的CMDB究竟应该如何设计?_第3张图片


以应用为中心

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

以应用为中心的CMDB究竟应该如何设计?_第4张图片


使用服务树拓扑管理应用

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

以应用为中心的CMDB究竟应该如何设计?_第5张图片

例如:

以应用为中心的CMDB究竟应该如何设计?_第6张图片


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

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

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

以应用为中心的CMDB究竟应该如何设计?_第7张图片



支持多环境管理

以应用为中心的CMDB究竟应该如何设计?_第8张图片

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


支持多集群管理

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

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

以应用为中心的CMDB究竟应该如何设计?_第9张图片


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


以应用为中心的CMDB究竟应该如何设计?_第10张图片


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

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

以应用为中心的CMDB究竟应该如何设计?_第11张图片


实例管理:

以应用为中心的CMDB究竟应该如何设计?_第12张图片



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

以应用为中心的CMDB究竟应该如何设计?_第13张图片


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

以应用为中心的CMDB究竟应该如何设计?_第14张图片


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

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

以应用为中心的CMDB究竟应该如何设计?_第15张图片

总结

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

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