淺談CMDB

什麼是CMDB

CMDB，Configuration Management Database的簡稱，從英文單詞中直譯」配置管理數據庫「，但實際上更多的被稱呼爲」資產管理系統「。
其實出現這種誤差的起因在於不一樣建設思路中對所要達成的」目標「不一樣，而對該」Configuration「的理解不一樣所致使。
CMDB一般具有存儲」Configuration「、創建」Configuration「之間的關係、利用流程或工具維護」Configuration「數據和保證其數據正確性等功能
而在此基礎上開放數據對外服務、聯動其他平臺（CI、CD、流程等）構建完善的運維架構體系是經常使用的作法。

爲何要建設CMDB

在沒有CMDB時，運維人員會採用excel、記事本或者紙質文件去記錄相關的機房、機櫃、物理設備、主機、應用相關的信息。
在這種狀況下常常會遇到疏於更新數據或遺漏丟失數據致使，在整理業務架構、分析當前資源使用率、機房機櫃等採購決策時作出錯誤的判斷，致使資源浪費、故障排查難、遷移難等問題。
總結下來本質問題爲：

1. 數據信息散亂、遺漏、不集中
2. 數據維護手段多種多樣、無規範化處理
3. 數據正確率低
4. 數據有效利用率低

爲解決以上問題，進行CMDB的建設，能夠保證如下基本需求

1. 統一數據存儲
2. 統一數據校驗
3. 統一數據維護手段

而在此基礎上開放CMDB數據給予其餘平臺消費，讓數據獲得充分的利用，例如根據關係鏈繪畫架構圖、故障根因分析等經典消費場景。

何時要建CMDB

很簡單，當你吐槽excel的時候就能夠開始了！

其實在你吐槽的時候，已經表明着公司的業務成長，你已經沒法用當前的作法去很好的維護這些數據、協調你的工做。
而你總會想着有個地方能夠統一的存儲這些數據，有個web界面給你去查看、更新，接下來你只須要保證數據的不丟失，就能達到你想要的初期效果。
更進一步不斷的優化該系統，使它更加的強大健壯時，你將會發現它不知不覺中成爲了不少系統的基石，這其實就是CMDB最原始的雛形。
固然，如今CMDB已經不止怎麼簡單了，每家公司由於它自身的文化、需求不一樣，造就的CMDB形態也各不相同。
而有些由於建設目標不明確，致使CMDB最終建設失敗，推倒重來也不在少數。

建設CMDB注意事項

我的從工做中總結，建設CMDB需注意如下幾點

1. 明確你的需求
   列出當前你所遇到的問題，分析其中起因，肯定最迫切、最麻煩的問題是什麼，從而肯定你的需求是什麼。
2. 制定你的目標
   整理出了需求以後，你得定下目標，不能只經過需求知足就已達成目標，目標必須是能夠量化的，好比說接入了多少數據、數據的準確率等等
3. 肯定你的CMDB形態
   在你肯定了需求、初定了目標以後，基本已經確認了你建設的是什麼樣的CMDB，而後能夠試圖從IOS7層去看何種方向去豐富你的數據。

CMDB形態簡介

1. 資產管理CMDB
   這種用戶遇到的問題每每會是機房、機櫃和物理設備等管理混亂、購買合同對不齊、交換機端口線路對不齊和IP地址網段分配散亂不清晰
   而從問題出發看出建設方向應是從下（物理層）往上去建設，將機房、機櫃、物理設備、合同、交換機等信息錄入並創建他們之間的關係。
   趨向於從摸得着到摸不着的數據豐富
2. 配置管理CMDB
   這種用戶遇到的問題是業務信息混亂、應用端口分配錯亂衝突、組件部署主機不清晰時，
   從問題出發看出建設方向應是從上（應用層）往下去建設，將從業務角度出發，將應用、中間件、主機等屬性配置信息存放並創建他們之間的關係。
   趨向於從摸不着到摸得着的數據豐富

不管是哪一種方式，都是歸一化的將其屬性數據化、關係數據化存放，更加易於消費使用。

如何建設CMDB

建設CMDB需從戰略方面開始、以戰術方面落地實施

戰略方面

從戰略方面需作到如下四點

1. 明確建設目標以及建設方向：知道自身痛點得出需求，接着從需求出發設定量化目標，最後從量化目標出發明確建設方向。
2. 明確須要數據化的對象：全盤梳理建設方向所涉及到各個對象名稱，需梳理各對象屬性（過程與建模同理）
3. 整理資源間的關係：從對象列表中，整理其關係，從中區分核心與非核心，優先建設核心上的對象
4. 整理用戶使用路徑：從用戶角度出發，模擬操做使用路徑，梳理業務流程，好比如何錄入、如何查看等

戰術方面

採購 or 自研

在常見的運維團隊裏，具有研發基礎或高級研發水平的人趨於少數。
若是要進行自研CMDB的話，天然須要尋求研發部外援或者招專職研發
但不管是招人，仍是團隊調整以及磨合都是須要時間的，
並且這裏也會有建設經驗上帶來的研發質量、需求實現誤差等問題。
因此選擇採購仍是自研能夠從時間成本、人員成本兩個維度去衡量

1. 考慮人員成本

   1. 團隊中是否具有研發基礎或高級研發水平的人
   2. 團隊中當前工做安排是否能允許人員進行研發工做
   3. 團隊中是否有相關建設經驗的人員

2. 考慮時間成本

   1. 建設需求是否並不緊急實現（如1~3個月就算緊急）
   2. 若是須要招人，是否允許招聘時間和團隊磨合時間（1到2個月）
   3. 若是須要培養，是否允許成員學習相關知識時間（1到2個月，甚至更久）

以上兩個維度的問題中，若是以上問題，」是「居多時可考慮選擇自研，」否「居多時考慮選擇採購。
固然若是財大氣粗，又不想麻煩的話，也能夠選擇採購。
但切記並非採購就等於沒麻煩，選擇成熟且領域頂尖的CMDB產品能夠減小麻煩，但這裏的技術維護成本、甲乙雙方之間的溝通成本以及安全性都須要考慮。
也切記自研並非必定要從0開始，站在巨人的肩膀上也能夠解決很多麻煩。

CMDB系統總體考量

我的在以往思考中對CMDB系統總體考量梳理以下，但願能夠提供參考，而這裏只是淺談就不展開了。

功能層面上

1. 考慮數據開放策略

   • 外部系統如何對接
   • 用戶如何使用這些數據

2. 考慮數據安全問題

   • 訪問如何進行權限校驗
   • 數據是否須要加解密傳輸
   • 存儲的數據是否須要脫敏

3. 考慮事件響應機制

   • 系統如何變動通知
   • 對接用戶如何消費

4. 考慮數據維護環路

   • 如何數據讀取的入口
   • 如何對數據進行變動
   • 查詢語法是否知足需求
   • 如何驗證數據正確性
   • 如何制定數據准入規範

5. 考慮數據如何展現

   • 展現數據的圖表組件是否足夠豐富
   • 是否提供通用以及強大的SQL層（查詢語法）
   • 是否能依據不一樣需求進行場景化展現

架構層面上

1. 考慮組件高可用

   1. 考慮前端web組件如何進行擴縮容（注意無狀態、有狀態）
   2. 考慮後端處理邏輯組件如何進行擴縮容（注意無狀態、有狀態）
   3. 考慮數據庫選型

2. 考慮數據庫容災

   1. 考慮數據備份方案
   2. 考慮數據恢復機制方案

3. 考慮跨機房方案

   1. 考慮網絡流量
   2. 考慮網絡延遲
   3. 考慮集羣建設

自研技術建設考量

1. 語言選擇

   • python
   • golang

2. 考慮數據存儲性能指標

   • 可承受量級
   • 查詢效率
   • 寫入效率
   • 查詢豐富度

3. 考慮數據庫存儲方案

   1. 單數據庫存儲方案
   2. 多數據庫存儲解決方案

4. 考慮事件總線組件方案

   1. 成熟隊列組件，支持發佈訂閱
   2. 高可用

5. 考慮數據入口方案

   1. 自動錄入

      • agent定時任務主動推送
      • 服務端定時拉取信息

   2. 文件錄入

      • excel
      • txt
   3. 對接流程變動錄入

如何評估CMDB建設

在建設中，要對成果或者階段作個評估，以便後續更加精進該系統或修正方向
而這時須要可量化的指標，因此就須要指定如下指標

1. 圍繞建設目標

   1. 當前已管理的對象數：對象個數
   2. 當前已管理的對象數據量級：各對象的實例數據量、以及總數據量
   3. 當前熱點消費數據分佈：根據訪問對象的次數（寫入、讀取)
   4. 當前熱點消費的對象是否符合預期：判斷是否符合建設目標中的核心對象
   5. 當前數據平均準確度：能夠經過反饋數和平常維護時的記錄去記錄，若是平臺有修正功能的話，能夠是修正數據次數

2. 技術層面

   1. 平臺性能

      • 平均查詢速度：根據CMDB查多寫少的場景，查詢速度是一個很是重要的指標
      • 平均組件CPU使用率：持續優化各組件所使用
      • 平均組件內存使用率：持續優化各組件所使用
      • 平均組件IO使用率：持續優化各組件所使用
      • 最大併發數：測出最大併發數以便維護並優化平臺
      • 平均磁盤佔用：持續優化各組件所使用
      • 平均網絡流量：持續優化各組件所使用

   2. 平臺穩定性

      • 請求成功率：保證其餘已對接的平臺能正確的使用數據
      • 高可用有效性：保證平臺的做爲基石的健壯性

有趣的看法

CMDB與監控結合

CMDB通常存儲的是靜態穩態的數據，這表明這並不會有高頻率的變更，從這點出發代表咱們沒法從CMDB層面去看資源的當前運行態是如何的
而這時候咱們該怎麼作呢？
監控平臺是能夠經過高效、豐富並支持分鐘級或秒級的採集手段採集着各類對象的指標數據。
可是監控平臺的數據在傳統建設中，只有在遇到問題時纔會來使用，這是極其浪費的事情。
因此經過CMDB + 監控平臺兩平臺的數據結合，咱們能夠結合穩態（配置、關係）和動態的數據（指標）去觀測資源的各方面的狀態
好比，經典場景中的」由業務關係出發的應用之間調度鏈以及實時請求訪問狀態圖「，這個圖例能夠實時的觀測到應用的運行狀態，也從圖中能夠全局把控整個調度鏈路。
這是一個很是有趣而實用的場景。
還有着，從關係鏈進行告警根因分析、告警收斂也是很好的實踐場景。
固然場景還有不少，能夠值得去深挖。

如何關聯起來？

CMDB的數據與監控平臺的數據的關聯，在於監控數據的維度概念

維度的簡單理解就是sql語句中的where條件所使用的字段，維度值通常以字符串存儲，能夠參考influxDB的tag概念

監控平臺的數據是從維度去定位到相關的對象的數據，好比經過mysql的ip、port定位到該mysql的指標數據
而CMDB中的數據實例中也會需具有這樣的穩態數據，從這點出發，創建二者的共性數據關聯策略就可將二者數據關聯起來。
這裏不詳細展開。

地圖化

在常見的CMDB中，錄入的數據，都可以用列表展現，可是若是用地圖呢？
能夠像地圖同樣，檢索查詢定位你想要的點，而後經過拉動，擴大縮小查看周邊的信息。
是否是很是有趣？
其實所謂的地圖化，簡單理解就是關係+場景化
那場景化是什麼呢？
場景化，簡單來講就是"什麼地圖"
好比你是從業務場景去看，那這個地圖就是業務地圖，而後你想要定位mysql實例位置
那順着業務出發層層分割，從業務->應用->依賴服務->Mysql服務->Mysql實例順着定位。
這跟咱們看地圖是同樣的思路，從國家->省->市->縣->鎮->街道，是否是很貼切？

地圖化有什麼用？

在一般狀況下CMDB中全部資源的關係都是平等的，就是一張很是巨大的網
而地圖化就是經過特定場景化封裝出有層次、有重點的關係鏈路網圖，在越靠近源點的關係數據價值越高。
這樣有利於梳理核心和非核心數據，去除干擾數據，專一場景消費使用，讓數據最大價值化。

結束語

本文是我的經歷中對CMDB認識的總結，但願對各位建設CMDB路上有所幫助，謝謝