CMDB:ITSM的必需—配置管理數據庫構建過程拆解

在IT管理向ITSM(IT服務管理)體系演進的征途中,CMDB(配置管理數據庫)從傳統的電子報表中走來,蛻變爲基於ITIL最佳實踐的IT服務管理核心。對於所有的ITSM體系的建設者而言,CMDB都是一部龐大機器上必須精心打磨與調試的一個關鍵部件。

   “水域,這是俄羅斯的必需!”彼得大帝的慨嘆表達了一個民族對海洋的渴望。而在獲得了出海口之後,封閉的俄羅斯終於打開了通往文明歐洲的窗口,走上富強之路。CMDB之於ITSM,或許遠不如十六世紀海洋對於俄羅斯如此那般的迫切。但是在今天的IT管理領域,CMDB在完整的ITSM系統中的核心地位絕對無可替代。今天,CMDB不僅是管理軟件廠商和ITIL倡導者常掛嘴邊的時髦詞彙,也早已成爲企業用戶在IT管理項目推進中的關注焦點。

“通過更先進的資產管理和自動化流程,幫助用戶建立跨系統的數據管理關聯,從而最終推動跨功能的流程整合”是CMDB對用戶的承諾。而在闡述CMDB現階段的定義之前,必須說明的是,CMDB並不是IT管理領域的新生事物或名詞。從誕生至今,CMDB經歷了三次脫胎換骨的技術蛻變。實際上,早期的許多管理軟件中都包含了現代CMDB的雛形,它們以電子報表的形式出現,簡單記錄IT資產信息。後來,CMDB演變爲依附於幫助臺的資產庫,與幫助臺捆綁向用戶銷售。如今,CMDB擺脫了管理軟件附屬品的角色,成爲獨立的系統管理模塊,是企業級集中式的配置數據庫。

    英國商務部出版的《ITIL服務支持》一書這樣定義CMDB:“它是一種包含每一個配置項(Configuration Item,CI)全部關聯細節,以及配置項之間重要關聯細節的數據庫”。可以說,是ITIL最佳實踐孕育了現代CMDB。目前CMDB中的CI信息覆蓋了企業網絡中的應用、操作系統、補丁、硬件設備、生命週期成本以及用戶鏈接。針對目前大多數企業中IT配置數據以不同格式保存在桌面機、服務器、補丁包、操作系統和網絡設備中的局面,CMDB把不同格式的數據統一採集到一個信息庫中,打破了IT域之間的固有壁壘。
 

        伴隨着ITIL版本的刷新,CMDB在整個ITIL框架中的作用也悄然發生着變化。有專家指出,ITIL v2奠定了CMDB在ITSM中的重要地位,而ITIL v3則進一步釋放了CMDB的效能,將其與知識管理和報告展現緊密地聯繫在一起。


    模型設計:專注數據完整

有人將當下全球盛行的ITIL實踐形容爲一場“奧林匹克”盛會,一方面在“重在參與”精神的感召下,ITIL在企業用戶中迅速普及;另一方面,“更高、更快、更強”的目標激發了參與者的潛能,用戶和IT服務供應商開始追逐更有效率、更有效果的卓越IT運營能力。在這一輪激烈的競技之中,CMDB被比喻爲ITIL的“發動機”。

    而在許多基於ITIL的ITSM項目中,實踐者雖深知CMDB的重要性,但在部署過程中卻往往被其構建所涉及的龐大工作量所困擾,感覺困難重重,不得要領。同時,由於CMDB數據庫工業標準尚處在討論和修訂階段,並未形成通用標準,也讓許多實踐者感到無法從成熟規範中尋求支持。因此,有分析人士指出,IT管理者需要從CMDB概念的混亂中找到一條通向管理數據集成和最佳實踐的路徑。
     

      要實現CMDB的成功構建,CMDB的設計和運作是必須攻克的兩大難點。如果設計不當或無法有效運作,將極大地制約ITSM系統的管理能力,讓IT運營的效率和效果大打折扣。同時,也只有解決這兩個問題,我們才能深入地探討CMDB工具的選型,以及軟件開發、數據挖掘和知識管理應用等更高層次的問題。

      在CMDB設計層面,對CMDB模型完整性的保證是設計過程中的重中之重。由於CMDB需要爲ITIL其他流程提供IT服務及基礎架構層面的配置信息,所以,只有CMDB記錄的數據完整才能準確地反映IT服務的真實狀態。而所謂完整的CMDB,包含了配置管理範圍的識別、CI屬性的選取和CI關係的構建。

        第一步,確定配置管理的範圍。
    這主要涉及CI的寬度和深度,以及CI的生命週期。需要說明的是,ITIL規範認爲,CI的生命週期是從CI的接收到最終報廢退出的全過程,但在具體實施過程中,由於流程管理主體的差異化,不同項目對CI生命週期的劃分和定義會有所不同。

      在確定CI的寬度和深度時,設計者應當從企業IT服務的需求、企業IT服務管理水平和CMDB運營管理成本三個方面進行規劃。具體來說,CMDB構建應該主要從IT服務角度考慮,IT服務本身也可以作爲CI記錄到CMDB中。同時,IT服務涉及的IT基礎架構及其相關的重要信息都應記錄到CMDB中。必須認識到,CMDB與企業IT服務管理水平之間緊密的聯動。企業IT服務管理水平越高,其對CMDB的依賴程度也隨之上升,對CMDB數據的準確性和完整性要求也越高。同時,企業變更管理的成熟度,包括變更管理範圍和流程執行力度也將在很大程度上影響CMDB數據的準確性和完整性。成本方面,CI的顆粒度決定了CMDB中信息的詳細程度,而這些信息的有效維護取決於IT部門投入的管理成本。

      CI生命週期的確定主要包含對兩個問題的確定:一是什麼時候識別CI並記錄到CMDB。在標準的配置管理流程中,CI全生命週期的理想狀態應該覆蓋從採購申請到報廢退出的過程。但在實際實施時,流程執行主體的管理範圍和職責將決定CI被識別的時間點;二是什麼時候刪除CI記錄。這一時間點同樣由流程執行主體的管理範圍和職責所決定。例如,對於租賃的CI,IT部門並不關心它的報廢過程,只關心其在生產環境中的運營狀況,因此,CI被租賃公司更換,則該記錄就有可能被標記爲刪除。而CI記錄的刪除並不是數據的真正刪除,而是將其標記爲刪除,這樣做的目的是爲IT審計提供數據支持。

      第二步,定義配置項的屬性。

      通常情況下,設計者需要遵循一個原則和一套結構。一個原則就是“精而不多”。如果我們將大量屬性納入CMDB,那麼,無疑將加大信息維護的成本。反之,如果屬性過少,CMDB對流程支持的有效性就降低了。所以,所謂“精而不多”就是找到適合自身需求的平衡點。ITIL專家指出,CI屬性的定義要注重選擇的屬性是否具備“面向服務的特性”。例如,一臺商用服務器可能會包含上百個屬性,但實際上經過篩選,對企業有實際意義的往往是CPU個數、CPU主頻、內存、硬盤、網卡等信息。

       一套結構指的是,我們通常可以把一個CI的屬性分爲五大來源。具體的劃分方法如附表所示。

 

 

 

    第三步,構建CI之間的關係。
      
      CI關係的定義也是配置管理建設與IT資產管理建設的區別之一。一般可以採取兩種方法進行CI關係的梳理工作,即“自上而下”和“自下而上”的方法。“自上而下”通常要求企業先明確對外提供的服務目錄,然後基於服務目錄按照“業務服務→IT服務→IT系統→IT組件”的順序進行梳理;“自下而上”則是逆流而上,先從對內部IT組件關係的梳理開始,然後逐步將IT組件映射到IT服務。


    流程運作:確保數據正確

上線後的CMDB要做到所記錄信息與生產環境的數據保持一致,這就需要建立一套良好的配置管理運作機制。這套機制包含了制定配置管理策略、確定變更/發佈與配置之間的流程關係、制定CMDB審計流程,以及配置管理的角色安排等工作。

    配置管理政策的制定

    該政策是企業配置管理的行動指南和共同綱領。它能夠幫助企業統一認識,減少不必要的溝通成本,實現流程的高效執行。配置管理政策主要包含宏觀政策和運營政策。其中,宏觀政策涉及企業或IT部門層面指導性、方向性的政策。

     運營政策主要涉及到流程目標、人員、輸入、輸出、活動以及KPI(關鍵績效指標)等要素,以及流程之間相互協調、信息交互方面的指導原則,其目標是使流程能夠在政策的指引下穩健、有效地執行。一般而言,包括CI的命名規範政策、CMDB數據保留政策,以及數據備份和恢復政策等。

     確定流程間的接口關係

     要實現CMDB的有效運作,成熟的變更/發佈管理流程必不可少。其原因是,這一流程掌握着CMDB中數據變更的通行證。變更/發佈管理流程與CMDB更新之間的關係如圖1所示。

 

 

 

 


    在圖1中,CMDB數據的任何變更都應該對應已批准的變更請求單。同時,由變更管理流程將變更信息遞送給負責配置管理的相關人員進行CMDB數據的更新。其中,CMDB數據的更新主要包括以下三種情況:
       一是CMDB數據結構的變更。通常發生在因管理需要而重構CMDB模型的情況下。例如新增需進行變更控制而未識別的CI,因服務調整而重新梳理CI間的關係等;二是新增或刪除CI。即指對已有CI的操作。例如更換或報廢設備,新採購標準的配置等;三是修改CI的屬性。此類變更是針對某CI具體屬性的操作。例如增加了某服務器CI的硬盤容量,就需要對其相應屬性進行調整。

        需要注意的是,CI屬性的變更通常會關聯到其他CI屬性的調整。例如,硬盤CI信息變更時,管理員還需要調整服務器CI的屬性,這無疑會增加數據維護的成本。針對這一問題,建議企業在確定CI屬性數據時,儘可能地從其他可靠數據源中獲取。例如,可以將服務器需要的硬盤容量屬性數據通過數據繼承關係,從硬盤CI本身的屬性中獲取。

        CMDB審計流程的制定

        在確保CMDB變更準確性的前提之下,變更管理流程的構建需要經歷一個持續改進的過程。用戶往往會遇到CMDB數據仍與實際環境不符的問題,這就需要通過審計流程來進行檢查、分析和修訂。

        制定CMDB審計過程中需要注意的是,首次審計一般發生在CMDB初始化準備上線之前,此後CMDB的全面審計應該定期展開,企業應根據需要設置週期,一般一年至少展開一次。另外,CMDB還需要進行一些專項審計,從而小範圍、細緻地核查某類CI或某項關鍵服務所涉及的CI“賬實相符”的狀況。當CMDB審計發現數據不符時應儘快查明原因,並通過變更工單提請變更,最終修改CMDB數據。CMDB審計流程應該獨立展開,審計員應由監管單位或部分的相關人員擔任。

         配置管理的角色安排

        配置管理活動所涉及的角色主要分爲四類,他們各司其職,協同完成CMDB的運作任務。其中,配置流程負責人需要對整個流程執行的結果負責,並擁有一定的流程管理權力;配置經理主要擔當流程開發和管理的角色,重點確保配置信息的準確性和可用性;配置管理員負責維護配置數據,保證提供給IT部門的CMDB信息總是準確的;配置審計員則主要負責通過審計操作確認配置數據。各個配置管理角色之間的關係如圖2所示。

 

 

 

    部署CMDB:豐儉由人

CMDB構建的重點在於對數據變更的把握,管理者需要用最合理的資源保證CMDB信息的“新鮮度”。這無疑是一項艱苦的任務,好在一些先行者積累了寶貴經驗供後來者分享。同時,CMDB已經在金融、電信、政府、教育等行業擁有了一定的部署規模,這些案例將在同行業的CMDB構建過程中發揮示範效應。
     

        中國工商銀行在ITSM領域的實踐一直處於行業領先地位,並且項目執行到位。在CMDB構建的問題上,工商銀行並沒有購買CMDB商業軟件,而是採取了自建的方法。在解釋選擇自建策略的原因時,工商銀行信息科技部的技術負責人表示,市場上商業化CMDB工具還不夠成熟。

        目前,大部分的CMDB軟件可以自動發現基於服務器的軟件應用,並構建映射關係圖,但是對於一些主機應用或企業自行開發的應用卻檢測不到。對於應用種類繁多,同時存在大量自有和遺留應用的金融企業,商業CMDB工具對整個IT環境的覆蓋能力有限。

    自建CMDB雖然需要企業投入更多的資金,但CMDB的獨立性和實時性卻能夠在企業內部得到有效保障。目前,工商銀行總行的資源管理庫已經運行多年,實現了CMDB與幫助臺、相關管理工具的有機結合,管理範圍覆蓋全行各分支機構,功能囊括主要的配置管理操作。而在電信行業,也有很多用戶傾向於自建方式,主要也是考慮到商業CMDB軟件對生產系統中管理對象的發現和管理能力欠缺的問題。

        無論是購買商業產品還是自行構建,CMDB的建設似乎都意味着企業需要投入巨資才能完成。這實際上是對CMDB的一種誤解。作爲ITSM實踐的起點,同時也是ITIL的基礎部件,CMDB的構建還有很多省錢的途徑。

        美國楊百翰大學基於MySQL開源數據庫構建校園CMDB是一個經典案例。新數據中心的落成和學校與上級機構的合併驅動了楊百翰大學踏上ITIL實踐之路,並着手進行IT資產配置數據的集成與分享。但是CMDB項目並沒有足夠的資金支持,因此,他們着眼於開源軟件。通過MySQL和廉價的學生勞動力,楊百翰大學構建了具備常規配置管理特性的CMDB。在CMDB構建的過程中,楊百翰大學對CI的類和子類進行了仔細的篩選,有效規避了CI顆粒度過細而容易導致的部署成本上升和構建難度加大等問題。而在未來,他們計劃將這一系統升級到甲骨文數據庫平臺。


    聯邦性:CMDB成熟的印記

Gartner2006年發佈的CMDB研究報告指出,並不是所有的配置數據庫都是CMDB,它必須具備聯邦性、協調性、同步性、映射和可視化四大特性。這份報告給出了CMDB成熟度評估的具體依據。目前,很多軟件廠商都宣稱向用戶提供CMDB工具,在其ITSM解決方案中也會包含CMDB組件。但如果站在專業ITSM實施的角度,它們中的一些更像是幫助臺資產庫尚未蛻變完全的產物。我們看到,很多所謂的CMDB得不到完整變更流程的支撐,數據的實時性無法保證;而一些產品介於IT資產庫和配置數據庫的中間,模型設計和配置策略不符合ITIL流程規範。聯邦性、協調性、同步性、映射和可視化是區分不成熟和成熟CMDB的剛性標準。而現在,CMDB市場的發展仍然處在向這一標準逐漸靠近的過程之中。

        聯邦性是軟件供應商難於攻克的部分,同時也是近期技術進展最大的CMDB特性。從2006年開始,許多廠商將CMDB的聯邦能力作爲產品研發的重點,並相繼推出了具有聯邦特性的CMDB產品。這些產品包括IBM的CCMDB(變更和配置管理數據庫)、Managed Objects的CMDB 360°,以及HP、BMC、CA、Symantec等公司的類似產品。
    

        聯邦式CMDB符合技術和應用的發展方向,這一點已經能夠通過現階段的客戶實踐加以驗證。在高度異構化的IT環境中,企業將所有IT資產的配置信息保存在一個通用數據庫的想法並不現實。如果能夠將多個數據庫連接在一起,通過一個邏輯配置數據庫構築一個聯邦式的CMDB,對於企業而言是一種切實可行的方案。這樣一來,客戶不必把所有配置數據都存儲在一個大數據庫中。聯邦式CMDB通過記錄不同數據庫中配置信息的關聯關係,在接到客戶的訪問請求時,可以快速追溯配置數據的保存位置。以前,很多廠商把CMDB的開發局限在自己的專有架構中,這種傳統的技術方式限制了CMDB對多數據源配置信息的發現與集成能力。同時,不合理的數據複製方式還會造成集成後CI的高度冗餘。聯邦式CMDB通過邏輯上對配置數據的靈活調用和統一管理,彌補了傳統CMDB的缺憾。


    推進方式:由點及面

CMDB的實施自然是“條條大路通羅馬”,但在現階段,從小處入手精心設計,逐步擴大CMDB的覆蓋範圍還是技術專家和企業客戶所青睞的項目推進方式。

        傳統的CMDB構建方法是自下而上地推進,也就是先做一個大的配置數據庫,再逐步精煉CI。但這種方式的缺點是投入巨大且浪費時間,很多企業耗時數年才能完成CMDB的部署;已經擁有簡單配置數據庫的用戶往往會選擇自中而上的推進方式,以現有數據庫爲基礎,添加必要的CI和CI之間的關係後,用戶可以用比較短的時間就組建一個功能相對豐富的CMDB。

    而對於佔據大多數的白手起家的用戶而言,“自上而下,漸進式擴充”是一種可行性更高的方法。專家建議,用戶可以先從訂單系統、郵件系統這樣的垂直應用開始,嘗試在單一環境中發現、收集、追蹤和管理配置信息的技巧,逐漸積累配置管理經驗。在構建了相對成熟的配置管理流程後再構建更大範圍的CMDB。

        一些用戶還會先期規劃一個小型的試驗項目,它會包含CMDB所必須的審計、控制、自動化等環節。啓動這種試驗項目可以幫助企業收穫一些關鍵的CMDB部署體驗。例如,對IT資產配置的描述方法,如何通過準確的配置信息來支持IT服務管理,事件、故障、變更和發佈管理流程的串聯和磨合,以及如果更高效地對配置記錄做出變更。

        而有專家建議,在啓動這樣的試驗時,最好選擇一個能夠得到廣泛支持的IT服務,而不是對業務營收至關重要的IT服務。同時,這樣的服務不應該需要進行頻繁地更新,並且在IT系統框架中處在相對獨立的環境之中。因爲頻繁的變更操作將增加管理的難度,也更容易導致管理錯誤的發生。   
 

本文出自 www.sinoserviceone.com 轉載等請務必保留此出處

【CNW.com.cn 專稿】在IT管理向ITSM(IT服務管理)體系演進的征途中,CMDB(配置管理數據庫)從傳統的電子報表中走來,蛻變爲基於ITIL最佳實踐的IT服務管理核心。對於所有的ITSM體系的建設者而言,CMDB都是一部龐大機器上必須精心打磨與調試的一個關鍵部件。

   “水域,這是俄羅斯的必需!”彼得大帝的慨嘆表達了一個民族對海洋的渴望。而在獲得了出海口之後,封閉的俄羅斯終於打開了通往文明歐洲的窗口,走上富強之路。CMDB之於ITSM,或許遠不如十六世紀海洋對於俄羅斯如此那般的迫切。但是在今天的IT管理領域,CMDB在完整的ITSM系統中的核心地位絕對無可替代。今天,CMDB不僅是管理軟件廠商和ITIL倡導者常掛嘴邊的時髦詞彙,也早已成爲企業用戶在IT管理項目推進中的關注焦點。

“通過更先進的資產管理和自動化流程,幫助用戶建立跨系統的數據管理關聯,從而最終推動跨功能的流程整合”是CMDB對用戶的承諾。而在闡述CMDB現階段的定義之前,必須說明的是,CMDB並不是IT管理領域的新生事物或名詞。從誕生至今,CMDB經歷了三次脫胎換骨的技術蛻變。實際上,早期的許多管理軟件中都包含了現代CMDB的雛形,它們以電子報表的形式出現,簡單記錄IT資產信息。後來,CMDB演變爲依附於幫助臺的資產庫,與幫助臺捆綁向用戶銷售。如今,CMDB擺脫了管理軟件附屬品的角色,成爲獨立的系統管理模塊,是企業級集中式的配置數據庫。

   
英國商務部出版的《ITIL服務支持》一書這樣定義CMDB:“它是一種包含每一個配置項(Configuration Item,CI)全部關聯細節,以及配置項之間重要關聯細節的數據庫”。可以說,是ITIL最佳實踐孕育了現代CMDB。目前CMDB中的CI信息覆蓋了企業網絡中的應用、操作系統、補丁、硬件設備、生命週期成本以及用戶鏈接。針對目前大多數企業中IT配置數據以不同格式保存在桌面機、服務器、補丁包、操作系統和網絡設備中的局面,CMDB把不同格式的數據統一採集到一個信息庫中,打破了IT域之間的固有壁壘。
  

        伴隨着ITIL版本的刷新,CMDB在整個ITIL框架中的作用也悄然發生着變化。有專家指出,ITIL v2奠定了CMDB在ITSM中的重要地位,而ITIL v3則進一步釋放了CMDB的效能,將其與知識管理和報告展現緊密地聯繫在一起。

    模型設計:專注數據完整

有人將當下全球盛行的ITIL實踐形容爲一場“奧林匹克”盛會,一方面在“重在參與”精神的感召下,ITIL在企業用戶中迅速普及;另一方面,“更高、更快、更強”的目標激發了參與者的潛能,用戶和IT服務供應商開始追逐更有效率、更有效果的卓越IT運營能力。在這一輪激烈的競技之中,CMDB被比喻爲ITIL的“發動機”。

   
而在許多基於ITIL的ITSM項目中,實踐者雖深知CMDB的重要性,但在部署過程中卻往往被其構建所涉及的龐大工作量所困擾,感覺困難重重,不得要領。同時,由於CMDB數據庫工業標準尚處在討論和修訂階段,並未形成通用標準,也讓許多實踐者感到無法從成熟規範中尋求支持。因此,有分析人士指出,IT管理者需要從CMDB概念的混亂中找到一條通向管理數據集成和最佳實踐的路徑。
      

      要實現CMDB的成功構建,CMDB的設計和運作是必須攻克的兩大難點。如果設計不當或無法有效運作,將極大地制約ITSM系統的管理能力,讓IT運營的效率和效果大打折扣。同時,也只有解決這兩個問題,我們才能深入地探討CMDB工具的選型,以及軟件開發、數據挖掘和知識管理應用等更高層次的問題。

      在CMDB設計層面,對CMDB模型完整性的保證是設計過程中的重中之重。由於CMDB需要爲ITIL其他流程提供IT服務及基礎架構層面的配置信息,所以,只有CMDB記錄的數據完整才能準確地反映IT服務的真實狀態。而所謂完整的CMDB,包含了配置管理範圍的識別、CI屬性的選取和CI關係的構建。

        第一步,確定配置管理的範圍。
   
這主要涉及CI的寬度和深度,以及CI的生命週期。需要說明的是,ITIL規範認爲,CI的生命週期是從CI的接收到最終報廢退出的全過程,但在具體實施過程中,由於流程管理主體的差異化,不同項目對CI生命週期的劃分和定義會有所不同。

      在確定CI的寬度和深度時,設計者應當從企業IT服務的需求、企業IT服務管理水平和CMDB運營管理成本三個方面進行規劃。具體來說,CMDB構建應該主要從IT服務角度考慮,IT服務本身也可以作爲CI記錄到CMDB中。同時,IT服務涉及的IT基礎架構及其相關的重要信息都應記錄到CMDB中。必須認識到,CMDB與企業IT服務管理水平之間緊密的聯動。企業IT服務管理水平越高,其對CMDB的依賴程度也隨之上升,對CMDB數據的準確性和完整性要求也越高。同時,企業變更管理的成熟度,包括變更管理範圍和流程執行力度也將在很大程度上影響CMDB數據的準確性和完整性。成本方面,CI的顆粒度決定了CMDB中信息的詳細程度,而這些信息的有效維護取決於IT部門投入的管理成本。

      CI生命週期的確定主要包含對兩個問題的確定:一是什麼時候識別CI並記錄到CMDB。在標準的配置管理流程中,CI全生命週期的理想狀態應該覆蓋從採購申請到報廢退出的過程。但在實際實施時,流程執行主體的管理範圍和職責將決定CI被識別的時間點;二是什麼時候刪除CI記錄。這一時間點同樣由流程執行主體的管理範圍和職責所決定。例如,對於租賃的CI,IT部門並不關心它的報廢過程,只關心其在生產環境中的運營狀況,因此,CI被租賃公司更換,則該記錄就有可能被標記爲刪除。而CI記錄的刪除並不是數據的真正刪除,而是將其標記爲刪除,這樣做的目的是爲IT審計提供數據支持。

      第二步,定義配置項的屬性。

      通常情況下,設計者需要遵循一個原則和一套結構。一個原則就是“精而不多”。如果我們將大量屬性納入CMDB,那麼,無疑將加大信息維護的成本。反之,如果屬性過少,CMDB對流程支持的有效性就降低了。所以,所謂“精而不多”就是找到適合自身需求的平衡點。ITIL專家指出,CI屬性的定義要注重選擇的屬性是否具備“面向服務的特性”。例如,一臺商用服務器可能會包含上百個屬性,但實際上經過篩選,對企業有實際意義的往往是CPU個數、CPU主頻、內存、硬盤、網卡等信息。

       一套結構指的是,我們通常可以把一個CI的屬性分爲五大來源。具體的劃分方法如附表所示。


 


    第三步,構建CI之間的關係。
      
      CI關係的定義也是配置管理建設與IT資產管理建設的區別之一。一般可以採取兩種方法進行CI關係的梳理工作,即“自上而下”和“自下而上”的方法。“自上而下”通常要求企業先明確對外提供的服務目錄,然後基於服務目錄按照“業務服務→IT服務→IT系統→IT組件”的順序進行梳理;“自下而上”則是逆流而上,先從對內部IT組件關係的梳理開始,然後逐步將IT組件映射到IT服務。

    流程運作:確保數據正確

上線後的CMDB要做到所記錄信息與生產環境的數據保持一致,這就需要建立一套良好的配置管理運作機制。這套機制包含了制定配置管理策略、確定變更/發佈與配置之間的流程關係、制定CMDB審計流程,以及配置管理的角色安排等工作。

   
配置管理政策的制定

    該政策是企業配置管理的行動指南和共同綱領。它能夠幫助企業統一認識,減少不必要的溝通成本,實現流程的高效執行。配置管理政策主要包含宏觀政策和運營政策。其中,宏觀政策涉及企業或IT部門層面指導性、方向性的政策。

     運營政策主要涉及到流程目標、人員、輸入、輸出、活動以及KPI(關鍵績效指標)等要素,以及流程之間相互協調、信息交互方面的指導原則,其目標是使流程能夠在政策的指引下穩健、有效地執行。一般而言,包括CI的命名規範政策、CMDB數據保留政策,以及數據備份和恢復政策等。

     確定流程間的接口關係

     要實現CMDB的有效運作,成熟的變更/發佈管理流程必不可少。其原因是,這一流程掌握着CMDB中數據變更的通行證。變更/發佈管理流程與CMDB更新之間的關係如圖1所示。





    在圖1中,CMDB數據的任何變更都應該對應已批准的變更請求單。同時,由變更管理流程將變更信息遞送給負責配置管理的相關人員進行CMDB數據的更新。其中,CMDB數據的更新主要包括以下三種情況:

       一是CMDB數據結構的變更。通常發生在因管理需要而重構CMDB模型的情況下。例如新增需進行變更控制而未識別的CI,因服務調整而重新梳理CI間的關係等;二是新增或刪除CI。即指對已有CI的操作。例如更換或報廢設備,新採購標準的配置等;三是修改CI的屬性。此類變更是針對某CI具體屬性的操作。例如增加了某服務器CI的硬盤容量,就需要對其相應屬性進行調整。

        需要注意的是,CI屬性的變更通常會關聯到其他CI屬性的調整。例如,硬盤CI信息變更時,管理員還需要調整服務器CI的屬性,這無疑會增加數據維護的成本。針對這一問題,建議企業在確定CI屬性數據時,儘可能地從其他可靠數據源中獲取。例如,可以將服務器需要的硬盤容量屬性數據通過數據繼承關係,從硬盤CI本身的屬性中獲取。

        CMDB審計流程的制定

        在確保CMDB變更準確性的前提之下,變更管理流程的構建需要經歷一個持續改進的過程。用戶往往會遇到CMDB數據仍與實際環境不符的問題,這就需要通過審計流程來進行檢查、分析和修訂。

        制定CMDB審計過程中需要注意的是,首次審計一般發生在CMDB初始化準備上線之前,此後CMDB的全面審計應該定期展開,企業應根據需要設置週期,一般一年至少展開一次。另外,CMDB還需要進行一些專項審計,從而小範圍、細緻地核查某類CI或某項關鍵服務所涉及的CI“賬實相符”的狀況。當CMDB審計發現數據不符時應儘快查明原因,並通過變更工單提請變更,最終修改CMDB數據。CMDB審計流程應該獨立展開,審計員應由監管單位或部分的相關人員擔任。

         配置管理的角色安排

        配置管理活動所涉及的角色主要分爲四類,他們各司其職,協同完成CMDB的運作任務。其中,配置流程負責人需要對整個流程執行的結果負責,並擁有一定的流程管理權力;配置經理主要擔當流程開發和管理的角色,重點確保配置信息的準確性和可用性;配置管理員負責維護配置數據,保證提供給IT部門的CMDB信息總是準確的;配置審計員則主要負責通過審計操作確認配置數據。各個配置管理角色之間的關係如圖2所示。


 


    部署CMDB:豐儉由人

CMDB構建的重點在於對數據變更的把握,管理者需要用最合理的資源保證CMDB信息的“新鮮度”。這無疑是一項艱苦的任務,好在一些先行者積累了寶貴經驗供後來者分享。同時,CMDB已經在金融、電信、政府、教育等行業擁有了一定的部署規模,這些案例將在同行業的CMDB構建過程中發揮示範效應。
      

        中國工商銀行在ITSM領域的實踐一直處於行業領先地位,並且項目執行到位。在CMDB構建的問題上,工商銀行並沒有購買CMDB商業軟件,而是採取了自建的方法。在解釋選擇自建策略的原因時,工商銀行信息科技部的技術負責人表示,市場上商業化CMDB工具還不夠成熟。

        目前,大部分的CMDB軟件可以自動發現基於服務器的軟件應用,並構建映射關係圖,但是對於一些主機應用或企業自行開發的應用卻檢測不到。對於應用種類繁多,同時存在大量自有和遺留應用的金融企業,商業CMDB工具對整個IT環境的覆蓋能力有限。

    自建CMDB雖然需要企業投入更多的資金,但CMDB的獨立性和實時性卻能夠在企業內部得到有效保障。目前,工商銀行總行的資源管理庫已經運行多年,實現了CMDB與幫助臺、相關管理工具的有機結合,管理範圍覆蓋全行各分支機構,功能囊括主要的配置管理操作。而在電信行業,也有很多用戶傾向於自建方式,主要也是考慮到商業CMDB軟件對生產系統中管理對象的發現和管理能力欠缺的問題。

        無論是購買商業產品還是自行構建,CMDB的建設似乎都意味着企業需要投入巨資才能完成。這實際上是對CMDB的一種誤解。作爲ITSM實踐的起點,同時也是ITIL的基礎部件,CMDB的構建還有很多省錢的途徑。

        美國楊百翰大學基於MySQL開源數據庫構建校園CMDB是一個經典案例。新數據中心的落成和學校與上級機構的合併驅動了楊百翰大學踏上ITIL實踐之路,並着手進行IT資產配置數據的集成與分享。但是CMDB項目並沒有足夠的資金支持,因此,他們着眼於開源軟件。通過MySQL和廉價的學生勞動力,楊百翰大學構建了具備常規配置管理特性的CMDB。在CMDB構建的過程中,楊百翰大學對CI的類和子類進行了仔細的篩選,有效規避了CI顆粒度過細而容易導致的部署成本上升和構建難度加大等問題。而在未來,他們計劃將這一系統升級到甲骨文數據庫平臺。

    聯邦性:CMDB成熟的印記

Gartner2006年發佈的CMDB研究報告指出,並不是所有的配置數據庫都是CMDB,它必須具備聯邦性、協調性、同步性、映射和可視化四大特性。這份報告給出了CMDB成熟度評估的具體依據。目前,很多軟件廠商都宣稱向用戶提供CMDB工具,在其ITSM解決方案中也會包含CMDB組件。但如果站在專業ITSM實施的角度,它們中的一些更像是幫助臺資產庫尚未蛻變完全的產物。我們看到,很多所謂的CMDB得不到完整變更流程的支撐,數據的實時性無法保證;而一些產品介於IT資產庫和配置數據庫的中間,模型設計和配置策略不符合ITIL流程規範。聯邦性、協調性、同步性、映射和可視化是區分不成熟和成熟CMDB的剛性標準。而現在,CMDB市場的發展仍然處在向這一標準逐漸靠近的過程之中。

        聯邦性是軟件供應商難於攻克的部分,同時也是近期技術進展最大的CMDB特性。從2006年開始,許多廠商將CMDB的聯邦能力作爲產品研發的重點,並相繼推出了具有聯邦特性的CMDB產品。這些產品包括IBM的CCMDB(變更和配置管理數據庫)、Managed Objects的CMDB 360°,以及HP、BMC、CA、Symantec等公司的類似產品。
     

        聯邦式CMDB符合技術和應用的發展方向,這一點已經能夠通過現階段的客戶實踐加以驗證。在高度異構化的IT環境中,企業將所有IT資產的配置信息保存在一個通用數據庫的想法並不現實。如果能夠將多個數據庫連接在一起,通過一個邏輯配置數據庫構築一個聯邦式的CMDB,對於企業而言是一種切實可行的方案。這樣一來,客戶不必把所有配置數據都存儲在一個大數據庫中。聯邦式CMDB通過記錄不同數據庫中配置信息的關聯關係,在接到客戶的訪問請求時,可以快速追溯配置數據的保存位置。以前,很多廠商把CMDB的開發局限在自己的專有架構中,這種傳統的技術方式限制了CMDB對多數據源配置信息的發現與集成能力。同時,不合理的數據複製方式還會造成集成後CI的高度冗餘。聯邦式CMDB通過邏輯上對配置數據的靈活調用和統一管理,彌補了傳統CMDB的缺憾。

    推進方式:由點及面

CMDB的實施自然是“條條大路通羅馬”,但在現階段,從小處入手精心設計,逐步擴大CMDB的覆蓋範圍還是技術專家和企業客戶所青睞的項目推進方式。

        傳統的CMDB構建方法是自下而上地推進,也就是先做一個大的配置數據庫,再逐步精煉CI。但這種方式的缺點是投入巨大且浪費時間,很多企業耗時數年才能完成CMDB的部署;已經擁有簡單配置數據庫的用戶往往會選擇自中而上的推進方式,以現有數據庫爲基礎,添加必要的CI和CI之間的關係後,用戶可以用比較短的時間就組建一個功能相對豐富的CMDB。

   
而對於佔據大多數的白手起家的用戶而言,“自上而下,漸進式擴充”是一種可行性更高的方法。專家建議,用戶可以先從訂單系統、郵件系統這樣的垂直應用開始,嘗試在單一環境中發現、收集、追蹤和管理配置信息的技巧,逐漸積累配置管理經驗。在構建了相對成熟的配置管理流程後再構建更大範圍的CMDB。

        一些用戶還會先期規劃一個小型的試驗項目,它會包含CMDB所必須的審計、控制、自動化等環節。啓動這種試驗項目可以幫助企業收穫一些關鍵的CMDB部署體驗。例如,對IT資產配置的描述方法,如何通過準確的配置信息來支持IT服務管理,事件、故障、變更和發佈管理流程的串聯和磨合,以及如果更高效地對配置記錄做出變更。

        而有專家建議,在啓動這樣的試驗時,最好選擇一個能夠得到廣泛支持的IT服務,而不是對業務營收至關重要的IT服務。同時,這樣的服務不應該需要進行頻繁地更新,並且在IT系統框架中處在相對獨立的環境之中。因爲頻繁的變更操作將增加管理的難度,也更容易導致管理錯誤的發生。

(本文作者之一陳宏峯先生爲翰緯IT管理研究諮詢中心研發總監)

    編看編想

CMDB普及期待標準支持

      CMDB在ITSM領域的重要性毋庸置疑,但是用戶在相關產品選型上的困惑短期內仍然難以消除。長期以來,不同品牌CMDB之間的互操作能力一直無法讓用戶滿意,這也是一部分用戶不惜巨資自建CMDB的關鍵原因。由於CMDB本身的演進過程就非常漫長,並且在相當長的時間內是通過與幫助臺捆綁的方式進入企業的IT環境的,那麼,配置數據庫的重疊在信息化起步早的企業中便成了非常普遍的現象。如何將分散在不同應用中的配置信息收集起來,並進行有效集成,目前的商業CMDB工具並不能提供成熟的解決方案。而這一問題的解決,有賴於CMDB標準化進程的快速推進。

      目前這一領域的軟件公司已經意識到,標準是激發CMDB市場潛力的催化劑。2006年4月,一個旨在建立配置數據共享通用規範的協作性組織CMDB聯盟工作組(CMDBf)成立,成員包括IBM、BMC、CA、HP、微軟等。今年2月,該組織推出了一份闡述配置信息共享機制的白皮書,8月,該組織發佈了公共過渡性草案0.95版本,定義了聯邦式CMDB與其他管理數據庫數據共享的形式。雖然CMDB規範框架初現,但與用戶的部署需求及項目實施的步伐相比,其進展仍顯滯後。這樣的規範缺失雖不致於讓用戶的實踐陷於無序,但這種狀態的持續將制約CMDB的普及。因此,無論是出於市場拓展的需要,還是向用戶提供規範化的部署指導,開放和遵循統一標準都應該是CMDB軟件供應商的共同選擇。


 
本文出自 www.sinoserviceone.com
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章