本文根據(jù)〖高效運(yùn)維社區(qū)講壇〗線上活動(dòng)的分享整理而成。
歡迎關(guān)注“高效運(yùn)維(微信ID：greatops)”公眾號(hào)，以搶先賞閱干貨滿滿的各種原創(chuàng)文章。
嘉賓介紹
前言
最近在社區(qū)多次看到CMDB的分享，大多是在探討CMDB如何建設(shè)（How）的問題，雖然如何建設(shè)的問題非常重要，但在當(dāng)今人人談云的云化時(shí)代下，究竟該建立一個(gè)什么樣（What）的CMDB更為重要。
首先要說明的是，今天在這里的分享都建立在傳統(tǒng)企業(yè)存量環(huán)境中，暫時(shí)不考慮互聯(lián)網(wǎng)企業(yè)。這種假設(shè)的考慮主要基于兩個(gè)方面：
- 本人相對(duì)于傳統(tǒng)行業(yè)更為熟悉
- 傳統(tǒng)企業(yè)的運(yùn)維理念和組織架構(gòu)設(shè)定和互聯(lián)網(wǎng)不同，進(jìn)而導(dǎo)致了運(yùn)維工具架構(gòu)、選擇、以及IT標(biāo)準(zhǔn)化策略等方面的不同
CMDB發(fā)展史
我先簡(jiǎn)要回顧一下十幾年來CMDB的建設(shè)歷程。
2004年
我從04年開始參與國(guó)內(nèi)某銀行的CMDB建設(shè)，這時(shí)CMDB的典型場(chǎng)景是資產(chǎn)信息的電子化。配置信息的采集主要采用Excel導(dǎo)入的方式，CMDB模型需要提前預(yù)設(shè)，不具備動(dòng)態(tài)擴(kuò)展能力，暫且稱之為CMDB1.0。
2006年
到了06年，我在某銀行主導(dǎo)實(shí)施了國(guó)內(nèi)第一個(gè)基于BMC Atrium CMDB架構(gòu)的CMDB項(xiàng)目，這時(shí)的CMDB開始側(cè)重于與其他ITSM (IT Service Management，IT服務(wù)管理 )流程的協(xié)同以及故障、變更影響分析等診斷場(chǎng)景。
但由于配置數(shù)據(jù)的初始化工作仍然需要手工Excel導(dǎo)入，同時(shí)配置信息的更新也不及時(shí)（無法在一個(gè)變更窗口內(nèi)更新完成），導(dǎo)致上層場(chǎng)景沒有發(fā)揮作用。這個(gè)階段我們稱之為CMDB2.0。
2007年
從07年開始，配置自動(dòng)化發(fā)現(xiàn)工具的引入，幫助企業(yè)極大簡(jiǎn)化了配置數(shù)據(jù)初始化工作。
2008年
緊接著，08年左右業(yè)界提出變更閉環(huán)的概念，即在變更結(jié)束后重新進(jìn)行配置自動(dòng)發(fā)現(xiàn)并更新配置信息。相比CMDB2.0階段，配置信息更新實(shí)時(shí)性有一定程度提高。
2012年
12年一些銀行開始嘗試通過配置自動(dòng)發(fā)現(xiàn)工具實(shí)現(xiàn)配置比對(duì)場(chǎng)景，尤其是災(zāi)備與生產(chǎn)環(huán)境配置比對(duì)，以及集群環(huán)境內(nèi)任意兩節(jié)點(diǎn)間的配置比對(duì)。
近幾年
應(yīng)該說，配置自動(dòng)發(fā)現(xiàn)工具一定程度上降低了配置數(shù)據(jù)初始化和維護(hù)的難度，但限于配置自動(dòng)發(fā)現(xiàn)工具的技術(shù)局限，發(fā)現(xiàn)時(shí)間往往較長(zhǎng)，發(fā)現(xiàn)的信息也存在一定盲區(qū)，同時(shí)還需使用root等管理員賬號(hào)，這些約束一定程度上影響了自動(dòng)發(fā)現(xiàn)工具的實(shí)際使用效果。這個(gè)階段我們稱之為CMDB3.0。
云化CMDB時(shí)代
隨著云計(jì)算在10年國(guó)內(nèi)的興起，大約在12年后逐步在大型企業(yè)內(nèi)部落地。落地過程中，我們發(fā)現(xiàn)云化資源的管理是一件比CMDB管理更為棘手的事情。
為此我們幫助國(guó)內(nèi)一些銀行實(shí)施了云化資源管理平臺(tái)，除了管理以往CMDB中常見的物理配置外，進(jìn)一步豐富了LPAR、端口、HBA卡、LV、VG等邏輯配置。這個(gè)階段我暫且稱之為云化CMDB1.0。
從CMDB在國(guó)內(nèi)發(fā)展的歷程看，隨著客戶對(duì)于CMDB認(rèn)知不斷深化，CMDB的場(chǎng)景已經(jīng)從傳統(tǒng)的資產(chǎn)臺(tái)賬管理逐步演化到流程協(xié)同管理、影響分析、配置比對(duì)、云化資源管理等方面，但在CMDB的技術(shù)架構(gòu)上，無論是開源產(chǎn)品還是商業(yè)化產(chǎn)品都沒有一個(gè)明顯的改進(jìn)，發(fā)展比較緩慢。這在一定程度上也影響了CMDB場(chǎng)景的拓展。
為了便于大家有更為直觀的認(rèn)識(shí)，我整理了下表羅列了不同階段CMDB的特點(diǎn)
需要說明的是，云化CMDB2.0是我現(xiàn)階段設(shè)定的一個(gè)目標(biāo)，未來也希望通過開源的方式實(shí)現(xiàn)的一個(gè)項(xiàng)目。
CMDB建設(shè)常見問題
回顧十幾年的CMDB建設(shè)，大家普遍的反映是CMDB建設(shè)很困難，下面我有必要分析一下當(dāng)前CMDB建設(shè)遇到的一些常見問題。
1. 缺乏合理化、整體化的規(guī)劃
需求不清晰，定義了不合理的配置廣度和深度。
在大而全? 還是小而深? 方面猶豫不決：
這種決策機(jī)制在項(xiàng)目初期往往耗費(fèi)了大量時(shí)間，但隨著新技術(shù)的不斷涌現(xiàn)，這種方式已經(jīng)無法適應(yīng)越來越敏捷的IT環(huán)境，我們發(fā)現(xiàn)一種相對(duì)靜態(tài)的CMDB模型已經(jīng)不能滿足納管新IT組件的要求。
如何解決？
用一種更為靈活的CMDB模型擴(kuò)展機(jī)制。
采用了不正確的管控策略：
按照經(jīng)典ITIL的管控和項(xiàng)目實(shí)施機(jī)制，配置管理規(guī)劃，尤其是CMDB模型的規(guī)劃往往由項(xiàng)目組承擔(dān)，一旦規(guī)劃完成后整個(gè)模型也就變得很難再進(jìn)行擴(kuò)展，應(yīng)該說這里采用的是一種集中管控的策略。
但在實(shí)際IT運(yùn)維工作中，我們發(fā)現(xiàn)對(duì)于CMDB使用最多的是各個(gè)二線團(tuán)隊(duì)，不同團(tuán)隊(duì)之間對(duì)于CMDB 深度和廣度的要求，以及管控方式都有較大差別。
如何解決？
基于集中分布式的理念建立CMDB管控體系
2. 配置管理人員職責(zé)定義不清晰
配置經(jīng)理、配置管理員、配置Owner之間職責(zé)不清晰：
按照ITIL或ISO20000中對(duì)于這三類角色的定義往往過于寬泛，沒有進(jìn)一步考慮實(shí)際運(yùn)維人員的運(yùn)維場(chǎng)景，以及使用的運(yùn)維工具，導(dǎo)致職責(zé)定義和實(shí)際做事方式脫節(jié)。
如何解決？
結(jié)合運(yùn)維場(chǎng)景、運(yùn)維工具、流程角色職責(zé)，對(duì)于各角色的職責(zé)進(jìn)行重定義。
角色職責(zé)和崗位的對(duì)應(yīng)不明晰：
在沒有ITIL以前，在企業(yè)IT部門或數(shù)據(jù)中心往往找到不到一個(gè)現(xiàn)成崗位對(duì)于IT配置信息進(jìn)行集中管理，而是每個(gè)人各管一攤。
實(shí)施ITIL后，究竟由哪個(gè)部門的哪個(gè)崗位承擔(dān)配置經(jīng)理這一職責(zé)往往是最讓人傷腦筋的，最后往往是趕鴨子上架。這種角色定義方式最終導(dǎo)致體系無法運(yùn)轉(zhuǎn)。
如何解決？
基于集中分布式的理念設(shè)定角色和崗位的對(duì)應(yīng)關(guān)系
3. 配置管理成了IT運(yùn)維的負(fù)擔(dān)
這其實(shí)是CMDB在企業(yè)落地所面臨的最大挑戰(zhàn)，無法充分調(diào)動(dòng)運(yùn)維人員的積極性，主要體現(xiàn)在：
初始數(shù)據(jù)收集工作量大：
存量的配置數(shù)據(jù)往往基數(shù)很大，一般配置的量級(jí)在5000以上，考慮到云化環(huán)境的海量運(yùn)維場(chǎng)景，這個(gè)基數(shù)還會(huì)更大。
隨著分布式應(yīng)用架構(gòu)以及微服務(wù)架構(gòu)的興起，未來一套新應(yīng)用系統(tǒng)上線引入新的配置項(xiàng)數(shù)量也無法簡(jiǎn)單通過手工輸入的方式來完成。
如何解決？
借助自動(dòng)化手段進(jìn)行數(shù)據(jù)采集
單一的自動(dòng)化配置發(fā)現(xiàn)工具只是一種幻想：
如前所說，約從2007年開始，業(yè)內(nèi)引入了自動(dòng)發(fā)現(xiàn)工具用以解決配置數(shù)據(jù)的初始化問題，但由于這類工具往往由某個(gè)廠商提供，導(dǎo)致了配置發(fā)現(xiàn)的局限性，企業(yè)往往也要付出較大成本。
如何解決？
建立適配多類自動(dòng)化工具的CMDB架構(gòu)，將企業(yè)現(xiàn)有的腳本、監(jiān)控工具、自動(dòng)化工具、云平臺(tái)都轉(zhuǎn)化為配置數(shù)據(jù)的提供方。
投產(chǎn)后由于變更頻繁，數(shù)據(jù)無法保證及時(shí)準(zhǔn)確：
以往企業(yè)一般采用變更操作驅(qū)動(dòng)配置修改（人工修改、或自動(dòng)化發(fā)現(xiàn)修改）的方式以確保配置數(shù)據(jù)的準(zhǔn)確性，這種方式往往出現(xiàn)了配置信息的不一致。
如何解決？
建立基于配置基線驅(qū)動(dòng)的IT環(huán)境變更（操作）架構(gòu)，即建立通過配置修改事件觸發(fā)變更操作的事件響應(yīng)模型。
對(duì)于未來軟件定義環(huán)境，這種架構(gòu)是一種必然選擇。
如何讓人人“樂于”參與：
這里的參與主要體現(xiàn)在二個(gè)方面：
1）需要使用與自己相關(guān)的配置數(shù)據(jù)時(shí)，CMDB可以立即提供；
2）遇到CMDB無法提供的數(shù)據(jù)時(shí)，IT部門可自行在一定標(biāo)準(zhǔn)和約束下擴(kuò)展?jié)M足本部門運(yùn)維CMDB模型，支撐部門級(jí)的運(yùn)維場(chǎng)景。
如何解決？
建立小、快、靈的CMDB架構(gòu)，支撐快速擴(kuò)展、快速納管、快速交付數(shù)據(jù)。
4. 配置數(shù)據(jù)的價(jià)值無法呈現(xiàn)
缺乏清晰的場(chǎng)景定義，包括流程價(jià)值、監(jiān)控價(jià)值、BSM價(jià)值、云價(jià)值等：
單一流程驅(qū)動(dòng)CMDB的場(chǎng)景，無法讓CMDB中的數(shù)據(jù)流動(dòng)起來，隨著時(shí)間的推移CMDB中的數(shù)據(jù)就逐漸腐敗—不及時(shí)也不準(zhǔn)確。
同時(shí)，CMDB在技術(shù)上作為一個(gè)“數(shù)據(jù)庫(kù)”，要讓其中的數(shù)據(jù)能夠流動(dòng)起來，必須明確與之匹配的運(yùn)維場(chǎng)景。
場(chǎng)景是用來描述與CMDB中某些配置項(xiàng)交互的一組活動(dòng)，滿足IT部門某一方面的運(yùn)維管理目標(biāo)，這一目標(biāo)可以被度量、跟蹤、改進(jìn)、可視化，與此同時(shí)，CMDB的價(jià)值也隨之呈現(xiàn)。
如何解決？
建立基于場(chǎng)景驅(qū)動(dòng)的CMDB解決方案集合;
缺乏有效、明確的配置數(shù)據(jù)集成策略：
如前所述，CMDB是一個(gè)邏輯上的數(shù)據(jù)庫(kù)，其中的數(shù)據(jù)需要和企業(yè)現(xiàn)有IT環(huán)境中的多類數(shù)據(jù)源進(jìn)行整合，一套行之有效的數(shù)據(jù)集成策略和ETL（數(shù)據(jù)抽取、轉(zhuǎn)換、轉(zhuǎn)載）工具也必不可少。
如何解決？
建立數(shù)據(jù)集成策略，引入ETL。
通過以上分析，我們回顧了CMDB的歷史發(fā)展過程，以及建設(shè)過程中遇到的挑戰(zhàn)。接下來我們看看云化環(huán)境下CMDB又將面臨什么新問題。
云化時(shí)代的特點(diǎn)以及帶來的挑戰(zhàn)
應(yīng)該說動(dòng)態(tài)變化是云化環(huán)境下最大的挑戰(zhàn)，無論對(duì)于配置模型還是配置數(shù)據(jù)的更新都提出了全新要求。我們勢(shì)必不能再參考現(xiàn)有CMDB產(chǎn)品架構(gòu)去定義或滿足云化CMDB的要求。
對(duì)于互聯(lián)網(wǎng)或互聯(lián)網(wǎng)業(yè)務(wù)而言，海量會(huì)是一個(gè)比較大的問題，這里的關(guān)鍵可能不是海量存儲(chǔ)的問題，而是如何在海量配置信息中快速配置定位、查找和可視化。
對(duì)于傳統(tǒng)企業(yè)而言，異構(gòu)永遠(yuǎn)是首要解決的問題，針對(duì)這個(gè)特點(diǎn)，以往廠商提出過聯(lián)邦的技術(shù)，但一直沒有找到可行的落地方法。這里我嘗試借助類似于ETL的機(jī)制，實(shí)現(xiàn)多數(shù)據(jù)源的整合。
云化CMDB應(yīng)具備的典型特征和范式
下面我們進(jìn)入今天討論的第三部分：云化CMDB應(yīng)具備的典型特征和范式
在云化時(shí)代，CMDB需要從原有的單一工具轉(zhuǎn)變?yōu)橐环N企業(yè)IT服務(wù)能力，即CMDB As A Service（以下為了便于敘述，使用云化CMDB代替）。
云化CMDB：是指 CMDB消費(fèi)者可以通過網(wǎng)絡(luò)隨時(shí)隨地獲取、維護(hù)、管理CMDB。
服務(wù)要素
如IaaS中服務(wù)要素是指IT基礎(chǔ)架構(gòu)，在云化中的服務(wù)要素包括三個(gè)層面：
配置模型：用以描述CMDB的深度和廣度，在技術(shù)上體現(xiàn)為一組配置標(biāo)簽（如服務(wù)器、網(wǎng)絡(luò)、應(yīng)用等，或生產(chǎn)環(huán)境、測(cè)試環(huán)境等）、與配置標(biāo)簽相關(guān)聯(lián)的配置對(duì)象、以及用于描述配置對(duì)象的屬性集合。
配置模型是用以描述配置項(xiàng)的元數(shù)據(jù)，其描述了某一配置項(xiàng)應(yīng)該具備的屬性，以及該配置項(xiàng)與其他配置項(xiàng)之間的邏輯關(guān)系，以及與配置項(xiàng)相關(guān)的一組操作。
配置項(xiàng)：用以描述某一配置對(duì)象的具體實(shí)例。如對(duì)于Server這個(gè)配置對(duì)象，其具體的IT環(huán)境中可能表現(xiàn)為IBM Server01，IBM Server02，IBM Server03等服務(wù)器實(shí)例。
配置項(xiàng)的關(guān)聯(lián)操作：這個(gè)層面是對(duì)ITIL的補(bǔ)充。操作用來描述某個(gè)配置項(xiàng)在實(shí)際特定的IT環(huán)境中允許進(jìn)行的一組行為集合。
舉例來說，對(duì)于IBM Server01配置項(xiàng)來說，可能有的操作包括啟動(dòng)、停止；對(duì)于比較復(fù)雜的應(yīng)用系統(tǒng)APP 01來說，可能有的操作就包括啟動(dòng)、停止、重啟、配置等。
如果說配置項(xiàng)屬性是對(duì)配置項(xiàng)的靜態(tài)描述，那么配置項(xiàng)操作就是對(duì)配置項(xiàng)的動(dòng)態(tài)描述，其描述了消費(fèi)者可以對(duì)當(dāng)前配置項(xiàng)施加的動(dòng)作。
上述服務(wù)要素并不能單獨(dú)存在，這就像數(shù)據(jù)庫(kù)管理系統(tǒng)中的數(shù)據(jù)一樣，在沒有被業(yè)務(wù)系統(tǒng)使用前，都只是一堆0和1組成的數(shù)據(jù)，必須放到某個(gè)特定的上下文中才具備其特定的含義。
這里說的業(yè)務(wù)系統(tǒng)其實(shí)說的就是場(chǎng)景。配置場(chǎng)景描述CMDB與某個(gè)具體運(yùn)維活動(dòng)或業(yè)務(wù)活動(dòng)之間的關(guān)系，在一個(gè)場(chǎng)景中可能同時(shí)觸發(fā)一組關(guān)聯(lián)操作。
在沒有JDBC或ODBC標(biāo)準(zhǔn)接口前，存放在數(shù)據(jù)庫(kù)管理系統(tǒng)中的數(shù)據(jù)只能通過特定的數(shù)據(jù)庫(kù)管理平臺(tái)才能進(jìn)行增、刪、查、改操作，這種方式嚴(yán)重制約了數(shù)據(jù)庫(kù)中的數(shù)據(jù)對(duì)外提供服務(wù)和消費(fèi)，給業(yè)務(wù)系統(tǒng)的開發(fā)帶來了極大的不便利性。
同理，在CMDB As A Service理念中，我們也需要通過把服務(wù)要素API化，將CMDB的服務(wù)能力真正暴露出去，以便于場(chǎng)景進(jìn)行調(diào)用。
CMDB API與服務(wù)要素一一對(duì)應(yīng)，包括三個(gè)層次：
- 配置模型的增、刪、查、改（類似于DML）；
- 配置數(shù)據(jù)的增、刪、查、改；配置項(xiàng)關(guān)系建立、移除（類似于DDL）；
- 配置操作的增、刪、查、改；并建立配置操作與特定的IT運(yùn)維自動(dòng)化工具的關(guān)聯(lián)（包括腳本、專業(yè)自動(dòng)化運(yùn)維工具、云平臺(tái)、監(jiān)控平臺(tái)等等）；
注：其實(shí)Puppet、Chef在架構(gòu)上已經(jīng)采取了類似的理念，這里我們希望再往上抽象一個(gè)層次
通過上述要素的組合，我給出云化CMDB的定義：
云化CMDB=模型 操作 數(shù)據(jù) API 場(chǎng)景
云化CMDB的基本架構(gòu)
下面我們進(jìn)入今天分享的最后一部分內(nèi)容：云化CMDB的基本架構(gòu)。
整個(gè)云化CMDB平臺(tái)自下而上分為四個(gè)層次，分別是：
系統(tǒng)管理層：該層為系統(tǒng)的使用提供了最基本的支持，包括組織、人員、角色、權(quán)限的管理。支持定義各類角色和權(quán)限的管理，有完整的角色管理和權(quán)限管理功能，權(quán)限配置支持組嵌套。并通過與外部IT管理云平臺(tái)集成實(shí)現(xiàn)用戶的統(tǒng)一認(rèn)證功能
CMDB服務(wù)要素層：按照云化CMDB的理念，服務(wù)要素包括模型、數(shù)據(jù)和操作，與之對(duì)應(yīng)的分別是模型維護(hù)、配置項(xiàng)維護(hù)和操作維護(hù)功能。
API層：通過封裝底層CMDB服務(wù)要素層的功能要素，對(duì)外提供模型管理API、配置項(xiàng)管理API和操作API
場(chǎng)景層：場(chǎng)景層采用了一種可擴(kuò)展的方式進(jìn)行設(shè)計(jì)，CMDB ETL和配置可視化是CMDB的兩個(gè)基本場(chǎng)景：
場(chǎng)景一：其中CMDB ETL主要實(shí)現(xiàn)對(duì)于多外部配置數(shù)據(jù)源的數(shù)據(jù)抽取、轉(zhuǎn)化和處理，并將處理的結(jié)果通過API層的配置項(xiàng)API進(jìn)行數(shù)據(jù)錄入，并記錄配置數(shù)據(jù)的變化，建立配置基線，并圍繞基線形成基線比對(duì)等功能；
場(chǎng)景二：配置可視化主要針對(duì)配置數(shù)據(jù)提供一種展示（圖形、聲音、文字等）手段，包括配置拓?fù)湔宫F(xiàn)（以圖形化方式展現(xiàn)配置項(xiàng)間的關(guān)聯(lián)關(guān)系）、配置項(xiàng)多維度查詢、配置報(bào)表以及預(yù)警功能。
除了基本場(chǎng)景外，開發(fā)人員可以通過API層的功能，并結(jié)合基本場(chǎng)景實(shí)現(xiàn)自定義場(chǎng)景，比如在本次項(xiàng)目中實(shí)現(xiàn)架構(gòu)標(biāo)準(zhǔn)配置比對(duì)功能就是一種基于配置比對(duì)功能基礎(chǔ)上的新場(chǎng)景應(yīng)用。
除了以上層次，平臺(tái)提供了CMDB管理門戶的GUI界面，便于系統(tǒng)管理員和配置管理相關(guān)用戶對(duì)于模型、配置項(xiàng)進(jìn)行維護(hù)、查詢。
目前已經(jīng)參考上述架構(gòu)啟動(dòng)開源云化CMDB項(xiàng)目，并實(shí)現(xiàn)了模型動(dòng)態(tài)擴(kuò)展，模型/配置數(shù)據(jù)API、配置基線、配置比對(duì)、ETL和可視化場(chǎng)景，預(yù)計(jì)7月份開源第一個(gè)版本。
今天就分享這些內(nèi)容，請(qǐng)大家多多指教！謝謝大家！還有一些具體細(xì)節(jié)，今天由于時(shí)間的原因就不展開了，歡迎具體探討。
精彩互動(dòng)
Q1：云平臺(tái)下運(yùn)維與傳統(tǒng)運(yùn)維的最大差異包括哪個(gè)方面？從而導(dǎo)致運(yùn)維平臺(tái)進(jìn)入一個(gè)新的發(fā)展時(shí)期。
A：云化環(huán)境下最大的挑戰(zhàn)是配置信息的動(dòng)態(tài)變化，以往在配置手工更新往往需要幾個(gè)小時(shí)甚至幾天時(shí)間，等更新后其實(shí)CMDB中已經(jīng)是臟數(shù)據(jù)了。
Q2：海量配置對(duì)比的實(shí)現(xiàn)原理和準(zhǔn)確性程度如何？
A：基本思路是將數(shù)據(jù)庫(kù)記錄級(jí)比對(duì)（傳統(tǒng)CMDB技術(shù)實(shí)現(xiàn)）轉(zhuǎn)變?yōu)槲谋炯?jí)比對(duì)。比對(duì)過程中可以識(shí)別新增、修改、刪除屬性、配置項(xiàng)等信息。
Q3：如果已經(jīng)有一個(gè)偏資產(chǎn)管理流程數(shù)據(jù)的cmdb了，那么想用這個(gè)云化cmdb思路落地是不是只能重構(gòu)了？
A：是。
Q4：配置主動(dòng)發(fā)現(xiàn)這個(gè)最重要。怎么去區(qū)分邏輯屬性，物理屬性，動(dòng)態(tài)屬性，靜態(tài)屬性，關(guān)聯(lián)配置項(xiàng)目，怎么與資產(chǎn)關(guān)聯(lián)？
A：應(yīng)該說配置主動(dòng)發(fā)現(xiàn)采用的是一種輪詢查找機(jī)制，我希望在新的云化CMDB中采用的思路是配置事件驅(qū)動(dòng)的模式進(jìn)行配置更新。
比如在IaaS中，我們要申請(qǐng)一臺(tái)VM，在申請(qǐng)的過程中已經(jīng)收集了VM相關(guān)信息，以及安裝的數(shù)據(jù)庫(kù)、中間件實(shí)例等配置信息，從這個(gè)例子中我們發(fā)現(xiàn)變更-配置更新是一體的，也就不需要配置自動(dòng)發(fā)現(xiàn)工具。
當(dāng)然在實(shí)際環(huán)境中，我們要兩者結(jié)合。配置自動(dòng)發(fā)現(xiàn)工具也不局限于特定的如ADDM、TADDM這類工具，可以擴(kuò)展到監(jiān)控、腳本等工具。
Q5：cmdb etl如何解釋？我知道etl但和cmdb一起完全沒有概念，請(qǐng)解釋，謝謝！
A： CMDB從本質(zhì)來說就是一個(gè)數(shù)據(jù)庫(kù)，我們要解決的是如何允許多個(gè)外部數(shù)據(jù)源同時(shí)錄入配置數(shù)據(jù)，那么數(shù)據(jù)源之間會(huì)出現(xiàn)沖突，這就需要一個(gè)合理的技術(shù)去解決。
ETL其實(shí)在數(shù)倉(cāng)里應(yīng)用多年，我們完全可以借鑒過來加以利用。這個(gè)方案在三個(gè)大行已經(jīng)得到了應(yīng)用。當(dāng)時(shí)我們用的是Kettl。
Q6:怎么區(qū)分模型還是場(chǎng)景？
A：模型其實(shí)簡(jiǎn)單說就是數(shù)據(jù)庫(kù)的表結(jié)構(gòu)，場(chǎng)景其實(shí)就是使用數(shù)據(jù)庫(kù)的應(yīng)用程序。
Q7:我覺得cmdb到后面就是個(gè)aws的json格式的api接口，殊途同歸，不曉得老師怎么看？
A：這個(gè)問題比較有意思，從接口的發(fā)展趨勢(shì)看，類似于RestFul的API目前已經(jīng)是事實(shí)標(biāo)準(zhǔn)，在云化CMDB中所有API也將通過這種方式提供。
Q8：例如不管是阿里云還是aws，所有的運(yùn)維活動(dòng)都是圍繞資源天然集成，似乎已經(jīng)失去了傳統(tǒng)環(huán)境下配置驅(qū)動(dòng)流程的意義了？
A：這個(gè)是個(gè)好問題。一個(gè)非常有意思的是無論是AWS、還是Openstack都沒有集中存放配置的管理組件。
前不久，AWS發(fā)布了AWSConfig，這個(gè)組件其實(shí)就是負(fù)責(zé)AWS上所有配置信息的集中管理，并已經(jīng)和20多個(gè)軟件廠商實(shí)現(xiàn)了整合，同時(shí)我們Netflix上也看到了類似的項(xiàng)目。
所以，答案已經(jīng)比較明顯了，配置管理的這類需求還很普遍。
Q9：在云環(huán)境下，資源都是服務(wù)，運(yùn)維服務(wù)和資源服務(wù)天然的聯(lián)動(dòng)集成，我個(gè)人感覺云環(huán)境下cmdb的功能更多是一個(gè)ci全景的可視查詢，還有其他場(chǎng)景嗎？
A：可視查詢是從配置消費(fèi)角度看到的一個(gè)典型場(chǎng)景，從配置提供的角度看，由于云化環(huán)境涉及了計(jì)算、網(wǎng)絡(luò)、存儲(chǔ)虛擬化，以及大量自動(dòng)化運(yùn)維工具，因此比較復(fù)雜的是配置數(shù)據(jù)提供場(chǎng)景。例如，如何在一個(gè)VM的交付過程中，實(shí)時(shí)的更新配置信息。
Q10：cmdb在建設(shè)初期怎么發(fā)揮價(jià)值？或者說，如何在運(yùn)維工作中發(fā)揮更大作用，而不只是一個(gè)電子臺(tái)帳？
A：
- 建立場(chǎng)景驅(qū)動(dòng)理念，確保配置數(shù)據(jù)有人去使用；
- 通過技術(shù)手段提升配置數(shù)據(jù)的自動(dòng)化率，確保CI項(xiàng)中的屬性絕大多數(shù)都能被某種自動(dòng)化工具覆蓋。
Q11：請(qǐng)問下CMDB里的數(shù)據(jù)準(zhǔn)確性是怎么保證的？
A：非云化環(huán)境，一般通過事后審計(jì)的方式，識(shí)別有問題的配置項(xiàng)，然后進(jìn)行手工修正。
云化環(huán)境，由于環(huán)境都是軟件定義的，基礎(chǔ)架構(gòu)的變更和配置更新是同時(shí)發(fā)生的，理論上來說CMDB中的數(shù)據(jù)是云化環(huán)境的快照。今天分享的內(nèi)容主要側(cè)重在云化環(huán)境。
Q12:邏輯關(guān)聯(lián)信息，可以定義嗎？如何進(jìn)行關(guān)聯(lián)關(guān)系的維護(hù)？
A：這個(gè)問題涉及模型定義問題。如果你有Puppet和Chef的經(jīng)驗(yàn)，我們就可以看到這種關(guān)系的定義。關(guān)系是一種特殊的CI屬性，在設(shè)計(jì)時(shí)，必須確?？梢酝ㄟ^自動(dòng)化工具提供數(shù)據(jù)。
在實(shí)際項(xiàng)目中，我們會(huì)形成上面的兩個(gè)表格。
Q13：如何將cmdb1.0和2.0合并在一起實(shí)現(xiàn)？自動(dòng)發(fā)現(xiàn)配置方面有沒有成型的解決方案？
A：上面只是處于表述的原因，將CMDB分為1.0和2.0，從實(shí)現(xiàn)角度看是可以同時(shí)考慮的。自動(dòng)發(fā)現(xiàn)配置方面常見的商業(yè)方案有BMC ADDM和IBM TADDM，開源的暫時(shí)沒有找到類似的解決方案，一般功能都比較散。
Q14:老師,你好.能講講你們Apache kylin主要拿來做什么嗎？
A：可參考http://www.oschina.net/p/kylin-olap
