01. 運維平臺的概念被泛化
近幾年行業發展和客戶實踐，運維體系和運維架構得到蓬勃的發展，各種概念和實踐層出不窮，而關于運維平臺，主流聲音和理解有幾種：
1）平臺工程
平臺工程是Gartner發布2023年十大戰略技術趨勢，Gartner預測，到2026年，80%的軟件工程組織將建立平臺團隊，其中75%將包含開發者自助服務門戶，其核心強調的是基于云平臺的技術和產品力，按照基礎設施消費者的角度，把基礎設施封裝成平臺服務，云工具鏈和服務打通、組成小規模平臺化團隊。國內的實踐更多是在研發側，業內也有各種聲音，包括平臺工程取代DevOps等，而較少考慮運維在平臺工程的應用和服務化，架構理念較為一致，但是沒有設計和定義運維組織如何實踐平臺工程。當然，這也是運維作為業務最后一環通常都會面臨的情況。
2）運維架構治理
運維架構治理國內也有一些標準和組織做一些定義，因為的確是國內中大企業普遍都面臨的情況，因而有拆到iPaaS、aPaaS等概念。但是怎么治理，往往是摸著石頭過河，從流程、數據、場景等各個維度的都有，往往走的模式姑且定義為網狀煙囪API打通，如：進行可觀測性整合，需要打通CMDB完成對象定義，同時打通Trace、Log、Metric實現數據融合等操作。然而，這一過程中仍會面臨諸多困境，一是缺乏從運維全局角度出發的視角，二是缺乏有效的治理方法和成功實踐可供借鑒。最終可能陷入“工具豐富、建設迷茫”的狀態。
3）SRE體系
SRE是一套旨在通過軟件工程的方式提高應用可靠性的體系，用軟件工程的管理和技術方法來解決運維問題的體系，其中特別強調主動管理和規避風險，包括如運維工作限制在50%以內、面向不確定性來設計、盡可能的自動化和簡單化。為了更好地實踐，國內通常會選擇基于可支持運維開發的運維平臺，以此來迅速構建運維系統的軟件工程能力。雖然這與運維的平臺化有所重合，但并未深入探討SRE體系與平臺之間的關聯。
從個人視角來看，運維的平臺化概念定義，要聚焦到事實的起點，就是到底解決什么問題：
- 企業建設了很多工具，但是包袱卻越來越重，工具之間橫向打通困難，縱向架構治理困難，如何破局？
- 業務和需求是變化的，如應用架構逐步從傳統走向云原生，已有的運維系統架構能否支撐業務需求？原有的能力能否引用，需要怎樣的新的能力和如何建設？
- 數據與AI、大語言模型、可觀測等領域技術發展，運維平臺的定義是否還存在？架構上如何支撐新的擴展場景？
- 因而我們把問題聚焦在對平臺化的定義上：運維平臺是對運維業務在軟件架構層面的定義，可擴展、高內聚、低耦合是對運維平臺的核心考驗與驗證。
接下來詳細分享個人的看法與實踐。
02. 運維平臺是整體架構抽象的實踐
在拆解運維平臺的架構抽象實踐前，我們先定義運維管理與運維系統之間的關系：運維管理是基于管理需求來描述一個主題領域的運維業務，而業務的定義則是由角色、活動流程、工具系統、活動對象，以及和業務域關聯集成設計組成，因而運維管理抽象成運維業務，是工具體系建設的起點，而工具體系是承接運維業務和運維管理落地的一種能力。
如下圖運維業務與工具能力關系圖所示。
我們可以把任何一個運維系統的功能設計，都可以劃分如下四層：
這四層的理解為：
① 從對象層、接入層、邏輯層和界面層進行完整閉環；例如我們構建一個監控系統，無論自研、用開源軟件還是商業軟件，對象層通過Agent、探針、協議或Kafka等做指標接入；邏輯上最核心的過程就是數據采集、數據檢測、告警、分析處置、視圖。
② 接入層設計：是基于對象和邏輯上的綜合考慮，例如要做主機監控，那接入層第一個考慮是能適配各類主機對象，以及最為關鍵的是獲取指標數據；第二是基于邏輯層在數據檢測上的考慮，來設計采集數據對象、采集頻率、采集傳輸等。
③ 邏輯層設計：是基于功能領域的模塊閉環，如基于業務架構和分層模型設計監控和告警的對象模型，意味著需要在監控工具內有一個小型的CMDB，來維護監控對象以及指標類的數據掛載。
④ 界面層設計：是工具使用角色，然后再匹配到企業的組織崗位角色。這也是單個工具的好與壞的地方，好的地方是自我閉環，壞的地方是難以滿足運維管理組織崗位職責的角色視角。
如果只是單個工具，架構考慮的只是這個工具本身邏輯合理、邊界清晰，但是放在整個運維架構的角度，就會有兩個問題：
一是工具支持運維管理落地的運維活動是場景化的，往往需要多個工具聯動才能閉環一個運維價值。例如，發布投產管理需要發布投產的邏輯設計，同時還需要CMDB、自動化作業、流程、監控告警的集成設計，難以單個工具實現一個相對大的場景閉環。
二是煙囪架構會帶來重復建設和技術債務的問題。重復建設很好理解，例如每個工具都有跟目標設備交互的接入層設計，如果每個工具都做一套，那就意味著Agent或管道在IT對象上會越來越多。而技術債務則是發展性必然出現的問題。當做到第N+1個場景時，會發現原有的技術架構、功能和數據提供無法滿足新的建設要求。這也是很多企業發現構建了監管控的基本運維系統體系，但實質的運維活動沒有很好的改進和變化的原因。
那這里就有幾個很核心的幾個思考：
- 企業需要怎樣全景的運維系統能力；
- 能力之間的關系如何定義；
- 能力如何組合滿足擴展性場景；
- 如何分階段分層次演進。
從單場景層面來看這個運維系統如何設計，會發現極其復雜：
- 例如都共用到對象接入、CMDB、流程編排等模塊，資源交付的CMDB需要納管線上的資源，對象接入用來驅動做自動化交付，流程編排用來做工單審批和自動化交付的過程編排；那是不是意味著做一個資源交付，需要把CMDB、流程引擎、自動化交付等都做起來才能滿足呢？
- 數據層面，都需要消費一些關鍵數據，如組織角色、配置數據、負載數據、成本數據、運行數據等。
- 那這里不得不去考慮業務域的高內聚、業務域之間的解耦，以及如果未來資源管理要升級到跨云調度，如何保障擴展性？
如下是一個概要的運維場景和工具設計藍圖示例：
這里有幾個核心架構抽象和設計的思考：
1）梳理場景
可大致劃分為日常維護、監控保障、變更發布、資源管理、運維流程、服務支持、應急保障、運營分析等運維場景，場景還不完全等于業務域，場景是運維組織視角的，例如我要做監控保障，其實要跨多個業務域的，包括監控管理、事件管理，可能還要關聯到應急保障。
2）場景到業務域的拆解
這就需要引用包括ITIL、TOGAF等達成業界共識的概念了。例如容量管理，從容量管理業務角度，則有如下核心價值節點：規劃性能容量、監控性能容量、分析評估性能容量、優化性能容量。
從功能層面則至少有：對象管理（資源和業務兩個容量維度）、數據采集、數據聚合與計算、指標閾值設置及告警、性能容量報表視圖、分析報告、優化建議、容量調度（需要關聯自動化能力），然后需要集成CMDB、監控指標數據、自動化執行、運維數據處理等獨立系統。
3）業務域需要共性能力
這個能力拆解成5個大的維度，這個點上業內有一定的共識：配置、觀測、執行、流程、智能分析；這5個能力的組合，再加上一部分業務域自身邏輯，就可以快速構建業務場景的運維系統。例如做應急管理業務域，則需要CMDB（定義對象）、監控告警（應急觸發）、流程（審批與協同）、自動化（預案執行）。所以這一層定義為核心業務能力，且這5個能力是橫向需要打通的，如做事件管理，告警就是核心事件來源，流程則執行整個事件管理業務，而執行則自動化解決一些事件。
4）最后抽象技術能力
5個能力都需要一些公共的對象定義、數據與執行管道、底層引擎等，因而就有了統一Agent設計、統一對象模型設計、統一作業與數據管道設計等；這樣就有了技術底座的設計。
所以這個時候我們再來看運維平臺的定義：運維平臺是對運維業務在軟件架構層面的定義，可擴展、高內聚、低耦合是對運維平臺的核心考驗與驗證。
① 可擴展
例如我們構建一個資源管理系統、應急災備系統，是可以充分利用技術原子和業務原子的，而不是從零寫起，如果還能支持運維開發，則平臺的可擴展性就能在一個更高的維度上升。
② 高內聚
運維業務的核心邏輯從業務原子開始就是充分遵循領域邊界的，例如配置中心，核心就是做好模型管理、實例管理、自動采集、報表、拓撲和對外消費，不在這個域里面去關聯監控指標和告警。
③ 低耦合
技術原子和業務原子均是低耦合可插拔的，可基于API Gateway、數據管道等方式與外部交互，且不限對方的技術架構，如要構建一個業務全景管理的應用，則模塊化的去調用CMDB、關聯指標和告警等即可，沒有控制耦合和內容耦合。
03. 如何設計可擴展的運維平臺架構
按上述技術原子+5個核心業務能力+n個業務域場景+m個客戶化界面場景的模式，就形成了真正的運維平臺，但是這的確是一個復雜工程，需要持續往這個方向分階段來建設。具體如何做呢，核心要做好這樣幾點：
1）第一步，共性模塊能力化
共性模塊抽象本質是一個積累的過程，遇到工具需求，拆解出接入層和邏輯層的共性能力，然后單獨來設計，這樣逐步積累、裁剪，就能設計出合理邊界的能力項，然后注冊到iPaaS（integration platform as a service）中，以組件的方式對工具提供模塊和數據消費；以CMDB為例，CMDB有兩個定義，一個是技術原子，作為所有運維系統的對象模型，一個是業務原子，滿足企業的具體配置管理和消費場景。
2）第二步，能力消費自主化
根據不同規模的企業，要建設的運維系統從最小化“1個監控軟件”，到最大化面向不同角色、場景提供不同的工具，工具領域建設非常重要的架構要求就是可自主和擴展，這也是平臺架構抽象的第二個關鍵點。如果沒有這一層的支撐，會使得平臺化建設做的都是后臺，而沒有場景活動的功能支撐；這時候aPaaS（application platform as a service）就會顯得非常關鍵，并且可以借助這個架構實現企業運維開發或自主可控轉型。
3）第三步，活動場景方案構建
PaaS是以能力化的軟件集成架構，來解決變化的需求的能力，因而我們如果從下往上看，iPaaS做了技術能力抽象，基于aPaaS做了單個工具領域集成和一體化，則再往上就是組合工具，而這里的整個能力、數據和服務集合，就支撐了運維活動的展開。
舉個例子：為了有效地實現應急保障活動場景，我們需要有應急協同、預案管理、應急處置等組合工具，而這些工具的構建，都需要基于CMDB獲取對象、基于可觀測獲取指標和運行狀態、基于流程來做協同和工作推進等，所以這時候越面向一線用戶的運維軟件需求，越是可組裝和輕邏輯的。
按這種架構設計模式，規劃一體化、平臺化的建設藍圖和階段如下示例，包含了能力與場景層的解耦，工具之間有效聯動，數據與智能的持續發展：
因而平臺架構抽象要做好，要有一定的“克制”與“堅定”，克制在要充分尊重打基礎的重要性，不能堆砌式陷入工具的浪潮；堅定是持續做架構治理，尤其是保障對象模型、流程貫穿和數據運營的統一。
這個時候我們再來看沒有平臺化之前的問題如何破局：
1、企業建設了很多工具，但是包袱卻越來越重，工具之間橫向打通困難，縱向架構治理困難，如何破局？
答：能力與場景解耦，能力分層，核心5個能力：配置、觀測、執行、流程、智能分析打通，打通的邏輯來源于場景和業務設計，可以參考三條線來做打通：CMDB作為所有系統建設的對象模型，ITSM作為各個業務域落地的流程過程，以數據模型為中心構建運營體系。
例如：有一個較為高階的場景，故障分析，要實現故障分析，需要前后連接觀測、告警、事件、處置，那故障分析就需要以CMDB作為業務和資源的對象元數據，告警、處置以ITSM的核心事件流程打通，最后利用數據和AI融合Trace、Log、Metric、Alter、工單等，來做如故障影響面、告警快照、故障決策樹、故障組件定位等場景，這是單用工具的API集成很難完成的。
2、業務和需求是變化的，如應用架構逐步從傳統走向云原生，已有的運維系統架構能否支撐業務需求？原有的能力能否引用，需要怎樣的新的能力和如何建設？
答：以云原生運維場景為例，已有的運維平臺可以充分利用，然后做如下變化：接入層能適配容器、云原生組件、微服務對象；邏輯層做好云原生運維更為關鍵的可觀測、應急管理、混沌工程、容量管理和智能化應用；渠道層則在原有的能力上追加多維度視圖或強化移動端等即可。
3、數據與AI、大語言模型、可觀測等領域技術發展，運維平臺的定義是否還存在？架構上如何支撐新的擴展場景？
答：架構層面仍然是平臺化架構，我們來看每個技術變化在架構層面的定位，數據與AI是一種能力，用來支撐場景，如做故障分析與定位，則調用數據分析和模型的能力；
大語言模型服務于界面層，解決人與系統之間更優的交互體驗，如智能問答、交互式反饋運維數據和信息等；
可觀測則是基于CMDB的對象統一、多維數據融合，來擴展更多的場景，如Trace與Log的關聯、告警的多維信息平面、拓撲化的狀態下鉆等。
04. 運維平臺的變與不變
運維平臺在架構層面的定義，短期并不會有太大的變化，包括技術、業務、場景各層的定義，仍然是一體化運維最好的承載和落地架構；但是從內容上，則會如下變化與發展：
- 對象層會不斷擴展：尤其是在容器、分布式組件、跨云、信創等對象上持續演進。
- 能力層會隨著技術發展補充新的能力：尤其是數據與AI的能力，使得基于數據融合的運維場景更為豐富，可觀測的核心也在統一模型對象和多維數據融合上才有更好的發展。
- 場景會跟隨業務架構變化而擴展和深化：數據化運營、智能監控模型、分布式云原生應用的運維場景、算力調度等會持續深化，且仍然是基于能力的增強。
- 渠道層則會呈現多樣和靈活化：大語言模型、消費化體驗則會強化與用戶的渠道和界面連接。
- 架構會隨著能力與場景的演進持續治理：架構層面則包括運維平臺自身的云原生化、能力解耦的深化等進一步發展。
- 嘉為藍鯨作為業內領先的平臺化、一體化、數智化運維解決方案提供商，我們堅定地致力于把成熟的業務實踐、領先的技術架構，賦能給我們的客戶。
本文談了“平臺化”方向，“一體化”相關內容請點擊下方“系列推薦”，下期我們一起來聊聊“數智化”相關內容，敬請期待~
最后，歡迎隨時與嘉為藍鯨共同探討！
總結：以上為筆者對運維平臺的剖析，歡迎探討交流，謝謝！
