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

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就是大搞數據生產，建立一系列配套流程制度和自動發現工具，定制大量數據維護和消費界面，傾力打造**貫穿前后臺數據生產、治理、消費的一體化能力平臺。**這種建設方式并不妥當，一方面打造前后臺一體化的能力平臺需要相當長的時間和巨大成本，另一方面，即使建設成了，無非是又立起了一個煙囪系統，隔絕于現有運維體系之外。

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