運維的目标
1.穩定性保障
2.提高人效
3.提高資源使用率，降低成本
運維的定位
1.運維是支撐團隊 合作是主旋律
7.有了CMDB，為什麼還需要應用配置管理
CMDB 是面向資源的管理，應用配置是面向應用的管理
1.CMDB 是面向資源的管理，是運維的基石
傳統SA建設運維的基礎管理平台做的事情（備注：面向應用運維的角度做這些不夠哦.....）
第1步：把伺服器、網絡、IDC、機櫃等這幾大次元先定下來；
第2步：把這些硬體的屬性确定下來，比如伺服器就會有 SN 序列号、IP 位址、廠商、 CPU、記憶體、硬碟、網卡等等；網絡裝置如交換機也會有廠商、型号、帶寬等等；
第3步：梳理以上資訊之間的關聯關系，或者叫拓撲關系。比如伺服器所在機櫃，虛拟機所在的主控端、機櫃所在 IDC，複雜一點就會有核心交換機、彙聚交換機、接入交換機以及機櫃和伺服器之間的級聯關系；
備注：在上面資訊的梳理過程中肯定就會遇到一些規劃問題，比如，
- IP位址段的規劃：哪個網段用于 DB，哪個網段用于大資料、哪個網段用于業務應用等
- 機櫃配置設定規劃：哪些機櫃用于做虛拟化主控端、哪些機櫃隻放 DB 機器等
以上資訊梳理清楚，通過 ER 模組化工具進行資料模組化，再将以上的資訊固化到 DB中，一個資源層面的資訊管理平台就基本成型了。但是，資訊固化不是目的，也沒有價值，隻有資訊動态流轉起來才有價值。接下來我們可以做的事情：
第 4 步：基于這些資訊進行流程規範的建設，比如伺服器的上線、下線、維修、裝機等流程。同時，流程過程中狀态的變更要同步管理起來；
第 5 步：拓撲關系的可視化和動态展示，比如交換機與伺服器之間的級聯關系、狀态（正常 or 故障）的展示等，這樣可以很直覺地關注到資源節點的狀态。
如下圖
2.應用配置管理是面向應用的管理，是運維的核心
面向應用，則需要應用名或者應用辨別，結合上面的，應用名<---> IP 的關聯關系就可以建立，當然也可以是其他唯一主機辨別，如InstanceId、主機名、容器ID等
抽象除兩個重要的概念：1.應用名 2.應用名和IP的關聯關系，如果不和應用關聯，影響力就僅僅在運維内部，但是和應用關聯後就會影響整個業務架構---> 技術架構---> 研發組織架構，以及其他的平台和系統建設，都和這兩個概念相關。
CMDB---> IP ---> 資源管理（如上圖）
CMDB---> 應用---> 應用管理，應該管理設計如下資訊：
1.應用的基礎資訊：研發負責人、測試負責人、運維負責人、Git位址
2.部署涉及的軟體包：語言包（Java、C++、GO 等）、Web 容器（Tomcat、JBoss 等）、Web 伺服器（Apache、Nginx 等）、基礎元件（各種 agent，如日志、監控、系統維護類的 tsar 等）
3.應用部署涉及的目錄：如運維腳本目錄、日志目錄、應用包目錄、臨時目錄等
4.應用運作涉及的各項腳本和指令，如啟停腳本、健康監測腳本
5.應用運作時的參數配置，如 Java 的 jvm 參數，特别重要的是 GC 方式、新生代、老生代、永生代的堆記憶體大小配置等
6.應用運作的端口号
7.應用日志的輸出規範
8.其他。
這個梳理過程其實也是标準化的過程，上面梳理的應用相關的資訊和CMDB裡的資源資訊是兩個次元的資訊，從資訊管理角度來看，資源配置和應用配置解耦後會更清晰更容易管理。
上面的資訊模組化和固化後，下一步就是建設基于應用配置管理的流程規範（如流程中心-機器申請流程） 和 工具平台。
應用配置管理
資源配置 & 應用配置結合
效果：
1.應用名----關聯--- 應用配置資訊
2.IP -------關聯---資源資訊
1 和 2 通過【應用名-IP】的對應關系，聯系到一起。
3.以上二者結合的價值
基于 應用 + 資源配置管理，後面可以做很多對業務有價值的事情，如：持續內建和釋出、持續傳遞（如流程中心-服務釋出流程&一鍵擴縮容流程）、彈性擴縮容、穩定性平台、成本控制等等。
8.如何在CMDB中落地應用的概念
1.如何有效的組織和管理應用(微服務)
組織成一個樹形的層次結構：命名方式統一、層次結構統一
業務架構拆分：按業務次元進行拆分：電商、支付、廣告，電商又包含：使用者、商家、商品，商品又包含：詳情、庫存、評價等。
業務架構-----決定----->技術架構-------決定----->研發團隊組織架構（每個小團隊負責不同業務的開發和實作）
産品線waimai
業務團隊C端
應用1-下單
prod
機器資源....
stag
機器資源....
test
機器資源....
dev
機器資源....
應用2-提單
prod
stag
test
dev
上面的prod、stag、test、dev屬于應用的叢集服務【分組建設】，當然也可以不按環境區分，比如按IDC區分，或者按服務場景區分，如：秒殺、非秒殺
應用名設定規範：
- 應用名必須以小寫英文字母、數字以及下劃線組合，不能以數字開頭；
- 應用名長度不超過 40 個字元，盡量簡單易懂；
- 不允許出現機房代号和主機名稱這樣的資訊。
2.CMDB在基礎服務體系中的核心位置
CMDB = 面向資源(ECS + RDS + Redis + MQ) + 應用
以上的應用-分組-資源的對應關系，對于周邊系統都是需要的，包括但不限于如下
1.監控系統
如：隻監控prod環境的機器和RDS/Redis執行個體資源
2.釋出系統
代碼編譯打包釋出到指定應用對應環境的所有機器上，如：持續內建、持續傳遞、彈性擴縮容等，另外也可以和成本控制等結合。
3.服務化架構
比如配置中心、注冊中心、4層7層負載均衡、ZK等，依賴應用名(應用)+環境(叢集分組資訊)，管理應用名，如：meituan.waimai.c.order.prod
4.基礎服務
DB、緩存、MQ和應用名關聯，代表哪個應該使用了這個基礎服務，
使用應用名的場景：
比如應用與NameServer的對應關系，應用與topic的對應關系，
使用應用名和資源對應關系的場景：
DB\MQ ACL授權的時候需要應用的某個叢集分組(可以了解為環境)下的IP的對應關系。當然配置的實作方式有多種：比如在DB中間件 或者 DB 或者作業系統上通過iptables配置
5.穩定性保障平台(服務治理平台)
降級限流、開關預案都是和應用直接關聯的，不同的叢集分組(如環境)政策也可能不同，政策下發到最終的伺服器上，又需要應用-叢集分組-資源的對應關系。
基于以上5點，CMDB和周邊系統的互動，如下圖
以應用為核心的運維體系，如下圖