組態管理資料庫（CMDB）能帶給您哪些好處？
作者：BMC Software
整理：謝旻儫 叡揚資訊 系統軟體服務事業處 技術主任
組態管理的重要性
面對複雜多變的商務需求與IT預算的不斷緊縮，企業的IT部門在為企業整體的營運目標提供可靠服務時都面臨空前的挑戰。想要解決這些問題就非得仰賴一個良好的組態 管理策略：必須先瞭解環境中的各項元件，才能對它們予以控制、維護與改善。特別是在ITIL導入的風氣逐漸吹入台灣中大型企業後，許多企業組織都決定要著手實施組態管 理資料庫（Configuration Management Database；簡稱CMDB）。企業都相繼體認到，唯擁有能夠提供IT基礎架構的邏輯模型，以識別、管理並確認環境中所有組態項目的單 一「記錄來源」才能帶來商業價值。根據「ITIL服務支援手冊」，如果能夠達成組態管理所追求的目標就能為企業組織帶來顯著、可衡量的控管、整合及決策支援優勢。而這些目標包括：
- 負責企業內的IT資產與組態以及其服務
- 提供組態的正確資訊及其文件說明以支援所有其它的「服務管理」程序
- 為「事件管理」、「問題管理」、「變更管理」與「版本發佈管理」提供紮實基礎
- 將組態記錄與基礎架構相比較並修正任何例外
IT人員可以透過CMDB中組態記錄的確認及修正，來提高對基礎架構的控制權。舉例來說，管理人員可藉由控制組態項目的版本，降低環境的複雜度，進而減少桌上型電腦的支援成本。任何突然遺失或是無端出現的項目將會很容易被發現，如此可協助掌控資產並避免法律問題，而擁有較高的環境控制權亦能夠提高企業的整體安全性。CMDB中的組態 記錄將作為「事件管理」、「問題管理」、「變更管理」與「版本發佈管理」這類程序的基礎，如果組態記錄能夠保持正確且即時（Up to date），將可降低管理成本與發生 錯誤的機率，同時擁有正確的組態資訊對應到服務管理程序，IT管理人員也可以從中獲益。在擁有完整且正確資料的情況下，不只決策效率會提高，還能讓資源與效能的預估 更加完善。IT部門不但能提高承諾的服務等級，風險管理也會越來越好，並縮短意外的停機時間。
資料就是核心
一旦IT部門決定實施組態管理程序後，就必須經常地更新組態記錄以保持資料的準確性，因為企業的各式IT組態是不斷地在改變，原本上週正確的資料不見得就能適用在 這一週的環境。此外，組態資料也必須能提供所有的IT程序存取，不然即使手上擁有最正確的資料也是於事無補。舉例來說，如果搜尋應用程式所提供的網路拓樸資料無法被 變更供管理應用程式存取，網路的重新設計規劃就會變得困難重重。因此，能讓IT人員維護正確的組態資料，並提供多個IT程序共用的唯一解決方案就是組態管理資料庫（CMDB）。
CMDB的演化
CMDB的概念經過多年的演化，一開始只是個別資料儲存的集合，後來演變為將資料儲存整合為一個單一、集中化的資料庫，每次的演變都以能夠成為一個組態資料記錄來 源的資料庫為目標，而不用耗費成本在基礎架構之上。如右上圖一所示，一開始時，CMDB僅是由數個儲存本身資料的應用程式所組成，而組態資料則儲存在其它的資料庫中。 如此方法即可達成ITIL負責IT資產與服務的第一個目標，但此時的資料仍未整合，功能尚且不足，連帶使得資產管理應用程式無法存取搜尋應用程式所提供的資料，且「服務影響管理」也無法修改「服務等級協定」（Service Level Agreements，SLA）。此方法的另一個缺點就是缺乏單一的進入點，使得需要資料的使用者無法得知該從何處以 及如何找到資料。最後一點，這個方法無法讓IT管理人員儲存組態項目（Configuration Item；簡稱CI）之間關係的相關資訊。
接著，IT部門直接將手上所擁有的各種資料來源與應用程式整合起來，就如下圖二所示，將所有的資料消費者與所需資料的提供者進行連接。此種方法讓不同的組態管理程序之間能夠共用資料，大幅提高了CMDB的實用性。缺點是它需要大量的資源才能建立並維護各種整合工作，再者與個別資料儲存相同的是，不熟悉系統的使用者可能會不知道該從何處取得特定的資料。
近來有許多廠商提供了單一、全方面的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人員避免此類問題。此外，有許多的資訊會與CI相關，例如：問題記錄、變更事件、合約、「服務等級協定」（SLA）、「限定軟體程式庫」（Digital Subscriber Line；DSL）等。雖然這些資訊不能代表CI本身，但它們卻含有與CI相關的資訊，而且是IT基礎架構中不可或缺的一部分。
CMDB及其基礎架構可分為三大層面：CMDB本身、與CMDB相互有連結的相關資料（稱之為「CMDB延伸資料」），以及與這兩層互動的應用程式（稱之為「CMDB 環境」），如上圖四所示。由CMDB及「CMDB延伸資料」兩層所構成者即為ITIL所稱的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成為記錄來源，同時連到相關資料與較不重要的屬性。
- 允許開放的資料存取。
- 其他於本篇文章沒有提到的，如：支援以物件為導向且可擴充的資料模型、支援組態分割、支援組態調解...等等。
