運維遇上中臺，送分或送命？我是這樣理解的

前段時間有篇文章朋友圈瘋傳，【中臺搞了2年，項目叫停，CIO被裁！本以爲中颱是道送分題，沒想到是送命題！】。從結果來說，這個項目肯定是失敗的，文章中透露出中臺是“最短的笑話”和”玄學”之類的表達。很多時候把中臺看成一個技術課題，但做着做着發現不對，它又是一個組織課題和業務課題。

在前不久的【數字化奇葩說】第一期關於ERP和中臺的討論，我也作爲嘉賓參與並發表了個人觀點【見文末】。其實想表達的是，能和中臺扯上關係的太多了，回到運維領域，是否有一個運維中臺存在？它是否是個玄幻話題？抑或是爲了概念而概念？如果有，我們該如何抽絲剝繭的理解它呢？

第一章，過去的運維平臺建設思路

從14年底開始，互聯網運維理念興起之後，傳統行業也開始日益重視運維平臺的建設。甚至按照運維平臺的建設情況來劃分運維成熟度水平，典型階段劃分如下：

手工運維
以人工作業爲主要表現形式的運維，發佈、故障處理、巡檢等等
腳本化運維

用一些自動化腳本來代替人工作業，有一些發佈的腳本封裝了人爲操作。
自動化平臺運維

用平臺可視化封裝各種場景化作業，按照場景細分，通道、原子作業庫、場景編排庫都開始出現了，最終界面可視化操作完成。
數據化運維

動化部分代替了人的事務勞動，此時精細化運營的要求就出來了，而精細化運營的核心就是要藉助數據來表達、驅動和優化，相關領域是ITOA。
智能化運維

行業也在提AI代替人的運維，基於模型和算法來把一些運維場景接管起來，比如說事件根因分析、故障影響分析、預測、異常探測等等。最終肯定是希望 AIOps 來實現無人化運維 NoOps。

過去的運維平臺建設是碎片的，缺啥立項做啥，其中原因是：

沒有整體規劃設計
在我幾年的創業過程中，也接觸了多個行業的客戶，能夠提出整體規劃設計的運維部門寥寥無幾，而運維體系建設得好的公司恰恰都是那些做了整體規劃的。
豎井式的組織架構
職能式的組織架構導致規劃的完全割裂，獨自建設。很有意思的是，在傳統企業，A部門不瞭解B部門的平臺建設內容。一個例子：聯邦CMDB絕對是豎井式組織架構下的妥協結果。曾經見過一個金融企業，運維平臺工具加起來有接近百個之多。
歷史遺留的累積歷史遺留是不可迴避的，但也是事實存在。歷史遺留不可怕，可怕的是建設沒有延續性，來了就重做，重新立項。我認爲一定週期的重建是OK的，否則都是瞎搞。這個和IT發展規律一樣，技術是有采用週期的。
過多倚重乙方服務支撐大部分傳統企業都是依賴乙方提供的解決方案，不同的乙方建設方案邊界本來就有重複的，最後就變成各種交叉重疊，導致系統職責不清。建設了幾年，發現沒有很大的變化，還在原地踏步。今天甲乙雙方的關係也要發生變化，更應該以“精益Partner”的方式來看待彼此，確保整個發展過程的延續性。

圍繞運維的目標：高可用、連續性、成本、效率和質量目標，碎片化的平臺是沒法提供協作能力的。而運維作爲一個服務主體存在，它的服務化需要整合後端的各個能力，否則無法直接暴露給它的被服務部門。

第二章，關於運維組織架構的討論

首先我想和探討一下組織命題：康威定律和反康威定律。康威定律是組織架構影響IT系統架構的設計；反康威定律是IT系統也會影響組織架構設計。這個地方至少暴露出一個邏輯：組織架構和IT架構設計的匹配度問題。在文章開頭講的那個項目，如果組織架構不變，失敗實在難免。一方面固化的組織架構無法改變人的思維模式，中臺落地也是災難；另一方面，中臺落地之後，組織架構不適應調整，業務流程不再造，中臺也是裹腳布。

運維組織架構過去一直是按照職能組織架構設計的，比如說網絡管理、數據庫管理、安全管理和一線NOC等等。在某些行業，爲了打通這些職能，上面還設計了其他職能部門：運行調度管理、流程管理等等。很有意思的現象是：能力是職能部門建設，管理制度是上層部門制定的，這個時候脫節也是不可避免。

很早講過今天的運維組織架構一定要“面向應用運維+運維開發”的組織架構來設計，以應用爲中心來驅動整個運維協作過程，拉通前後端資源。個人很喜歡TOGAF架構，覺得應用架構是架構的核心，沒有應用架構承上啓下的作用，缺少管理支點。隨着未來工作負載逐漸遷移到容器之上，你對應用的理解會更加深刻，雲原生應用標準會更加的普及，應用的理解也會越來越普遍。

運維開發是取決於平臺的建設模式，是自研，是共研，是外研，這個要結合企業自己的情況來定。自研是需要投入大量的研發資源的，必須要按照業務系統研發的配置來做，是和規模大的企業；共研是核心能力外包給第三方，但是要求在開放源碼的模式，一起開發，適合規模中等的企業；外研，就是把平臺能力交給第三方，適合中小型企業。這樣的組織架構是從業務和技術兩個維度拉通了底層職能部門，保證了最終的運維服務化輸出。

我們要注意模塊化架構和服務中臺化架構的區別。在18年底，我發現連續做了三年多的EasyOps產品，是個模塊化產品，表現是多客戶需求無法協調，開關隨處可見，最糟糕的就是爲某個客戶做的開關。注意：模塊化平臺不等於碎片化平臺！

隨着我們服務的客戶越來越多，行業越來越多，挑戰就出來了—— 無法基於模塊做公共能力抽象，讓我們對客戶需求的響應異常緩慢。造成此問題的核心原因，客戶每次提的需求都要經歷優維的每個角色（項目經理、產品經理、開發經理）。後來對產品做了一個定義： Product = Platform + Plugin。

Platform就要基於業務域做公共能力抽象，如資源管理、應用部署、環境管理等等，這就是我所說的運維中臺；Plugin 就要基於公共平臺能力做個性化封裝，我們稱之爲微應用。確定了這樣一個產品架構，19年初，我們對公司組織架構做了一次調整（如下圖）。“一個戰略的落地必須要組織大腦先動”，必須要把屁股從原有的位置上挪開，纔會產生新的思維模式。

組織架構調整到了，接下來就是業務認知的問題了。

第三章，運維的業務領域是如何劃分的？

運維是一個複雜的過程，結合IT對象、人和目標來看，是一個非常複雜的課題，以前對外分享是從四個維度做過一些分析的：

此處不展開復雜的介紹，拋開這些複雜的因素，今天提出一個新的方法：運維生命週期分析法，先來看個例子：

用生命週期的觀點來理解運維整個過程，運維生命週期過程包含四部分：

資產交付。完成一個從預算、採購到上架的過程過程管理，到加電狀態。
資源交付。按照業務和應用的需求，完成一個OS級的資源交付過程，會涉及到雲的資源交付，這也是今天CMP的核心定位。
應用交付。OS交付到應用部門之後，應用從部署到運行的過程，這是今天DevOps的核心定位。
運營管理。在各類資源在生產運行的過程中，要輔助各種運營管理手段、監控、事件、變更、可用性，連續性等管理

基於生命週期過程，把運維的生命週期過程框架抽象如下：

關於該生命週期過程，還可以進一步細化成不同的領域（Domain）業務模型。在這個地方，建議大家去了解和學習一下【領域驅動設計】知識，順便推薦一本書《領域驅動設計軟件核心複雜性應對之道》，以便我們更好的掌握一些業務設計語言和思維，在此也不做贅述。基於生命週期過程，我把運維的業務領域劃分成如下九個部分：

資產管理域（資產預算、採購和交付管理）
資源管理域（統一IT資源管理）
資源交付域（統一雲管）
應用交付域（部署態）
應用運行域（運行態）
服務交付域（部署態）
服務運行域（運行態）
運營管理域（流程管理）
運營調度域（運營管理）

有了業務域的劃分，運維平臺的建設邊界也就確定了，要反過來支撐業務。運維也是有業務領域驅動，做大而全的產品，推銷大而全的方案，當下看基本上不靠譜。

第四章，運維中臺如何形成？

前面把組織架構和業務領域都做了詳細分析，它們都是重要的前置因素。對它們的影響不認識清楚，運維的中臺建設無從談起。接下來從技術的角度來看看運維中臺如何形成的？有兩種觀點我們需要討論一下：

運維中臺是一套全新的技術平臺

如果誰這麼說，我覺得是忽悠偏多的。

千萬注意，不要一上來就說要做一個新的運維中臺，危險的想法！

運維中臺絕不是一個全新的東西，必須要照顧企業過去的運維平臺建設情況，當然不合理的部分該修理就要修理，該重建就要重建。

就拿ITSM來說，無法流程協作，就需要修理；

業務中臺所依賴的技術中臺部分大部分都是要重建，命令通道、數據通道、服務編排等等。
運維中臺是一套能力平臺的整合，協作形成運維業務價值的輸出
很多公司的運維平臺已經建設了部分，可以兼顧現有的系統建設現狀，提供能力平臺的整合，面向業務場景實現協作，這個纔是正確的思路。

在今天運維平臺採購建議中，我給所有甲方的一個核心建議：

誰不開放API，開放了後續API要定製，這種平臺都可以不考慮。但今天在國內，由於2B服務商都喜歡貪大求全，什麼都做，最終導致能力不斷重疊，給客戶也造成了困擾，比較喜歡聚焦模式，聚焦在一個業務域做深做透。

運維中臺是通過整合，迭代設計出來，不是一次性開發出來的。因此這個地方提供的集成方案是分四個層次（暫時用手繪）：

基於門戶的URI集成。

實現各個平臺入口級的整合，可以形成面向個人的四大入口：

任務入口、服務入口、信息入口、產品入口
基於微應用的UI集成。

用微應用重新封裝服務中臺的能力API服務，實現個性化的服務輸出。
基於中臺的API集成。

通過統一API服務網關，把多平臺的能力整合起來，統一服務輸出給上層微應用模塊。
基於CMDB的數據集成。

這個類似於servicenow的“one data model”的思想，實現所有數據的集成（不包括動態數據）。

有了這四層集成能力平臺，給一個完整的運維中臺例子（供參考）：

通用能力層。

是技術中臺的部分，是公共化技術能力的封裝
服務中臺層。

是按照業務領域構建的可複用的業務能力平臺，一定要注意是按照業務域劃分的。
微應用層。

是按照個性化能力封裝的，數據和自動化能力的個性化。
門戶層。

底層能力越來越多，複雜，屏蔽底層的複雜業務細節，需要門戶來做多個維度收斂。

第五章，運維中臺的行業化落地？

深入到行業領域，也看看運維中臺如何在行業落地的（銀行，券商，運營商，保險）。這個問題其實是很複雜的，要兼顧企業的組織架構、系統現狀、人力情況及業務目標來定。我反對爲了中臺而中臺，過度投入和設計很可能都是災難。不要寄希望於這些新概念和新名詞（包括AIOps），否則就真的變成一個送命題。我給很多客戶設計的運維平臺體系架構，以服務驅動的運維平臺體系的構建，如下：

服務是有業務目標的，服務的上下、橫向關係，我們要非常清楚。 ITSM如何和後端服務整合？自動化運維整個過程和場景如何提煉？數據化運維平臺的數據類型是什麼？數據類型的不同帶來的技術和平臺有什麼變化？數據的IT運營價值如何進一步去提煉？數據如何進行整合關聯和業務理解？如何從數據模型和數據服務上面去打通各個能力？

作爲一個規模化服務實體（如我們或者大型機構的運維部門），此時需要從組織架構的角度打破壁壘，建設能力複用平臺，做API全開放，還需要在此基礎上提供一個快速開發環境RAD，把個性化定製能力推到業務部門。由此延伸出來對人員能力的要求是什麼樣的？運維開發team該如何去設置？各個運維職能小組內該如何配備相應的運維專家和運維開發人員？

運維研發體系需要做什麼樣的劃分？中臺開發和個性化開發如何形成賦能關係？中臺開發一方面不斷抽象提煉、共性化中臺能力，另外還要結合IT趨勢如何實現創新突破？這都是擺在運維複雜系統面前的課題。

更需要領導者對運維的業務目標有清晰的認識，業務目標決定後面的平臺形態，切不可“唯技術論”或者“技術至上論”。一個小創業公司Excel是可以解決問題的，你非要給他推薦一個大管理系統，不合適。需要認識運維中臺的本質，絕不是一個技術中臺，更不是玄幻之術，而是先有生命週期過程，而後是業務域的劃分。一方面也要把自己手裏的存貨價值搞清楚，不要一上來就推倒重來，另外一方面需要查缺補漏的部分，可以補充。

總結：切忌一上來就中臺搞定一切，技術化理解中臺。我們更應該關注中臺背後的那些影響因素、服務體系和分塊的能力建設，打好基礎，再走向下一步：中臺化。

接下來，基於中臺，我還會寫幾篇文章：

【深入解析運維自動化框架】
【CMDB，統一數據模型的價值】
【基於統一公共服務網關的平臺能力集成】
【運維中臺配上低代碼開發模式，絕佳的組合】

附錄：【數字化奇葩說】，老王的觀點：

1、中臺和ERP的關係

觀點：ERP是聚焦在企業內過程信息化管理；中臺是聚焦在企業內外協同的過程統一數字化管理。

論述：ERP是基於一套管理理念，最終延伸出一套IT平臺落地最佳實踐，是企業內部全過程能力管理，其中分了多個模塊實現；中臺是數字化平臺架構體系，分域分層建設的能力複用平臺，ERP是部分企業的業務能力中臺的一部分。

2、有了ERP，是否要建設中臺？如何建？

觀點：ERP平臺是企業數字化中臺的一部分，藉助中臺能力整合網關，中臺建設更易形成。

論述：企業中臺覆蓋業務(應用）和數據兩個領域，ERP作爲企業業務的核心中樞平臺之一，中臺必須實現對其整合。通過API網關或者ESB技術實現企業應用集成，但中臺的業務域還包含很多，特別是一些大型的互聯網業務系統，中臺還包含如積分、會員、支付、商品等等。

3、沒有ERP，是否要建設中臺？如何建？
觀點：中臺建設與ERP無關，它是對企業系統架構和組織架構一次全面重構升級。

論述：中臺一方面要關注系統架構，更要關注組織架構和業務能力。沒有匹配的組織架構，中臺建設不起來，是屬於無“腦”指揮；沒有業務能力，中臺建設也無從談起，是屬於無“心”執行。針對不同的業務領域，中臺能力涵蓋的範圍會有所不同，而非必須要有ERP作爲中颱建設前提，如DevOps及運維、營銷、敏捷供應鏈等等，垂直行業如地產、汽車、能源等等。

來源：本文轉自公衆號互聯網運維雜談，作者王津銀。

6月19日，GNSEC 全球新一代軟件工程 2020 線上峯會，高效運維社區核心成員，GOPS 全球運維大會金牌講師趙舜東（趙班長）與您聊聊中小企業自動化運維平臺開發實踐。