應用運維的重要場景是應用軟件的自動化發布，在數字化轉型的大背景下，企業使用應用發布系統主要面臨這幾個問題：
● 隨著業務線上化和業務量的快速增長，應用往往需要大規模集群的方式部署，加上對于業務連續性的要求，發布的工作量和復雜度成倍提升 。
● 敏捷 、DevOps的新理念的流行，應用更新迭代速度加快。
● 新技術的不斷涌現，迫使企業需要主動擁抱探索新型IT技術，應用技術百花齊放（容器、微服務等 ），對應用運維提出了更高的要求。
一、標準化是構建應用發布系統的第一步
人工運維已經很難滿足當前的發展趨勢， 建設自動化運維成為了接下來運維工作的重點。但是往往許多企業盲目的引進大量的工具去完成自動化，最終卻會發現工具用了一大堆，看起來好像降低了人手動的工作，可效率并沒有提升，這種情況往往是因為沒有把“標準化”這個基礎工作先做好。
標準化的內容有很多，大到標準的發布方案、應用全生命周期的標準流程，小到發布腳本、參數的標準化、應用名稱的規范等。其中，我們認為最重要的也是最基礎的，是需要對應用這個邏輯的抽象有一個共同的認知，通過識別拆解業務系統并且在CMDB中描述。
二、如何有效管理應用
1. 構建應用拓撲樹
微服務的流行，分布式架構的日益成熟，導致我們需要管理的應用系統數量快速增長。你是否有過與產品同事雞同鴨講，一會兒是服務，一會兒是組件的經歷？你是否經歷過突然某天應用重啟命令無權限的情況，因為基礎架構運維的同事把webLogic的用戶調整了？
如何有效管理這些應用及其使用的基礎資源，統一命名、層級結構，是構建CMDB的目的。這里提供的思路是基于應用部署的視圖拆分，基于“應用系統-環境-集群-模塊”的模型對應用系統進行描述。
應用系統：對外提供特定、完整業務服務的一組系統資源（軟硬件資源）的有機組合，位于整個應用拓撲的頂層，例如：ERP系統、手機銀行系統、英雄聯盟系統。
環境：指的開發測試環境、預發布環境、生產環境、災備環境等。
集群：大型應用系統一般會在多個地域機房部署相同的應用，如分布式架構下的北京集群、深圳集群；每一個集群可以獨立提供完整業務服務。
模塊：最小化的功能板塊，有許多相似的叫法：應用、服務、組件、模塊等等，比如在電商系統下的訂單模塊、評價模塊等等。
一般在傳統應用架構下有幾個特點：
● 沒有把模塊劃得很細。
● 應用往往有獨享的數據庫、消息隊列等基礎資源。
● 應用架構相對簡單。幾臺weblogic加上Oracle數據庫就可以組成一個應用系統，所以這里的模塊由應用模塊和技術模塊共同組成，如：報表模塊、Oracle模塊。
而在互聯網架構下，往往只聚焦應用模塊和業務功能。
2. 構建面向應用運維的應用配置管理
CMDB主要還是以面向資源的管理，但僅以資源的視角看CMDB是不夠的，對于應用運維而言，需要以應用的視角縱觀全局。至于如何打通應用與資源的關系，可以以模塊為中心，構建面向應用運維的應用配置管理。
部署配置管理: 對于應用發布而言，介質是繞不開也必須管理的對象，包括介質的下載地址、增量/全量類型、版本等屬性。因此，需要思考介質是否適合放在CMDB中管理，可以從幾個方面入手：
● 介質的消費場景是否通用？
● 介質的信息準確性是否有技術或者管理手段保證？
綜上思考，我認為介質的信息不應該放在CMDB中，介質的版本信息理應由制品庫維護，并且只有在發布的場景中需要消費介質的數據，所以建議在發布系統中維護介質的管理信息。
應用拓撲管理: 即上一章節描述的應用拓撲模型，在CMDB中維護。
基礎資源管理: 這也是CMDB最基礎最核心的管理內容，以資源的視角看到IT資源的全景。通過關聯的方式與模塊進行聯動，由于應用最終部署的目標還是主機，因此首先需要維護好應用與主機的邏輯關系。
當維護好主機的關系后，就打通了業務與物理的關系，這該如何理解？因為基礎資源都是部署在主機上的，應用拓撲是業務信息，所以當模塊與主機存在關系后，就意味著應用與基礎資源的關系打通了。
綜上內容，可以以模塊為中心，左邊延展發布介質的信息，右邊通過主機看到模塊使用的基礎資源內容，結合上邊的應用拓撲，實現整個以應用為中心視角的IT資源視圖。
03. CMDB怎么在發布場景中起作用？
將發布這個場景動作拆分成三個大的要素：發布目標、發布介質、執行操作。通過“發布介質”在“發布目標”上執行“執行操作”實現發布場景，并且在發布時需要按照以模塊為中心的原則執行發布動作。將應用系統這一個抽象的概念通過結構化的描述落地在CMDB中后，確保所有應用部門、運維同事都具備共同的語言與認知。
比如，當明確發布的目標是：電商系統的生產環境下廣東集群的訂單模塊時，那么就需要部署到訂單模塊下的A、B、C三臺主機上，并且如果涉及到SQL發布的場景，可以通過模塊與MySQL實例的關系清楚的知道這一過程需要在MySQL01這個實例上執行SQL腳本。
又比如，在發布系統上，由于維護好了一個關系：模塊-介質，所以哪怕在晚上12點腦子暈乎乎執行發布變更時，選擇了訂單模塊時也只能選擇與之關聯的order_jar_v1.1.jar程序包，這樣就不會發生“把隔壁購物車模塊的包部署到訂單模塊的機器上”這種錯誤。
在列舉另外兩個發布場景：
高級發布場景：應用發布系統可以通過CMDB主機數據的消費，進行主機的編排，并行、串行、分批等，實現灰度、滾動發布等發布策略。運維人員可以通過編排模塊之間的執行依賴，滿足集群級別的灰度發布策略或者服務依賴場景的復雜場景。
聯動監控/日志系統：驗證發布的成功與否，除了業務上的驗證之外，其實可以通過監控、日志系統進行發布前后的分析。那么如何聯動發布系統、監控系統、日志系統呢？若部署了訂單模塊，又如何知道在日志系統中哪些日志是訂單模塊的？
答案是：CMDB ，通過共同的語言實現多系統的打通。
應用發布系統建設的第一個基礎重點是標準化，我們需要先將CMDB落地應用的概念，并且以應用為中心管理應用的介質、基礎資源等信息，為后續的應用發布場景提供準確標準的數據。
