《前聚美優(yōu)品運維負(fù)責(zé)人：CMDB的那些事兒》要點：
本文介紹了前聚美優(yōu)品運維負(fù)責(zé)人：CMDB的那些事兒，希望對您有用。如果有疑問，可以聯(lián)系我們。

講師介紹

張川,前聚美優(yōu)品運維負(fù)責(zé)人.任職聚美優(yōu)品四年間,負(fù)責(zé)運維自動化系統(tǒng)、監(jiān)控系統(tǒng)及網(wǎng)站系統(tǒng)架構(gòu)的優(yōu)化與重構(gòu).主導(dǎo)設(shè)計并參與建設(shè)運維平臺,推動完成了整個運維團(tuán)隊從工具化、人工化到平臺化的過渡.同時,在公司的多次大促活動中(瞬時并發(fā)達(dá)到平時幾十倍),保證各業(yè)務(wù)線系統(tǒng)的穩(wěn)定.

分享大綱：

1. 什么是CMDB
2. CMDB的表現(xiàn)形式與現(xiàn)狀
3. 怎樣管理與設(shè)計CMDB
4. 關(guān)于CMDB的一些構(gòu)想

一、什么是CMDB

CMDB大家并不陌生,在運維的工作中幾乎都會用到CMDB,在聚美內(nèi)部我們也稱它為資產(chǎn)系統(tǒng),管理整個服務(wù)器的資產(chǎn),當(dāng)然也包括一些配置上的變更.

二、CMDB的表現(xiàn)形式與現(xiàn)狀

這個截圖可能算是聚美優(yōu)品第一版的CMDB,這是剛進(jìn)公司,我們在做第一版監(jiān)控系統(tǒng)時(那時用的是Nagios),通過這個去管理資產(chǎn)信息,再通過用腳本去讀取這個文件,最后生成報警配置,這樣我們管理監(jiān)控時只需要修改這個文件,最后再執(zhí)行腳本就可以達(dá)到監(jiān)控變更的目的.

上面的圖是Ansible的CMDB模塊,這是官網(wǎng)上的截圖,大概的原理就是基于hosts文件里面的主機(jī)信息,生成相應(yīng)的資產(chǎn)信息,大家可以看到,這里的信息已經(jīng)比較豐富了,包括硬件及系統(tǒng)相關(guān)的一些信息,而且顆粒度已更細(xì)致.

CMDB的表現(xiàn)形式非常多,上面只是舉了兩個例子.很多時候大家可能都沒有意識到我們在使用它,我再舉個例子,早期的時候,大家或許有過這樣的經(jīng)歷,我們用excel去管理服務(wù)器信息,這其實也可算做是CMDB的表現(xiàn)形式之一,只是這種方式的對象是人,而非某個系統(tǒng).

這類的方式都有一個比較大的問題.大家可以從上面的例子看到,監(jiān)控系統(tǒng)和自動化系統(tǒng)的CMDB其實是隔離的,CMDB是沒有辦法去做到統(tǒng)一修改的,所以在變更了監(jiān)控系統(tǒng)相應(yīng)配置之后,自動化系統(tǒng)是不會生效的,我們又要單獨的去變更自動化系統(tǒng)的信息,導(dǎo)致額外的維護(hù)成本,所以很多時候我們面臨的都是這樣一個現(xiàn)狀——有多套CMDB并存.

在開始做CMDB之前,理想是美好的,希望CMDB是中心化的,就像這張圖所表達(dá)的一樣,如果說整個遠(yuǎn)維平臺是一個大樹的話, 那么CMDB就相當(dāng)于這顆樹的樹干和樹根,有著非常重要的作用,而其它子系統(tǒng),像是監(jiān)控系統(tǒng),自動化系統(tǒng),還有業(yè)務(wù)相關(guān)的一些系統(tǒng)等就像樹的樹枝和樹葉,大家互相依存,在CMDB上面做任何的變更之后,其它周邊的一些系統(tǒng)能夠立馬知道,而且同時能將這些變更應(yīng)用到具體的場景上.

三、怎樣管理與設(shè)計CMDB

在設(shè)計CMDB之前, 我首先會從運維的角度去考慮,怎么去管理這個系統(tǒng),讓系統(tǒng)更易于維護(hù)和管理,所以在設(shè)計之前必須先問一個問題：怎么去管理?那首先就要知道需要去管理哪些信息,也就是說哪些信息應(yīng)該放到CMDB里面,這些信息的我們對它怎樣進(jìn)行分類 .另外一個就是這些信息對我們后續(xù)的一些系統(tǒng)的建設(shè)能夠提供什么樣的一個價值.

第二個就是怎樣去保障這個數(shù)據(jù)的準(zhǔn)確性.要保證數(shù)據(jù)準(zhǔn)確性有兩種：一個是我們在線上跟線下數(shù)據(jù)的同步,線下數(shù)據(jù)跟線上數(shù)據(jù)保持一致,前期要不停地盤點,到做CMDB的時候,這些數(shù)據(jù)才能用起來.第二個一定要避免人工干預(yù),這個可以通過一些自動化的手段和中心化CMDB相結(jié)合達(dá)到這個目的 .

前面提到了在CMDB的信息管理里面需要管理哪些信息.信息的分類,我的理解,大致可分為兩種,一種是可變信息,另外一種是固定信息.固定信息的,很多數(shù)據(jù)都可以通過一些程序,或者是自動化的手段進(jìn)行自動的錄入,幾乎是不會變的,但需要有一個比較好的規(guī)范,比如像機(jī)房或者交換機(jī)這樣一些信息,自動化工具是抽取不出來的,所以我們采用了一個變通的方法,統(tǒng)一交換機(jī)的命名規(guī)范,統(tǒng)一采用機(jī)房+機(jī)柜的命名規(guī)范,然后通過腳本抓包的方式把網(wǎng)絡(luò)結(jié)構(gòu)還原出來.如果主機(jī)也是基于這樣的規(guī)范命名的話,甚至還可以把機(jī)柜還原出來.

可變信息是構(gòu)成CMDB生命最重要的信息,有了這些信息才讓資源真正有了相應(yīng)的歸屬.人員的信息,包括像聯(lián)系方式的等信息,主要是為監(jiān)控系統(tǒng)提供相應(yīng)的數(shù)據(jù),狀態(tài)信息包括資源上線狀況、下線狀況,主要是為自動化上線提供相應(yīng)的信息,環(huán)境信息包括生產(chǎn)環(huán)境還是測試的環(huán)境,主要是為監(jiān)控系統(tǒng)及自動化系統(tǒng)提供相應(yīng)的信息,項目信息在跟一些業(yè)務(wù)系統(tǒng)做一對接時時非常重要的,比如說業(yè)務(wù)系統(tǒng)需要知道某一個項目有哪一些IP都需要從這里面取數(shù)據(jù),同時也是自動化系統(tǒng)的支撐,有了項目歸屬,服務(wù)器才知道應(yīng)該去做哪些部署.

CMDB在設(shè)計的過程中,我覺得是比較重要的是自動化的系統(tǒng)跟CMDB系統(tǒng)的結(jié)合.首先,在一個資源交付之后,可以通過一些裝機(jī)和初始化的腳本去調(diào)用CMDB的接口,這樣機(jī)器的IP信息就會同步到資產(chǎn)系統(tǒng)的資源池里面去,后續(xù)在領(lǐng)用這些資源時,可變信息就發(fā)生了變化,這時候就有項目的屬性,在我們的CMDB系統(tǒng)里面就知道了這個機(jī)器到底是屬于哪一個項目,知道了屬于哪個項目,然后才能明確后續(xù)需要進(jìn)行哪些操作.

但是這個時候,我們的自動化系統(tǒng)是不知道項目信息的,所以需要通過CMDB API去拿到項目等相關(guān)的信息,我們使用的是Saltstack,簡單的說,就是將從CMDB獲取到的項目等信息來更新我們的grains,這樣自動化系統(tǒng)在后面進(jìn)行業(yè)務(wù)部署的時候,才知道應(yīng)該做什么操作.同時這個時候,自動化系統(tǒng)還會將自己讀取到的固定信息,通過調(diào)用CMDB API,將這些信息刷入資產(chǎn)系統(tǒng),完成整個信息的完善, 這樣就實現(xiàn)自動化系統(tǒng)和CMDB系統(tǒng)的聯(lián)動.

之前提到,很多時候我們其實都是面對的多套CMDB并存的情況,在我們運維平臺開始設(shè)計時,由于像自動化系統(tǒng)、監(jiān)控系統(tǒng)這些系統(tǒng)本身就是基于CMDB開發(fā)的,所以直接讀取相應(yīng)的一些存儲數(shù)據(jù)就好,或者也可以通過CMDB的API進(jìn)行聯(lián)動,但是由于其它系統(tǒng)的CMDB是獨立的,比如發(fā)代碼時要改發(fā)布系統(tǒng)的CMDB信息,這樣話可能在操作上面難免會有一些失誤.所以為了解決這樣的問題,我覺得一個比較好的辦法的話就是把CMDB的一些信息同步到配置服務(wù)里面去,比如說像ZooKeeper,etcd里面,同步進(jìn)去之后,如果是其它系統(tǒng)要用的時候,再把的信息拿出來,對它進(jìn)行處理.這樣的話基本就可以達(dá)到一次變更,所有生效的目的,實現(xiàn)了中心化CMDB,集中化信息管理的目標(biāo).

前面講的更多的是偏實現(xiàn)的一些東西,下面主要想聊下關(guān)于展示相關(guān)的一些東西,前面提到在做CMDB之前要首先考慮CMDB的價值在哪里?一是支撐我們整個運維平臺的建設(shè),盡量做到自動化,中心化的管理,這個是接口層的價值.展示層的價值在哪里呢,上面的這個截圖是我們一個子功能的截圖,通過這樣一個展示就很方便地知道我現(xiàn)在的物理服務(wù)器,虛擬機(jī)等的比例是多少,亦或者可以知道我們每個機(jī)柜的容量是多少,只要數(shù)據(jù)是準(zhǔn)確的,有價值的,基于這些數(shù)據(jù),我們就可以做出非常多的組合.

四、關(guān)于CMDB的構(gòu)想

關(guān)于CMDB的一些構(gòu)想,在很多時候,大家可能都會面臨過這樣的情況,就是一個同事可能有多個的賬號,比如說公司的電腦登錄賬號,公司郵箱賬號等,這些信息如果按CMDB的定義去看理解的話,可能不能稱它為CMDB,但是我認(rèn)為也可按CMDB中心化方式去管理,將存儲層打通起來.比如代碼倉庫,郵箱賬號,服務(wù)器登錄等都可以通過openldap去做統(tǒng)一的數(shù)據(jù)存儲,這樣在發(fā)生人員變更的時候,就可以做到一處變更多處生效的目的,而不需要過多的人工干預(yù).

但這個方案也有一個缺點,會存在一定安全隱患,因為如果數(shù)據(jù)層都打通的話,如果發(fā)生密碼泄漏,其它的項目自然會面臨同樣的風(fēng)險,因為各個系統(tǒng)的密碼都一樣了,所以最好是能再加一層雙因子驗證,保證信息的安全性.

• CMDB的價值

從我自己的理解,運維的工作很多時候都涵蓋在這三個領(lǐng)域里面,穩(wěn)定是最重要的,第二個是效率,然后是成本.CMDB在哪個地方可以體現(xiàn)它的價值呢?我個人認(rèn)為在成本這一塊能力體現(xiàn)非常大的價值,上面提到的固定信息里面,包括了硬件,系統(tǒng)等信息.而成本,我理解也是一個固定信息,比如說我們可以根據(jù)CPU和內(nèi)存去推算我的這個月這臺服務(wù)器支出是多少,有了這些數(shù)據(jù)就可以得到每個月的機(jī)房支出 .

有了這些信息后,比如說我們的服務(wù)器資源通過監(jiān)控系統(tǒng)查看這個月已經(jīng)跑得非常滿了,下個月找老板我要買服務(wù)器,但沒有數(shù)據(jù)支撐的話,直接給老板說買50臺機(jī)器是沒有任何說服力的,實際上用CMDB也可以做這個事情 .服務(wù)器價都是可以推算的,甚至還可以通過爬蟲去爬取網(wǎng)上的一些報價信息,在當(dāng)月資源不夠用時,需要增加時,可以提取出來告訴老板,就知道需要多少成本預(yù)算了.

第二的話是效率,如果是在開始設(shè)計CMDB之前,我們就按照之前中心化的思路去做CMDB話,有很多信息就不需要多處去變更了,從這個維度來說,也就提高了我們的效率,提高效率的同時也就保證整個系統(tǒng)的穩(wěn)定,因為人工操作難免都會出現(xiàn)一些問題的.

最后引用小米提出來的這個概念,NOOPS,我們可以通過把所有的系統(tǒng)打通起來,去幫助研發(fā)提高他們的效率,比如說他們涉及資源使用時可以通過工單系統(tǒng)去申請資源,經(jīng)過審批之后,自動交付資源,發(fā)布代碼,上線后可以通過業(yè)務(wù)監(jiān)控獲知業(yè)務(wù)的狀態(tài),達(dá)到一個自主上線的狀態(tài),當(dāng)然這中間還是需要人工做干預(yù),不過這個干預(yù)更多的就是流程上的審批,目前這也是我們努力的方向.

文章來自微信公眾號：DBAplus社群

轉(zhuǎn)載請注明本頁網(wǎng)址：
http://www.fzlkiss.com/jiaocheng/3731.html