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