AdvancedITIL: ITIL 的目標

ITIL 的目標

組態管理目標

第 4 章

許多 ITIL 專家都說「組態管理」就像是 ITIL 中的太陽，並由其他 ITIL 行星環繞著。這個比喻很真實，因為所有其他的 ITIL 程序都與「組態管理」有著非常密切的關係。因此，符合「組態管理」的目標是成功建置 ITIL 的關鍵。您是否符合 ITIL「組態管理」目標？讓我們稍微檢視一下：

「組態管理」藉由找出、控制、維護與確認現有「組態項目」(CI)的版本來提供基礎架構或某項服務的邏輯模型。

「組態管理」的目標有：

  • 負責企業內的 IT 資產與組態及其服務
  • 提供組態的正確資訊及其文件說明以支援所有其他的「服務管理」程序
  • 為「事件管理」、「問題管理」、「變更管理」與「版本上線管理」提供紮實的基礎
  • 將組態記錄與基礎架構相比較並修正任何例外

讓我們將「組態管理」目標細分為基本元素，並找出能夠充分支持 ITIL 觀點的項目：

“「組態管理」藉由找出、控制、維護與確認現有「組態項目」(CI)的版本來提供基礎架構或某項服務的邏輯模型”：

在我們檢視這項要素時，我們需要先了解 ITIL 對組態項目的定義：

一項基礎架構的元素，或是項目，也就是說 (或即將是) 受到組態管理的控制。從整個系統 (包括所有的硬體、軟體與文件說明) 到單一模組或次要的硬體元件，個別的 CI 依其複雜度、大小與類型來說差異性可能非常大。

「組態項目」是一項基礎架構元件，用來提供所需的服務、系統與應用程式以便提供同意的服務給 IT 客戶。CI 的複雜度完全由您選擇，例如，您可以決定某個工作站當作一個 CI，或是將工作站細分為元件 (處理器、鍵盤、滑鼠與螢幕)，這些元件每項都是一個 CI。「組態管理」主要是有關 CI 之間的關係，也就是說，藉由觀察某個 CI，您可以知道它與其他 CI 的關係以及這些 CI 如何共同處理某項特殊的系統或服務。「服務台」可以利用這些 CI 之間的關係來建立衝擊並決定優先次序。請注意，「資產管理」將資產細節維持在一定比值、其商務單元以及其位置之上，而「組態管理」則同時負責維護資產間的關係，而這是「資產管理」所辦不到的。

在您嘗試評估是否符合此目標要素時，首要問題就是確定您是否擁有可指出 CI 或是資產之間關係的資料庫。如果沒有的話，您如何找出受衝擊的範圍？您如何復原遠端的災難？首先，先看看您是否擁有集中式的「資產資料庫」。如果有的話，看看它是否顯示項目之間的關係，然後依此準備您的專案。您可能會發現如果沒有集中式的「資產資料庫」這事本身就足以證明 ITIL 的適當性。

這項目標要素主要內容有：找出、控制、維護與確認「組態項目」的版本。在這裡您需要決定是否擁有管理 CI 從生到死的生命週期的標準方法。如果有的話，看看這個方法是否涵蓋所有的 CI 且方法受到良好的維護。要判斷資料是否正確的好方法就是看看「服務台」接到的客戶來電中，有關元件的部分是否列在「組態/資產資料庫」中。例如，客戶抱怨：「我的掃描器沒辦法用。」「服務台」回答：「這不奇怪，因為根據我們的記錄，您根本沒有掃描器」。(這情況讓人很臉紅，但卻清楚說明此觀點。)總之，需要檢查的兩件事就是您擁有找出與控制 CI 的程序，而且您擁有與維護這些 CI 現狀的程序。根據您得出的結果來準備您的論點內容。

「組態項目」是一項基礎架構元件，用來提供所需的服務、系統與應用程式以便提供同意的服務給 IT 客戶。CI 的複雜度完全由您選擇，例如，您可以決定某個工作站當作一個 CI，或是將工作站細分為元件 (處理器、鍵盤、滑鼠與螢幕)，這些元件每項都是一個 CI。「組態管理」主要是有關 CI 之間的關係，也就是說，藉由觀察某個 CI，您可以知道它與其他 CI 的關係以及這些 CI 如何共同處理某項特殊的系統或服務。「服務台」可以利用這些 CI 之間的關係來建立衝擊並決定優先次序。請注意，「資產管理」將資產細節維持在一定比值、其商務單元以及其位置之上，而「組態管理」則同時負責維護資產間的關係，而這是「資產管理」所辦不到的。

在您嘗試評估是否符合此目標要素時，首要問題就是確定您是否擁有可指出 CI 或是資產之間關係的資料庫。如果沒有的話，您如何找出受衝擊的範圍？您如何復原遠端的災難？首先，先看看您是否擁有集中式的「資產資料庫」。如果有的話，看看它是否顯示項目之間的關係，然後依此準備您的專案。您可能會發現如果沒有集中式的「資產資料庫」這事本身就足以證明 ITIL 的適當性。

這項目標要素主要內容有：找出、控制、維護與確認「組態項目」的版本。在這裡您需要決定是否擁有管理 CI 從生到死的生命週期的標準方法。如果有的話，看看這個方法是否涵蓋所有的 CI 且方法受到良好的維護。要判斷資料是否正確的好方法就是看看「服務台」接到的客戶來電中，有關元件的部分是否列在「組態/資產資料庫」中。例如，客戶抱怨：「我的掃描器沒辦法用。」「服務台」回答：「這不奇怪，因為根據我們的記錄，您根本沒有掃描器」。(這情況讓人很臉紅，但卻清楚說明此觀點。)總之，需要檢查的兩件事就是您擁有找出與控制 CI 的程序，而且您擁有與維護這些 CI 現狀的程序。根據您得出的結果來準備您的論點內容。

“負責企業內的 IT 資產與組態及其服務”：這是一項很重要的目標，因為並非所有的 CI 都是顯示為資產。例如，內部人員撰寫的程式、程序性說明文件以及人員在正常情況下都不被當成資產，但是他們都是屬於「組態項目」。這個目標要素意味著必須執行檢查以確保所有潛在的 CI 都被納入「組態管理資料庫」(CMDB) 中。您很容易就可以得知是否符合這項要素。您檢查了嗎？當然，如果您尚未擁有 CMDB，則您將無法檢查。

“提供組態的正確資訊及其文件說明以支援所有其他的「服務管理」程序”：假設您的 CMDB 中資料是正確的，問題是：您要如何使其他「服務管理」程序能夠利用到這些資料？「服務管理」程序中的整合便扮演關鍵角色。例如，當「服務台」將資料輸入「事件」記錄中時，CI 資料庫會自動在記錄中填入組態與說明文件資訊嗎？或著，「服務台」代理人需要手動輸入該資訊？更甚者，因為資料尚未齊全所以您根本無法輸入？若要檢查您是否符合此目標要素，看看其他的「服務管理」程序並找出是否有未善用 CMDB 資料的地方。當然，如果您尚未擁有「組態資料庫」，則您將無法檢查。

“為「事件管理」、「問題管理」、「變更管理」與「版本上線管理」提供紮實的基礎”：「事件」、「問題」與「變更管理」等程序利用 CMDB 作為資訊來源或是更重要的決策依據。一項正確且完整的 CMDB 能夠促成思慮周延的決策，以便找出問題或事件的衝擊，同時也有利於潛在變更的成本計算，也改善了問題回報的正確性。

關於「服務管理」的知識工具已經有太多人討論過，最重要的知識就是了解您所擁有的所有資產，其位置、相互關係；也就是指 CMDB 內的資訊。然而，人們通常忽略掉 CMDB 的重要性。這項目標要素將著重在 CI 內含的屬性。擁有 CMDB 還不夠，您必須在每個 CI 內擁有資料以便提供有意義的資訊給其他「服務管理」程序。看看您的 CI 屬性或欄位以確定這些資料是否提供有用的資訊給其他「服務管理」程序。您將需要詢問其他程序的擁有者，看看他們是否得到所需的資料；如果沒有的話，還需要哪些額外的資料。從這裡您就可以決定是否已符合目標要素。當然，如果您尚未擁有 CMDB，則您將無法檢查。

“將組態記錄與基礎架構相比較並修正任何例外”：如上述，「組態管理」提供資訊與資料給所有其他的程序。這個要素關聯到先前的要素，但是不需要所有的 CI 存在於 CMDB，而是 CI 內容必須正確。就像先前的要素一樣，您很容易就可以確認是否符合此要素，問題是您檢查了沒？當然，如果您尚未擁有 CMDB，則您將無法檢查。

現在您已經看過許多遍「當然，如果您尚未擁有…，則您將無法檢查。」之類的說明。然而您還是忽略了這個訊息。根據估計，花在 Y2K 的 70% 的營收，幾乎都是用在追蹤資產與其關係。如果您尚未擁有一個集中式、正確且完整的 CMDB，則您應該立即提高警覺。

> > 第 5 章 - 版本上線管理目標