从CMDB到数据中台

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


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

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


我推荐大家看看王健写的系列文章《白话中台战略》，在这里我只做一个简朴的概括。


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

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


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


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


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

另一种方法是在后台和前台之间构建一个共享服务平台，将各个后台体系的核心能力、数据、用户信息加以沉淀和打磨，然后按照前台轻易利用的方式对其进行服务化包装，从而将后台能力平滑的通报给前台。这个共享服务平台就是中台。中台就像是在前台与后台之间添加的组“变速轮”，将前台与后台的速率进行匹配，解决前台快一点、后台慢一点的矛盾。
阿里是最早提出并践行中台战略的，通过多年不懈的努力，在业务的不断催化滋养下，终于将⾃己的技术和业务能力沉淀出一套综合能力共享平台，具备了对于前台业务厘革及创新的快速响应能力。以是，我们认为中台与企业平台化战略一脉相承，它是企业平台化战略的一种落地方式。




二、运维需要中台吗？


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

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


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


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




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


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

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


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


数据服务
数据中台一定是开放的、服务化的，要通过 API 的方式提供数据，而不是直接把数据库袒露给前台。因此Data API是数据中台的核心，至于如何提升API生产效率，让API 更加清楚，调用更加便捷，性能和数据质量更好，这些都是围绕数据服务需要打造的关键能力。
运维数据中台和我们熟悉的运维大数据平台有什么区别呢？


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


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


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

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


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

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


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


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




五、数据中台对CMDB建立有哪些启发？


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


详细来说，数据商人做什么事情呢？好比：

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

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

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

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


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


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

优锘志


更多优锘牛人技文 敬请关注
优锘科技公众号 -精选文章-技术分享
【往期文章↓】
CMDB的本质以及它能解决什么问题？

Netcool王者变青铜，监控的大统谁来继续？
面向运营的CMDB

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！