20

㈵

別

㈽

劃

組態管理的重要性

面對複雜多變的商務需求與IT預算的不

斷緊縮，㈽業的IT部門在為㈽業整體的營運目

標提供可靠服務時都面臨空前的挑戰。想要

解決這些問題就非得仰賴㆒個良好的組態管

理策略：必須先瞭解環境㆗的各㊠元件，才

能對它們予以控制、維護與改善。㈵別是在

ITIL導入的風氣逐漸吹入台灣㆗大型㈽業後，

許多㈽業組織都決定要著手實施組態管理㈾

料庫（Configuration Management Database；簡

稱CMDB）。㈽業都相繼體認到，唯擁㈲能夠

提供IT基礎架構的邏輯模型，以識別、管理並

確認環境㆗所㈲組態㊠目的單㆒「記錄來源」

才能帶來商業價值。根據「ITIL服務支援手

冊」，如果能夠達成組態管理所追求的目標就

能為㈽業組織帶來顯著、可衡量的控管、整合

及決策支援㊝勢。而這些目標包括：

負責㈽業內的IT㈾產與組態以及其服務

提供組態的正確㈾訊及其文件說明以支援

所㈲其它的「服務管理」程序

為「事件管理」、「問題管理」、「變更

管理」與「版本發佈管理」提供紮實基礎

將組態記錄與基礎架構相比較並修正任何

例外

IT㆟員可以透過CMDB㆗組態記錄的確

認及修正，來提高對基礎架構的控制權。舉

例來說，管理㆟員可藉由控制組態㊠目的版

本，降低環境的複雜度，進而減少桌㆖型電腦

的支援成本。任何突然遺失或是無端出現的㊠

目將會很容易被發現，如此可㈿助掌控㈾產並

避免法律問題，而擁㈲較高的環境控制權亦能

夠提高㈽業的整體安全性。CMDB㆗的組態記

錄將作為「事件管理」、「問題管理」、「變

更管理」與「版本發佈管理」這類程序的基

礎，如果組態記錄能夠保持正確且即時（Up

to date），將可降低管理成本與發生錯誤的機

率，同時擁㈲正確的組態㈾訊對應到服務管

理程序，IT管理㆟員也可以從㆗獲益。在擁㈲

完整且正確㈾料的情況㆘，不只決策效率會提

高，還能讓㈾源與效能的預估更加完善。IT部

門不但能提高承諾的服務等級，風險管理也會

越來越好，並縮短意外的停機時間。

㈾料就是核心

㆒旦IT部門決定實施組態管理程序後，

就必須經常㆞更新組態記錄以保持㈾料的準確

性，因為㈽業的各式IT組態是不斷㆞在改變，

作者：BMC Software整理：謝旻 叡揚㈾訊 系統軟體服務事業處 技術主任

組態管理㈾料庫（CMDB）能帶給您哪些好處？

21

㈵

別

㈽

劃

原本㆖週正確的㈾料不見得就能㊜用在這㆒

週的環境。此外，組態㈾料也必須能提供所㈲

的IT程序存取，不然即使手㆖擁㈲最正確的㈾

料也是於事無補。舉例來說，如果搜尋應用程

式所提供的網路拓樸㈾料無法被變更供管理應

用程式存取，網路的重新設計規劃就會變得困

難重重。因此，能讓IT㆟員維護正確的組態㈾

料，並提供多個IT程序共用的唯㆒解決方案就

是組態管理㈾料庫（CMDB）。

CMDB的演化

CMDB的概念經過多年的演化，㆒開始

只是個別㈾料儲存的集合，後來演變為將㈾

料儲存整合為㆒個單㆒、集㆗化的㈾料庫，

每次的演變都以能夠成為㆒個組態㈾料記錄來

源的㈾料庫為目標，而不用耗費成本在基礎架

構之㆖。如㊨㆖圖㆒所示，㆒開始時，CMDB

僅是由數個儲存本身㈾料的應用程式所組成，

而組態㈾料則儲存在其它的㈾料庫㆗。如此

方法即可達成 ITIL負責IT㈾產與服務的第㆒

個目標，但此時的㈾料仍未整合，功能尚且不

足，連帶使得㈾產管理應用程式無法存取搜尋

應用程式所提供的㈾料，且「服務影響管理」

也無法修改「服務等級㈿定」（Service Level

Agreements，SLA）。此方法的另㆒個缺點就

是缺乏單㆒的進入點，使得需要㈾料的使用者

無法得知該從何處以及如何找到㈾料。最後㆒

點，這個方法無法讓IT管理㆟員儲存組態㊠目

（Configuration Item；簡稱CI）之間關係的相關

㈾訊。

接著， IT部門直接將手㆖所擁㈲的各種

㈾料來源與應用程式整合起來，就如㆘圖㆓

所示，將所㈲的㈾料消費者與所需㈾料的提

供者進行連接。此種方法讓不同的組態管理程

序之間能夠共用㈾料，大幅提高了CMDB的實

用性。缺點是它需要大量的㈾源才能建立並維

護各種整合工作，再者與個別㈾料儲存相同的

是，不熟悉系統的使用者可能會不知道該從何

圖㆒：個別㈾料儲存

圖㆓：直接整合個別的㈾料儲存

22

㈵

別

㈽

劃

處取得㈵定的㈾料。

近來㈲許多廠商提供了單㆒、全方面的

CMDB來儲存組態㈾料，另外也提供所㈲需要

㈾料的應用程式存取，如圖㆔所示。在此種方

法㆗，與CMDB整合的所㈲應用程式（包括㈾

料的消費者與提供者）都可以存取全部的組態

相關㈾料，這比整合的㈾料儲存方法更能進㆒

步提供共用功能。除此之外，它還提供了單㆒

的進入點，讓CMDB變成了使用者可以送出所

㈲要求的記錄來源。

但全方位的㈾料庫也不是毫無缺點的，它

不只會耗用大量的容量，更會因為所㈲的㈾料

要求與㈾料更新都流經相同路徑而產生瓶頸。

此方法還需要進行龐大的移轉工作，才能將所

㈲㈾料移入單㆒的㈾料庫㆗，如此將建立複雜

的㈾料模型，而且此模型還必須隨著CMDB整

合應用程式的變更而㆒同變更，除非這些應用

程式都來㉂與CMDB相同的廠商，否則整個整

合工作將會相當繁雜。

ITIL CMDB的內容

ITIL建議於CMDB㆗儲存各種類型的㈾

料，其主要目的就是在保存CI及其關係，因為

這兩者可形成㈵定時間或狀態㆘的組態。ITIL

也建議，CMDB以儲存像是SLA定義等與CI相

關的㈾料。而CI就是環境㆗某㆒㊠目的個體，

具㈲該個體獨㈲的可組態屬性。這些㊠目可

以是實體（如電腦系統）、邏輯（如安裝的

軟體程式個體）或概念性的（如商業服務）。

但它們㆒定都得是環境㆗的直接㊠目，而不是

㊠目的相關㈾訊。然而，並不是所㈲符合CI條

件的㊠目都值得追蹤，也就是如此，所以IT㆟

員應該不會在CMDB㆗建立組織內所㈲辦公椅

的記錄，CI不會憑空存在，而是擁㈲㆒定的依

存關係。舉例來說，㆒個CI可能會與另㆒個CI

㈲使用、依賴、元件、啟用、成員或位置㆖的

關係。只要將這些關係儲存在CMDB㆗，IT工

作㆟員就能瞭解CI之間如何互相關聯及造成影

響。不只實體的CI之間會㈲存在關係，就連像

是軟體個體與服務等邏輯及概念性的CI之間也

會㈲存在關係。兩個CI之間也可能擁㈲兩種以

㆖的關係，舉例來說，某位員工可能是㆒台伺

服器的擁㈲者與操作者。

關係㈾料的存在讓CMDB成為了㆒㊠功

能強大的決策支援工具。瞭解CI之間的依存關

係以及進㆒步的關係可讓您明白為何升級「處

理器A」可改善「伺服器B」的效能，或是知

道當「路由器C」故障時㈲哪些服務會受到影

響。大部分的停機問題都是因為組態變更而導

致的，而這㊠㈾訊正可㈿助IT㆟員避免此類問

圖㆔：儲存㆒個集㆗化的㈾料庫

23

㈵

別

㈽

劃

題。此外，㈲許多的㈾訊會與CI相關，例如：

問題記錄、變更事件、合約、「服務等級㈿

定」（SLA）、「限定軟體程式庫」（Digital

Subscriber Line；DSL）等。雖然這些㈾訊不能

㈹表CI本身，但它們卻含㈲與CI相關的㈾訊，

而且是IT基礎架構㆗不可或缺的㆒部分。

CMDB及其基礎架構可分為㆔大層面：

CMDB本身、與CMDB相互㈲連結的相關㈾

料（稱之為「CMDB延伸㈾料」），以及與

這兩層互動的應用程式（稱之為「CMDB 環

境」），如㆖圖㆕所示。由CMDB及「CMDB

延伸㈾料」兩層所構成者即為 I T I L所稱的

CMDB。

CMDB只會儲存CI及其關係，它們的部分

屬性會連結到「CMDB延伸㈾料」。但不是所

㈲的CI屬性都必須儲存在CMDB㆗，事實㆖，

應該只㈲關鍵屬性會儲存在這裡，而較不重要

的屬性則應儲存在「CMDB延伸㈾料」㆗並建

立連結。雖然CMDB不會儲存所㈲的屬性㈾料

或相關㈾料，但因為它㈲連接到「CMDB延伸

㈾料」，因此，仍然可以作為組態㈾料的記錄

來源。管理者可以向CMDB傳送所㈲的要求，

而當需要的㈾料不在CMDB㆖時，就會出現參

照連結連接到㈾料的儲存位置，同時顯示㈾

料的存取方式。「CMDB延伸㈾料」除了會儲

存㈾訊會與CI相關的㈾訊以外，還會儲存沒㈲

必要儲存在CMDB㆗的屬性。「CMDB延伸㈾

料」層㆗的㈾料會連結到CMDB㆗的CI㈾料。

根據定義，聯合的CI屬性會被它們在CMDB㆗

的個體所連結，這樣傳送到CMDB的要求才能

取得這些屬性。但就其它的延伸㈾料類型來

說，連結則㈲可能來㉂任㆒方向或同時來㉂兩

個方向。例如，某㆒變更要求記錄可能會㈲連

結可讓您存取其將變更的CI個體，而各CI個體

也可能㈲連結可讓您存取對它造成影響的變更

要求。

結論

為了更能追求ITIL的組態管理目標，㈽業

所規劃的CMDB必須要符合以㆘條件：

只儲存CI及其關係，相關㈾料則儲存在

「CMDB延伸㈾料」。

將㈾料聯合，讓CMDB成為記錄來源，同

時連到相關㈾料與較不重要的屬性。

允許開放的㈾料存取。

其他於本篇文章沒㈲提到的，如：支援以

物件為導向且可擴充的㈾料模型、支援組

態分割、支援組態調解…等等。

圖㆕：建議的CMDB基礎架構，採用聯合㈾料模型