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