[[329509]]

第一章，過(guò)去的運(yùn)維平臺(tái)建設(shè)思路

• 手工運(yùn)維
  以人工作業(yè)為主要表現(xiàn)形式的運(yùn)維，發(fā)布、故障處理、巡檢等等

• 腳本化運(yùn)維
  用一些自動(dòng)化腳本來(lái)代替人工作業(yè)，有一些發(fā)布的腳本封裝了人為操作。

• 自動(dòng)化平臺(tái)運(yùn)維
  用平臺(tái)可視化封裝各種場(chǎng)景化作業(yè)，按照?qǐng)鼍凹?xì)分，通道、原子作業(yè)庫(kù)、場(chǎng)景編排庫(kù)都開始出現(xiàn)了，最終界面可視化操作完成。

• 數(shù)據(jù)化運(yùn)維
  動(dòng)化部分代替了人的事務(wù)勞動(dòng)，此時(shí)精細(xì)化運(yùn)營(yíng)的要求就出來(lái)了，而精細(xì)化運(yùn)營(yíng)的核心就是要借助數(shù)據(jù)來(lái)表達(dá)、驅(qū)動(dòng)和優(yōu)化，相關(guān)領(lǐng)域是ITOA。

• 智能化運(yùn)維
  行業(yè)也在提AI代替人的運(yùn)維，基于模型和算法來(lái)把一些運(yùn)維場(chǎng)景接管起來(lái)，比如說(shuō)事件根因分析、故障影響分析、預(yù)測(cè)、異常探測(cè)等等。最終肯定是希望 AIOps 來(lái)實(shí)現(xiàn)無(wú)人化運(yùn)維 NoOps。

過(guò)去的運(yùn)維平臺(tái)建設(shè)是碎片的，缺啥立項(xiàng)做啥，其中原因是：

• 沒有整體規(guī)劃設(shè)計(jì)
  在我?guī)啄甑膭?chuàng)業(yè)過(guò)程中，也接觸了多個(gè)行業(yè)的客戶，能夠提出整體規(guī)劃設(shè)計(jì)的運(yùn)維部門寥寥無(wú)幾，而運(yùn)維體系建設(shè)得好的公司恰恰都是那些做了整體規(guī)劃的。

• 豎井式的組織架構(gòu)
  職能式的組織架構(gòu)導(dǎo)致規(guī)劃的完全割裂，獨(dú)自建設(shè)。很有意思的是，在傳統(tǒng)企業(yè)，A部門不了解B部門的平臺(tái)建設(shè)內(nèi)容。一個(gè)例子：聯(lián)邦CMDB絕對(duì)是豎井式組織架構(gòu)下的妥協(xié)結(jié)果。曾經(jīng)見過(guò)一個(gè)金融企業(yè)，運(yùn)維平臺(tái)工具加起來(lái)有接近百個(gè)之多。

• 歷史遺留的累積
  歷史遺留是不可回避的，但也是事實(shí)存在。歷史遺留不可怕，可怕的是建設(shè)沒有延續(xù)性，來(lái)了就重做，重新立項(xiàng)。我認(rèn)為一定周期的重建是OK的，否則都是瞎搞。這個(gè)和IT發(fā)展規(guī)律一樣，技術(shù)是有采用周期的。

• 過(guò)多倚重乙方服務(wù)支撐
  大部分傳統(tǒng)企業(yè)都是依賴乙方提供的解決方案，不同的乙方建設(shè)方案邊界本來(lái)就有重復(fù)的，最后就變成各種交叉重疊，導(dǎo)致系統(tǒng)職責(zé)不清。建設(shè)了幾年，發(fā)現(xiàn)沒有很大的變化，還在原地踏步。今天甲乙雙方的關(guān)系也要發(fā)生變化，更應(yīng)該以“精益Partner”的方式來(lái)看待彼此，確保整個(gè)發(fā)展過(guò)程的延續(xù)性。

第二章，關(guān)于運(yùn)維組織架構(gòu)的討論

很早講過(guò)今天的運(yùn)維組織架構(gòu)一定要“面向應(yīng)用運(yùn)維+運(yùn)維開發(fā)”的組織架構(gòu)來(lái)設(shè)計(jì)，以應(yīng)用為中心來(lái)驅(qū)動(dòng)整個(gè)運(yùn)維協(xié)作過(guò)程，拉通前后端資源。個(gè)人很喜歡TOGAF架構(gòu)，覺得應(yīng)用架構(gòu)是架構(gòu)的核心，沒有應(yīng)用架構(gòu)承上啟下的作用，缺少管理支點(diǎn)。隨著未來(lái)工作負(fù)載逐漸遷移到容器之上，你對(duì)應(yīng)用的理解會(huì)更加深刻，云原生應(yīng)用標(biāo)準(zhǔn)會(huì)更加的普及，應(yīng)用的理解也會(huì)越來(lái)越普遍。

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

組織架構(gòu)調(diào)整到了，接下來(lái)就是業(yè)務(wù)認(rèn)知的問題了。

第三章，運(yùn)維的業(yè)務(wù)領(lǐng)域是如何劃分的？

• 資產(chǎn)交付。完成一個(gè)從預(yù)算、采購(gòu)到上架的過(guò)程過(guò)程管理，到加電狀態(tài)。
• 資源交付。按照業(yè)務(wù)和應(yīng)用的需求，完成一個(gè)OS級(jí)的資源交付過(guò)程，會(huì)涉及到云的資源交付，這也是今天CMP的核心定位。
• 應(yīng)用交付。OS交付到應(yīng)用部門之后，應(yīng)用從部署到運(yùn)行的過(guò)程，這是今天DevOps的核心定位。
• 運(yùn)營(yíng)管理。在各類資源在生產(chǎn)運(yùn)行的過(guò)程中，要輔助各種運(yùn)營(yíng)管理手段、監(jiān)控、事件、變更、可用性，連續(xù)性等管理

基于生命周期過(guò)程，把運(yùn)維的生命周期過(guò)程框架抽象如下：

• 資產(chǎn)管理域（資產(chǎn)預(yù)算、采購(gòu)和交付管理）
• 資源管理域（統(tǒng)一IT資源管理）
• 資源交付域（統(tǒng)一云管）
• 應(yīng)用交付域（部署態(tài)）
• 應(yīng)用運(yùn)行域（運(yùn)行態(tài)）
• 服務(wù)交付域（部署態(tài)）
• 服務(wù)運(yùn)行域（運(yùn)行態(tài)）
• 運(yùn)營(yíng)管理域（流程管理）
• 運(yùn)營(yíng)調(diào)度域（運(yùn)營(yíng)管理）

第四章，運(yùn)維中臺(tái)如何形成？

• 運(yùn)維中臺(tái)是一套全新的技術(shù)平臺(tái)
  如果誰(shuí)這么說(shuō)，我覺得是忽悠偏多的。
  千萬(wàn)注意，不要一上來(lái)就說(shuō)要做一個(gè)新的運(yùn)維中臺(tái)，危險(xiǎn)的想法！
  運(yùn)維中臺(tái)絕不是一個(gè)全新的東西，必須要照顧企業(yè)過(guò)去的運(yùn)維平臺(tái)建設(shè)情況，當(dāng)然不合理的部分該修理就要修理，該重建就要重建。
  就拿ITSM來(lái)說(shuō)，無(wú)法流程協(xié)作，就需要修理；
  業(yè)務(wù)中臺(tái)所依賴的技術(shù)中臺(tái)部分大部分都是要重建，命令通道、數(shù)據(jù)通道、服務(wù)編排等等。

• 運(yùn)維中臺(tái)是一套能力平臺(tái)的整合，協(xié)作形成運(yùn)維業(yè)務(wù)價(jià)值的輸出
  很多公司的運(yùn)維平臺(tái)已經(jīng)建設(shè)了部分，可以兼顧現(xiàn)有的系統(tǒng)建設(shè)現(xiàn)狀，提供能力平臺(tái)的整合，面向業(yè)務(wù)場(chǎng)景實(shí)現(xiàn)協(xié)作，這個(gè)才是正確的思路。

  在今天運(yùn)維平臺(tái)采購(gòu)建議中，我給所有甲方的一個(gè)核心建議：

  誰(shuí)不開放API，開放了后續(xù)API要定制，這種平臺(tái)都可以不考慮。但今天在國(guó)內(nèi)，由于2B服務(wù)商都喜歡貪大求全，什么都做，最終導(dǎo)致能力不斷重疊，給客戶也造成了困擾，比較喜歡聚焦模式，聚焦在一個(gè)業(yè)務(wù)域做深做透。

運(yùn)維中臺(tái)是通過(guò)整合，迭代設(shè)計(jì)出來(lái)，不是一次性開發(fā)出來(lái)的。因此這個(gè)地方提供的集成方案是分四個(gè)層次（暫時(shí)用手繪）：

• 基于門戶的URI集成。

  實(shí)現(xiàn)各個(gè)平臺(tái)入口級(jí)的整合，可以形成面向個(gè)人的四大入口：

  任務(wù)入口、服務(wù)入口、信息入口、產(chǎn)品入口

• 基于微應(yīng)用的UI集成。

  用微應(yīng)用重新封裝服務(wù)中臺(tái)的能力API服務(wù)，實(shí)現(xiàn)個(gè)性化的服務(wù)輸出。

• 基于中臺(tái)的API集成。

  通過(guò)統(tǒng)一API服務(wù)網(wǎng)關(guān)，把多平臺(tái)的能力整合起來(lái)，統(tǒng)一服務(wù)輸出給上層微應(yīng)用模塊。

• 基于CMDB的數(shù)據(jù)集成。

  這個(gè)類似于servicenow的“one data model”的思想，實(shí)現(xiàn)所有數(shù)據(jù)的集成（不包括動(dòng)態(tài)數(shù)據(jù)）。

有了這四層集成能力平臺(tái)，給一個(gè)完整的運(yùn)維中臺(tái)例子（供參考）：

• 通用能力層。

  是技術(shù)中臺(tái)的部分，是公共化技術(shù)能力的封裝

• 服務(wù)中臺(tái)層。

  是按照業(yè)務(wù)領(lǐng)域構(gòu)建的可復(fù)用的業(yè)務(wù)能力平臺(tái)，一定要注意是按照業(yè)務(wù)域劃分的。

• 微應(yīng)用層。

  是按照個(gè)性化能力封裝的，數(shù)據(jù)和自動(dòng)化能力的個(gè)性化。

• 門戶層。

  底層能力越來(lái)越多，復(fù)雜，屏蔽底層的復(fù)雜業(yè)務(wù)細(xì)節(jié)，需要門戶來(lái)做多個(gè)維度收斂。

第五章，運(yùn)維中臺(tái)的行業(yè)化落地？

• 【深入解析運(yùn)維自動(dòng)化框架】
• 【CMDB，統(tǒng)一數(shù)據(jù)模型的價(jià)值】
• 【基于統(tǒng)一公共服務(wù)網(wǎng)關(guān)的平臺(tái)能力集成】
• 【運(yùn)維中臺(tái)配上低代碼開發(fā)模式，絕佳的組合】

3、沒有ERP，是否要建設(shè)中臺(tái)？如何建？
觀點(diǎn)：中臺(tái)建設(shè)與ERP無(wú)關(guān)，它是對(duì)企業(yè)系統(tǒng)架構(gòu)和組織架構(gòu)一次全面重構(gòu)升級(jí)。

論述：中臺(tái)一方面要關(guān)注系統(tǒng)架構(gòu)，更要關(guān)注組織架構(gòu)和業(yè)務(wù)能力。沒有匹配的組織架構(gòu)，中臺(tái)建設(shè)不起來(lái)，是屬于無(wú)“腦”指揮；沒有業(yè)務(wù)能力，中臺(tái)建設(shè)也無(wú)從談起，是屬于無(wú)“心”執(zhí)行。針對(duì)不同的業(yè)務(wù)領(lǐng)域，中臺(tái)能力涵蓋的范圍會(huì)有所不同，而非必須要有ERP作為中臺(tái)建設(shè)前提，如DevOps及運(yùn)維、營(yíng)銷、敏捷供應(yīng)鏈等等，垂直行業(yè)如地產(chǎn)、汽車、能源等等。