建站
咨詢
售后
建站咨詢
新聞中心
前段時間有篇文章朋友圈瘋傳，【中臺搞了2年，項目叫停，CIO被裁！本以為中臺是道送分題，沒想到是送命題！】。從結果來說，這個項目肯定是失敗的，文章中透露出中臺是“最短的笑話”和”玄學”之類的表達。很多時候把中臺看成一個技術課題，但做著做著發(fā)現(xiàn)不對，它又是一個組織課題和業(yè)務課題。
在前不久的【數(shù)字化奇葩說】第一期關于ERP和中臺的討論，我也作為嘉賓參與并發(fā)表了個人觀點【見文末】。其實想表達的是，能和中臺扯上關系的太多了，回到運維領域，是否有一個運維中臺存在？它是否是個玄幻話題？抑或是為了概念而概念？如果有，我們該如何抽絲剝繭的理解它呢？
專業(yè)領域包括成都網(wǎng)站建設、成都網(wǎng)站制作、商城網(wǎng)站建設、微信營銷、系統(tǒng)平臺開發(fā)， 與其他網(wǎng)站設計及系統(tǒng)開發(fā)公司不同，創(chuàng)新互聯(lián)的整合解決方案結合了幫做網(wǎng)絡品牌建設經(jīng)驗和互聯(lián)網(wǎng)整合營銷的理念，并將策略和執(zhí)行緊密結合，為客戶提供全網(wǎng)互聯(lián)網(wǎng)整合方案。
第一章，過去的運維平臺建設思路
從14年底開始，互聯(lián)網(wǎng)運維理念興起之后，傳統(tǒng)行業(yè)也開始日益重視運維平臺的建設。甚至按照運維平臺的建設情況來劃分運維成熟度水平，典型階段劃分如下：
-
手工運維
以人工作業(yè)為主要表現(xiàn)形式的運維，發(fā)布、故障處理、巡檢等等 -
腳本化運維
用一些自動化腳本來代替人工作業(yè)，有一些發(fā)布的腳本封裝了人為操作。 -
自動化平臺運維
用平臺可視化封裝各種場景化作業(yè)，按照場景細分，通道、原子作業(yè)庫、場景編排庫都開始出現(xiàn)了，最終界面可視化操作完成。 -
數(shù)據(jù)化運維
動化部分代替了人的事務勞動，此時精細化運營的要求就出來了，而精細化運營的核心就是要借助數(shù)據(jù)來表達、驅(qū)動和優(yōu)化，相關領域是ITOA。 -
智能化運維
行業(yè)也在提AI代替人的運維，基于模型和算法來把一些運維場景接管起來，比如說事件根因分析、故障影響分析、預測、異常探測等等。最終肯定是希望 AIOps 來實現(xiàn)無人化運維 NoOps。
過去的運維平臺建設是碎片的，缺啥立項做啥，其中原因是：
-
沒有整體規(guī)劃設計
在我?guī)啄甑膭?chuàng)業(yè)過程中，也接觸了多個行業(yè)的客戶，能夠提出整體規(guī)劃設計的運維部門寥寥無幾，而運維體系建設得好的公司恰恰都是那些做了整體規(guī)劃的。 -
豎井式的組織架構
職能式的組織架構導致規(guī)劃的完全割裂，獨自建設。很有意思的是，在傳統(tǒng)企業(yè)，A部門不了解B部門的平臺建設內(nèi)容。一個例子：聯(lián)邦CMDB絕對是豎井式組織架構下的妥協(xié)結果。曾經(jīng)見過一個金融企業(yè)，運維平臺工具加起來有接近百個之多。 -
歷史遺留的累積
歷史遺留是不可回避的，但也是事實存在。歷史遺留不可怕，可怕的是建設沒有延續(xù)性，來了就重做，重新立項。我認為一定周期的重建是OK的，否則都是瞎搞。這個和IT發(fā)展規(guī)律一樣，技術是有采用周期的。 -
過多倚重乙方服務支撐
大部分傳統(tǒng)企業(yè)都是依賴乙方提供的解決方案，不同的乙方建設方案邊界本來就有重復的，最后就變成各種交叉重疊，導致系統(tǒng)職責不清。建設了幾年，發(fā)現(xiàn)沒有很大的變化，還在原地踏步。今天甲乙雙方的關系也要發(fā)生變化，更應該以“精益Partner”的方式來看待彼此，確保整個發(fā)展過程的延續(xù)性。
圍繞運維的目標：高可用、連續(xù)性、成本、效率和質(zhì)量目標，碎片化的平臺是沒法提供協(xié)作能力的。而運維作為一個服務主體存在，它的服務化需要整合后端的各個能力，否則無法直接暴露給它的被服務部門。
第二章，關于運維組織架構的討論
首先我想和探討一下組織命題：康威定律和反康威定律?？低墒墙M織架構影響IT系統(tǒng)架構的設計；反康威定律是IT系統(tǒng)也會影響組織架構設計。這個地方至少暴露出一個邏輯：組織架構和IT架構設計的匹配度問題。在文章開頭講的那個項目，如果組織架構不變，失敗實在難免。一方面固化的組織架構無法改變?nèi)说乃季S模式，中臺落地也是災難；另一方面，中臺落地之后，組織架構不適應調(diào)整，業(yè)務流程不再造，中臺也是裹腳布。
運維組織架構過去一直是按照職能組織架構設計的，比如說網(wǎng)絡管理、數(shù)據(jù)庫管理、安全管理和一線NOC等等。在某些行業(yè)，為了打通這些職能，上面還設計了其他職能部門：運行調(diào)度管理、流程管理等等。很有意思的現(xiàn)象是：能力是職能部門建設，管理制度是上層部門制定的，這個時候脫節(jié)也是不可避免。
很早講過今天的運維組織架構一定要“面向應用運維+運維開發(fā)”的組織架構來設計，以應用為中心來驅(qū)動整個運維協(xié)作過程，拉通前后端資源。個人很喜歡TOGAF架構，覺得應用架構是架構的核心，沒有應用架構承上啟下的作用，缺少管理支點。隨著未來工作負載逐漸遷移到容器之上，你對應用的理解會更加深刻，云原生應用標準會更加的普及，應用的理解也會越來越普遍。
運維開發(fā)是取決于平臺的建設模式，是自研，是共研，是外研，這個要結合企業(yè)自己的情況來定。自研是需要投入大量的研發(fā)資源的，必須要按照業(yè)務系統(tǒng)研發(fā)的配置來做，是和規(guī)模大的企業(yè)；共研是核心能力外包給第三方，但是要求在開放源碼的模式，一起開發(fā)，適合規(guī)模中等的企業(yè)；外研，就是把平臺能力交給第三方，適合中小型企業(yè)。這樣的組織架構是從業(yè)務和技術兩個維度拉通了底層職能部門，保證了最終的運維服務化輸出。
我們要注意模塊化架構和服務中臺化架構的區(qū)別。在18年底，我發(fā)現(xiàn)連續(xù)做了三年多的EasyOps產(chǎn)品，是個模塊化產(chǎn)品，表現(xiàn)是多客戶需求無法協(xié)調(diào)，開關隨處可見，最糟糕的就是為某個客戶做的開關。注意：模塊化平臺不等于碎片化平臺！
隨著我們服務的客戶越來越多，行業(yè)越來越多，挑戰(zhàn)就出來了——無法基于模塊做公共能力抽象，讓我們對客戶需求的響應異常緩慢。造成此問題的核心原因，客戶每次提的需求都要經(jīng)歷優(yōu)維的每個角色（項目經(jīng)理、產(chǎn)品經(jīng)理、開發(fā)經(jīng)理）。后來對產(chǎn)品做了一個定義：Product = Platform + Plugin。
Platform就要基于業(yè)務域做公共能力抽象，如資源管理、應用部署、環(huán)境管理等等，這就是我所說的運維中臺；Plugin 就要基于公共平臺能力做個性化封裝，我們稱之為微應用。確定了這樣一個產(chǎn)品架構，19年初，我們對公司組織架構做了一次調(diào)整（如下圖）。“一個戰(zhàn)略的落地必須要組織大腦先動”，必須要把屁股從原有的位置上挪開，才會產(chǎn)生新的思維模式。
組織架構調(diào)整到了，接下來就是業(yè)務認知的問題了。
第三章，運維的業(yè)務領域是如何劃分的？
運維是一個復雜的過程，結合IT對象、人和目標來看，是一個非常復雜的課題，以前對外分享是從四個維度做過一些分析的：
此處不展開復雜的介紹，拋開這些復雜的因素，今天提出一個新的方法：運維生命周期分析法，先來看個例子：
用生命周期的觀點來理解運維整個過程，運維生命周期過程包含四部分：
- 資產(chǎn)交付。完成一個從預算、采購到上架的過程過程管理，到加電狀態(tài)。
- 資源交付。按照業(yè)務和應用的需求，完成一個OS級的資源交付過程，會涉及到云的資源交付，這也是今天CMP的核心定位。
- 應用交付。OS交付到應用部門之后，應用從部署到運行的過程，這是今天DevOps的核心定位。
- 運營管理。在各類資源在生產(chǎn)運行的過程中，要輔助各種運營管理手段、監(jiān)控、事件、變更、可用性，連續(xù)性等管理
基于生命周期過程，把運維的生命周期過程框架抽象如下：
關于該生命周期過程，還可以進一步細化成不同的領域（Domain）業(yè)務模型。在這個地方，建議大家去了解和學習一下【領域驅(qū)動設計】知識，順便推薦一本書《領域驅(qū)動設計 軟件核心復雜性應對之道》，以便我們更好的掌握一些業(yè)務設計語言和思維，在此也不做贅述?；谏芷谶^程，我把運維的業(yè)務領域劃分成如下九個部分：
- 資產(chǎn)管理域（資產(chǎn)預算、采購和交付管理）
- 資源管理域（統(tǒng)一IT資源管理）
- 資源交付域（統(tǒng)一云管）
- 應用交付域（部署態(tài)）
- 應用運行域（運行態(tài)）
- 服務交付域（部署態(tài)）
- 服務運行域（運行態(tài)）
- 運營管理域（流程管理）
- 運營調(diào)度域（運營管理）
有了業(yè)務域的劃分，運維平臺的建設邊界也就確定了，要反過來支撐業(yè)務。運維也是有業(yè)務領域驅(qū)動，做大而全的產(chǎn)品，推銷大而全的方案，當下看基本上不靠譜。
第四章，運維中臺如何形成？
前面把組織架構和業(yè)務領域都做了詳細分析，它們都是重要的前置因素。對它們的影響不認識清楚，運維的中臺建設無從談起。接下來從技術的角度來看看運維中臺如何形成的？有兩種觀點我們需要討論一下：
- 運維中臺是一套全新的技術平臺
如果誰這么說，我覺得是忽悠偏多的。千萬注意，不要一上來就說要做一個新的運維中臺，危險的想法！
運維中臺絕不是一個全新的東西，必須要照顧企業(yè)過去的運維平臺建設情況，當然不合理的部分該修理就要修理，該重建就要重建。 就拿ITSM來說，無法流程協(xié)作，就需要修理； 業(yè)務中臺所依賴的技術中臺部分大部分都是要重建，命令通道、數(shù)據(jù)通道、服務編排等等。 -
運維中臺是一套能力平臺的整合，協(xié)作形成運維業(yè)務價值的輸出
很多公司的運維平臺已經(jīng)建設了部分，可以兼顧現(xiàn)有的系統(tǒng)建設現(xiàn)狀，提供能力平臺的整合，面向業(yè)務場景實現(xiàn)協(xié)作，這個才是正確的思路。在今天運維平臺采購建議中，我給所有甲方的一個核心建議：
誰不開放API，開放了后續(xù)API要定制，這種平臺都可以不考慮。但今天在國內(nèi)，由于2B服務商都喜歡貪大求全，什么都做，最終導致能力不斷重疊，給客戶也造成了困擾，比較喜歡聚焦模式，聚焦在一個業(yè)務域做深做透。
運維中臺是通過整合，迭代設計出來，不是一次性開發(fā)出來的。因此這個地方提供的集成方案是分四個層次（暫時用手繪）：
-
基于門戶的URI集成。
實現(xiàn)各個平臺入口級的整合，可以形成面向個人的四大入口：
任務入口、服務入口、信息入口、產(chǎn)品入口
-
基于微應用的UI集成。
用微應用重新封裝服務中臺的能力API服務，實現(xiàn)個性化的服務輸出。
-
基于中臺的API集成。
通過統(tǒng)一API服務網(wǎng)關，把多平臺的能力整合起來，統(tǒng)一服務輸出給上層微應用模塊。
-
基于CMDB的數(shù)據(jù)集成。
這個類似于servicenow的“one data model”的思想，實現(xiàn)所有數(shù)據(jù)的集成（不包括動態(tài)數(shù)據(jù)）。
有了這四層集成能力平臺，給一個完整的運維中臺例子（供參考）：
-
通用能力層。
是技術中臺的部分，是公共化技術能力的封裝
-
服務中臺層。
是按照業(yè)務領域構建的可復用的業(yè)務能力平臺，一定要注意是按照業(yè)務域劃分的。
-
微應用層。
是按照個性化能力封裝的，數(shù)據(jù)和自動化能力的個性化。
-
門戶層。
底層能力越來越多，復雜，屏蔽底層的復雜業(yè)務細節(jié)，需要門戶來做多個維度收斂。
第五章，運維中臺的行業(yè)化落地？
深入到行業(yè)領域，也看看運維中臺如何在行業(yè)落地的（銀行，券商，運營商，保險）。這個問題其實是很復雜的，要兼顧企業(yè)的組織架構、系統(tǒng)現(xiàn)狀、人力情況及業(yè)務目標來定。我反對為了中臺而中臺，過度投入和設計很可能都是災難。不要寄希望于這些新概念和新名詞（包括AIOps），否則就真的變成一個送命題。我給很多客戶設計的運維平臺體系架構，以服務驅(qū)動的運維平臺體系的構建，如下：
服務是有業(yè)務目標的，服務的上下、橫向關系，我們要非常清楚。ITSM如何和后端服務整合？自動化運維整個過程和場景如何提煉？數(shù)據(jù)化運維平臺的數(shù)據(jù)類型是什么？數(shù)據(jù)類型的不同帶來的技術和平臺有什么變化？數(shù)據(jù)的IT運營價值如何進一步去提煉？數(shù)據(jù)如何進行整合關聯(lián)和業(yè)務理解？如何從數(shù)據(jù)模型和數(shù)據(jù)服務上面去打通各個能力？
作為一個規(guī)模化服務實體（如我們或者大型機構的運維部門），此時需要從組織架構的角度打破壁壘，建設能力復用平臺，做API全開放，還需要在此基礎上提供一個快速開發(fā)環(huán)境RAD，把個性化定制能力推到業(yè)務部門。由此延伸出來對人員能力的要求是什么樣的？運維開發(fā)team該如何去設置？各個運維職能小組內(nèi)該如何配備相應的運維專家和運維開發(fā)人員？
運維研發(fā)體系需要做什么樣的劃分？中臺開發(fā)和個性化開發(fā)如何形成賦能關系？中臺開發(fā)一方面不斷抽象提煉、共性化中臺能力，另外還要結合IT趨勢如何實現(xiàn)創(chuàng)新突破？這都是擺在運維復雜系統(tǒng)面前的課題。
更需要領導者對運維的業(yè)務目標有清晰的認識，業(yè)務目標決定后面的平臺形態(tài)，切不可“唯技術論”或者“技術至上論”。一個小創(chuàng)業(yè)公司Excel是可以解決問題的，你非要給他推薦一個大管理系統(tǒng)，不合適。需要認識運維中臺的本質(zhì)，絕不是一個技術中臺，更不是玄幻之術，而是先有生命周期過程，而后是業(yè)務域的劃分。一方面也要把自己手里的存貨價值搞清楚，不要一上來就推倒重來，另外一方面需要查缺補漏的部分，可以補充。
總結：切忌一上來就中臺搞定一切，技術化理解中臺。我們更應該關注中臺背后的那些影響因素、服務體系和分塊的能力建設，打好基礎，再走向下一步：中臺化。
接下來，基于中臺，我還會寫幾篇文章：
- 【深入解析運維自動化框架】
- 【CMDB，統(tǒng)一數(shù)據(jù)模型的價值】
- 【基于統(tǒng)一公共服務網(wǎng)關的平臺能力集成】
- 【運維中臺配上低代碼開發(fā)模式，絕佳的組合】
附錄：【數(shù)字化奇葩說】，老王的觀點：
1、中臺和ERP的關系
觀點：ERP是聚焦在企業(yè)內(nèi)過程信息化管理；中臺是聚焦在企業(yè)內(nèi)外協(xié)同的過程統(tǒng)一數(shù)字化管理。
論述：ERP是基于一套管理理念，最終延伸出一套IT平臺落地最佳實踐，是企業(yè)內(nèi)部全過程能力管理，其中分了多個模塊實現(xiàn)；中臺是數(shù)字化平臺架構體系，分域分層建設的能力復用平臺，ERP是部分企業(yè)的業(yè)務能力中臺的一部分。
2、有了ERP，是否要建設中臺？如何建？
觀點：ERP平臺是企業(yè)數(shù)字化中臺的一部分，借助中臺能力整合網(wǎng)關，中臺建設更易形成。
論述：企業(yè)中臺覆蓋業(yè)務(應用）和數(shù)據(jù)兩個領域，ERP作為企業(yè)業(yè)務的核心中樞平臺之一，中臺必須實現(xiàn)對其整合。通過API網(wǎng)關或者ESB技術實現(xiàn)企業(yè)應用集成，但中臺的業(yè)務域還包含很多，特別是一些大型的互聯(lián)網(wǎng)業(yè)務系統(tǒng)，中臺還包含如積分、會員、支付、商品等等。
3、沒有ERP，是否要建設中臺？如何建？
觀點：中臺建設與ERP無關，它是對企業(yè)系統(tǒng)架構和組織架構一次全面重構升級。
論述：中臺一方面要關注系統(tǒng)架構，更要關注組織架構和業(yè)務能力。沒有匹配的組織架構，中臺建設不起來，是屬于無“腦”指揮；沒有業(yè)務能力，中臺建設也無從談起，是屬于無“心”執(zhí)行。針對不同的業(yè)務領域，中臺能力涵蓋的范圍會有所不同，而非必須要有ERP作為中臺建設前提，如DevOps及運維、營銷、敏捷供應鏈等等，垂直行業(yè)如地產(chǎn)、汽車、能源等等。
網(wǎng)站題目：運維遇上中臺，送分或送命？我是這樣理解的
本文路徑：http://www.dlmjj.cn/article/dpigesc.html
