寫在前面
隨着越來越多企業應用上雲，雲上應用的規模與複雜度日趨增長，對雲上應用的運維，也提出了新的挑戰。華爲雲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模塊主要負責大數據計算及智能化能力，在線和離線分析數據，以事件驅動各子系統運行。
另外架構圖中的底座環境，展示了AOM運維範圍，從基礎設施到PaaS層應用及容器和VM應用，覆蓋了應用運行所依賴各層資源。