一. 介紹

作者介紹

本文作者是吳秀民 聯絡方式：autohomeops@autohome.com.cn，主要負責汽車之家資產管理系統和配置管理系統的開發工作。 個人Blog http://pylixm.cc/

團隊介紹

我們是汽車之家運維團隊，是汽車之家技術部裡最為核心的團隊，由op和dev共同組成。我們的目標是為汽車之家集團打造一個高效能，高可擴充套件，低成本，並且穩定可靠的網站基礎設施平臺。 團隊技術部落格地址為 http://autohomeops.corpautohome.com

聯絡方式

可以通過郵件或者在官方技術部落格留言跟我們交流。

二. 前言

隨著私有云及公司各自動化系統對CMDB資料依賴的加深，CMDB已變為公司伺服器維護的基礎資料來源，一旦cmdb的資料有問題，可能造成不可預估的後果，

嚴重的可能導致線上業務的癱瘓。我們CMDB開發之初，制定了“高度準確性，高度可用性，高度自動化”的建設方向，而維持這個方向的核心是“流程管控”。

而“流程管控”是個長期建設的過程，某些時候很可能會趕不上業務流程的發展，這個時候為了不影響日常工作的順利進行，免不了需要按照約定的規範流程來手動處理， 如果時間一長，就可能造成機器資料不準確。

資料的準確性，一直是CMDB建設的一大難題。接下來，說下我們除了“流程管控”外保證資料準確性做的一些探索，歡迎交流。

三. 我們遇到的問題

隨著私有云及各自動化系統的建設，CMDB各種資料的維護都已實現自動化處理。但是上面已經提到過，“流程管控”和“業務流程發展”是一個相互博弈的過程，會有人工介入的機會。 在其中，我們遇到了許多問題，幾個比較常見問題如下：

問題 1. 資產各欄位資料不準確的情況；

公司私有云平臺從CMDB中抓取IP使用時，是根據機房和業務線來抓取事先分配好的IP段。當業務線和機房出現問題時，則會抓取錯誤。

之前有同事在CMDB中建立了個機房用來劃分IP，建立機房時，沒有安照規定好的格式命名，且是從後臺新增沒有校驗。

造成私有云在裝機時拿不到可用的IP而工單流程走不下去。像這種資料不準確的情況，是非常危險的。這次只是一個機房命名，一旦私有云分配錯了IP，有可能

把線上的伺服器業務給覆蓋掉，後果嚴重。

問題 2. 某個資產狀態下，該為空的欄位還有值，造成其他私有云工單流程入庫時出現資料唯一性錯誤；

有業務線的同事申請雲主機，各級領導批示通過後，遲遲沒有收到雲主機申請的結果郵件。於是便聯絡運維檢視，運維又聯絡雲主機管理員，

管理員再聯絡雲主機開發人員，開發人員發現機器在自動入CMDB資產庫的時候出錯，找到我們。我們經過日誌排查，發現一臺伺服器下線後

ip 沒有清空，導致資料入庫時報唯一性錯誤。經過多個系統的開發人員的合力排查，最後發現是資料問題。這種問題耗時耗力，還不可預見。

問題 3. 由於沒有私有云上線工單而手動修改狀態，造成時間有誤，統計上線資產時資料不準確。

在對CMDB資料進行分析時，依賴各種事件變化的時間，但是人為修改資料時，有可能不去修改變更時間。這樣當我們分類統計資產資料時，和

私有云的工單資料對不上，需要進一步核對明細。此時，就令人崩潰了。

四. 我們的審計方案

4.1 概述

基於以上問題，我們翻閱了大量資料，很少有資料對資產的自審計這塊做很詳細的介紹。

我們根據自身的問題，制定了以“盤”、“審”、“罰”為核心的自我審計方案，來保證cmdb資料的準確性。

4.2 盤 - 日誌回算，外部核對

4.2.1 記錄資料來源

我們的CMDB是基於Django構建的，我們重寫了Django的model，在資料儲存變化時，同時記錄資料的變化日誌。

將資料記錄變化前和變化後的值都儲存下來，作為以後回算的資料來源。

4.2.2 回算

有了資產的最詳細的資料變更日誌，這樣只要我們遍歷資料的變更日誌，便可以知道歷史任意時刻資產的狀態資訊。

例如，我們要計算上個月某個業務線申請了多少臺機器。我們只要遍歷上月CMDB的資料變更日誌，將業務線和狀態同時變更的記錄累計起來，

便是我們需要的資料了。

4.2.3 外部盤態

根據回算處理，可以得到一些彙總性的資料。我們也可以從工單系統等外部系統拿到一些彙總性的資料。根據這2個資料我們可以判斷出

CMDB 的資料記錄是否有錯誤，是多資產了還是少資產了。

外部盤態的流程，如下圖：

4.3 審 - 定期審查，自我修正

除了盤庫外，我們還定製了自審查後臺任務。每天會對CMDB資產的各欄位準確性及是否為空做校驗，找到資料有問題的資產。

將資產列入黑名單，並以郵件的形式傳送給相關運維人員，提醒他此資產什麼地方有問題需要修正。先於外部呼叫系統發現問題，爭取主動權。

郵件樣式：

除了郵件，我們還開發了黑名單的核實功能-“黑名單列表”，來督促運維人員做資料的修正。運維將修改過的資產在“黑名單列表”中做確認 操作，等下午發第二封郵件時會公佈大家的修改程式，這樣起到大家相互督促監督的作用。

4.4 罰 - 劃分責任，落實到人

執行力，也是資料準確性的一大保證。以上我們通過自動盤庫找到了有問題的資產，能夠及時有效的修正資料也是一個大問題。

4.4.1 視覺化規則條例

為了解決“執行力”的問題，我們制定了規章條例，並將它視覺化，在cmdb中以資產的形式管理起來，供各運維檢視學習。

頁面原型如下：

4.4.2 將黑名單和條例結合

將黑名單和條例視覺化後，便有條可依。當資產資料再出現問題時，先給予運維時間去自行修正，如資料錯誤仍然存在， 便可進行不同程度上的小小懲罰。

頁面原型如下：

獎罰條例事件流程圖：

五. 經驗總結

在CMDB的整個構建過程中，資料的準確性一直是一個大難題。我們在這個方向上的一些經驗總結：

1. 將責任角色劃分到人，減少扯皮的麻煩。出了什麼問題，就找什麼角色的人。
2. 私有云工單流程控制中各資產的資料變更時間記錄要詳盡，便於滿足各種統計需求。
3. 將超級管理員和開發人員分開，解放開發人員，避免開發過多的參與錯誤資料的核對耽誤正常開發。

六. 未來的Roadmap

1. 基於黑名單的資產鎖定處理
2. 部分問題資產的自我修正

七. 參考資料

CMDB理解

華為cmdb

藍鯨

優雲軟體

---