立體運維架構與定位

寫在前面

隨着愈來愈多企業應用上雲，雲上應用的規模與複雜度日趨增加，對雲上應用的運維，也提出了新的挑戰。華爲雲AOM服務面向大規模企業應用的運維，在實踐中演進並構建了一套完整的面向雲上應用的立體化運維繫統。

1、常見雲上應用的架構

雲上應用早期較多的是購買雲服務I層資源（多爲基礎設施如主機等計算資源）自建各類集羣，運維人員多以主機監控爲中心進行運維，同時本身搭建應用及數據庫等監控系統進行應用層和業務層運維。隨着容器技術的普及，愈來愈多的企業轉向CaaS和PaaS來管理應用，經過微服務框架開發，業務的實現也更多的使用雲上服務，如分佈式中間件，函數服務，AI服務等，同時運維也轉向雲上的運維服務。

 

一個典型的現代雲上應用架構：

 

通過域名解析階段後，靜態資源命中CDN後直接返回，無命中時會回源去拉取，動態請求直接訪問WEB服務，在請求到達四層和七層ELB以前，多數企業應用也會選擇WAF來清洗異常流量。

通過ELB後，請求到達業務應用服務器，業務實例多爲分佈式構架，微服務之間相互調用，通常狀況下企業運維人員較多的關注點是應用實例這一層，多爲企業自行開發的服務。

持久化層當前各CSP提供的中間件不同，華爲雲上用戶使用較多的如分佈式緩存，分佈式數據庫等。因爲提供動態擴容及較高級別的SLA，愈來愈多的企業再也不須要專業的DBA，轉而使用雲上的服務，開發上也更加敏捷。

如此多的雲服務和各類資源，任何一個環節出現問題，都將致使應用KPI異常，用戶體驗降低，進而致使企業運營受到影響，而每一個使用公有云服務的企業，若是投入大量人力去自建運維繫統而且將整個請求的各個環節關聯起來，成本會很是高。所以華爲雲AOM在幫助企業對應用運維的過程當中，經過實踐構建了一套立體運維體系，幫助企業更好的進行一站式運維。下面章節將爲您介紹立體運維的定位及架構。

2、立體運維的定位及架構

立體運維定位：

立體化運維主要是圍繞用戶應用進行監控，一站式完成用戶體驗監控，應用性能監控，基礎設施監控。

參考以上典型雲應用架構，經過將業務請求路徑上通過的不一樣資源進行分層，圍繞分層設計不一樣的專業運維服務子系統，將不一樣數據在不一樣子系統上串聯協同、關聯分析，構築一個雲上的運維平臺，從而最大化的實現數據價值，爲運維人員提供一個統一的運維中心，達到一站式立體化運維的目的。以下爲立體運維分層：

 

構創建體運維，除了要覆蓋應用的端到端資源之外，重點還要經過多種運維數據進行數據分析，經過多種可視化手段進行友好的界面展現。所以立體運維體系建設包括如下工做：

 

資源模型化

其實就是將應用依賴的資源接入CMDB，可是雲上業務的CMDB與自建數據中心運維有所區別，後者多對應的是SRE（網站可靠性工程師）層面的CMDB，而應用運維管理所須要的CMDB是面向雲資源的量身打造的CMDB。主要有如下特徵

• 分離業務模型與存量資源模型（後續文章後詳細解讀）
• 存量模型能表述不一樣的雲服務下的不一樣雲資源
• 支持對雲服務內雲資源創建映射關係
• 支持對跨雲服務的資源創建映射關係
• 支持雲資源標籤管理（打標籤，同步標籤，按標籤查詢）
• 支持歷史資源快照

資源模型化這一步是全部數據關聯及運維平臺化的基礎，經過統一的模型將不一樣資源關聯起來後，能夠幫助用戶快速的找到故障的根因，也能經過關聯關係對大量告警進行分析，抑制重複告警等。

數據可視化

良好的可視化界面不但能提升運維人員運維效率，還能夠經過直觀的展現查看各類資源消耗趨勢，幫助企業分析運營走勢，預測將來資源使用狀況等。應用運維管理數據可視化聽從如下原則進行設計

• 創建左右逢源的資源拓撲圖

資源拓撲是指一個資源與其餘資源的關聯關係，如雲主機與ELB及VPC，CDN的關係，經過一個資源拓撲圖進行展現。以下

所謂左右逢源是指以一個資源爲中心，拓撲圖展現其上下各一層的關聯資源便可，避免拓撲過大，但又能經過一個資源找到上層或者下層資源。

• 關聯資源下鑽

創建拓撲後，經過圖上的資源連接，能夠跳轉到選中的另外一個資源的拓撲圖中去，而新的拓撲圖是以新的資源爲中心，如此來達到經過關聯資源不斷下鑽的目標，方便運維人員查找問題。

• 雲資源快速跳轉

一個雲資源可能涉及到多個雲服務，如ELB實例，涉及ELB服務自己，VPC，CDN，ECS，而各個雲服務入口較分散，須要在資源名稱增長超連接快速跳轉到雲服務console。

• 視圖模板化

各資源監控數據的展現，由AOM默認提供模板，但同時要支持用戶自定義模板，因爲運維人員關注的指標或其餘數據側重點不同，所以要能經過模板支持同一個資源不一樣視角的查看方式。

• 功能嚮導化

複雜功能須要經過嚮導快速指導用戶進行設置或配置，以減小用戶學習文檔或者視頻的時間成本。

 

服務平臺化

平臺化目標要支持用戶經過各子系統經過開放API實現自動化運維。指標，日誌，事件告警等數據要支持用戶經過接口訂閱，轉發到外部系統供用戶運維平臺進行分析，分析結果經過API輸入立體運維平臺並經過事件驅動平臺業務持續分析。

也就是經過數據流，實現平臺與用戶運維繫統的協同，實現流程化自動化。

自動化將會協助用戶實現故障自動恢復，如經過數據分析後發現須要擴容，能夠經過事件觸發或者API調用彈性伸縮子系統進行實例擴容。還能夠在資源空閒時縮容以節省企業運營成本。

分析智能化

針對指標數據提供動態閾值計算能力，無需用戶設置閾值，經過機器學習進行異常檢測，對於大型系統的運維能夠有效的下降人工配置成本。同時也避免靜態閾值設置不合理須要不斷調整的重複工做。

針對日誌數據，智能提取模板，分析可變參數與靜態文本，經過日誌關鍵字監控，實時掌握應用異常狀況。

 

應用運維管理的總體架構：

如下爲應用運維管理總體的架構，主要分爲五個子系統，每一個子系統經過多個微服務提供不一樣功能，總體協同實現立體運維目標。

ALM模塊負責事件告警的管理及相關性分析，支持用戶配置通知策略以及時將告警發送給運維人員。

ALS模塊負責分析日誌。

INV模塊即CMDB模塊，實現資源的管理及資源的映射及查詢等能力。

AMS模塊主要負責指標數據的管理，提供閾值配置能力。

DPA模塊主要負責大數據計算及智能化能力，在線和離線分析數據，以事件驅動各子系統運行。

 

另外架構圖中的底座環境，展現了AOM運維範圍，從基礎設施到PaaS層應用及容器和VM應用，覆蓋了應用運行所依賴各層資源。