寫在前面
隨著越來越多企業應用上雲，雲上應用的規模與複雜度日趨增長，對雲上應用的運維，也提出了新的挑戰。華為雲aom服務面向大規模企業應用的運維，在實踐中演進並構建了一套完整的面向雲上應用的立體化運維系統。
一、常見雲上應用的架構
雲上應用早期較多的是購買雲服務i層資源（多為基礎設施如主機等計算資源）自建各種集群，運維人員多以主機監控為中心進行運維，同時自己搭建應用及資料庫等監控系統進行應用層和業務層運維。隨著容器技術的普及，越來越多的企業轉向caas和paas來管理應用，通過微服務框架開發，業務的實現也更多的使用雲上服務，如分布式中介軟體，函式服務，ai服務等，同時運維也轉向雲上的運維服務。
乙個典型的現代雲上應用架構：
經過網域名稱解析階段後，靜態資源命中cdn後直接返回，無命中時會回源去拉取，動態請求直接訪問web服務，在請求到達四層和七層elb之前，多數企業應用也會選擇waf來清洗異常流量。
持久化層當前各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模組主要負責指標資料的管理，提供閾值配置能力。
另外架構圖中的底座環境，展示了aom運維範圍，從基礎設施到paas層應用及容器和vm應用，覆蓋了應用執行所依賴各層資源。
華為立體運維 前言 什麼是立體運維
在雲時代，企業應用火力全開，紛紛上雲 隨之而來，在雲端，應用運維也出現了新的挑戰 購買了伺服器，計算，儲存，網路，資料庫等資源業務增長後，出現資源不足導致應用異常的問題，如何快速找到資源瓶頸點並做好長期資源規劃，對於分布式架構，微服務化的各類複雜應用，應用依賴和呼叫關係呈幾何指數增長，散落日誌進行關...
Redis 運維架構
1.2 redis 高可用架構優劣對比？1.3 常見的 redis 集群方案有哪些優缺點？二 redis 通用 三 redis 故障排查 3.2 如何知道，當前 redis 例項是處於阻塞狀態？3.3 redis 運維的故障有哪些？四 redis 效能優化 redis 是乙個開源的使用 ansi c...
網路系統建設與運維 IT基礎架構運維服務認知
什麼是it基礎架構？網路定義 it基礎架構是相對於it應用架構而言的，指的是為了各種應用系統能夠順利 可靠地執行，而提供的一系列硬體 軟體的集合體。正是因為有了這些it基礎架構的各種設施，it應用架構才能執行並提供服務。網度釋義 it基礎架構指的是客戶端裝置 伺服器 儲存 網路裝置 交換機 路由器 ...