ITILv3服务运营篇(中文).ppt

ITIL v3-ITIL v3-服務運營篇服務運營篇Continual ServiceImprovementServiceStrategyDemand ManagementService Portfolio ManagementServiceDesignFinancial ManagementService Catalog ManagementService Level ManagementAvailability ManagementCapacity ManagementSupplier ManagementInformation Security ManagementIT Service Continuity ManagementServiceTransitionTransition Planning & SupportChange ManagementConfiguration ManagementRelease ManagementService Validation & TestingEvaluationKnowledge ManagementServiceOperationEvent ManagementIncident ManagementRequest FulfillmentProblem ManagementAccess ManagementService DeskTechnical ManagementIT Operations ManagementApplications ManagementService MeasurementService ReportingService Improvement目的：是為了交付已商定的服務級別給客戶和用戶，並且管理支持服務目的：是為了交付已商定的服務級別給客戶和用戶，並且管理支持服務交付的應用程序、技術和框架。

交付的應用程序、技術和框架服務：是為業務實現價值，服務運營的人員有責任保証該價值是否實現服務：是為業務實現價值，服務運營的人員有責任保証該價值是否實現對於服務運營、平衡目標間的沖突是非常重要的：對於服務運營、平衡目標間的沖突是非常重要的：1、內部IT與外部業務的觀點2、穩定與響應3、服務質量與服務成本4、被動與積極主動的行動 服務運營人員需盡可能使兩者保持平衡，過分強調某一部分都會使服務運營人員需盡可能使兩者保持平衡，過分強調某一部分都會使服務的質量降低服務的質量降低概概 述述Service DeskAccessManagementRequestfulfilmentUserTechnicalManagementApplicationManagementIT OperationsProblemmanagementEventManagementCMSIncidentmanagementKnow Know ErrorErrordatabasedatabaseCMDBService OperationEvent、Incidents and Service RequestIncidentsEventService DeskServiceRequestIncident managementIncident management（事故管理）（事故管理） 事故事故 ( Incident )  ( Incident ) 是指對一項是指對一項ITIT服務或一項服務或一項ITIT服務品質減少的非計畫中斷。

服務品質減少的非計畫中斷 事故管理流程的主要目標是根據服務級別協定的要求，在盡可能小地影響客事故管理流程的主要目標是根據服務級別協定的要求，在盡可能小地影響客戶和使用者業務的情況下盡可能快地將服務恢復到戶和使用者業務的情況下盡可能快地將服務恢復到““正常狀態正常狀態” ” 22223緊急度1影響度11用戶能承受的等待時間現象現象\類別類別一類一類二類二類三類三類系統崩潰101530無法訪問152040速度減慢203060“主動告知”事故管理流程：事故管理流程：事故事故由技術員工報告和記錄，由技術員工報告和記錄，但並不是所有的事件都是事故，許多但並不是所有的事件都是事故，許多的事件並不與中斷相關，而僅是正常的事件並不與中斷相關，而僅是正常運營指標或一些簡單的資訊儘管事運營指標或一些簡單的資訊儘管事故和服務請求都報告給服務台，但兩故和服務請求都報告給服務台，但兩者並不相同，者並不相同， 服務請求並不代表協服務請求並不代表協定服務的中斷，而是滿足客戶需要的定服務的中斷，而是滿足客戶需要的方法，當然也可能是方法，當然也可能是SLASLA中協定目標中協定目標經常發生的故障建立經常發生的故障建立“ “故障模型故障模型” ”。

emailemail不能收發）不能收發）故障單故障單（狀態（狀態inging）（選擇、填）（選擇、填空、論述）（字段）空、論述）（字段）事件管理事件管理事件事件(Event)(Event)可被定義為任何可察覺和可識別的，對可被定義為任何可察覺和可識別的，對 IT  IT 基礎設施管理或者基礎設施管理或者 IT  IT 服務造成影響和背離的重要現象事件通常由服務造成影響和背離的重要現象事件通常由 IT  IT 服務、配置項或者監控工具產生服務、配置項或者監控工具產生事件管理流程的目標是為了確保正常運營而進行的對事件管理流程的目標是為了確保正常運營而進行的對 IT  IT 基礎設施中發生的所有事件進行監控的流程，事件管理也負責對例外情況進基礎設施中發生的所有事件進行監控的流程，事件管理也負責對例外情況進行偵測並進行必要的升級行偵測並進行必要的升級 有效的服務運營需要對有效的服務運營需要對IT IT 設施運行狀態的及時掌控和任何對服務偏移的識別，這依賴於有效的監控管設施運行狀態的及時掌控和任何對服務偏移的識別，這依賴於有效的監控管理系統 事件管理流程用於需要被控制和可自動化的服務管理的各個方面。

事件事件管理流程用於需要被控制和可自動化的服務管理的各個方面事件管理的監控範圍包括配置項，環境條件（如，機房煙火的監測）管理的監控範圍包括配置項，環境條件（如，機房煙火的監測） ，軟件許可和使用情況監控，安全及標準活動（如，對應用或對伺服器操作，軟件許可和使用情況監控，安全及標準活動（如，對應用或對伺服器操作行跟蹤）行跟蹤） 事故事故（（IncidentIncident））: :事故往往來自多方的輸入事故往往來自多方的輸入，包括來自事件管理的輸入、，包括來自事件管理的輸入、最終用最終用戶戶的直接反饋的直接反饋而而事件的來源通常是自動化的檢測工具、系統，於是事件的來源通常是自動化的檢測工具、系統，於是ITIT部門便有可能在部門便有可能在最終用最終用戶戶發現之前首先發現問題發現之前首先發現問題InformationalWarningExceptionAlert事件管理流程圖服務請求服務請求 該流程主要針對“服務請求”類事件，指的是IT 部門向用戶提供的一系列不同種類的普通的需求，這些請求大部分可以分為幾類:一類是低風險、經常發生且成 本低的微小變更；比如重置口令，對某個特殊的工作站進行額外軟體安裝的請求等；另一類為資訊諮詢請求。

因為這些請求是經常發生、低風險，因而需要採取一個 單獨的流程來進行管理，而不是混雜于正常的事件和變更管理流程，變成一種累贅和障礙請求實現流程的主要目標是：請求實現流程的主要目標是： •對於某些預定義的申請和需求，為用戶提供一個管道來獲得這些標准服務； •為客戶和使用者提供服務請求管理流程服務和程式資訊； •獲得和交付請求的標準服務元件； •協助處理一般資訊、抱怨或者投訴 服務請求流程圖問題管理問題管理問題：是一個或多個不知原因的事件 問題管理流程的主要目標目標是預防問題和事故的再次發生，並將未能解決的事故的影響降低到最小 事故管理關注解決事件的速度 問題管理強調找事件出根源，定制解決方案預防再次發生 問題管理與知識管理，以及諸如已知錯誤資料庫等工具有著緊密聯繫問題管理流程由兩個主要類型的流程： 被動問題管理是服務運營通常執行部分 主動問題管理是由服務運營發起的，但通常是由服務改進驅動的重復發生的事件或重大事故一般升級為問題管理在尚未查明事故產生的原因前，事故所對應的潛在原因被稱為問題，而找到事故產生的根本原因後，問題就成為一個已知錯誤，隨後可以提出一個變更請求來消除該已知錯誤和防止類似事故再次發生。

ProblemWorkaroundKnown ErrorRFCSolution問題管理指標問題管理指標下列指標應該用來判斷問題管理有效性和效率：•一段期間問題總數量 •百分比的問題，解決的SLA目標（及百分比是沒有）•超出目標解決時間問題的數目用百分比表示） •未關閉問題數量和發展趨勢（靜態，減少或增加）•處理問題的平均成本•問題的數目（打開和關閉和積壓）•有多少已知錯誤添加到已知錯誤資料庫（KEDB）•已知錯誤資料庫（KEDB）準確程度的百分比•主要問題評價順利完成的百分比，並列出明細分類：處理時間，影響的嚴重性，緊急度和優先級訪問管理訪問管理訪問管理流程是授權給合適的使用者合理的使用服務，同時也限制未授權使用者的訪問訪問管理也被稱為許可權管理或者身份管理 訪問管理流程提供使用者權限能夠使用一項或一組服務因而，它是對安全和可用性管理定義的政策和行動的執行 訪問管理流程是可用性和資訊安全管理有效地執行訪問管理不是一個單獨的職能，所有的技術和應用程式管理職能都應該執行該流程為了能對訪問管理的協調有 一個單一控制點，經常由運作管理或服務台來控制訪問管理也能由服務台的服務請求發起訪問管理流程的主要活動如下： •訪問請求 •驗證：•許可權提供 •監控身份狀態 •記錄和跟蹤訪問 •移除或限制許可權•組策略服務台(Service Desk)在用戶支持方面扮演了重要的角色。

一個成熟的服務台可作為其他IT 部門的前臺，能夠在無需聯繫專家的情況下處理一些客戶詢問對於使用者來說，服務台為他們提供了聯繫IT 部門的單一聯繫點，從而可以確保他們能找到合適的支持人員來幫助解決其問題或請求換句話說，使用者再也不需要不停地尋找能夠解決其問題的支持人員通常， 服務台也負責跟蹤來自IT 部門內部的呼叫服務台類似一個路由器+應答機+滅火器+發布機”服務台目標服務台目標目標：儘快恢復使用者正常服務1.記錄事件、服務請求、分配優先順序2.提供一線調查和診斷3.解決事件、服務請求4.向用戶通報進展5.關閉解決事件、服務請求及其他請求6.開展用戶滿意度調查7.更新CMS服務台服務台服務台結構：服務台結構：有多種選擇常見的方式包括：集中式服務台：作為所有用戶的單一聯繫點，可能還單獨設立了一個服務台來處理使用者在業務應用系統方面的問題本地式：服務台分佈在多個地方通常，將服務台劃分為多個本機服務台將會導致更加難以管理虛擬式服務台：並沒有實質性的位置，這是由於使用了通信技術這裡具體討論集中式服務台這裡具體討論集中式服務台集中式服務台是企業最實用最多的一種類型這種方式可以與運營組織的其他功能組織緊密結合使用以方便服務台和運營管理(生產、運營)之間的直接溝通，這裡所指的生產(Production)包括網絡管理、電腦運營等。

這種直接溝通可以保證在出現服務台不能立即解決錯誤的情況下仍然能夠作出快速回應服務台角色服務台角色 服務台經理服務台主管服務台支援超級用戶服務台對技術要求服務台對技術要求電話：電話：•自動呼叫分配系統•電腦電話介面系統：自動從CMS記錄中識別呼叫者和調用詳細資訊•VOPI：降低國際和遠端使用者通訊成本•統計軟體：統計收到的號碼、回應時間、呼叫處理率、呼叫失敗率、平均話時間支援工具支援工具•已知錯誤資料庫•診斷腳本•網頁自助介面•遠端工具ITSMITSM工具的工具的ITIT服務連續性計畫服務連續性計畫服務台設立時需要考慮的幾個方面服務台設立時需要考慮的幾個方面1.客戶服務的期望2.業務需求，如預算，呼叫回應時間等3.大小，相對年齡，設計和複雜的IT基礎設施和服務目錄 - 例如，事故數量和類型，定制的程度相比，標準的現成軟體部署等4.支援的客戶和使用者數量，及其他如有關的因素： 語言種類、技能水準5.事件和服務請求類型（和適當的RFC種）：各類型呼叫所需的時間期限；內部或外部的專業知識要求 ；事故、服務請求的數量和類型6.滿足需求所要提供的支援，包括： 時間範圍、非工作時間支援、支援時區、現場支持、移動的時間與地點、工作時間模式、服務等級目標7.服務台反應類型：電話； E-mail/fax/voice郵件/視頻；物理席位；線上訪問/控制8.訓練等級9.現有技術的支援（如電話系統，遠端支援工具等）10.工作人員的現有技能水準服務台人員所應具備的技能水準服務台人員所應具備的技能水準 關於所需的技能水準決定往往是由目標；解決時間；複雜性和業務的代價。

一般來說，目標時間越短，成本更高，因為需要更多的資源可以通過提供有效 的基礎知識；診斷腳本和集成支援工具；培訓和提高認識，使第一線解決率逐步增加服務台人員應具備以下技能：服務台人員應具備以下技能：1.人際技巧，如電話技巧，溝通技巧，積極傾聽和客戶服務培訓2.商業意識：該組織的業務領域，驅動，結構，優先事項等具體知識3.服務意識：對企業關鍵IT服務4.技術認識（和更深入的技術培訓到適當的水準，這取決於尋求解決問題的比率）5.提供的支援程度而定，一些診斷技能6.支援工具和技術7.意識培訓和新系統上線前培訓8.程式和流程9.打字技能       應對服務台建立衡量指標來定期考核服務台的工作效率與品質如何正確的選擇考核指標指標包括：一線解決率： 服務台第一次接觸得到解決的比率，服務台一線單獨解決比率， 一線與二線聯合解決的比率1.一線解決事件平均時長2.事件升級平均時長3.服務台處理事件平均成本4.服務台費用/受理數量計算受理成本但不能反應不同類型事件受理的成本可用於規劃5.服務台總費用與總受理時間計算通話成本6.SLA或客戶期望時間內解決事件比率7.審查、關閉已解決呼叫的平均時長8.日或周呼叫接通失敗的數量與平均通話量來決定員工數量總結與思考總結與思考問題：服務台受理數量上升，是工作存在不穩定性，還是服務台受到認可使用使用者上升。

在選擇指標時不應單方面的去考慮問題關注：應關注服務台一線人員培訓和流失的問題服務台指標服務台指標需求開發/採購上線硬件/網絡日常維護Application層Application/technical層Application/technical層technical層Technical/Operations層對於對於ITIT運營來說運營來說ITIT服務的管理系統是必須的服務的管理系統是必須的ITIT運營管理的技術總需求運營管理的技術總需求1.自助：向使用者提供自助服務相當有用，利用一些網頁形式提供一個自助服務範圍和服務要求的功能表並與後繼流程連接 2.工作流：工作流程是對流程預先定義和控制事先定義職責、活動、時間限制、升級路徑、報警，然後自動管理 3.綜合配置管理系統(CMS)：CMS可以控制組織的IT基礎設施、元件、服務和任何CI項，關聯相關屬性，在一個集中的區域並相互儲存和維護，關聯事件，已知錯誤和變化記錄 4.發現/部署/許可證技術：自動發現或審計工具能寫入或CMS資料，並且協助授權管理這些工具能被運行在網路任意位置並允許查詢和恢復所有組件構成、關聯、架構等相關資料 5.使用過濾使資料可以延續審核和提取必要的資料。

6.佈置新軟體到目的地區域，讓補丁、工具等能分發給準確用戶 7.允許軟體下載通過一個自助介面來完成 8.遠程控制：對服務台和其他支援團隊有用，能幫助他們控制用戶桌面來進行調查和設置設備 9.診斷工具 10.報告 11.整合業務管理：將業務相關流程與IT服務管理相結合—業務服務管理服務運營的技術需求服務運營的技術需求事件管理技術要求事件管理技術要求1.多環境，對整個IT基礎設施和服務組織檢測和報警 2.低沉本，易於部署 3.使用標準的代理程式對日常環境，元件，系統進行監控 4.使用開放通用介面來接受任何標準事件的警報輸入 5.所有事件集中在一個區域 6.報警的症狀和影響可以程式化來判斷和處理 7.允許操作者確認和升級警報事故管理技術要求事故管理技術要求1.CMS能自動的維護事故、服務請求、問題、已知錯誤和其他配置項之間的關聯 2.CMS能協助確定優先順序和協助調查，診斷 3.允許一個流程預先定義和自動控制內部團體的路徑和外部EMIAL SMS介面 4.自動報警和升級能力，防止事故被忽視和拖延 5.事件管理工具介面公開，使事件能自動升級到事故 6.通過WEB介面，提供自助服務和服務請求 7.使用KEDB記錄和查詢診斷、解決的事件和問題。

幫助加快事故處理 8.易用的報告設施以便生成事故指標和方便事故分析、有助於問題管理和可用性管理各流程和功能對技術的要求如下各流程和功能對技術的要求如下服務請求技術要求服務請求技術要求集成ITSM技術是服務請求中必須的使其能與事故或已發生事件相關聯 服務請求一般被定義為事故管理的一個子集當組織將其單獨處理時需要工具來處理前臺自助將允許用戶通過網頁提交需求，通過功能表選擇流程服務請求管理中對設施的管理與事件管理比較類似，預先定義服務請求工作流，優先順序，自動升級，有效的報告問題管理技術要求問題管理技術要求綜合業務管理技術：ITSM集成工具需要區分事件和事故，單獨的問題記錄只對加快事故處理有幫助但不能將事故關聯問題記錄功能能將問題記錄與多個事故做匹配 變更管理：問題管理與變更管理集成很重要因此請求，事件，事故和問題記錄可以與出現問題的變更請求關聯 綜合配置管理：CMS允許問題記錄與元件的影響，服務的影響和其他相關CIS項關聯 已知錯誤資料庫：一個有效地KEDB的基本條件是能方便的存儲和檢索已知錯誤資料一個良好的報表功能能減輕生成管理報告的工作量，使資料能自動被輸入並允許提取事件、問題分析訪問管理技術要求人力資源技術：驗證使用者身份和追蹤其狀態 目錄服務技術目錄服務技術 在應用軟體，中介軟體，作業系統和網路系統的訪問管理功能。

變更管理系統 請求傳遞技術電話：電話： 1.自動呼叫分配系統2.電腦電話介面系統：自動從CMS記錄中識別呼叫者和調用詳細資訊3.VOPI：降低國際和遠端使用者通訊成本4. 統計軟體：統計收到的號碼、回應時間、呼叫處理率、呼叫失敗率、平均話時間支援工具支援工具    1.已知錯誤資料庫2.診斷腳本3.網頁自助介面•FAQ和解決方案•搜索功能•服務公告包括：服務事項、詳情、恢復時間等•密碼修改功能•軟體補丁下載•通知系統•軟體下載4.遠端工具ITSMITSM工具的工具的ITIT服務連續性計畫服務連續性計畫 當組織依賴ITSM工具時需要對其進行BIA和風險分析並計畫改進以確保適當的IT連續性和恢復水準服務台對技術要求服務台對技術要求。