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