[[329509]]

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

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

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

• 自動化平臺運(yùn)維
  用平臺可視化封裝各種場景化作業(yè)，按照場景細(xì)分，通道、原子作業(yè)庫、場景編排庫都開始出現(xiàn)了，最終界面可視化操作完成。

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

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

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

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

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

• 歷史遺留的累積
  歷史遺留是不可回避的，但也是事實(shí)存在。歷史遺留不可怕，可怕的是建設(shè)沒有延續(xù)性，來了就重做，重新立項(xiàng)。我認(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ù)性。

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

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

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

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

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

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

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

• 資產(chǎn)管理域（資產(chǎn)預(yù)算、采購和交付管理）
• 資源管理域（統(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ùn)營調(diào)度域（運(yùn)營管理）

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

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

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

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

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

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

• 基于門戶的URI集成。

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

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

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

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

• 基于中臺的API集成。

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

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

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

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

• 通用能力層。

  是技術(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ùn)維中臺的行業(yè)化落地？

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

3、沒有ERP，是否要建設(shè)中臺？如何建？
觀點(diǎn)：中臺建設(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ùn)維、營銷、敏捷供應(yīng)鏈等等，垂直行業(yè)如地產(chǎn)、汽車、能源等等。