[[329509]]

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

• 手工運維
  以人工作業為主要表現形式的運維，發布、故障處理、巡檢等等

• 腳本化運維
  用一些自動化腳本來代替人工作業，有一些發布的腳本封裝了人為操作。

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

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

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

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

• 沒有整體規劃設計
  在我幾年的創業過程中，也接觸了多個行業的客戶，能夠提出整體規劃設計的運維部門寥寥無幾，而運維體系建設得好的公司恰恰都是那些做了整體規劃的。

• 豎井式的組織架構
  職能式的組織架構導致規劃的完全割裂，獨自建設。很有意思的是，在傳統企業，A部門不了解B部門的平臺建設內容。一個例子：聯邦CMDB絕對是豎井式組織架構下的妥協結果。曾經見過一個金融企業，運維平臺工具加起來有接近百個之多。

• 歷史遺留的累積
  歷史遺留是不可回避的，但也是事實存在。歷史遺留不可怕，可怕的是建設沒有延續性，來了就重做，重新立項。我認為一定周期的重建是OK的，否則都是瞎搞。這個和IT發展規律一樣，技術是有采用周期的。

• 過多倚重乙方服務支撐
  大部分傳統企業都是依賴乙方提供的解決方案，不同的乙方建設方案邊界本來就有重復的，最后就變成各種交叉重疊，導致系統職責不清。建設了幾年，發現沒有很大的變化，還在原地踏步。今天甲乙雙方的關系也要發生變化，更應該以“精益Partner”的方式來看待彼此，確保整個發展過程的延續性。

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

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

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

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

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

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

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

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

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

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

• 運維中臺是一套能力平臺的整合，協作形成運維業務價值的輸出
  很多公司的運維平臺已經建設了部分，可以兼顧現有的系統建設現狀，提供能力平臺的整合，面向業務場景實現協作，這個才是正確的思路。

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

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

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

• 基于門戶的URI集成。

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

  任務入口、服務入口、信息入口、產品入口

• 基于微應用的UI集成。

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

• 基于中臺的API集成。

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

• 基于CMDB的數據集成。

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

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

• 通用能力層。

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

• 服務中臺層。

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

• 微應用層。

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

• 門戶層。

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

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

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

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

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