一、中臺是什么，能解決什么問題？

2018年年底到2019年年初，一場組織變革的颶風席卷了國內(nèi)各大互聯(lián)網(wǎng)公司。阿里、騰訊、百度、京東、美團等先后拿出了幾年來最大規(guī)模的組織調(diào)整計劃。在這些變化中，一個值得關注的現(xiàn)象是，各大公司都不約而同地在組織架構(gòu)中增設“中臺”。

那么，“中臺”到底是什么？跟我們熟悉的“平臺”有什么關系？

我推薦大家看看王健寫的系列文章《白話中臺戰(zhàn)略》，在這里我只做一個簡單的概括。

大家估計聽過某公司在幾年前就提出的“平臺炮火支撐精兵作戰(zhàn)”的平臺化戰(zhàn)略，“讓聽得到炮聲的人能呼喚到炮火”說的就是大平臺賦能一線團隊，快速將后臺能力投送到需要支援的地方，使某公司可以迅速響應瞬息萬變的市場機會。

在平臺化戰(zhàn)略的實踐過程中，隨著企業(yè)業(yè)務的發(fā)展，逐漸誕生了很多支撐前臺營銷場景的工具系統(tǒng)。這些工具系統(tǒng)主要面向企業(yè)的最終用戶和市場營銷人員，要快速響應市場需求，快速創(chuàng)新迭代。因此產(chǎn)生大量調(diào)取后臺系統(tǒng)資源的需求。

然而，很多后臺系統(tǒng)在創(chuàng)建之初是為了解決特定場景下的管理效率或安全管控需求（比如財務系統(tǒng)、CRM系統(tǒng)、物流系統(tǒng)等），其目標并不是服務于前臺的各種業(yè)務創(chuàng)新。所以在能力設計上，這些老后臺系統(tǒng)大部分是封閉的，很難開放出來給前臺系統(tǒng)調(diào)用。

此時的前臺和后臺就像是兩個不同轉(zhuǎn)速的輪，前臺轉(zhuǎn)的快，后臺轉(zhuǎn)的慢，就出現(xiàn)了匹配失衡。

解決這個問題有兩個辦法，一種是重建后臺系統(tǒng)，讓后臺系統(tǒng)具備靈活、開放的服務化能力，能夠讓前臺方便調(diào)用。但這種做法的風險很大，因為后臺管理企業(yè)的核心數(shù)據(jù)，牽一發(fā)動全身，而且還有各種安全、審計、合規(guī)、法律等限制，當然是穩(wěn)定至上。所以后臺不是不愿意轉(zhuǎn)快點兒，是后臺本來就應該慢一點、穩(wěn)一點。

另一種方法是在后臺和前臺之間構(gòu)建一個共享服務平臺，將各個后臺系統(tǒng)的核心能力、數(shù)據(jù)、用戶信息加以沉淀和打磨，然后按照前臺容易使用的方式對其進行服務化包裝，從而將后臺能力平滑的傳遞給前臺。這個共享服務平臺就是中臺。中臺就像是在前臺與后臺之間添加的組“變速輪”，將前臺與后臺的速率進行匹配，解決前臺快一點、后臺慢一點的矛盾。

阿里是最早提出并踐行中臺戰(zhàn)略的，通過多年不懈的努力，在業(yè)務的不斷催化滋養(yǎng)下，終于將?己的技術(shù)和業(yè)務能力沉淀出一套綜合能力共享平臺，具備了對于前臺業(yè)務變化及創(chuàng)新的快速響應能力。所以，我們認為中臺與企業(yè)平臺化戰(zhàn)略一脈相承，它是企業(yè)平臺化戰(zhàn)略的一種落地方式。

二、運維需要中臺嗎？

上面說的都是企業(yè)管理和互聯(lián)網(wǎng)經(jīng)驗，在運維領域需要中臺嗎？

現(xiàn)在很多IT組織自身也在進行數(shù)字化轉(zhuǎn)型。為了從以“穩(wěn)定、安全、可靠”為核心的被動運維轉(zhuǎn)型成以“體驗、效率、效益”為核心的主動運營，我們需要打造可視化、場景化、數(shù)字化的IT運營平臺。但在這個過程中困難重重，我們也遇到了前后臺配速失衡的問題，如下圖：、

我們會發(fā)現(xiàn)，目前市場上比較成熟的運維軟件產(chǎn)品主要是后臺系統(tǒng)，而前臺運維系統(tǒng)有明顯的多樣性和個性化特征，同樣的場景、不同的IT組織就可能有完全不同的實現(xiàn)要求（以應急指揮為例，從應急響應、應急分析到應急處置，按理說是比較標準化的，但交行、中行對應急的側(cè)重點不同，就導致功能需求完全不同），所以很難形成標準化的產(chǎn)品。即使定制化開發(fā)也困難重重，因為要對接大量后臺系統(tǒng)的數(shù)據(jù)和能力（要接入各種告警和指標數(shù)據(jù)，還要對接工單、自動化操作、預案等），實施復雜度非常高。而且由于前臺場景的需求變化普遍很快，更增加了項目實施成本。各大ITOM廠商原本提供的是后臺系統(tǒng)，卻被迫定制開發(fā)各種前臺場景，這種前后一體化的做法讓廠商苦不堪言，客戶也對后臺廠商在短時間內(nèi)拼湊出的前臺場景不滿意。

要破解這個困境，還是要想辦法建立一個資源共享層，既能讓后臺系統(tǒng)專注把自己的事情做好，也能讓前臺系統(tǒng)放飛自我，快速迭代創(chuàng)新。

那么，哪些資源容易、也迫切需要被共享呢？是“數(shù)據(jù)”。因為前臺各種分析協(xié)作場景都離不開后臺數(shù)據(jù)的支持，而這類專注做數(shù)據(jù)共享服務的中臺，我們也稱之為運維數(shù)據(jù)中臺。

**三、**什么是運維數(shù)據(jù)中臺，和運維大數(shù)據(jù)平臺有什么區(qū)別？

運維數(shù)據(jù)中臺的職責是識別前臺數(shù)據(jù)需求、整合后臺數(shù)據(jù)、加工數(shù)據(jù)、輸出數(shù)據(jù)，是數(shù)據(jù)中心級的數(shù)據(jù)服務共享平臺。

運維數(shù)據(jù)中臺應有兩個核心理念：

數(shù)據(jù)中心級

指數(shù)據(jù)中心內(nèi)所有運維系統(tǒng)都是數(shù)據(jù)中臺的用戶。因此在建設運維中臺的時候，從格局上就一定要跳出單條業(yè)務線站在中心整體視角來審視數(shù)據(jù)需求和供給現(xiàn)狀，識別優(yōu)先級，尋找那些最需要被共享的數(shù)據(jù)。

數(shù)據(jù)服務

數(shù)據(jù)中臺一定是開放的、服務化的，要通過 API 的方式提供數(shù)據(jù)，而不是直接把數(shù)據(jù)庫暴露給前臺。因此Data API是數(shù)據(jù)中臺的核心，至于如何提升API生產(chǎn)效率，讓API 更加清晰，調(diào)用更加便捷，性能和數(shù)據(jù)質(zhì)量更好，這些都是圍繞數(shù)據(jù)服務需要打造的關鍵能力。

運維數(shù)據(jù)中臺和我們熟悉的運維大數(shù)據(jù)平臺有什么區(qū)別呢？

它們不是一個維度上的概念。運維大數(shù)據(jù)平臺更像一個技術(shù)概念。我們一提到運維大數(shù)據(jù)平臺，首先想到的是大數(shù)據(jù)存儲技術(shù)、流式計算、智能算法等技術(shù)，其能力側(cè)重在數(shù)據(jù)的相關性和周期性分析方面，主要用于異常檢測、故障預測等少數(shù)運維“高端”場景。

而運維數(shù)據(jù)中臺是一個業(yè)務概念，它是一個能力傳導層，聚焦如何將后臺數(shù)據(jù)平滑傳給前臺系統(tǒng)。

舉個比喻，**大數(shù)據(jù)平臺類似高檔餐廳，打造的是前后端一體化能力，而數(shù)據(jù)中臺是送外賣，更偏向能力整合。**數(shù)據(jù)中臺可以整合、配送來自資源管理平臺、云管平臺、監(jiān)控平臺、自動化平臺、流程平臺的數(shù)據(jù)，也可以配送來自大數(shù)據(jù)平臺的數(shù)據(jù)，甚至數(shù)據(jù)中臺本身也可以利用大數(shù)據(jù)平臺技術(shù)構(gòu)建。

四、CMDB和數(shù)據(jù)中臺有什么關系？

它們都是數(shù)據(jù)能力的傳導平臺，核心職責都是整合數(shù)據(jù)、加工數(shù)據(jù)、輸出數(shù)據(jù)（CMDB業(yè)務模型圖和中臺圖對比）

CMDB也符合運維數(shù)據(jù)中臺兩大核心理念：數(shù)據(jù)中心級和數(shù)據(jù)服務。

這里的“數(shù)據(jù)中心級”有兩個含義，首先指CMDB的數(shù)據(jù)范圍包含與應用系統(tǒng)相關的所有IT資源，這是CMDB與所有專業(yè)領域配置庫（如資產(chǎn)庫、云資源庫、DB性能分析庫、網(wǎng)管資源庫等）的核心區(qū)別之一。其次，CMDB是面向數(shù)據(jù)中心所有運維工具使用的，解決的是跨專業(yè)數(shù)據(jù)共享問題。這也引出CMDB的第二個核心理念，即必須具備靈活、開放的數(shù)據(jù)服務能力。

但CMDB和運維數(shù)據(jù)中臺也有些許不同點，在數(shù)據(jù)范圍方面，數(shù)據(jù)中臺是全域數(shù)據(jù)（包括配置、告警、指標、工單、操作），而CMDB只有靜態(tài)的配置數(shù)據(jù)。從這點看，其實數(shù)據(jù)中臺是可以涵蓋CMDB的。事實上，CMDB可以定位成數(shù)據(jù)中臺的主數(shù)據(jù)管理模塊。

五、數(shù)據(jù)中臺對CMDB建設有哪些啟發(fā)？

**1.**要先做數(shù)據(jù)商人，而不是數(shù)據(jù)科學家

數(shù)據(jù)商人會將注意力放在解決跨部門、跨工具數(shù)據(jù)流通不暢的問題，要促進數(shù)據(jù)商品的流通。而數(shù)據(jù)科學家則專注于對某個專業(yè)領域開展數(shù)據(jù)研究，以解決這個專業(yè)領域的某個難題。

具體來說，數(shù)據(jù)商人做什么事情呢？比如：

從服務請求流程獲得新增的IT資源（后稱CI），對該資源數(shù)據(jù)進行整合、加工，然后將數(shù)據(jù)送給自動化平臺進行監(jiān)控部署

從自動發(fā)現(xiàn)平臺中獲取文件系統(tǒng)CI，給這些CI豐富應用責任人信息，然后將數(shù)據(jù)送給監(jiān)控平臺進行告警豐富

從防火墻管理工具中獲取網(wǎng)絡訪問策略信息，給這些訪問策略豐富源、目的CI的配置信息（包括主機名、所屬應用、責任人等），然后將數(shù)據(jù)提供給應用崗，供日常查詢

那什么是數(shù)據(jù)科學家做的事情？

研究原始的防火墻策略日志，設計復雜的數(shù)據(jù)分析邏輯，輸出結(jié)構(gòu)化的訪問策略

采集數(shù)據(jù)庫參數(shù)信息，開發(fā)參數(shù)比對程序，輸出比對結(jié)果

在建設初期，CMDB應該先做好數(shù)據(jù)商人，這里主要是從成本和收益考慮，畢竟有大量的跨部門、跨工具數(shù)據(jù)共享需求，這些需求涉及的配置數(shù)據(jù)并不復雜，但收益卻非常明顯，所以應該優(yōu)先建設。至于數(shù)據(jù)科學家的工作，可以在CMDB成熟后逐漸開展，不過最理想的方案仍然是由專業(yè)的技術(shù)管理工具解決專業(yè)的問題。

**2.**要關注消費場景，但不應大包大攬，要聚焦數(shù)據(jù)服務

按照數(shù)據(jù)中臺的思想，CMDB的定位是“做外賣”，但很多IT組織把CMDB做成了“開飯館”。開飯館就要買菜、洗菜、切菜、炒菜、端菜、甚至搞點節(jié)目讓顧客吃得開心，這是貫穿前后臺的一體化能力。對應CMDB就是大搞數(shù)據(jù)生產(chǎn)，建立一系列配套流程制度和自動發(fā)現(xiàn)工具，定制大量數(shù)據(jù)維護和消費界面，傾力打造**貫穿前后臺數(shù)據(jù)生產(chǎn)、治理、消費的一體化能力平臺。**這種建設方式并不妥當，一方面打造前后臺一體化的能力平臺需要相當長的時間和巨大成本，另一方面，即使建設成了，無非是又立起了一個煙囪系統(tǒng)，隔絕于現(xiàn)有運維體系之外。

基于中臺思路，我們認為更加合理的建設方式是橫向能力整合，類似送外賣。這種建設思路首先要考慮的是前臺用戶是誰，有什么數(shù)據(jù)需求，數(shù)據(jù)的生產(chǎn)源頭在哪里，如何與數(shù)據(jù)源的流程對接實現(xiàn)數(shù)據(jù)的自然沉淀，然后對沉淀的數(shù)據(jù)進行加工整合，最后通過服務化接口將數(shù)據(jù)投送到用戶嘴里。這種建設方式的成本更低、見效更快。