【文章內(nèi)容簡介】 例，可適用于幾乎所有 IT 組織 ，無論其規(guī)模大小，或采取何 種技術(shù)。ITIL 對 IT 服務(wù)管理實踐中涉及的 許多重要問題進行了系 統(tǒng)的分析，包括全. .. . ..學(xué)習(xí)參考面的檢查清單、任務(wù)、程序、責(zé)任等與任何 IT 服務(wù)組織 密切相關(guān)的問題。這些概念的定義也涵蓋了大多數(shù) IT 服務(wù)組織的主要行為 。IT 服務(wù)組織可以借助 ITIL的指導(dǎo)建立和拓展自己的 IT 服務(wù)流程。 運維服務(wù)管理流程體系運維務(wù)管理最核心的是“服務(wù)支持”（ServiceSupport）和“服務(wù)提供”（ServiceDelivery）兩個 模塊。各流程相互貫穿和作用，形成有機整體，共同建立一個健全的服務(wù)管理體系。 如下圖所示： 服務(wù)支持服務(wù)支持的內(nèi)容描述了一個客戶如何訪問適當?shù)姆?wù)，以支持其業(yè)務(wù)。服務(wù)支持包含以下內(nèi)容：. .. . ..學(xué)習(xí)參考 服務(wù)臺我們?yōu)槠髽I(yè)建設(shè)服務(wù)臺，提供統(tǒng)一報障電話，統(tǒng)一報障、統(tǒng)一維修接口，越秀工商可以通過統(tǒng)一的報障電話申請服務(wù)、查詢服務(wù)處理進程，監(jiān)控服務(wù)質(zhì)量。服務(wù)臺(ServiceDesk)是 IT 服務(wù)組織和用戶相互聯(lián)系的接入點。服 務(wù)臺曾經(jīng)被稱為幫助臺(HelpDesk) 。HelpDesk 的主要任務(wù)是記錄，分解和監(jiān)控提出的問題。一個服務(wù)臺可以具備更寬范的角色，如接收變更請求(RFC)，并且可以支撐多種流程中的操作。服務(wù)臺是服務(wù)提供者和用戶之間的日常工作的單一聯(lián)系點。它也是報告突發(fā)事件和提交服務(wù)請求的焦點。正因為如此，服務(wù)臺的職責(zé)是保持將服務(wù)相關(guān)信息，行為和契機通知用戶，并追蹤了解用戶每日的行為。例如，服務(wù)臺可能扮演用戶提交變更請求的聯(lián)系點，基于變更管理流程傳達變更實施計劃，并保持將變更實施進程通知用戶。變更管理應(yīng)該確保服務(wù)臺隨時保持對變更行為情況的掌握。在任何對 SLA 產(chǎn)生影響的事件面前，服 務(wù)臺處于第一線，并維護高速的信息流通道。圍繞突發(fā)事件，服務(wù)臺有可能在其權(quán)限范圍被授權(quán)實施變更。此類變更的范圍可能被預(yù)先定義。當所有相關(guān)變更發(fā)生時，變更管理流程將被告知?；旧?，當對任何 CI 的規(guī)范做出修改之前，變更流程都需要對其進行預(yù)先審批。. .. . ..學(xué)習(xí)參考 突發(fā)事件管理突發(fā)事件管理流程致力于解決突發(fā)事件，并快速恢復(fù)服務(wù)供應(yīng)。突發(fā)事件被記錄下來，并且事件記錄的質(zhì)量決定了相關(guān)的其它流程的效力。服務(wù)臺接近于突發(fā)事件管理流程和問題管理流程，并處于它們之間。如果沒有適當?shù)目刂?，變更有可能引入新的突發(fā)事件。因此需要建立有效途徑對變更進行跟蹤。這是為什么建議持續(xù)不斷地將突發(fā)事件記錄在同一個 CMDB 中，并分類為“問題 ”， “已知錯誤 ”， “變更記錄”等信息，以促 進服務(wù)臺界面的信息溝通能力，簡化事件調(diào)查和報告。突發(fā)事件的優(yōu)先權(quán)及其升級需要作為服務(wù)級別管理流程中的一部分進行協(xié)商，并在 SLA 中備案。突發(fā)事件管理的目標：突發(fā)事件管理的目標是盡可能迅速地根據(jù) SLA 中定義的普通服務(wù)級別作出反應(yīng)，使產(chǎn)生問題后對業(yè)務(wù)行為及組織和用戶的影響最小。突發(fā)事件管理也應(yīng)該保留對事件的有效記錄，以便于衡量和改進流程，并向其它流程匯報。突發(fā)事件流程如下圖所示：. .. . ..學(xué)習(xí)參考 問題管理對于突發(fā)事件有兩種處理方法，一種是對其做出服務(wù)快速響應(yīng)，盡快恢復(fù)其正常運行，另一種是鑒別和解決問題根源。這兩種方法之間存在微妙的區(qū)別，而且經(jīng)常被互相混淆。對其做好區(qū)分具有重要意義。如果問題被懷疑存在于 IT 架構(gòu)內(nèi)部，問題管理流程 將會瞄準其潛在的根源。一個問題可能是被突發(fā)事件暴露出來的，但是顯然，問題管理的目標是解決問題根源，預(yù)防其可能產(chǎn)生的干擾，而不是迅速恢復(fù)系統(tǒng)運行。當問題被識別后(被識別的問題通常稱之為已知錯誤)，通常需要進行一個業(yè)務(wù)決策，決定是否采取永久性措施改進系統(tǒng)架構(gòu)，以預(yù)防再次發(fā)生新的突發(fā). .. . ..學(xué)習(xí)參考事件。如果需要，提交一個變更請求來實現(xiàn)改進。為了有效和高效地識別突發(fā)事件背后的問題根源及其發(fā)展趨勢，問題管理流程需要準確全面的突發(fā)事件的記錄。問題管理流程同樣需要和可用性管理流程密切聯(lián)絡(luò)，以確定這些趨勢并明確補救措施的重要性。流程： 配置管理配置管理致力于控制一個變化中的 IT 架構(gòu)( 標準化和狀態(tài)監(jiān)控)，鑒別配置項目( 清冊 ，相互關(guān)聯(lián)，審 核與注冊) ，收集和管理有 關(guān) IT 架構(gòu)的文檔，為所有其它流程提供 IT 架構(gòu)的相 關(guān)信息。配置管理是所有其它服務(wù)管理流程不可分割的一部分。擁有當前架構(gòu)中所有部件的最新的，準確的，全面的和詳細的信息，并管理其變更，使這些信息有效而高效地支持其它流程運行。變更管理可以與配置管理集成。至少，建議在配置管理系統(tǒng)中控制變更的登錄和實施，并自在配置管理系統(tǒng)的幫助下對變更影響做出評估。因此所有變更請求應(yīng)該被輸入配置管理數(shù)據(jù)庫(CMDB)，并隨. .. . ..學(xué)習(xí)參考著變更請求的進展隨時更新記錄，直至其實施。配置管理系統(tǒng)識別一個變更項目和架構(gòu)中其它部件的關(guān)系，將這些部件的所有人召集到影響評估流程中來。不管一個變更是否在架構(gòu)中實施，相互關(guān)聯(lián)的配置管理記錄應(yīng)該在 CMDB 中得到更新。最好在 變更發(fā)生時，使用集成工具自動地更新記錄。CMDB 應(yīng)該開 放給整個服 務(wù)支持組，使所有人理解部件失效可能的原因，從而使突發(fā)事件和問題可以被更容易地解決。CMDB 還應(yīng)當被用來把突發(fā)事件及問題記錄和其它記錄聯(lián)系起來，比如失效的配置項目(ConfigurationItemCI)和用戶之間的聯(lián)系。如果缺少了配置管理流程的集成，發(fā)布管理將難以實現(xiàn)，并可能錯誤連連。服務(wù)交付流程同樣依賴于 CMDB 中的數(shù)據(jù)。例如：服務(wù)級別管理需要識別相互結(jié)合在一起的部件，并在此基礎(chǔ)上設(shè)置支持協(xié)議，交付服務(wù)。IT 財務(wù)管理需要知道每 個 業(yè)務(wù)部門使用的 IT 架構(gòu) 部件，尤其是對于收費的項目。IT 服務(wù)持續(xù)性和可用性管理需要識別部件，用于問題風(fēng)險 分析和部件失效影響分析。下圖顯示了配置管理和其它服務(wù)管理流程之間的關(guān)系：. .. . ..學(xué)習(xí)參考圖：能力管理，變更管理，配置管理和發(fā)布管理之間的關(guān)系 變更管理變更管理專注于對 IT 架構(gòu) 實施可控的變更。此流程的目 標是確定所需的變更，并決定這些變更如何在對 IT 服務(wù)產(chǎn)生最小的不利影 響的范圍內(nèi)得以實施。同時確保其變更是可追溯的，而且是經(jīng)過整個組織內(nèi)部有效地磋商和協(xié)調(diào)的。在客戶組織提交變更請求后，由配置管理流程監(jiān)控其狀態(tài)，與問題管理和若干其它流程進行協(xié)調(diào)。變更實施履行一特定的路徑，包括定義，計劃，建立，測試，接受，實施，和評估。變更管理流程依賴于配置數(shù)據(jù)的準確性，以確保獲知所有實行變更造成的影響。因此變更管理與配置管理之間有密切的聯(lián)系。變更流程的詳細內(nèi)容應(yīng)在 SLA 中存檔，確保用戶知道提交變更申請的程序，項目目標及時間，以及實施變更造成的影響。變更的詳細內(nèi)容需要通知服務(wù)臺。即使變更經(jīng)過了全面測試，仍然很有可能存在實施變更的過程中發(fā)生各種困難，這些困難可能緣于變更沒有按需求或. .. . ..學(xué)習(xí)參考預(yù)期運行，或者對變更對功能造成的影響產(chǎn)生質(zhì)疑。變更咨詢會議(ChangeAdvisoryBoardCAB)由可向變更管理小組提供專家意見的人員組成。這個會議很可能由來自于所有領(lǐng)域的 IT 及業(yè)務(wù)單位的人參與。 發(fā)布管理發(fā)布是指一組配置項目(ConfigurationItems –CI)經(jīng)過測試被引入處于活動狀態(tài)的環(huán)境中。發(fā)布管理的主要目標是確保發(fā)布信息被成功地公布，包括歸納綜合，測試與存檔。發(fā)布管理確保只有經(jīng)過測試和正確授權(quán)的軟硬件版本才能提供給 IT 運行環(huán)境。發(fā)布管理與配置管理和變更管理的行為密切相關(guān)。真實的變更實施經(jīng)常通過發(fā)布管理行為得以貫徹。變更的結(jié)果可能經(jīng)常來自于新硬件，新版本軟件，以及新的文檔(自行建立，或購買而來)等。對它們進 行控制，并打包和頒發(fā)。有關(guān)存檔安全和公布程序應(yīng). .. . ..學(xué)習(xí)參考該和變更管理和配置管理流程緊密集成。發(fā)布的程序也可能作為突發(fā)事件管理和問題管理流程中不可分割的一部分，同時還和 CMDB 密切相連，以維護及時更新的記錄。 服務(wù)提供服務(wù)提供主要包括：服務(wù)級別管理、IT 服務(wù)財務(wù)管理、能力管理、持 續(xù)持續(xù)管理、可用性管理等。 服務(wù)級別管理服務(wù)級別管理的目標是縷清與客戶之間有關(guān) IT 服務(wù) 的協(xié)議，并付諸實施。 因此， 服務(wù)級別管理需要收集客戶需求， IT 服務(wù)組織 可提供的設(shè)施，以及可. .. . ..學(xué)習(xí)參考用的財務(wù)資源。 服務(wù)級別管理針對提供給客戶的服務(wù) (聚焦客戶的)。因此是基于客戶需求建立服務(wù) (需求拉動) ，而非單純基于現(xiàn)有技術(shù)所及( 供應(yīng)驅(qū)動)，從而使 IT 服務(wù)組織 提高客 戶滿意度。服務(wù)級別管理 闡述的內(nèi)容有： ? 如何在服務(wù)級別協(xié)議(Service Level Agreement – SLA)中清楚地定義條款， 使其可優(yōu)化 IT 服務(wù) 成本， 并為用戶所接受。? 如何監(jiān)控和討論所提供的服務(wù)。? 如何管理 IT 服務(wù)組織 的供應(yīng)商及其下包合同。 服務(wù)級別管理(Service Level Management －SLM)流程是用來確保服務(wù)級別協(xié)議，并支持運行級別協(xié)議及其它合同，保證所有對服務(wù)質(zhì)量的影響減少到最小。此流程在服務(wù)質(zhì)量和 SLA 基礎(chǔ)上評估各種變 更造成的影響，包含預(yù)期變更前的影響， 也包含評估實施變更后的影響。SLA 中某些最重要的目標和服務(wù)可用性、以及在容許周期內(nèi)對突發(fā)事件形成決策有關(guān)。SLM 是服務(wù)支持和服務(wù)交付的 關(guān)鍵。由于它依賴于其它流程的存在性， 有效性及運行效率， 它不可孤立存在。一個缺乏基礎(chǔ)支持流程的 SLA 是沒有意義的， 缺乏支持的 SLA 就失去了承認其內(nèi)容的基 礎(chǔ)。 IT 服務(wù)的財務(wù) 管理財務(wù)管理針對于 IT 服務(wù)的 謹慎從事。例如，當所提供的 IT 服務(wù)在進行中時，財務(wù)管理將提供其導(dǎo)致的成本信息。這樣使考慮 IT 架構(gòu)或 IT 服務(wù)的改變時，能夠合理地考慮成本和利益( 價格和性能) 之間的關(guān)系。 財務(wù)管理中對成本的鑒別、分配、預(yù)測和監(jiān)控使成本成為可知因素，減少成本和預(yù)算的差距。 重點結(jié)合 IT. .. . ..學(xué)習(xí)參考服務(wù)組織的贏利， IT 服務(wù) 的財務(wù)管理描述了多種 支付方法，包括設(shè)立支付和定價的目標，以及預(yù)算計劃。財務(wù)管理負責(zé)對成本及 IT 服務(wù)投資回報的會計核算， 并管理任何來自于客戶的成本。財務(wù)管理需要與能力管理(Capacity Management)，配置管理(Configuration Management，包含資產(chǎn)數(shù)據(jù)) ，以及 SLM 的良好接口， 來確定服務(wù)的真實成本。 在 IT 組織預(yù)算談判階段和客 戶的 IT 耗費核算階段， 財務(wù)管理很可能與業(yè)務(wù)關(guān)系管理(Business Relationship Management)及 IT 組織密切相關(guān)。 能力管理能力管理是優(yōu)化成本，獲得時間，以及開發(fā) IT 資源的流程， 來支持與客戶簽訂的服務(wù)條款。能力管理針對資源管理，性能管理，需求管理，建模，能力計劃， 負載管理，以及應(yīng)用軟件能力推測。能力管理強調(diào)用計劃來確保所簽訂的服務(wù)級別可以被履行和成長。能力管理負責(zé)確保在所有時間具備足夠的可用能力，以滿足業(yè)務(wù)需求。 能力管理不是簡單地與系統(tǒng)部件的性能相關(guān)， 而是直接與業(yè)務(wù)需求相關(guān)。 在那些與能力問題相關(guān)的困難面前， 能力管理在突發(fā)事件決策和問題鑒別過程中被引入。能力管理提交變更請求以確保得到適當?shù)目捎媚芰Α?這些 RFC 被提交給變更管理流程， 其實施可能影響若干 CI， 包括硬件， 軟件和文檔，并需要提供有效的版本管理。. .. . ..學(xué)習(xí)參考能力管理應(yīng)該在評估所有變更時被引入， 用來確定變更導(dǎo)致的在能力和性能上的影響。 這種影響在變更實施前后都有可能出現(xiàn)。 能力管理應(yīng)該特別關(guān)注變更在一定周期后引起的累積性變化。 容易被忽略的單個的變更往往在經(jīng)過累積后， 引起響應(yīng)時間衰減， 文件存儲問題， 和對處理能力的過度需求。 IT 服務(wù)持續(xù) 性管理此流程在業(yè)務(wù)中斷時對 IT 服務(wù)進行災(zāi)難恢復(fù)措施的準 備和計劃。 業(yè)務(wù)持續(xù)性管理為客戶組織遇到災(zāi)難時準備好緊急預(yù)案， 根據(jù)此預(yù)案采取與 IT 服務(wù)相關(guān)的預(yù)防災(zāi)難發(fā)生的措施。 IT 服務(wù)持續(xù)性管理流程 對技術(shù)， 財務(wù)和管理資源需求做好計劃和協(xié)調(diào)， 確保災(zāi)難發(fā)生后可持續(xù)提供服務(wù)， 并就其內(nèi)容達成客戶同意。IT 服務(wù)持續(xù)性管理 與一個 組織在業(yè)務(wù)中斷后在某個 可允許范圍內(nèi)繼續(xù)運作的能力密切相關(guān)。 至少要保證最基本的業(yè)務(wù)運行所需要的 IT 服務(wù)， 預(yù)先對其服務(wù)級別作出規(guī)定， 并和客戶達成一致。 有效的 IT 服務(wù)持續(xù)性需要一個平衡的風(fēng)險縮減措施， 例如有彈性的系統(tǒng)和備份恢復(fù)設(shè)施。 配置管理流程中的數(shù)據(jù)被用來輔助其計劃和預(yù)防措施。 需要對架構(gòu)和業(yè)務(wù)變更對持續(xù)性計劃造成的潛在影響進行評估。 有關(guān) IT 和業(yè)務(wù)的計劃應(yīng)該提交 變更管理程序。 在持續(xù)性管理流程中， 服務(wù)臺承擔(dān)著重要角色。. .. . ..