01. 運維一體化的概念被泛化

運維一體化是近幾年被廣泛提起的概念，有各種解讀和實踐形態，在到具體的技術架構和管理實踐前，我們還是要對一體化有幾個基本定義，這樣才能更為嚴肅地探討運維一體化的本質。

1）什么是運維業務

我們采用TOGAF定義的業務架構來定義運維業務，運維業務是價值定位、管理、組織、關鍵業務流程的組合描述，抽象來講要回答幾個問題：干什么（業務能力）、誰來干（業務角色）、怎么干（業務流程）、所需應用（運維應用架構）、所需數據（運維數據架構）、所需技術（運維的技術變化與發展）；

例如這里就可以用一句很泛的話術來描述運維業務：基于業務安全穩定運行和IT服務滿意（業務能力），組織職能線和專業線的IT運維角色（業務角色，如調度室是跨專業的職能線、DBA則是具體的專業線角色），基于服務管理、事件管理、變更管理等流程實踐（業務流程，這里就需要拆解角色和崗位的映射），基于運維的監管控等工具（運維應用），管理log、metric、trace、event、工單、配置等數據（運維數據），基于分布式組件、容器化架構，實現運維業務支撐。

更細化一點，運維業務需要定義對應運維主題領域的四要素：角色、活動流程、工具系統、活動對象，來滿足對應的運維業務能力。

以一般性IT服務管理主題為例：

• 這里涉及多個關鍵角色：管理層、普通用戶、一線坐席、二線專家、運維工程師、流程經理，還可能會包括三線開發專家或供應商角色等；
• 活動流程：這里可以按經典的服務設計與轉換來定義，包括服務定義、服務發布、服務運營、持續改進等關鍵活動節點，同時還可以進一步把每個二級業務域進行拆解；
• 工具系統：具備自助服務、服務發布、服務目錄管理、sla管理、服務與流程定義、請求管理、事件管理、問題管理、變更管理、發布管理等功能，并與ITOM通過關鍵業務關系鏈接，如發布投產調用發布自動化工具等；
• 活動對象：包括人員、業務、應用、資源和基礎設施，均是上述活動和工具系統里關聯的對象，這也是運維領域帶來復雜度提升的一個重要點：技術對象的更新迭代，規模發展、橫縱切面的復雜性。

而業務定義清楚，對應的管理規范就清晰了，再到應用設計，就清晰了技術規范，規范輔助業務的落地。

2）業務單元與業務交互邏輯是什么

運維大的體系可被拆解到多個業務子域，ITIL實踐幫我們已經做了一定的總結，不過技術性指導不夠；一般來講從業界通用的運維領域來看運維業務設計，我們可以定義運維業務設計大的主題分為兩類：服務管理、技術管理；服務管理是數據中心為相關利益方提供真正體現數據中心價值的服務的管理過程；技術管理是從數據中心內部發展角度，為服務提升提供前瞻性、系統性的技術創新研究的管理活動；而展開就有了服務管理包含：配置管理、變更管理、事件管理、投產管理、問題管理、應急災備管理、監控管理、操作管理等；技術管理則包含架構管理、運維開發管理、數據管理等；

而這些業務子域之間，則往往基于共同滿足一個大的運維價值和活動場景，需要做業務域的關聯設計，這種交互的邏輯一部分源于場景端到端的驅動，一部分源于技術復用和關聯的驅動。例如：我們要做企業信息系統的災備應急管理，首先要定義這個業務的四要素，角色（應急管理崗、應急實施崗、綜合管理崗等），活動（組織管理、預案管理、演練管理、應急處置管理、資源管理），流程（事件應急流程、災備應急流程），活動對象（資源、事件、預案、人員等）。而信息系統業務域與其他業務域的關聯設計時，則例如業務活動里面的應急處置管理，來源是監控管理業務領域的生產事件，這屬于場景端到端驅動，而資源基于CMDB構建，則是技術復用和關聯。

業務域關聯設計示例：災備應急業務域在場景端到端驅動，尤其是故障生命周期視角，以及技術復用和關聯驅動，尤其是統一對象模型和流程上，實現業務關聯設計。

3）實現業務的應用架構是否一體化

具體是指實現某個運維業務的閉環，最后落到工具系統時，工具系統本身沒有好的內聚與耦合設計，沒有實現與周邊關聯系統集成，最后并不能完成整個業務的閉環支撐；

例如：我們規劃發布投產的業務，定義好業務要素后，進行應用架構設計，但是不可能把投產流程獨立于ITSM之外再做一遍；且發布對象如果面臨傳統和容器化架構，對象是否能通過CMDB統一，包含了CMDB如何納管容器化架構應用等；然后投產發布活動中有一個活動節點：投產實施，此時需要關聯關閉告警，避免誤報太多；這個時候就會發現，不是一個業務域一個工具，而是一個業務域是跨工具實現的場景，且多個業務域才能滿足更高階的閉環管理。例如業務連續性關聯，關聯的監控管理、災備應急、運行操作管理等多個業務域，而到工具系統時，災備應急則需要關聯監控告警、CMDB等工具才能閉環。

所以從工具一體化視角來看，要定義核心所屬業務域，以及外部調用與被調用的關系設計，以發布投產一體化工具為例，應用架構如下，除核心業務活動過程與功能外，外部與DevOps，以及與ITOM、ITSM的關聯設計都需要考慮：

因而，運維一體化較為嚴肅的定義是：基于運維業務視角的角色、流程、活動（對象）、工具系統的整合，業務運轉順暢、流程運行高速、工具支撐高效是對運維一體化的核心驗證。運維一體化不只是工具全和單一工具技術功能完整，而是要融入業務設計和整個體系中。

接下來管中窺豹探索一體化運維體系落地。

02. 運維業務拆解模型

談如何建設一體化，必須先對運維業務拆解，回歸到對業務架構的定義，有如下三段的拆解模型，其中又有運維這個業務形態所面臨的場景復雜和對象復雜的特殊要素。

1）業務架構定義

定義四要素：角色、活動流程、工具系統、活動對象；下面以大家熟知的配置管理業務主題為例，做拆解分析。

角色：配置經理進行配置規劃和配置運營，制定配置管理體系和配置運營體系；配置管理員定義模型、權限和數據準入及審核；配置owner則映射各個專業管理員，管理本專業的對象數據實例、屬性及關系；

活動流程：核心是5個活動流程，配置規劃、模型與數據創建、配置維護、配置消費和持續運營，而活動則可以更細一步拆解的任務和步驟，如配置維護的任務包括：對象新增、對象查詢、對象修改、對象刪除，而對象修改任務則進一步拆解成步驟，如選擇對象實例、修改關系、修改屬性等；

工具系統：工具系統則承接活動、任務、步驟的信息化實現，基本都需要有模型管理、數據實例管理、配置審核、自動采集、配置拓撲、配置報表等功能；

活動對象：對于配置管理的對象，則主要是IT系統的實體及邏輯對象，可以大致劃分為應用、資源、基礎設施；這里關于邏輯對象特別強調下，例如微服務容器化架構，k8s是資源層的模型設計，業務則是一個邏輯概念，可以把多個k8s集群定義為一個業務，也可以把一個業務系統組合定義成一個業務，最后兩個維度做邏輯關聯。

2）功能架構設計

是對應用結構和交互的描述，這些應用是提供關鍵業務功能和管理數據資產的功能組，尤其是應用組件及其交互，與業務流程的關系。仍然以配置管理為例，為了支撐持續運營這個活動，功能上需要有報表、運營分析（如配置質量評分等）的功能，而這個要與配置數據實例管理關聯；

繼續以配置管理為主題拆解：

核心應用組件：一級功能需要包含能支撐主要業務活動的模型管理、數據實例管理、配置發現、配置報表及拓撲、數據運營，以及權限控制、日志等通用功能；

組件交互：這里就較為關鍵了，以配置發現為例，配置發現支撐了模型與數據創建這個關鍵業務活動，這個與模型關聯的關系支撐了從模型到數據的活動過程，與數據實例管理的管理是支撐了數據實例自動采集的活動；

與周邊系統集成：配置管理可以分為兩類集成，均是支撐配置消費場景，一個是內部消費，包括臺賬、多維度報表、拓撲視圖等，一個是外部消費，尤其是作為構建其他運維系統的元數據對象模型。

3）與其他業務域關聯

業務域的關聯設計是由各個業務主體的建設去設計，然后與其他業務域達成一致，原因就是一個業務域設計無法完全貫穿一個完整的運維場景，尤其是高階的運維場景。類似這種場景就特別多了，例如我們要做監控管理，其中有一個關鍵業務活動節點是告警處置，就會根據告警級別關聯不同的業務域，如事件管理、運行處置（故障自動解決）等。

而這種全量場景，可以基本劃分為日常維護類、變更發布類、故障應急類、服務響應類、優化提升類等，每個企業不盡相同，且關注重點不一，可以基于崗位、技術對象、活動來梳理，進而由場景做業務域的關系設計，當然，運維的業務域，在業界還是有一定共識的，一般可以先從請求管理、配置管理、變更管理、事件管理、發布投產管理、問題管理、應急災備管理、監控管理、操作管理、資源管理這幾個著手，后續進而考慮高階和擴展的業務域。

總結下，運維業務拆解模型利于我們定義幾個東西：

① 確定業務領域邊界

運維體系最容易出現的情況是建設混亂，工具繁多但是一體化的價值并沒有達到，例如：之前遇到一個需求，基于應用和資源拓撲視角的監控與處置一體化，這個需求歸屬到配置管理，還是監控管理、運行處置，就有很大的爭議，從技術視角來看，應用和資源拓撲是CMDB管理維護的，對象監控是監控告警工具提供的，處置則是自動化提供的，較為容易出現建設混亂，但是從業務視角來看，應該歸屬于監控管理領域的“全景視圖”，然后與自動化處置做業務域打通，屬于監控管理領域的故障視圖活動節點；

② 確定業務域打通的邏輯

業務域打通的邏輯是源自業務之間的關系設計，例如做好事件管理，需要考慮監控告警域、運行處置域、變更管理域、配置管理域等幾個域的關系設計，事件來源有巡檢、告警等，事件可能需要上升到變更管理才能解決，事件的技術手段解決則需要關聯到運行處置域，打通方式則有包括流程的API對接、數據消息傳遞等；

③ 功能是為業務服務的

沒有對業務架構的定義，尤其是業務架構的關鍵角色、活動節點、活動對象、流程的定義，就無法細化到角色與崗位之間的映射，且無法轉換成支撐崗位活動的功能設計，進而變成了人要習慣工具，而不是人與工具遵循規范化活動運轉。

03. 業務、應用、數據、技術多維建設來推進一體化

當定義清晰了眾多業務域后，建設一體化運維，則可以從如下視角展開：

1）業務層面基于流程端到端的貫穿

核心是運行、管理、處置一體化，有如下展開場景：

① 運行管理一體化

生產運行基于監控管理和監控運行完成，包括關鍵的數據采集、數據檢測、數據告警、數據分析、數據視圖等關鍵活動，運行與處置的一體是指在數據告警活動節點，數據告警根據業務級別、應用、影響面、故障類別、故障信息構成，由此生成事件在事件管理業務域去跟蹤管理，如果由事件上升到應急，則調用應急處置預案去完成。

較為典型的就是告警轉事件的聯動場景：

② 運行處置一體化

運行處置一體是指數據告警、數據分析的活動節點，對于標準化告警，直接調用運行操作完成基于規則的標準化自愈；對于上升到事件應急的，則調用運行操作的應急預案自動化，完成生產回復；同時對于數據分析場景，則基于運行操作進行故障決策樹分析、告警快照、多維信息視圖獲取等操作，來進行故障輔助分析，當然，也有基于AI的故障初因定位、根因定位，從業務活動來講業務是沒變的，實現業務的技術手段在不斷蓬勃發展；

③ 管理處置一體化

管理與處置的一體是當前IT服務發展的一個關鍵趨勢和特性：敏捷；應用在如服務自助自動化、標準變更自動化、配置管理自動化、工單自動處理等場景，較為典型的如發布投產管理，基于發布投產的管理活動，執行時輸入標準化的技術參數：程序包、sql、腳本、配置文件、對象參數等，再調用發布自動化工具，完成管理流與執行流的編排與一體化，管理流程編排中可嵌入技術編排，從而實現這個打通：

2）應用架構基于統一對象模型

眾多業務域構建應用架構時，都需要考慮運維的一個核心定義：對象；如做可觀測，我們所有觀測的對象都需要有對象元數據的定義，包括了實體對象和邏輯對象；如做發布，發布策略編排則是基于對象在應用架構中的關系來設計的，也需要一個對象元數據。而這里就有一個首要的一體化：統一配置管理體系建設；除了滿足配置管理的內部管理功能外，非常核心的一點是能支撐一體化運維的應用系統的對象模型統一設計。

以可觀測建設為例，統一的對象模型是起點，沒有統一對象模型的定義，無法去構建指標體系、數據關聯及融合場景。以可觀測的指標體系為例，基于統一對象模型的設計如下，核心是進行對象和數據實例在外部系統與CMDB之間的映射：

3）數據層面則基于數據治理框架支撐場景

運維數據可以劃分成5個域：

配置域：IT資產管理系統、配置管理中各類電子信息設備的基本信息、技術參數及關聯關系等信息，包括PC機、服務器、存儲設備、網絡設備、安全設備、輔助設備、機房環境設備、套裝軟件及應用系統軟件等；

狀態域：IT監控、自動化運維、安全監測等采集的設備軟硬件性能、狀態、事件、日志、告警及實用化數據等；

流程域：運維流程管理中執行一個業務流程所產生的相關記錄數據；

作業域：自動化作業、故障自愈、編排處置步驟等作業執行流程數據和操作審計數據；

知識域：故障事件處理經驗，其他相關知識庫，以知識主題、關鍵字索引、內容等形式存在。

數據治理框架核心要定義幾個問題：

• 運維數據之間的邏輯和關聯設計如何做？
• 運維大數據平臺的定位？
• 數據消費場景如何持續建設？
• 數據與AI如何統一建設？

關鍵邏輯為：

這里面有幾個實踐建議：

① 消費場景聚焦在提升性能容量、觀測整合、運營分析的高階運維能力；尤其是在觀測整合上，當前可觀測主要圍繞故障分析和定位展開，基于數據管理框架，則可以完成數據標簽統一、數據聚合計算、數據關聯信息平面、AI模型應用等，例如其中一個觀測場景可以基于告警視角，展開trace、log、metric、場景視圖、知識庫關聯、變更事件關聯分析等，來形成初步的觀測整合分析場景：

② 技術價值上主要體現在復雜和大規模的數據清洗、開發和存儲需求；跨數據源的數據關聯計算；聯動MLOps實現數據樣本和數據源的關聯，實現AIOps模型開發和應用；

③ 數據管理采用專業分散，消費驅動的模式管理，專業分散是指如CMDB、metric、trace、log等都在專業管理工具里，消費驅動則是基于場景調用時，再去做數據接入、標簽、關聯計算等，支撐數據之上的場景應用；

4）技術架構基于統一管控管道和平臺架構

統一管控管道指的是適配各類運維應用的運維對象管道，核心包括三個設計：

• 可擴展，可支持監控、配置、自動化等上層應用場景對agent的任務調度，且可支持agent擴展采集插件和適配不同的技術對象，以及適配復雜網絡的架構；
• 穩定性，這是最為關鍵的部分，海量分布式管控的穩定性對于運維系統至關重要，穩定性需要大規模環境的實踐，且包含多種如進程守護、安全機制、性能控制等設計；
• 性能，包括如十萬級實時并發任務、毫秒級任務日志反饋等，可保障采集任務和執行任務的并發執行。

平臺架構核心是做能力和場景的解耦，保持持續的擴展性能力。（下一期將對平臺化進行詳細介紹，敬請期待~）

04. 一體化運維在投產發布下的設計示例

最后更具象化一點設計一體化運維在具體業務域的設計示例：

1）設定情景

業務系統100+，主機節點5W+，K8S集群主機節點5000+，實現高質量、高安全、高效率的統一發布；

2）業務設計

組織角色：以應用為維度，負責部門為應用運維管理員，協同研發、基礎設施維護人員；發布經理負責發布的統籌、組織和方案把控，發布工程師負責發布的任務編排、發布執行、驗證、回滾；發布領導負責外部溝通、業務影響評估和風險回退控制；技術專家包括研發對包的質量管理、基礎架構專家負責準備對應的資源及環境；

工作流程：通過投產計劃、程序驗證、投產評審、投產執行、應用驗證這幾個核心流程組成，每個流程可以進一步展開到里面具體的角色活動；

關鍵活動：

• 發布管理員配置發布模板，模板包括了對傳統及容器化架構環境的三類操作：文件分發或鏡像發布、腳本執行、基于接口的容器化調度編排；
• 應用運維人員基于發布方案輸入參數，參數包括：發布對象、對象編排、介質（含二進制包或鏡像、配置文件、腳本、SQL等）、時間窗口等；
• 領導主管監視發布大屏以及獲取運營分析數據……

規范指引：《生產發布運行管理辦法》：應用架構與運行環境、發布過程、常規故障處置、緊急回滾；

3）工具設計

接入層：與不同環境及不同資源對象進行對接，主要是主機和容器化環境；

邏輯層：最核心是任務編排、制品管理、應用管理；從而滿足一站式發布，支持灰度、藍綠建設；

界面層：面向不同角色的生命周期活動階段，如發布經理最為關注影響分析、發布編排、發布驗證、發布回滾；管理層最為關注發布計劃、影響分析、回退機制及運營數據；

外部集成：與DevOps聯動、觸發告警時間屏蔽、與ITSM變更流程聯動；

落地設計示例：

工具產品界面：

所以至此，簡單總結下幾個結論：

• 基于運維業務視角的角色、流程、活動（對象）、工具系統的整合，業務運轉順暢、流程運行高速、工具支撐高效是對運維一體化的核心驗證；
• 運維業務需要經過業務架構、應用架構、業務關聯設計這三個步驟展開，進行企業實例化設計，起步可以先從請求管理、配置管理、變更管理、事件管理、發布投產管理、問題管理、應急災備管理、監控管理、操作管理、資源管理這幾個維度根據緊迫程度著手；
• 一體化的推進要從業務、應用、數據、技術這幾個維度的視角來做規劃和設計，其中最為關鍵的是業務場景的一體化，如何把運行、管理、處置聯動起來；應用架構的一體化，如何基于統一對象模型構建；數據管理的一體化，核心是專業分散，消費驅動的模式管理，切忌做成數據開發的模式；技術架構的一體化，核心是抓準統一管控和平臺架構這兩個關鍵點。

嘉為藍鯨作為業內領先的平臺化、一體化、數智化運維解決方案提供商，我們堅定地致力于把成熟的業務實踐、領先的技術架構，賦能給我們的客戶。

最后，歡迎隨時與嘉為藍鯨共同探討！

總結：以上為筆者對一體化運維的剖析，歡迎探討交流，謝謝！