立體運維架構與定位

寫在前面

隨著越來越多企業應用上云，云上應用的規模與復雜度日趨增長，對云上應用的運維，也提出了新的挑戰。華為云AOM服務面向大規模企業應用的運維，在實踐中演進并構建了一套完整的面向云上應用的立體化運維系統。

一、常見云上應用的架構

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

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

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

經過ELB后，請求到達業務應用服務器，業務實例多為分布式構架，微服務之間相互調用，一般情況下企業運維人員較多的關注點是應用實例這一層，多為企業自行開發的服務。

持久化層當前各CSP提供的中間件不一樣，華為云上用戶使用較多的如分布式緩存，分布式數據庫等。由于提供動態擴容及較高級別的SLA，越來越多的企業不再需要專業的DBA，轉而使用云上的服務，開發上也更加敏捷。

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

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

立體運維定位 ：

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

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

                                              立體運維分層

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

資源模型化

其實就是將應用依賴的資源接入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 模塊主要負責大數據計算及智能化能力，在線和離線分析數據，以事件驅動各子系統運行。

更多信息可查看： https://www.huaweicloud.com/product/aom.html

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