cmdb是什麼？
cmdb 就像乙個人的大腦核心，是乙個資訊協調庫，其儲存的資料是協調身體完成各種複雜運動的資訊**。
我心中的 cmdb
碎片整合
面向運維工具的碎片化場景，是盤活整個運維管理的資料核心
. 元資料庫
提供運維活動的基礎元資料，是唯一可信的運維配置資料服務
. 場景驅動
為運維聯動提供資料驅動，可協調工具來完成各類自動化場景
自動擴容+自動監控
cmdb 如何建設？
痛點現象與對策 i 模型建不好
存在的問題：
. 建模維度（粒度）失去控制
粒度若建得太細，連網線、記憶體條都變成配置項，最後 cmdb 中儲存的 70% 資料沒有作用，只是做了大量無用功。
缺少行業實踐參考
國內很多時候都是根據 bmc、hp 等模型來建立乙個模型庫，但實際上老外的思路與國人迥異，往往會做出過於複雜的模型體系。
模型調整太笨重
使用關係型資料庫，模型中每乙個型別的屬性都是乙個列，最後調整總是要動用研發，完成一次調整需要 2 天的時間，而這種調整在資料補充階段，往往要經常進行，耗時耗力。
我們怎麼幹的–管理
. 目標驅動
持續迭代的方式推進，只實現當前目標需要的最小模型集合。建議不要使用傳統軟體研發大瀑布模式來建設模型，而是使用持續迭代的方式，每次都設定一下較小的目標，按這個目標去建立剛好滿足要求的模型庫。
行業參考
尋找和借鑑行業最佳實踐。尋找行業內的最佳實踐，去學習他們的模型，尤其也是學習其演進路線，切不可一口吃成乙個胖子。
我們怎麼幹的
– 技術
第一步，資料型別標籤化, 支援多重身份
傳統的 cmdb 系統，往往使用科學分類法的思路，按界、門、綱、目等樹型結構去嚴格劃分，但這樣給建模帶來了非常巨大的挑戰，因為一定有一些資料四不像。比如虛擬機器，到底是劃到傳統的計算裝置資源下，還是劃到虛擬資源下？所以我們提議使用資料型別標籤化的方式來進行分類。比如虛擬機器，我可以同時打上計算裝置與虛擬資源這樣兩個標籤。
第二步，使用關係建立聯絡, 分清關係與屬性
使用弱型別約束的關係，而不是屬性。因為屬性往往要提前建模，但實際上很多配置項在建立時，是想不清楚它可能與哪些配置項產生聯絡的，所以使用關係可以更輕量化。
第三步，易於調整模型, 支援動態屬性
在 cmdb 系統的技術設計過種中，要注重使用能快速調整的儲存模型，比如使用支援 scheme 調整友好的資料庫，或 postgresql 這樣支援 json 擴充套件欄位的資料庫，可以實現動態屬性。
痛點現象與對策 ii 資料不準確
存在的問題：
. 人工錄入資料、準確率低
. 沒有及時維護、資料過期
. 資料**多、存在衝突
我們怎麼幹的–管理
. 確定地位
確定 cmdb 作為唯一資料來源，若上下資料流不準確，應從 cmdb 開始修正
. 職權劃定
自定原則，例如誰提供，誰維護
. 定期審查
從制度上需要確定團隊能定期對 cmdb 中的資料進行審計，尋找錯誤資料並改進問題。如同一些倉儲管理，需要定期核查帳面與實際庫存，cmdb 也需要定期審查資料與生產環境的實際符合度。
我們怎麼幹的
– 技術
. 支援協同
配置變更熱點, 訂閱我關注的配置項變更。每個人都可以檢視他人的資料足跡，配置項也允許按變更次數或者被使用次數，作成熱點圖，最後也應允許訂閱我關心的配置項，這樣可以在配置項變更時，相關負責人可以及時收到通知。
. 記錄歷史
允許隨時查詢資料的變遷歷史，並可回溯基線。在每一次資料入庫後，都能記錄資料的變更歷史，以便可以隨時對比版本變更的內容，以及在糾錯時回溯基線。
. 支援調和
利用策略、規則實現多資料來源的調和。資料**過多，也會導致出現資料衝突。在資料出現衝突時，能顯示不同資料**的衝突，並支援人為調和，同時 cmdb 系統也應學習這些人為的調和依據，可以形成自動化調和。
. 依賴工具
在資料的採集和補充上，以使用監控與自動化工具為主，它們可以減少大量的錄入工作，並且避免人為的錯誤。
痛點現象與對策iii資料不好用
存在的問題：
.不清楚有哪些使用場景
經常有這樣的情形：為了cmdb而cmdb，導致最後cmdb只是當資源臺帳使用，最常使用的功能也僅僅變成了excel匯入與匯出。而實際上，我們需要建設的是乙個服務型的cmdb。
.系統開放性差
cmdb開放性差，往往只是提供了讀寫api，把cmdb當成乙個普通的資料庫來使用。
我們怎麼幹的–管理
1.積極尋找場景，消費資料，讓資料產生價值。
2.影響分析：使用訊息盤，做配置變更演練，做故障演練。
3.自動監控：當新增一些配置項時，可以通知到監控系統，自動產生監測策略。
4.自動排障：在監測到故障時，可以自動排障。
5.容量管理：在配置庫中為應用記錄擴容收容閾值，以便自動伸縮擴容。
我們怎麼幹的–技術
1.關係推導：提供從乙個配置項按關係提煉其它配置項的能力。
2.全文檢索：能便捷的使用關鍵字，搜尋符合的配置項。
3.變更通知：配置項變更不但提供對人的通知，更要利用mq，提供對運維工具的通知，以觸發一些自動化場景。
4.事務控制：允許通過api建立沙箱，整個沙箱中的配置項是一起提交與一起回滾，這特別適用於應用的上線。
5.版本對比：允許查詢乙個配置項的歷史資料與變更情況。
6.web整合：除了api，還應該提**用間的介面整合還應該提**用間的介面整合還應該提**用間的介面整合。
cmdb
成功要素
能消費起來的 cmdb 才是好 cmdb！
模型：定義了最小可用的 cmdb 模型結構與規則
資料：正確地維護了 cmdb 各類資料及其關係
api：提供了開放友好的 api 服務
場景：利用 cmdb 的資料玩轉各種運維場景
cmdb = 模型 + 資料 + api + 場景
python 自動化運維 CMDB實現的核心邏輯
ssh方式實現 paramiko模組 原文 通過中控機操作採集資訊，傳送到api過濾處理資料 適應場景 伺服器較少的情況下 優點 不需要每台機器裝agent程式 缺點 有乙個中控機，速度慢 import paramiko ssh paramiko.sshclient 生成ssh客戶端連線物件 ssh...
運維自動化
1，cobbler安裝環境準備 安裝epel epel release 6 8.noarch.rpm x86 64 epel release 6 8.noarch.rpm x86 安裝系列依賴環境 要是區域網用，建議關閉iptables 或是放行25151 80 69埠 和關閉selinux 檢視狀...
自動化運維
考慮的因素 源 打包為映象 發布到映象庫 利用k8s發布到物理機器執行，以服務的形式對外提供服務 目前的做法 0 建立乙個執行遠端命令的框架 1 每個應用建立乙個部署檔案指令碼 a 指定元 位址 c 同步源 到目標主機 d 接受指令碼引數 vername 2 版本號，映象tag fromport 3...