配置管理資料庫

出自 MBA智库百科(https://wiki.mbalib.com/)

配置管理資料庫(Configuration Management Database,CMDB)

　　配置管理資料庫是指這樣一種資料庫，它包含一個組織的IT服務使用的信息系統的組件的所有相關信息以及這些組件之間的關係。配置管理資料庫提供一種對數據的有組織的檢查和從任何想要的角度研究數據的方法。

　　配置管理資料庫的作用在於：用來收集所有與配置有關的信息；用來評價系統變更的效果；用來為配置管理過程提供管理信息。而根據配置管理資料庫的不同應用，可以分為以下3種。

　　(1)開發庫：它是指專門供給開發人員使用，裡面存儲的信息可能會作頻繁的修改，而且對其控制也相當寬鬆。主要是為了更好地適應開發人員日常工作的需要。

　　(2)受控庫：是指在生存期某一階段工作結束後發佈的階段性產品，通常包括人工製品和機器可讀信息{源代碼、可執行文件等)。由於軟體配置管理的關鍵也正是對受控庫中的各個軟體項進行管理，因此受控庫也通常稱之為軟體配置管理庫。

　　(3)產品庫：是指開發的軟體產品已經通過了系統測試後使用的配置管理資料庫。它通常存放的是最終產品，等待交付用戶或現場安裝的產品。

　　1)確定配置管理的範圍

　　建立配置管理資料庫，首先要考慮的是IT基礎架構中哪些信息需要納入配置管理的控制、配置項的寬度和深度，以及配置項的生命周期。

　　配置管理流程作為IT服務的支持流程，IT服務本身也可以作為配置項記錄在配置管理資料庫中，配置管理資料庫與組織IT服務管理水平密切相關。一方面組織的服務管理水平不斷提高，需要配置管理資料庫為之提供更詳細、更準確的配置項信息，對配置管理資料庫的管理要求也隨之提高；另一方面，配置項的廣度的擴大會造成IT成本的增加，深度的加深又會給IT管理帶來一定的難度，因為組織海量級的配置項信息需要實時性和準確性才能對業務服務有所幫助，否則就很難體現出配置管理資料庫的價值。所以組織應該從IT服務需求和配置管理資料庫成本平衡角度出發，選擇一個能夠為業務提供所需基礎信息又能將IT管理投資最小化的適合組織發展的配置管理範圍。

　　配置項的生命周期應該從採購申請開始到報廢銷毀結束。所以組織需要確定一個配置項信息被記錄到配置管理資料庫和從配置管理資料庫中被刪除的時間點，為配置管理審計提供支持。

　　2)配置管理資料庫基線

　　配置管理資料庫的信息由配置信息基線和變更集組成，基線備份分為兩種：

　　·基於資料庫的定期備份

　　制定備份策略，備份代理定期或者適時連接備份伺服器，將配置管理資料庫備份到備份伺服器上的備份庫中。作為某個特定時刻配置管理資料庫狀態的快照，當配置信息遭到破壞或丟失時，配置管理資料庫可以恢復到故障前最近的完整狀態，提高系統資源的安全性和抗毀性，將災難帶來的損失降到最低。

　　·基於變更內容的備份

　　對配置項的修改來自於變更任務，在每次實際修改過程中，自動備份配置項的修改前內容，作為變更前版本，修改後內容作為配置項的當前值，保障配置項歷史信息的回溯和查詢。

　　3)確定配置項的顆粒度

　　配置管理資料庫能否為業務服務提供良好的支持，很大程度上取決於配置項的詳細程度，組織應該制定所有配置項分類的顆粒度範圍，配置項顆粒度太粗會導致配置管理資料庫無法為其他流程和業務服務提供支持，同時會影響到配置項之間的關聯關係。舉例來說，如果網路設備中以一個交換機為配置項，當交換機上的某一個埠發生故障時，無法立刻定位影響到哪套信息系統，只能說和這台交換機有關的業務可能都受到了影響，這就無法體現配置管理資料庫的價值所在。但是配置項顆粒度如果太細，就會造成配置管理資料庫管理人員的巨大壓力，會大大增加IT運維成本。就剛纔的例子來說，如果反之網路設備的配置項細化到每個交換機的埠都是一個配置項，那麼當它發生故障時，的確能夠很快根據配置管理資料庫中的信息定位到受影響的業務系統，並且能夠確定影響程度和範圍，但是一個組織若有上百台甚至上千台的交換機，每天僅埠信息的修改就會給組織的人力、物力帶來很大的壓力。所以如何定義配置項的顆粒度對於配置管理資料庫的使用和價值體現都起著決定性的作用。

　　4)確定配置項的屬性內容

　　一個配置項的屬性內容決定了它能為其他流程服務提供的具體信息，但是一個配置項的屬性可能有成百上千個，選擇找到適合配置項自身需求的屬性、最有用的信息，就能夠大大降低維護信息的成本。一個配置項屬性的定義要具備面向服務的特性。例如一臺伺服器有很多屬性，但是可能對於某個組織來說，只有IP地址、記憶體、CPU等信息是有實際意義的。

　　5)建立配置項之間的關聯關係

　　配置項的關聯關係對於處理事件、問題，確定變更的影響範圍和程度以及對服務可用性的預測起著很大的幫助作用。配置項之間的關聯關係可以分為四種，屬於、包含、對應和連接。組織可以採用兩種方式對配置項關聯關係進行整理，第一種方式是自上而下的方式，即按照“業務服務→IT服務→IT系統→IT組件”的模型定義配置項關聯關係，這種模式的優點在於以業務為主線能夠快速建立起所需要的配置項關聯關係模型，但是很難建立完整的配置管理資料庫。另一種方式是自下而上的模式，即先建立組織內部的所有配置項和配置項關係，然後逐步映射到相應的業務服務。這種模式的優點在於能夠建立全面的配置管理資料庫，為配置管理日後發展打下扎實的基礎，但是建立周期較長，企業會在配置項的建立上花很多的時間。

　　6)配置項狀態

　　配置項的狀態共分為以下四種。

　　·新申請狀態：當對於新增配置項的變更請求還未經過評估和批准，需要在配置管理資料庫中記錄該新增配置項時，其狀態為“新申請”。

　　·準備狀態：新增配置項的變更請求已經經過評估和批准，但是配置項還未投入正常使用，其狀態為“準備”。

　　·運行狀態：配置項在正常使用，其狀態可置為“運行”。

　　·報廢：當配置項已經被撤銷，不會再使用時，將狀態置為“報廢”。

　　7)配置項的命名規範

　　每個配置項都應該有唯一的配置項編號，建議組織在制定配置項命名規範時，能夠充分考慮編號的可擴展性和易記性，同時從編號中能夠反映一部分的配置項信息和關聯關係信息，為配置項管理員提供幫助。

　　8)配置項和流程的關聯

　　變更、事件、問題管理流程都會牽涉到配置項的更新，同時配置項信息也為IT服務管理流程提供幫助，這就需要配置項能夠和這些流程緊密結合。

　　一個高效、好用的配置管理資料庫(Configuration Management Database，CMDB)需滿足以下6條重要標準，即聯合、靈活的信息模型定義、標準合規、支持內置策略、自動發現和嚴格的訪問控制。

　　車輛製造商、大型零售商、銀行這些全然不同的企業之間有什麼共同之處？答案就是它們都需要IT，或者更準確地說，它們都要遵循IT基礎架構庫(ITIL)服務管理的最佳實踐，採用自動化IT管理解決方案以實現重要的業務目標，包括減少服務中斷、降低成本、提高IT效率、促進法規遵從等。

　　實施ITIL最佳實踐的核心就是配置管理資料庫(CMDB)。CMDB將IT基礎架構的所有組件儲存為配置項，它不僅能維護每個配置項的詳細數據，而且能維護各配置項之間的關係數據。同時，CMDB還能維護各配置項中包括其事件和變更歷史在內的管理數據。通過將這些數據整合到中央存儲庫，CMDB可為企業瞭解和管理數據類型之間的因果關係提供保障。更為關鍵的是，CMDB可實現IT服務支持、IT運維及IT資產管理內部及三者之間的流程整合與自動化，為業務服務管理(BSM)這全面、統一的IT運行平臺奠定堅實基礎。

　　業內普遍認為，一個精心架構的CMDB能為IT部門奠定堅實的基礎，提高服務基礎架構的透明度、可靠性以及可控性，並能自動化服務的配置管理，同時確保IT運維持續遵從企業政策、政府法規、行業標準和最佳實踐。當然，為實現這種高水平的集成度和自動化，CMDB需滿足以下六條重要標準，即聯合、靈活的信息模型定義、標準合規、支持內置策略、自動發現和嚴格的訪問控制。

　　聯合

　　CMDB提供IT環境的單一、準確的信息源，因此，可以將它看做是一個記錄IT基礎架構數據的中央存儲庫。但是，將所有基礎架構信息存放在一個資料庫中很難實現，因為基礎架構的類型、各類元素類型及管理數據的類型種類繁多，且各數據類型中也存在著不同的粒度水平。比較可行的方法是將各個CMDB和其他的數據存儲統一到ITIL所定義的配置管理系統(CMS)中。這樣，根據IT基礎架構和運維管理的不同功能所創建的各個CMDB數據集將共同形成一個整體的企業CMDB。

　　統一多個數據存儲需要採用一種聯合的方法，並且在創建企業CMDB架構時就需設計考慮到這種聯合方法，而不能事後補入。建立在聯合架構中的CMDB能接入廣泛的信息，而無需將所有數據移動或複製到CMDB中。為確保該方法有效實行，整體企業CMDB中的各個數據存儲必須清晰地隸屬於不同的功能領域，且滿足數據交換、數據核實和數據訪問三方面要求。

　　比如，在一家大型服裝零售店裡， CMDB存儲了IT環境的基本信息，併為其他關鍵、詳細的數據存儲提供索引。配置項關係和管理信息使工作人員能夠將資產與事件和問題相關聯，理清事件之間的相互關聯信息，從而能從根源上分析事件和問題產生的原因。通過聯合方法，CMDB向工作人員提供所需信息，讓他們更有效地管理資產生命周期。這將有助於確保企業不會浪費資金，繼續支持維護歷史遺留系統。

　　採用聯合方法的一項關鍵要求是具備強大的數據整合能力，以確保多源數據的準確性和一致性。數據整合不僅能消除重覆數據，使各部分有且僅有一個配置項，還能確保多源數據連接到正確的配置項。

　　靈活的信息模型定義

　　CMDB信息模型有兩種不同的方式。一種是自上而下，即先有一個巨集觀的企業視圖，然後在CMDB中為該視圖部署一個元數據模型，然後確保所有管理應用程式符合元數據模型。另一種方式是自下而上，即把低層的數據集進行標準化，依此開發元數據模型。

　　大多數IT機構會選擇自下而上的方式。因為採用這種方式，現有的管理數據集能輕鬆地併入元數據模型中，減少部署工作，加快產生價值。由此產生的元數據模型與具體的管理功能和應用無關，因而比實際的低層次數據集更易操控，而那些低層次數據集則受制於具體應用所引發的具體管理功能。自下而上方式的另一項優點在於它更易被接受，因為與自上而下的方法不同，它無需破壞企業的組織架構和文化。精心架構的CMDB可同時支持這兩種方式，滿足IT要求並提供部署CMDB所需的IT靈活性。

　　標準合規

　　聯合架構包含多個CMDB，也就意味著出現多個數據集，因此必須實現各個CMDB之間及數據集之間的互操作性。這就需要標準化的數據交換機制，以確保數據準確，保護數據安全，實現有控制的訪問。所以，CMDB架構需在網路服務方面支持如XML和SOA等開放標準。通過標準支持，可實現不同數據存儲之間的相互操作，同時確保數據不違反IT部門為其企業CMDB開發的元數據定義的整體性。

　　支持內置策略

　　精心架構的CMDB可以涵蓋策略、記錄服務及服務相關輔助組件的創建、更新、實施、持續合規追蹤等環節中用到的標準。這些服務可以是應用、中間件、系統可用性、資料庫、網路設備和操作系統等。服務相關輔助組件可以是網路伺服器、資料庫伺服器、應用伺服器、網路設備、客戶機等。標準中必須包括數據集的詳細信息，如配置、安裝、性能和運行時間。策略可能是動態的，並且可能因時間、用戶數和服務水平協議(SLA)等因素而變動。

　　精心架構的CMDB還可包括流程模型。由於IT環境通常隨時間變化而發生變更，因此這些流程模型必須也是動態的，以自動適應這些變更。

　　由於能夠包含策略和流程模型，CMDB在基於策略的流程自動化中發揮著十分重要的作用。這種自動化能大幅加快流程執行，同時執行最佳實踐流程應用。例如，一家專註於卡式支付交易服務、電子支付系統和國際金融信息的基礎架構服務供應商應用了CMDB之後表示，CMDB可以幫助IT部門在極短時間內高質量高水平地執行所有發佈、變更和SLA管理等主動的、前瞻性的流程。

　　自動發現

　　CMDB需自動發現IT基礎架構中的所有資產及其詳細信息、各項資產之間的物理和邏輯關係，以及資產與其支持的服務之間的關係。聯合方法可以支持自動發現，因為該方法能獲得基礎架構中任何一項組件的詳細信息。

　　已經有一些領先的企業選擇了自動化工具來發現IT環境中的配置項並將其反饋到CMDB，這些工具還能捕捉組件之間的邏輯依賴關係，並識別哪些IT組件包含企業應用。

　　傳統上，IT利用自動發現功能快速傳播庫存信息。最新一代的自動發現方案還可定期掃描IT環境，提供特定組件在不同時間點的實時配置信息。對於任何針對組件及其支持的服務所進行的分析而言，實時發現加之按時間順序產生的一系列實時信息，將有著十分重要的意義。

　　嚴格的訪問控制

　　在IT領域，未經授權或未預料到的訪問和變更會導致服務中斷或宕機。因此，安全和訪問控制在CMDB設計和部署中發揮著必不可少的作用。訪問政策可用於用戶和工作群創建資料介紹和訪問控制。

　　CMDB必須符合安全標準，以防止對數據集執行任何未經授權的變更。這些標準可以通過目錄進行歸檔，以確定各個數據集的各自授權訪問人員，以及訪問人員的數據集操作許可權。CMDB具有這種內置的、基於角色的訪問控制之後，就可以通過目錄訪問許可權來實現用戶身份驗證。

　　為了確保CMDB項目實施的成功，防止不必要的項目拖延，企業在實施配置管理資料庫（CMDB）時應該有一些預防措施，本文提出了6個方面的缺陷，企業在實施CMDB時應該極力避免。

　　缺陷1:不能識別CMDB的目標和收益

　　CMDB管理著企業環境內的眾多配置項及其關係，這些配置項可以是服務、軟體、硬體、系統、操作系統、應用程式、資料庫、流程文檔、安全文檔、網路組件等。

　　在不同的企業之內，這些特定的配置項的重要性是不同的。CMDB不能也不應該管理企業內的每個資產、文檔或流程。每一個企業都不應該對自己的配置項的特定目標和利益視而不見。

　　如果知道CMDB如何應用，比如理解變更的影響，就可以基於CMDB購買和實施的成本，對項目的目標進行成本－利益分析和衡量。清楚地定義短期目標和長期規劃，對於CMDB項目的初期開展很關鍵。如果不能合理地定義目標和量化投入產出比（ROI），你的方案就很難得到管理層的同意。

　　缺陷2:讓CMDB成為一個元數據的傾銷庫

　　為了獲得最大的業務價值，要認識到CMDB中什麼可以管理與什麼應該管理兩者之間的區別。一些企業在發起實施CMDB時，有時候會不加區別地將所有來自配置項（CI）倉庫的數據全部輸入到CMDB，而未能進行充分地關係文檔化或者是對配置項的變化進行管理。

　　CMDB應該只包含那些計劃將要積極去管理的配置項。如果將所有的數據都倒入CMDB之中，沒有一個規劃，企業就會身處一個難以管理且價值不大的知識庫之中。

　　缺陷3:忽視變更管理的需要

　　如果沒有一個有效的變更管理流程，CMDB將很快就會與現實不同步。因此，CMDB和配置管理流程必須與變更管理流程緊密結合在一起。只有經過認可的變更可以進入CMDB，只有作為變更請求（RFC）的一部分的配置項才能進行更新。如果不能滿足這些要求，CMDB的實施將會陷入一個向下的螺旋，直至失敗。

　　缺陷4:不能獲得利益相關者的支持

　　CMDB實施在企業之內會有很多接觸點。與配置項相關財務、能力和可用性等屬性都要求從分離的不同部門輸入，如果關鍵的利益相關者從一開始就沒參與，如果他們不能得到CMDB能為組織交付的真正價值，那麼要讓他們支持一個包含所有必要的屬性和關係的CMDB的建設會很困難。

　　因此，在CMDB項目的開始，就要努力獲得關鍵的利益相關者的支持。要向他們表明，CMDB將會使得他們持續不斷地改善相關指標和關鍵績效指標（KPI），這樣你就能得到所有相關方面的支持。

　　缺陷 5: 難以更廣泛地實施

　　在項目開始之初就能對其進行有效的引導和控制，比如說一個被清楚定義的業務服務的實施，這對於項目的成功是關鍵的。首先要確定支持業務服務的配置項，如應用伺服器、網路伺服器、路由器、資料庫和資料庫伺服器等，然後就要確定在這些配置項之間存著什麼類型的關係，比如說是“依托運行”、“主機”、“連接”、“管理者”等。這些關係有助於理解和降低與組成服務的配置項的變更相關的風險

　　一旦CMDB按照這樣的做法初步成功實施，企業就可以考慮擴展項目的範圍，以一種有效且高效率的方式來管理更多的配置項。這種漸進的方法可以讓企業迅速地實現價值，同時還會獲得進行更廣泛實施所需要的經驗。

　　缺陷6：在流程和培訓的投入上吝惜

　　CMDB的成敗取決於使用和維護它的人，如果這個人沒有經過合理使用和維護流程的培訓，那麼，CMDB將會是低效的，其中的內容很快就會變得過時和不准確。正確的培訓也有助於確保一個成功的實施，以及一次值得付出的投資。

　　能夠避免以上六個方面錯誤的企業將會安全地完成CMDB的實施，並提高成功的可能性。這意味著他們能以更低的成本為業務提供所需要的服務，同時還能確保這些服務在一個符合要求的績效水平上運行。