从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

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