IO 功能： 以 ITIL/COBIT 為基礎的管理程序 - 基本至標準化層級

  • 發行項
本頁內容

簡介 簡介
需求： 支援與變更管理程序 需求： 支援與變更管理程序
檢查點： 支援與變更管理程序 檢查點： 支援與變更管理程序

簡介

基礎結構最佳化模型中強調的所有工作都必須定義最佳作法程序，才能獲得最大效益和效能。下表列出在以 ITIL/COBIT 為基礎的管理程序中移至標準化層級的高層級挑戰、適用解決方案，以及優點。

挑戰

解決方案

優點

業務挑戰

整個組織的系統複雜、不相容、昂貴，且提供的服務有限

IT 挑戰

具備極少的 IT 原則和自動化程序

多重軟硬體設定

被動的支援、事件及問題管理程序

沒有資產生命週期管理策略

沒有變更或發行管理程序

專案

使用自行評估工具評估目前作業架構

以發行準備練習驗證變更準備

定義事件與問題管理程序

開發及實作全面性的支援工程師策略

業務效益

使用者具有已知的服務等級協定，並連絡疑難排解問題，提高工作團隊生產力

因可重複的已知程序更容易實作變更

IT 優勢

IT 人員及企業組織會記錄並瞭解 IT 作業

簡易的建構管理可提升 IT 作業效率及未來部署活動

最佳化的標準化層級要求貴組織具備已定義的程序，以進行事件管理、問題管理、使用者支援、建構管理，及變更管理。

需求： 支援與變更管理程序

對象

如果您沒有處理問題、事件、服務、建構和變更管理的程序，請閱讀本章節。

概觀

基礎結構最佳化不僅需要產品和技術。人員和程序對組織的 IT 服務成熟度也十分重要。許多標準和最佳作法組織會處理 IT 服務管理中的人員和程序領域。Microsoft® Operations Framework (MOF) (英文) 應用 IT 基礎結構程式庫 (ITIL) (英文) 及資訊及相關技術的控制目標 (COBIT) (英文) 標準中的許多知識，使 Microsoft 客戶能執行這些技術並且可達成目標。

階段 1： 評估

作業管理中「評估階段」的目標，在於評估組織目前的功能與挑戰。Microsoft 開發出 Microsoft Operations Framework (MOF) 服務管理評估 (SMA)，隨附於 MOF 持續改進藍圖 (英文) 以及較簡易的線上版本 MOF Self-Assessment Tool (英文)，以支援作業評估程序。

image011.jpg

MOF 服務管理評估著重於提升人員與 IT 服務管理程序的效能，並提供可改善業務價值的技術。SMA 會提供詳盡完整的建議，而且這些建議都是企業價值中所必須的，特定關鍵效能指標則提供及支援詳細的服務改進藍圖，以監視改進實作的進度。

階段 2： 識別

MOF 服務管理評估的結果，就是「識別階段」的基礎。評估通常可觸及 IT 作業中幾個潛在需要改進之處。在「識別階段」，我們要考量這些結果並根據業務需要排定改進專案的優先順序。MOF 持續改進藍圖內含工具及工作輔助，可以協助制訂優先順序。

階段 3： 評估與規劃

作業改進的「評估與規劃階段」，必須依賴所識別和排定順序的改進部分。MOF 服務改進計畫 (SIP) 指南可協助您完成這個階段。SIP 區分成兩個主要重點部分： 特定 MOF/ITIL 程序改進和服務改進指南。指南的提供係透過工具協助使用者識別特定問題點、提供專門的修正指引，以及提供主要效能指標支援以衡量程序改進。   

移轉至標準化層級的建議採行程序

本節所提供的建議是以在基本層級所遇到的一般問題，以及標準化層級所需的改進為主。這些僅是建議，特定組織或產業可能有所不同。

在基本層級，通常要花很多時間來管理問題或提供要求服務。隨著 IT 服務管理移轉至標準化層級，問題與要求會排列優先順序，並使用工具加以管理。雖然原則中並未正式化，但是會通訊與維護可接受的服務層級，且使用者知道該和誰連絡以取得 IT 服務。此外，團隊角色、責任以及作業擁有權的範圍都已定義。

標準化層級表示增加工具的使用，以管理和監視 IT 作業與基礎結構。同樣的，變更管理、建構管理和發行管理的程序也會變得標準化而具備可預測性。要注意的是，預先部署測試及穩定變得很重要。標準化層級也表示更適於專案管理，但還是有機會改進多個同步專案與策略計畫的整合。

Microsoft 提供 Microsoft Operations Framework (MOF) (英文) 作為反覆模型，以定義和改善 IT 作業。MOF 將服務管理功能 (SMF) 定義為 IT 組織內部的邏輯作業功能。SMF 可以分為四個廣泛的領域： 變更、操作、支援和最佳化。本指南著重在最佳化的基本層級階段中組織常出現要改進的部分：

  • 事件管理

  • 問題管理

  • 提升使用者支援服務

  • 服務定義和建構管理

  • 實作變更管理最佳作法

視組織而定，這些管理功能的改進不一定會對作業效率和改善產生最大的影響。建議您的組織至少要完成線上自我評估 (英文)，且最好進行完整的服務管理評估 (英文)，以識別幾個需要程序或服務改進的最重要部分。

事件管理

事件管理是一個關鍵程序，可讓組織先偵測事件，然後以正確的支援為目標以盡快解決事件。

事件管理的主要目標為盡快還原一般服務作業，並降低對企業營運造成的負面影響，以維護最佳層級的服務品質與可用性。一般服務作業的定義是服務等級協定 (SLA) 限制中的服務作業。

事件管理的目標為：

  • 盡可能快速還原一般服務。

  • 盡可能降低事件對業務的影響。

  • 確保事件與服務要求的處理一致且不漏掉任何內容。

  • 直接支援最需要資源的地方。

  • 提供資訊以支援要最佳化的程序、要減少事件的數目，以及要執行的管理規劃。

下面各節探討事件管理的主要程序。

階段 4： 部署 (事件管理)

偵測、自助與記錄

偵測程序會透過各種媒體以記錄事件，包括連絡服務台的人員報告的事件，或事件管理系統中的警示所引發的事件。

使用者可以存取自助工具以引發自己的事件、檢查現有事件的進度，以及存取自助資訊。

所有事件都必須記錄，以便追蹤、監視和更新整個生命週期。這項資訊可用於問題管理、報告、程序最佳化及規劃等用途。

服務要求處理

這項程序會定義如何處理服務要求。不同類型的服務要求必須以不同方式處理。服務台可以處理某些要求，而其他要求則需要傳送給其他團隊處理，例如變更管理。

分類及初始支援

分類程序會將事件按照指派的優先順序分類。

初始支援程序則提供事件第一線的解決方式。若要如此操作，可以檢查已知的錯誤、現有的問題以及先前的事件，以找出記錄的因應措施。

調查與診斷

這個程序會處理事件的調查並收集診斷資料，以找出盡快解決事件的方法。這個程序包括提升至較高的管理層級或技術專業，如果必須符合 SLA 目標還可提升功能性。

主要事件程序

主要事件程序所探討的是關鍵事件，需要超越一般事件程序所提供的回應。此類事件可能會對維持作業或有效執行業務的能力產生重大的影響。雖然這些事件仍遵循一般事件生命週期，但主要事件流程提供這些高優先性事件所需強化的協調、擴大、通訊及資源。

解決方式與復原

解決方式與復原程序包含解決事件所需的程序，通常是透過變更管理程序以實作修正動作。採取動作後，就會確認解決成功。

事件解決 (例如取代錯誤硬碟) 之後，可能需要執行復原動作，例如還原資料及重新啟動服務。

問題結束

這個程序可確保客戶滿意在結束事件記錄前就先解決事件。

問題管理

在事件管理程序時實作問題管理程序，組織就可以識別並解析任何重大或重複性事件的根本原因，因而降低重複發生的可能性。

問題管理的目標為：

  • 找出並取得會影響基礎結構與服務的問題擁有權。

  • 採取步驟以降低事件與問題的影響。

  • 找出問題的根本原因，並以建立已識別問題的因應措施或永久解決方案為目標啟始活動。

  • 使用記錄的問題與事件資料執行趨勢分析以預測未來的問題，並將問題管理活動排列優先順序。

下面各節探討問題管理的主要程序。

階段 4： 部署 (問題管理)

問題記錄與分類

這個程序負責處理問題的初始偵測與記錄。問題可能是透過事件管理程序所報告，或經由問題管理團隊所收集的資料分析所偵測。您必須將問題與現有事件連結並記錄問題，以協助排列問題解決方式的優先順序。當您記錄問題，要評估對業務的影響，並判斷解決問題的緊急性。這項評估可以判斷問題的分類。

問題調查與診斷

這個程序負責調查問題及診斷根本原因。接著資料可以用於協助問題管理團隊評估解決問題原因所需的資源與技術。這個程序包括需要其他規劃、協調、資源及通訊的主要問題，以及何者可能導致啟始正常的專案。

錯誤控制

錯誤控制程序處理的是成功修正已知的錯誤。目標為變更 IT 元件或程序，以移除影響 IT 基礎結構的已知錯誤，因而避免事件再次發生。

問題結束

問題結束程序描述完整記錄所有錯誤詳細資訊的需要。必須儲存有關所有問題的組態項目 (CI)、症狀及解決方法或規避動作的資料。如此可建立組織的知識庫。

成功的變更實作以解決錯誤後，就可以結束錯誤記錄以及任何相關的事件或問題記錄。接著實作後續審核 (PIR) 就可以確認解決方案的有效性。

提升使用者支援服務

支援服務又稱為服務台，是連絡組織的第一步。能有效的回應客戶問題與考量，有助於提升企業聲望。

服務台的目標可因各種因素而不同，例如組織的規模以及定義的服務台功能範圍。

服務目標包括：

  • 提供使用者與 IT 部門間的單一及中央連絡點。

  • 提供使用者使用其他服務管理功能的介面。

  • 提供高品質支援以達到業務目標。

  • 識別並降低 IT 服務的整體擁有成本 (TCO)。

  • 支援跨越業務、技術與程序界限的變更。

  • 提高客戶滿意度。

  • 留住所有客戶。

  • 識別其他商機。

服務台功能中的主要程序於下列章節中討論。

階段 4： 部署 (服務台)

記錄及服務事件

事件 (Incident) 是不屬於服務標準作業中的單一事件 (Event)。事件可能會導致服務正常作業中斷，或降低服務的品質。

在這個情況下，服務台的功能在於協助受影響的使用者盡快還原服務。

管理服務要求

服務要求可以是下列任何一種：

  • 變更要求。

  • 資訊要求 (即查詢)。

  • 視需要的工作要求。

  • 採購要求。

  • 使用者與 IT 部門之間的通訊 (例如，申訴、讚美、意見或建議)。

在這個服務要求的情況下，服務台的功能就是確保必須直接滿足要求，或將要求分配至適當的解析群組，以達到使用者滿意度。

服務定義和建構管理

有效管理 IT 基礎結構的主要原則，就是記錄其元件以及之間的關係。建構管理提供制訂決策的基礎，以決定變更管理、協調 SLA、評估 IT 容量及其他關鍵程序。

建構管理是一個關鍵程序，負責識別、控制及追蹤所有版本的硬體、軟體、文件、程序、流程，以及 IT 組織的其他元件。建構管理的目標，在於確定只有授權的元件 (稱為組態項目，CI) 會使用於 IT 環境中，並且記錄及追蹤 CI 元件生命週期的所有變更。建構管理程序包括下列目標：

  • 識別組態項目及其關係，並將項目加入至建構管理資料庫 (CMDB)。

  • 可存取 CMDB 及 CI 以使用其他功能。

  • 更新及變更 CI 會使發行管理程序期間的 IT 元件變更。

  • 建立審核程序，確保 CMDB 精確的反映生產 IT 環境。

下列章節探討建構管理的目標。

階段 4： 部署 (建構管理)

建立組態項目 (CI)

在您設計 CMDB 時，必須判斷每一個 CI 詳細的適合層級。然後組織中的每一個 CI 都可以加入至 CMDB 中。

除了資產管理外，建構管理所提供的其中一個重要優勢，在於 IT 元件之間的關係模組化。例如，工作站是由桌上型電腦、作業系統及應用程式所組成的，而工作站則連接至網路並使用網路。適當的瞭解並記錄 IT 元件之間的關係，以便詳細的分析對提議變更所產生的影響。

存取組態項目

當您將有關 IT 元件以及關係的資訊加入至 CMDB 後，資訊就可由其他 SMF 使用。例如，變更管理使用 CMDB 內所定義的關係，以決定變更 IT 環境中其他元件的影響。

變更組態項目

發行管理開始對 IT 元件進行變更時，就必須對 CMDB 進行對應的變更。沒有精確和最新的資訊，建構管理就沒有價值。應該在所有地方自動執行這個程序。由於資訊量及變更頻率，只有小型企業適合以手動輸入資料。

審核組態項目

儲存在 CMDB 中的資訊精確性，對於變更管理與事件管理 SMF 以及其他服務管理功能是否能夠成功，非常重要。必須建立審核程序，以確定資料庫精確的反映生產 IT 環境的需求。

實作變更管理最佳作法

變更管理說明一致的程序，以啟始基礎結構變更、評估與記錄潛在的影響、核准實作，以及排程和審核部署。

變更管理的目標在於提供原則化的程序，以引進必要的變更至 IT 環境，並盡可能避免中斷持續性的作業。若要達到這個目標，變更管理程序包括下列目標：

  • 提出要求變更 (RFC) 以正式啟始變更。

  • 評估變更的緊急性以及對基礎結構或使用者的影響後，指派優先順序和分類。

  • 建立有效的程序，將 RFC 傳遞給決策者，以核准或拒絕變更。

  • 規劃變更部署。

  • 搭配發行管理以管理變更的發行和部署至生產環境。如需有關 MOF 發行管理 SMF 的詳細資訊，請至 https://www.microsoft.com/technet/solutionaccelerators/cits/mo/smf/smfrelmg.mspx。

  • 執行實作後續審核，以判斷變更是否已達到目標，並判斷是否要維持或逆轉變更。

下列章節探討建構管理的目標。

階段 4： 部署 (變更管理)

程序變更要求

一般而言，業務環境中的任何人都可以要求變更，以成為變更啟動者。因為潛在的變更啟動者集區很多，而且包括熟悉相關程序不同層級的人員，所以需要程序以產生品質與完成度一致的變更要求，並捨棄不相關的要求。

將變更分類指派給接受的變更要求

在這個階段，雖然尚未核准，但變更要求已通過啟始篩選。下一個需求就是區別變更的優先順序與分類。即使優先順序與分類已由變更啟動者輸入，變更管理員或指定的代理人還是會加以審核，且具有權限可以視需要加以更改。

變更授權

變更管理員正確的排列優先順序和分類變更後，就必須授權變更。

變更開發

在 RFC 核准後 (根據優先順序與分類使用適當路徑)，就會移至變更開發階段。這個階段所討論的是規劃變更、開發變更交付項目 (例如，開發新程式碼或設定新硬體)，以及移交發行管理程序等必要的步驟，以便將變更部署至生產環境。

變更審核

成功的發行與部署至生產環境後 (如果是標準變更則為部署至生產環境後)，必須執行審核程序以判斷變更是否會產生想要的效果，以及是否達到原始變更要求的需求。

建議閱讀

MOF 支援象限

MOF 變更象限

檢查點： 支援與變更管理程序

需求

 

實作事件管理技術。

 

實作問題管理技術。

 

提升使用者支援服務。

 

實作服務定義和建構管理

 

實作變更管理最佳作法。

如果您已經完成上列步驟，則貴組織就已達到基礎結構最佳化模型中，「以 ITIL/COBIT 為基礎的管理程序」功能的支援與變更管理程序標準化層級的最低要求。

建議您遵循 Microsoft Operations Framework (英文) 的支援 (英文) 與變更 (英文) 象限中所說明的其他最佳作法，並開發 MOF、ITIL 及 COBIT 概念的知識庫。