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

  • 發行項
本頁內容

簡介 簡介
需求： 操作、最佳化，以及變更程序 需求： 操作、最佳化，以及變更程序

簡介

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

挑戰

解決方案

優點

業務挑戰

SLA 為非正式或隱含性

以基本組建檢查清單和試算表組成的非正式建構管理

IT 挑戰

非正式的發行管理

專案

對整個 IT 作業實作服務層級管理

實作最佳發行管理作法

最佳化網路及系統管理程序

實作最佳工作排程作法

業務效益

主動的 IT 作業可提早解決問題，避免降低使用者生產力

IT 優勢

自動化服務與工具可釋出資源，以便實作新服務或最佳化現有服務

擁有正式的 SLA 能提高 IT 的信譽，繼而建立 IT 與業務之間的聯繫

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

需求： 操作、最佳化，以及變更程序

對象

如果您還沒有採用服務層級管理、發行管理、系統管理、網路管理和工作排程方面的程序，請閱讀本章節。

概觀

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

階段 1： 評估

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

圖 16. MOF 持續改進的生命週期

圖 16. MOF 持續改進的生命週期

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

階段 2： 識別

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

階段 3： 評估與規劃

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

移轉至合理化層級的建議採行程序

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

雖然標準化層級會增加使用管理與監視 IT 作業與基礎結構的工具，以及諸如變更管理、建構管理和發行管理等程序成為標準化且可預期的環境，但在重要領域方面仍有改進的空間。服務層級管理對於非正式或僅有隱含性質的服務等級協定 (SLA) 為基本處理。建構管理屬於非正式性質，一般是由基本的組建檢查清單和試算表所組成，發行管理則定義不夠完善，缺乏嚴謹性。

合理化基礎結構在管理桌上型電腦和伺服器方面，所需的花費是最低的，而程序和原則經過最佳化，在支援和擴充業務上開始擔任重要的角色。安全性具備高度的主動性，而且可以快速因應和控制威脅與挑戰。採用零接觸的部署可大幅降低成本、部署時間和技術上的挑戰。映像的數目極少，管理桌上型電腦的程序極為精簡。這些客戶的軟硬體清查十分清楚徹底，並且只採購需要的授權和電腦。所採取的原則和控制非常嚴格，因此從桌上型電腦到伺服器、防火牆和外部網路，都具備高度主動的安全性。

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

  • 服務層級管理

  • 發行管理

  • 系統管理

  • 網路管理

  • 工作排程

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

服務層級管理

服務層級管理 (SLM) 是使得業務需求與 IT 服務的遞送相吻合的關鍵程序。它能形成與業務之間的介面，允許其它 SMF 在成本合理之下提出符合業務需求的 IT 解決方案。主要目標在於成功地提供、維護和改善 IT 服務。

SLM 是用來透過定義、協定、作業測量與審核的程序，達到調整和管理 IT 服務的目的。SLM 的範圍包括定義組織的 IT 服務，並且制定這些服務的 SLA。為了確保履行 SLA，會針對內外的服務遞送，運用支援合約 (UC) 和作業等級協定 (OLA)。將「服務層級管理」引入企業並不能立即改進所提供的服務層級。這是需要長期投入的工作。起初，服務的改變可能很細微，但只要假以時日，就能不斷改進，達成目標，然後超越目標。

組織若要實作服務層級管理，首先必須評估 IT 為組織的客戶提供哪些服務，並且判斷這些服務目前已採用哪些合約。這項評估往往讓 IT 服務部門這才恍然大悟，瞭解期望之下必須達到的服務範圍。憑著這次活動所取得的資訊，組織就能夠開發與實作「服務層級管理」程序的完整優勢。

服務層級管理要求 IT 組織充分瞭解本身所提供的服務。實作服務層級管理時，須遵循下列步驟：

  • 建立服務類別目錄。

  • 開發 SLA。

  • 監視及報告。

  • 定期執行服務層級審核。

SLA 的開發須符合服務類別目錄中所正式記錄服務項目的需求與優先順序、SLA 協商之下指定的需求、依照協定準則對服務實施的監視，和這份資訊的報告與審核，以突顯並且移除服務效能層級中的失誤。

階段 4： 部署 (服務層級管理)

設定活動

設定活動是在服務層級管理專案開始時所執行的一系列評估步驟。這些初步性質的步驟能夠協助企業判斷是否有服務層級管理的這個需要，以及是否擁有能夠實作的資源。在這套程序當中，將由 IT 部門取得現有服務與管理活動的快照，訂定出企業的基準。最後一個步驟則是分析從先前步驟當中所收集的資訊，再運用結果來規畫服務層級管理的實作，為企業謀取最大的優勢。

建立服務類別目錄

服務類別目錄會列出目前所提供的服務、摘要服務特性、描述服務的使用者，以及詳細說明負責持續維護的人員。

服務是依照企業組織的看法所定義的。例如，電子郵件可以是一項服務，列印也可以是一項服務，而無論為一般使用者提供服務所需要的服務元件數量有多少。

使服務類別目錄正式化因為能夠建立官方承認的記錄，所以是很重要的步驟。讓服務類別目錄成為組織內的正式記錄，即可接受變更控制。由於唯有記錄受到維護並且正確才有價值，所以這一點很重要。

使服務類別目錄正式化的方式很多。判斷以哪一種方式最為適用時，請考慮您想要如何檢視、報告，和使用服務類別目錄。服務類別目錄可以儲存在建構管理資料庫 (CMDB) 中，作為一個元件 (服務類別目錄) 或是其服務。Microsoft 應用程式，例如 Microsoft Excel 或 Microsoft Access，可以用來記錄服務以及例如元件、效果、優先順序，和 SLA 與 SLO 等等詳細資料。如果選定的工具允許服務類別目錄成為 CMDB 的部分，則可藉由將服務類別目錄中的資訊與 CMDB 中的建構項目 (CI) 相整合，達到附加價值的效果。之後就能使用 CMDB，為變更管理 SMF、事件管理 SMF 與所有其它 SMF 附加更多價值。

開發服務等級協定 (SLA)

SLA 是 IT 服務提供者與客戶/使用者社群之間制定的協定。SLA 能使客戶/使用者對於服務層級的需求正式化，並且定義所有相關各方的責任。

建立 SLA 的步驟如下：

  • **定義 SLA 的類型。**例如，屬於內部、外部、作業層級，還是多服務層級的協定？

  • 定義 SLA。 例如，提供的服務層級，包括諸如可用性、因應能力與效能、完整性與正確性，和安全性等可度量的事項。

  • **協商與議定 SLA。**例如，判斷所議定的項目是否能在企業與 IT 部門的合理成本之下提供。

  • **將 SLA 作成正式記錄。**例如，以書面方式記錄下議定內容以及相關各方。

使 SLA、OLA 和 UC 的承諾成為一致

支援合約 (UC) - 與針對 SLA 建立服務交付項目的協力服務提供者之間所簽訂，具有法定約束力的合約；另外還有作業等級協定 (OLA) - 支援 SLA 需求的內部協定 - 必須要有與 SLA 承諾一致的服務評量標準。

服務層級監視

服務層級管理需要對 IT 服務的達成實施一個持續週期的議定、監視與報告，並且採取適當行動，使得服務層級與業務需求及成本達到平衡。

議定 SLA 並且施行之後，高效服務層級管理的下一階段就是依照服務層級目標 (SLO) 中所指定的準則，監視服務的效能。有各種方法可以監視服務層級管理，但主要顧慮還是在於準則的表現是否違反 (或幾近違反) SLA 規定。

服務等級協定審核

「SLA 審核」是 MOF 四大作業管理審核 (OMR) 的其中一項。這是管理上的重要檢查點，按照指定間隔實施 (如 SLA 上所規定)。此項審核的用意在於確保企業與 IT 部門有機會依照 SLA 的目標來評估效能，以及審核 SLA 的作業。SLA 審核在審核程序中涉及高階管理，以確保 IT 部門與企業兩者未來對於服務遞送的所有決策都能夠參與和進行溝通。

發行管理

發行管理服務管理功能 (SMF) 負責將變更部署到資訊技術 (IT) 環境中。有一或多項變更經過開發、測試並且封裝成為供部署的版本之後，發行管理便負責引入這些變更和管理其發行。發行管理也能把這些變更合併成為一個版本，共同部署，協助高效引入變更。

發行管理程序的目標是為了確保在干擾最少的情況下，所有的變更都能夠順利地部署到生產的 IT 環境中。因此，發行管理負責：

  • 帶動發行策略，與變更諮詢委員會 (CAB) 協同之下，主導如何將變更部署至生產環境之中的設計、規畫與作法。

  • 依照發行準則 (版本品質、版本包裝與生產環境的就緒程度、訓練與支援計畫、部署與退出計畫，以及風險管理計畫)，判斷各版本是否準備就緒。

發行管理：

  • 提供部署至生產環境中之所有變更的封裝版本，並且只部署經變更管理核准的變更。

  • 需要變更管理來核准變更，並在發行程序全程加以追蹤。

  • 確保進行變更後，這些變更會報告建構管理以求輸入 CMDB 中。

  • 需要建構管理的資訊，以在新版本的開發階段之中，建立與驗證有效的測試環境。

  • 需要建構管理來評估變更對 IT 環境的影響，和提供版本套件的固定儲存區。

階段 4： 部署 (發行管理)

發行規畫

發行程序的第一步是要建立計畫，以識別將版本順利部署到生產環境當中所需要的活動與資源。這個計畫包括判定需要完成的工作、何時必須完成 (時程)，和與其它工作相較之下的優先順序如何。一旦充分瞭解這些議題之後，發行管理員即可擬定詳細的活動計畫，為專案指派適當的資源。在發行管理中，發行管理員所扮演的角色是負責為變更管理所核准的每一個 RFC 建立發行 (專案) 計畫。

發行建立

議定發行計畫之後，即由發行小組的成員識別與開發將版本部署到生產環境之中所需要的程序、工具與技術。雖然絕大多數的版本都能以手動方式部署到生產環境中，但有些工具和技術可以用來執行相同的工作。為善加運用時間和資源，發行小組應當識別出能使部署程序盡可能自動化的工具和技術。

發行機制選定之後，發行小組便建立版本套件，其中包含所需的程序、工具與技術，可以運用選定的機制將版本部署到生產環境中，必要時也可從生產環境中將之移除。

有些版本的版本套件可能只由一套列入記錄的安裝與移除程序所組成。

完成的版本套件應在實驗環境中測試，讓發行小組有一定程度的把握，確信於生產環境中使用時能夠正確運作。假如測試順利通過，版本與版本套件的內容就會送交變更管理，接受控管。

接受度測試

到目前為止，測試的重點是要確認版本與版本套件在開發環境中能夠正確運作。接受度測試允許開發人員與業務代表瞭解在密切反映生產環境的環境中，版本與版本套件的效能如何。在部分情況下，需要藉由試驗測試建立信心，以繼續進行整體組織的變更部署。

雖然在模擬的生產環境中進行測試能讓發行小組對於發行具備一定程度的信心，但仍無法保證版本在條件可能大不相同的生產環境下確實能夠運作良好。因此，可能必須在生產環境中執行一些受控管的測試，以確認版本符合期望。在生產環境中試驗測試版本，會對該環境帶來一些風險，因此只能在版本套件中所含的復原程序已經過測試環境的實證之下，才能夠執行。

發行準備

試驗測試與接受度測試完成之後，下一個步驟就是要為發行準備生產環境，進行準備程序，議定所要採取的行動 - 不是進入發行就緒審核階段，就是把版本退還給變更擁有者或是發行管理員，進行額外工作。

發行管理員、變更管理員與變更擁有者是發行就緒審核的主要參與討論者，但也可包括其它相關團體的代表，例如測試小組、服務台，和使用者社群 (依照發行的性質與規模而定)。

雖然版本在實驗環境和生產環境中可能經過數次測試後仍然失敗，但是這樣的失敗可能不足以阻礙部署。即使對於生產環境有些指涉的意義，但仍可能有一些說服力強的業務性質理由認定，必須部署該版本。

例如，在企業對企業的商用網站中，一項功能 (例如自動化註冊) 可能無法作用。這項功能很容易就能移除，改用手動因應措施。所以，小組可能決定不用這項功能，直接繼續進行。

學到的測試經驗與心得 (還有開發的因應措施) 都會經過擷取並列入記錄。如果測試過程中挑出會影響使用者社群或服務層級的問題，則必須與服務台代表討論因應措施和預期的問題，並確保在部署之前會將因應措施提供給服務台。可能必須發起其它的 RFC，使發行工作能夠依照計畫運作。無論哪種情形，都必須把決策和其它支援的資訊全部更新到變更記錄檔中。

發行部署

將版本部署到生產環境的程序，取決於版本的類型與性質，和選定的發行機制。無論如何，發行管理員都應該拿到狀態報告，以及視情況取得用來追蹤與監視部署進度的工具和技術。部署過程中，若對 IT 元件作出變更，也必須隨之對於在 CMDB 中將之模組化的設定項目與關係作出相對應的變更。

版本一經部署之後，發行管理員會先確認運作正常，才繼續進一步的部署。有些版本的情形是，可由技術支援人員使用一些工具和技術來取得確認，也有的是需要由發行管理員請服務台連絡個別使用者，徵詢意見反應和意見。

如果版本不合乎期望、或部署過程中發生嚴重問題，可能需要問題管理來協助識別與診斷問題的根本成因。如果找得到適合的修復或因應措施，則應列入正式記錄，並且建立變更要求，以部署到生產環境當中。否則，可能可以執行退出程序，將版本從該環境中移除。

發行部署階段完成時，發行程序必須確保為了支援發行而採用的因應措施或 RFC 的相關結果與資訊，全都列入正式記錄。如果必須將版本退出，也必須列入正式記錄，包括支持這項決定的所有資訊在內。

系統管理

系統管理功能可執行安全性管理、服務監視和控制、工作排程、網路管理、目錄服務管理、列印與輸出管理，以及儲存管理。這項功能的設計、開發與實作方式是依照組織的規模與架構來決定的。大型組織會有定義明確的模型，較小的組織可能會合併功能，以便維持系統的健全狀況和操作功能。

系統管理 SMF 的目標是為了每日例行性的管理運算環境。隨之而來的是管理生產環境中的各項元素，與提供操作上的支援。

系統管理功能負責提供管理服務，以支援含有集中與分散式硬體兩者的運算環境。

也可能在未直接負責實作與管理的其它 SMF 執行功能管理的情形下，由系統管理功能提供協助。此協助可能包括：

  • 服務監視和控制功能的第一層效能與容量監視。

  • 帳戶管理的每日例行功能管理，包括新增、刪除或移動帳戶。為目錄服務管理和安全性管理查詢資源，例如印表機和安全性存取權。

  • 為「列印與輸出管理」管理產生列印報告與輸出所用的資源。

  • 備份與還原重要資料所需的系統管理工作。

  • 強制實施安全性原則，以保護資料與共用網路資源，包括檔案、資料夾和印表機。

階段 4： 部署 (系統管理)

實作集中化的系統管理模型

集中化的系統管理模型內，所有或大多數的操作與支援功能都集中位在單一或多個站台中。隨著區域網路、廣域網路、分散式與用戶端伺服器的運算與支援網路的成熟，已有越來越多組織針對所安裝的資源、應用程式和解決方案方面，大步朝著集中化支援的方向邁進。

給遠端站台和分公司的頻寬越來越普遍，並且能夠負擔。支援分公司運算 (傳輸通訊協定、遠端存取工具、無周邊伺服器等等) 的基本技術已經改進，使得各分公司本身不再需要個別的支援人員。因此，企業越來越能夠針對分散到遠端站台或分公司的系統，維護其可用性、可靠度、每日例行支援，與管理所需要的基礎支援功能加以集中化。

集中化的系統管理一般認定所有或大多數的運算系統與資源都集中位置加以管理 (系統管理)。雖然這種情形日益普遍，但仍然會有個案的特定解決方案 (也就是自訂應用程式、專用資料庫等等) 並未集中到企業的資料中心，而是分散到遠端分公司或站台。這種有部分應用程式與資料庫分散的情形，並不妨礙讓系統管理模型採取集中化的方式。

實作集中化/遠端的系統管理模型

集中化/遠端的系統管理模型能夠發揮完全集中化模型的大多數優勢。大多數的系統管理仍舊在集中位置 (例如，中央資料中心) 執行，以對執行系統管理功能所需的資源維持最大的控制與整合程度。

不過，由於遠端資料中心的環境在維護上必須以本機系統管理儘可能減少為原則，還是有部分控制與資源整合必須放棄。分散式系統的修正性系統維護需求可能包括電腦必須重新啟動的系統更新，以及磁帶備份和儲存工作。依照所管理的應用程式或特定系統而定，可能還有其他本機站台的系統管理需求；您必須基於技術的應用方式來判斷必須要有哪些特定的職責。

集中化/遠端的系統管理模型說明所有主要系統管理控制功能留在集中位置之下，分散到遠端位置的系統。如同以上所描述，目前需要在遠端或區域位置有資料中心存在，以便放置伺服器或儲存設備。這就表示在資料中心的基礎架構上頭會有成本發生，包括實體廠房、樓板空間、電源、佈線、HV/AC 和安全性元件。

如果技術應用發展到這個模型不再可行的地步 (換句話說，不再符合服務等級協定)，或不再合乎成本效益，則您可能需要移至分散式系統管理模型。如為分散式的系統管理模型，運算資源以及人力資源會實際設在遠端位置。這種模型會在下一節中描述。

實作集中化/委派的系統管理模型

這個模型嘗試充分落實具有全部固有功能與優點的最佳集中化與遠端系統管理模型，又同時體現分散式系統管理模型的一些優點。得到這些優點的作法是把相對小型並且專門的系統管理工作與職責子集推送到當地分公司和遠端站台。

如同集中化的模型一般，主要的系統管理功能和系統管理工作力設在企業 (中央) 資料中心 - 所有系統管理的指示與控制都來自這個位置。由集中化的資源繼續管理集中化的資料中心型網路伺服器與服務；這些集中化的資源也在合理、並且適用的可能情形下，儘量繼續以遠端方式透過網路管理服務。

某些情況要求分散特定服務、伺服器與資源；這時若是允許部分系統管理工作在區域或遠端位置執行，可能會來得謹慎及/或更有效率。其作法是委派極為特定的授權給遠端位置的資源。「極為特定的授權」是指允許遠端系統管理員執行特定零散工作的系統管理權限與存取權限的小型子集。

實作分散式的系統管理模型

分散式系統管理與其它模型不同，必須倚賴位在遠端站台或分公司的充分支援資源。由位在遠端站台的資源執行所需的基礎 (卻屬關鍵) 性支援功能，讓分散到這些站台的系統得以維護健全狀況、可用性與可靠度。

分散到遠端位置的系統維護方面可能仍然有業務上的驅策因素。其中部分的驅策因素可能是有關於效能、延展性、特定類型的應用程式，或支援集中化解決方案的網路頻寬之成本或可用性。

運算與人力資源完全分散到遠端分公司和區域站台。於是，組織可針對特定技術的應用項目體現更佳的本機站台效能。

實作集中化資料中心模型的分散式系統管理

第五種可能的系統管理方式，本文中稱為「日不落」(follow-the-sun) 模型，也可以稱為「分散式系統管理集中化資料中心」(多數) 模型。

這裡的「日不落」是指隨著部分分公司打烊，其它的正要開始營業，把支援的職責移轉至全球的不同區域，以全球性地提供每週 7 日的全天候支援。

這種模型相當獨特，不如前文所說明的四種基本模型那麼普遍實作。不過，有一點必須注意，那就是確實有企業已經嘗試或目前正在嘗試在組織內實施這種模型。

網路管理

網路管理服務管理功能著重在作業網路，也就是電腦系統與共用周邊彼此通訊所透過的基礎架構元件。這是 IT 基礎架構的最基本層級，若沒有網路設施，就沒有基礎架構，只剩下個別電腦的集合而已。

網路管理 SMF 的目標在於提供與參照處理程序的堅實基礎，以便每日例行性地管理網路環境。隨之而來的是管理生產環境中的各項元素，與提供操作上的支援。SMF 的目標包括提供擴展現有網路設施的規畫與部署服務，以及疑難排解和修復網路環境中所發生錯誤的支援服務。透過高效地實作網路管理 SMF，IT 組織預期能夠：

  • 增進網路基礎架構的部署。

  • 改進疑難排解的程序與相關的事件管理程序。

  • 提高網路可靠度。

  • 強化 IT 解決方案與服務的可用性。

網路一般的組成份會有硬體 - 包括纜線、路由器、交換器、集線器、實體伺服器等等元件 - 以及控制硬體元件使用方式的軟體或韌體。依照開放系統互相連線 (OSI) 所描述的網路模型，IT 基礎架構一般為分層結構，從位於堆疊底部之所有服務所用的基底元件，直到頂端的專用應用程式。

組成 OSI 堆疊的分層為 (由上至下依序)：

  1. 應用程式

  2. 展示

  3. 工作階段

  4. 傳輸

  5. 網路

  6. 連結 (資料連結)

  7. 實體

網路管理通常需要用到堆疊中的頭三層，大多數由硬體所組成。傳輸層級的網路與系統管理之間有些重疊，包括讓兩點之間能夠傳輸資料的連結與網路通訊協定。從 MOF 的觀點看來，諸如 DNS、WINS 和 DHCP 等等服務的管理，可提供完整功能 IT 服務所需的基本名稱解析服務。依照組織各不相同，這些核心服務也可能包含在網路服務功能之內。因為 DNS、WINS 和 DHCP 是在伺服器上執行，所以網路伺服器有時會包含在由網路管理 SMF 所管理的硬體元件當中。

階段 4： 部署 (網路管理)

維護網路

操作網路基礎架構大體上就是指監視其效能、對照預期的典範加以評估，若效能下降時並且產生疑難排解的工作項目。網路內部的硬體元件大多數都應該在無需人工維護或干預的情形下操作，也就是說可在製造商的平均故障間隔時間和其它效能準則等規格範圍以內操作。MOF 容量管理 SMF 可提供容量計畫的詳細資料，協助網路設計小組進行網路效能的最佳化。

不過，網路的伺服器型元件的確需要定期注意。這類元件需要視情形定期備份，並依照儲存管理 SMF 評估儲存或容量需求。

支援網路

網路支援會密切地配合「支援象限」中的活動，尤其是事件管理 SMF 和問題管理 SMF。由 IT 網路專家透過事件管理 SMF 中描述的事件解決程序，修正網路錯誤、開發因應措施，防止或減緩網路的隱憂問題。雖然事件管理 SMF 指引文件中有說明解決事件的一般程序，下列章節仍提出網路特定的疑難排解程序。

工作排程

工作排程服務管理功能 (SMF) 是用來確保依照預定時間和指定順序，高效地處理資料，以盡量運用系統資源，並且盡可能使線上使用者不受衝擊。批次處理程序是系統與資料庫的互動，無需使用者參與互動，而且是在背景依序執行。批次處理程序的執行可以自動化，也可以手動。批次執行通常選在使用者與系統互動量低的營業時間過後。

批次執行因為容易是密集使用資源並且長時間執行的重複程序，所以一般需要自有架構。程序通常需要從資料庫讀取大量資料、處理資料，以及將結果傳回資料庫。這個程序是透過執行指令碼來完成的。

組織所執行的批次工作類型包括：

  • 財務管理報告

  • 行銷報告

  • 供應鏈管理報告

  • 清查報告

  • 發票報告

  • 客戶帳目處理 (每月帳戶帳單等等)

  • 自動化備份系統與應用程式資料

  • 系統處理摘要與容量計畫報告

階段 4： 部署 (工作排程)

批次架構

批次架構是由用來高效管理批次處理作業的程序與元件所組成。批次架構的用意在於離峰時段執行批次，以達到最佳化處理的目的 (改善回應時間與系統資源的使用率)。此架構應該能夠提供給容量管理員易用的介面，並且允許以標準並且集中的方式來進行批次排程、監視、控制和錯誤修正。此架構應該非常具有延展性，以便迎合組織未來的需求。此外也應該具有高可用性，停機時間甚短，並且讓通常與批次作業同時進行的線上作業盡可能不受衝擊。部分組織可能可以決定使用備份元件，例如事件伺服器，以確保能夠完成所有任務關鍵的批次工作。

批次架構的基本元件包括管理伺服器、容量資料庫 (CDB)、監視器、印表機、應用程式伺服器，和資料庫。除了連接管理伺服器的監視器之外，每部應用程式伺服器也應該要有監視器，以便檢視本機批次處理活動，如此一來也能在本機層級進行錯誤分析。

批次處理

討論排定的批次執行之前，最好先瞭解批次處理程序的階層，和批次指令碼的內容。批次執行是由多個獨立的批次工作所組成，這些工作排定以週期性的方式來執行。大型組織可以依照處理所需要的資源，全天候實施多個批次執行。每個批次工作各由控制執行工作之特定活動的多個批次工作步驟所組成。

一個組織通常會處理眾多的批次工作。為確保以一致的方式執行每項工作，批次工作的基本架構應當構思成為包含每項工作所需要的標準化程式碼；特定工作的資訊應當編碼成為基本架構之內的專屬區域。這個基本架構也透過將每個工作指令碼的內容與結構標準化，幫助擬定開發與維護的需求。例如，任何類型的標準化作業，例如批次工作執行成功與否的通知、和交易資料的封存與刪除，都應該包含在所執行的每一個指令編碼中。

排定的批次執行是在預先定義的批次視窗以排程工具起始的，通常選在系統使用者活動最少的時段。以程式設定排程工具之後，批次執行的過程中，除非發生工具無法修復的錯誤，否則容量管理員應該不需要進行互動。

批次執行一律由排程工具來起始。若未能依照排程開始執行，工具會中止執行，並將錯誤記錄在錯誤記錄檔中；部分排程工具也有能力嘗試重新啟動批次執行。如果起始成功，便會執行第一項批次工作。在用來執行批次處理的每部應用程式伺服器上，工作的執行，是由排程器來管理的。如果在工作執行期間沒有發生錯誤，工具就會把順利完成工作記錄在批次記錄檔中，接著執行下一項工作，依此類推。

如果在批次工作執行期間有錯誤發生，排程工具會停止處理那項工作，並且把錯誤送到錯誤記錄檔。批次工作的實際執行取決於一些輸入，因此可能是工作未能執行的原因。例如，可能需要下列輸入項目：

  • 生產資料的可用性

  • 佇列工作相依的工作完成

  • 執行工作所用資源的可用性

  • 工作與批次視窗的優先順序

有些情形，例如若 CPU 或磁碟空間容量超出處理批次工作的應用程式伺服器的閾值時，也可能在處理工作期間產生警告。警告應該不致於使批次工作無法完成；不過，出現警告時，容量管理員一律應當儘速處理，以免導致未來工作處理失敗。如果錯誤造成工作停止，部分排程工具會嘗試自動修復問題，從停止處理時正在執行的工作步驟開始處理工作。若處理極長的批次工作時，復原非常地實用，因為中斷的工作不需要從頭重新開始。如果無法復原，則這項工作必須重新啟動。

如果排程工具無法重新啟動或修復失敗的工作 (或在特定實例中能夠重新啟動或復原)，容量管理員必須手動起始重新啟動或復原程序。

工作排程活動

理想狀態下，批次架構應當設定成為容量管理員所需進行的互動非常少。然而，還是有許多每日例行工作是容量管理員所必須執行的，包括：

  • 監視

  • 分析

  • 微調

  • 實作

  • 事件管理

  • 視需要處理要求

  • 排程變更

  • 系統備份

  • 封存

  • 稽核

  • 容量管理員記錄檔項目

  • 報告

以上每項活動都是工作排程程序不可或缺的部分。監視、分析、微調與實作等活動會形成重覆性程序。對程序的輸入包括資源使用率和監視批次架構所依據的 OLA 閾值。有持續的活動存在，其目標在於使得架構的效能與使用達到最佳狀態。其餘的活動則是因應事件、要求或需求所執行。

文件與訓練

所有原則與程序都應當清楚列入正式記錄，好讓容量管理員能有每日操作指引的參考。文件應當包含下列資訊：

  • 啟動與停止批次執行的程序。

  • 變更工作優先順序的程序。

  • 處理警示與錯誤的程序。

  • 處理常見錯誤的程序。

  • 分析錯誤成因的程序。

  • 將錯誤上報的程序。

  • 提交 RFC 的程序。

  • 將工作記錄到容量管理員的記錄檔中的程序。

  • 監視對象與時機的程序。

  • 視需要處理要求的程序，包括檢視、測試，及執行這些要求。

若無適當訓練，容量管理員將無法進行本文件所探討的活動。必須提供容量管理員適當的訓練，以便處理的錯誤能夠及時因應與修正。如果有的話，容量管理員應該參加組織所運用排程工具的廠商訓練。

詳細資訊

如需詳細資訊，請造訪 Microsoft Operations Framework (英文) 網站。

若要瞭解 Microsoft IT 部門如何使用 Microsoft Operations Framework 與 IT 服務管理的最佳作法，請至 https://www.microsoft.com/technet/itshowcase/content/mofmmppt.mspx (英文)。

檢查點： 操作、最佳化，以及變更程序

需求

 

對整個 IT 作業實作服務層級管理。

 

實作最佳發行管理作法。

 

最佳化網路及系統管理程序。

 

實作最佳工作排程作法。

如果您已經完成上列步驟，則貴組織就已達到核心基礎結構最佳化模型中，「操作、最佳化，以及變更程序」合理化層級的最低要求。我們建議您依照 Microsoft Operations Framework (英文) 作業管理中的其它最佳作法資源的指引進行。