从CMDB到数据中台

2018年年底到2019年年初，一场组织变革的飓风席卷了国内各大互联网公司。阿里、腾讯、百度、京东、美团等先后拿出了几年来最大规模的组织调整计划。在这些变化中，一个值得关注的现象是，各大公司都不约而同地在组织架构中增设“中台”。

1

中台是什么，能解决什么问题？

那么，“中台”到底是什么？跟我们熟悉的“平台”有什么关系？

大家估计听过华为在几年前就提出的“平台炮火支撑精兵作战”的平台化战略，“让听得到炮声的人能呼唤到炮火”说的就是大平台赋能一线团队，快速将后台能力投送到需要支援的地方，使华为可以迅速响应瞬息万变的市场机会。

（图片来源网络）

在平台化战略的实践过程中，随着企业业务的发展，逐渐诞生了很多支撑前台营销场景的工具系统。这些工具系统主要面向企业的最终用户和市场营销人员，要快速响应市场需求，快速创新迭代。因此产生大量调取后台系统资源的需求。

然而，很多后台系统在创建之初是为了解决特定场景下的管理效率或安全管控需求（比如财务系统、CRM系统、物流系统等），其目标并不是服务于前台的各种业务创新。所以在能力设计上，这些老后台系统大部分是封闭的，很难开放出来给前台系统调用。

此时的前台和后台就像是两个不同转速的轮，前台转的快，后台转的慢，就出现了匹配失衡。

解决这个问题有两个办法，一种是重建后台系统，让后台系统具备灵活、开放的服务化能力，能够让前台方便调用。但这种做法的风险很大，因为后台管理企业的核心数据，牵一发动全身，而且还有各种安全、审计、合规、法律等限制，当然是稳定至上。所以后台不是不愿意转快点儿，是后台本来就应该慢一点、稳一点。

另一种方法是在后台和前台之间构建一个共享服务平台，将各个后台系统的核心能力、数据、用户信息加以沉淀和打磨，然后按照前台容易使用的方式对其进行服务化包装，从而将后台能力平滑的传递给前台。这个共享服务平台就是中台。中台就像是在前台与后台之间添加的组“变速轮”，将前台与后台的速率进行匹配，解决前台快一点、后台慢一点的矛盾。

阿里是最早提出并践行中台战略的，通过多年不懈的努力，在业务的不断催化滋养下，终于将⾃己的技术和业务能力沉淀出一套综合能力共享平台，具备了对于前台业务变化及创新的快速响应能力。所以，我们认为中台与企业平台化战略一脉相承，它是企业平台化战略的一种落地方式。

2

运维需要中台吗？

上面说的都是企业管理和互联网经验，在运维领域需要中台吗？

现在很多IT组织自身也在进行数字化转型。为了从以“稳定、安全、可靠”为核心的被动运维转型成以“体验、效率、效益”为核心的主动运营，我们需要打造可视化、场景化、数字化的IT运营平台。但在这个过程中困难重重，我们也遇到了前后台配速失衡的问题，如下图：

我们会发现，目前市场上比较成熟的运维软件产品主要是后台系统，而前台运维系统有明显的多样性和个性化特征，同样的场景、不同的IT组织就可能有完全不同的实现要求（以应急指挥为例，从应急响应、应急分析到应急处置，按理说是比较标准化的，但交行、中行、建行对应急的侧重点不同，就导致功能需求完全不同），所以很难形成标准化的产品。即使定制化开发也困难重重，因为要对接大量后台系统的数据和能力（要接入各种告警和指标数据，还要对接工单、自动化操作、预案等），实施复杂度非常高。而且由于前台场景的需求变化普遍很快，更增加了项目实施成本。各大ITOM厂商原本提供的是后台系统，却被迫定制开发各种前台场景，这种前后一体化的做法让厂商苦不堪言，客户也对后台厂商在短时间内拼凑出的前台场景不满意。

要破解这个困境，还是要想办法建立一个资源共享层，既能让后台系统专注把自己的事情做好，也能让前台系统放飞自我，快速迭代创新。

那么，哪些资源最容易、也最迫切需要被共享呢？是“数据”。因为前台各种分析协作场景都离不开后台数据的支持，而这类专注做数据共享服务的中台，我们也称之为运维数据中台。

3

什么是运维数据中台，和运维大数据平台有什么区别？

运维数据中台的职责是识别前台数据需求、整合后台数据、加工数据、输出数据，是数据中心级的数据服务共享平台。

运维数据中台应有两个核心理念：

数据中心级

指数据中心内所有运维系统都是数据中台的用户。因此在建设运维中台的时候，从格局上就一定要跳出单条业务线站在中心整体视角来审视数据需求和供给现状，识别优先级，寻找那些最需要被共享的数据。

数据服务

数据中台一定是开放的、服务化的，要通过 API 的方式提供数据，而不是直接把数据库暴露给前台。因此Data API是数据中台的核心，至于如何提升API生产效率，让API 更加清晰，调用更加便捷，性能和数据质量更好，这些都是围绕数据服务需要打造的关键能力。

运维数据中台和我们熟悉的运维大数据平台有什么区别呢？

它们不是一个维度上的概念。运维大数据平台更像一个技术概念。我们一提到运维大数据平台，首先想到的是大数据存储技术、流式计算、智能算法等技术，其能力侧重在数据的相关性和周期性分析方面，主要用于异常检测、故障预测等少数运维“高端”场景。

而运维数据中台是一个业务概念，它是一个能力传导层，聚焦如何将后台数据平滑传给前台系统。

举个比喻，大数据平台类似高档餐厅，打造的是前后端一体化能力，而数据中台是送外卖，更偏向能力整合。数据中台可以整合、配送来自资源管理平台、云管平台、监控平台、自动化平台、流程平台的数据，也可以配送来自大数据平台的数据，甚至数据中台本身也可以利用大数据平台技术构建。

4

CMDB和数据中台有什么关系？

它们都是数据能力的传导平台，核心职责都是整合数据、加工数据、输出数据（CMDB业务模型图和中台图对比）

CMDB也符合运维数据中台两大核心理念：数据中心级和数据服务。

这里的“数据中心级”有两个含义，首先指CMDB的数据范围包含与应用系统相关的所有IT资源，这是CMDB与所有专业领域配置库（如资产库、云资源库、DB性能分析库、网管资源库等）的核心区别之一。其次，CMDB是面向数据中心所有运维工具使用的，解决的是跨专业数据共享问题。这也引出CMDB的第二个核心理念，即必须具备灵活、开放的数据服务能力。

但CMDB和运维数据中台也有些许不同点，在数据范围方面，数据中台是全域数据（包括配置、告警、指标、工单、操作），而CMDB只有静态的配置数据。从这点看，其实数据中台是可以涵盖CMDB的。事实上，CMDB可以定位成数据中台的主数据管理模块。

5

数据中台对CMDB建设有哪些启发？

1

要先做数据商人，而不是数据科学家

数据商人会将注意力放在解决跨部门、跨工具数据流通不畅的问题，要促进数据商品的流通。而数据科学家则专注于对某个专业领域开展数据研究，以解决这个专业领域的某个难题。

具体来说，数据商人做什么事情呢？比如：

1. 从服务请求流程获得新增的IT资源（后称CI），对该资源数据进行整合、加工，然后将数据送给自动化平台进行监控部署
2. 从自动发现平台中获取文件系统CI，给这些CI丰富应用责任人信息，然后将数据送给监控平台进行告警丰富
3. 从防火墙管理工具中获取网络访问策略信息，给这些访问策略丰富源、目的CI的配置信息（包括主机名、所属应用、责任人等），然后将数据提供给应用岗，供日常查询

那什么是数据科学家做的事情？

1. 研究原始的防火墙策略日志，设计复杂的数据分析逻辑，输出结构化的访问策略
2. 采集数据库参数信息，开发参数比对程序，输出比对结果

在建设初期，CMDB应该先做好数据商人，这里主要是从成本和收益考虑，毕竟有大量的跨部门、跨工具数据共享需求，这些需求涉及的配置数据并不复杂，但收益却非常明显，所以应该优先建设。至于数据科学家的工作，可以在CMDB成熟后逐渐开展，不过最理想的方案仍然是由专业的技术管理工具解决专业的问题。

2

要关注消费场景，但不应大包大揽，要聚焦数据服务

按照数据中台的思想，CMDB的定位是“做外卖”，但很多IT组织把CMDB做成了“开饭馆”。开饭馆就要买菜、洗菜、切菜、炒菜、端菜、甚至搞点节目让顾客吃得开心，这是贯穿前后台的一体化能力。对应CMDB就是大搞数据生产，建立一系列配套流程制度和自动发现工具，定制大量数据维护和消费界面，倾力打造贯穿前后台数据生产、治理、消费的一体化能力平台。这种建设方式并不妥当，一方面打造前后台一体化的能力平台需要相当长的时间和巨大成本，另一方面，即使建设成了，无非是又立起了一个烟囱系统，隔绝于现有运维体系之外。

基于中台思路，我们认为更加合理的建设方式是横向能力整合，类似送外卖。这种建设思路首先要考虑的是前台用户是谁，有什么数据需求，数据的生产源头在哪里，如何与数据源的流程对接实现数据的自然沉淀，然后对沉淀的数据进行加工整合，最后通过服务化接口将数据投送到用户嘴里。这种建设方式的成本更低、见效更快。（来源：优锘科技)

如有转载需求，欢迎与"editor@cloudbest.cn"联系或文章下面留言。已经授权使用作品的，应在授权范围内使用，并注明“来源：CloudBest”。