ITIL-v3服务运营篇(1)

1、.1 ITIL v3-服務運營篇服務運營篇 .2 Continual Service Improvement Service Strategy Demand Management Service Portfolio Management Service Design Financial Management Service Catalog Management Service Level Management Availability Management Capacity Management Supplier Management Information Security Manageme

2、nt IT Service Continuity Management Service Transition Transition Planning & Support Change Management Configuration Management Release Management Service Validation & Testing Evaluation Knowledge Management Service Operation Event Management Incident Management Request Fulfillment Problem Managemen

3、t Access Management Service Desk Technical Management IT Operations Management Applications Management Service Measurement Service Reporting Service Improvement .3 目的：是為了交付已商定的服務級別給客戶和用戶，並且管理支持服務 交付的應用程序、技術和框架。 服務：是為業務實現價值，服務運營的人員有責任保証該價值是否實現。 對於服務運營、平衡目標間的沖突是非常重要的： 1、內部IT與外部業務的觀點 2、穩定與響應 3、服務質量與服務成

4、本 4、被動與積極主動的行動 服務運營人員需盡可能使兩者保持平衡，過分強調某一部分都會使 服務的質量降低。 概 述 .4 Service Desk Access Management Request fulfilment User Technical Management Application Management IT Operations Problem management Event Management CMS Incident management Know Error database CMDB Service Operation .5 Event、Incidents and

5、Service Request Incidents Event Service Desk Service Request .6 Incident management（事故管理） 事故 ( Incident ) 是指對一項IT服務或一項IT服務品質減少的非計畫中斷。 事故管理流程的主要目標是根據服務級別協定的要求，在盡可能小地影響客戶和使 用者業務的情況下盡可能快地將服務恢復到“正常狀態” 。 2 22 2 3 緊急度1 影響度1 1 用戶能承受的等待時間 現象現象類別類別一類一類二類二類三類三類 系統崩潰101530 無法訪問152040 速度減慢203060 “主動告知” .7 事故管理流

6、程： 事故由技術員工報告和記錄，但並不 是所有的事件都是事故，許多的事件 並不與中斷相關，而僅是正常運營指 標或一些簡單的資訊。儘管事故和服 務請求都報告給服務台，但兩者並不 相同， 服務請求並不代表協定服務 的中斷，而是滿足客戶需要的方法， 當然也可能是SLA中協定目標。 經常發生的故障建立“故障模型”。 （email不能收發） 故障單（狀態ing）（選擇、填空、 論述）（字段） .8 事件管理 事件(Event)可被定義為任何可察覺和可識別的，對 IT 基礎設施管理或 者 IT 服務造成影響和背離的重要現象。事件通常由 IT 服務、配置項或者監 控工具產生。 事件管理流程的目標是為了確保正

7、常運營而進行的對 IT 基礎設施中發 生的所有事件進行監控的流程，事件管理也負責對例外情況進行偵測並進行 必要的升級。 有效的服務運營需要對IT 設施運行狀態的及時掌控和任何對服 務偏移的識別，這依賴於有效的監控管理系統。 事件管理流程用於需要被控制和可自動化的服務管理的各個方面。事件 管理的監控範圍包括配置項，環境條件（如，機房煙火的監測） ，軟件許可 和使用情況監控，安全及標準活動（如，對應用或對伺服器操作行跟蹤） 。 事故（Incident）:事故往往來自多方的輸入，包括來自事件管理的輸入、 最終用戶的直接反饋。 而事件的來源通常是自動化的檢測工具、系統，於是IT部門便有可能在 最終用戶

8、發現之前首先發現問題。 InformationalWarningExceptionAlert .9 事件管理流程圖 .10 .11 .12 服務請求服務請求 該流程主要針對“服務請求”類事件，指的是IT 部門向 用戶提供的一系列不同種類的普通的需求，這些請求大部 分可以分為幾類: 一類是低風險、經常發生且成 本低的微小變更；比如重置 口令，對某個特殊的工作站進行額外軟體安裝的請求等； 另一類為資訊諮詢請求。因為這些請求是經常發生、低風 險，因而需要採取一個 單獨的流程來進行管理，而不是混 雜于正常的事件和變更管理流程，變成一種累贅和障礙。 請求實現流程的主要目標是：請求實現流程的主要目標是：

9、對於某些預定義的申請和需求，為用戶提供一個管道來獲 得這些標准服務； 為客戶和使用者提供服務請求管理流程服務和程式資訊； 獲得和交付請求的標準服務元件； 協助處理一般資訊、抱怨或者投訴。 .13 服務請求流程圖 .14 問題管理問題管理 問題：是一個或多個不知原因的事件。 問題管理流程的主要目標目標是預防問題和事故的再次發生，並將未能解決的事 故的影響降低到最小。 事故管理關注解決事件的速度。 問題管理強調找事件出根源，定制解決方案預防再次發生。 問題管理與知識管理，以及諸如已知錯誤資料庫等工具有著緊密聯繫 問題管理流程由兩個主要類型的流程： 被動問題管理是服務運營通常執行部分 主動問題管理是

10、由服務運營發起的，但通常是由服務改進驅動的 重復發生的事件或重大事故一般升級為問題管理。 在尚未查明事故產生的原因前，事故所對應的潛在原因被稱為問題，而找到 事故產生的根本原因後，問題就成為一個已知錯誤，隨後可以提出一個變更 請求來消除該已知錯誤和防止類似事故再次發生。 ProblemWorkaroundKnown ErrorRFCSolution .15 .16 問題管理指標問題管理指標 下列指標應該用來判斷問題管理有效性和效率： 一段期間問題總數量 百分比的問題，解決的SLA目標（及百分比是沒有） 超出目標解決時間問題的數目。（用百分比表示） 未關閉問題數量和發展趨勢（靜態，減少或增加）

11、處理問題的平均成本 問題的數目（打開和關閉和積壓） 有多少已知錯誤添加到已知錯誤資料庫（KEDB） 已知錯誤資料庫（KEDB）準確程度的百分比 主要問題評價順利完成的百分比，並列出明細分類：處理時間，影響 的嚴重性，緊急度和優先級。 .17 訪問管理 訪問管理流程是授權給合適的使用者合理的使用服務，同時也限制未授權使 用者的訪問。訪問管理也被稱為許可權管理或者身份管理。 訪問管理流程提供使用者權限能夠使用一項或一組服務。因而，它是對安全 和可用性管理定義的政策和行動的執行。 訪問管理流程是可用性和資訊安全管理有效地執行。訪問管理不是一個單獨 的職能，所有的技術和應用程式管理職能都應該執行該流程

12、。為了能對訪問管理 的協調有 一個單一控制點，經常由運作管理或服務台來控制。訪問管理也能由服 務台的服務請求發起。 訪問管理流程的主要活動如下： 訪問請求 驗證： 許可權提供 監控身份狀態 記錄和跟蹤訪問 移除或限制許可權 組策略 .18 服務台(Service Desk)在用戶支持方面扮演了重要的角色。一個成熟的 服務台可作為其他IT 部門的前臺，能夠在無需聯繫專家的情況下處理一些客 戶詢問。對於使用者來說，服務台為他們提供了聯繫IT 部門的單一聯繫點， 從而可以確保他們能找到合適的支持人員來幫助解決其問題或請求。換句話 說，使用者再也不需要不停地尋找能夠解決其問題的支持人員。通常， 服務

13、台也負責跟蹤來自IT 部門內部的呼叫。 “服務台類似一個路由器+應答機+滅火器+發布機” 服務台目標 目標：儘快恢復使用者正常服務 記錄事件、服務請求、分配優先順序 提供一線調查和診斷 解決事件、服務請求 向用戶通報進展 關閉解決事件、服務請求及其他請求 開展用戶滿意度調查 更新CMS 服務台 .19 服務台結構：有多種選擇。常見的方式包括： 集中式服務台：作為所有用戶的單一聯繫點，可能還單獨設立了一個服務台來處理使用者在 業務應用系統方面的問題。 本地式：服務台分佈在多個地方。通常，將服務台劃分為多個本機服務台將會導致更加難以 管理。 虛擬式服務台：並沒有實質性的位置，這是由於使用了通信技術

14、。 這裡具體討論集中式服務台。 集中式服務台是企業最實用最多的一種類型。 這種方式可以與運營組織的其他功能組織緊密結合使用以方便服務台和運營管理(生產、運 營)之間的直接溝通，這裡所指的生產(Production)包括網絡管理、電腦運營等。這 種直接溝通可以保證在出現服務台不能立即解決錯誤的情況下仍然能夠作出快速回 應。 .20 .21 .22 .23 服務台角色 服務台經理 服務台主管 服務台支援 超級用戶 服務台對技術要求 電話： 自動呼叫分配系統 電腦電話介面系統：自動從CMS記錄中識別呼叫者和調用詳細資訊 VOPI：降低國際和遠端使用者通訊成本 統計軟體：統計收到的號碼、回應時間、呼叫

15、處理率、呼叫失敗率、平 均話時間 支援工具 已知錯誤資料庫 診斷腳本 網頁自助介面 遠端工具 ITSM工具的IT服務連續性計畫 .24 服務台設立時需要考慮的幾個方面 客戶服務的期望 業務需求，如預算，呼叫回應時間等 大小，相對年齡，設計和複雜的IT基礎設施和服務目錄 - 例如，事故數量和類型，定制的程 度相比，標準的現成軟體部署等 支援的客戶和使用者數量，及其他如有關的因素： 語言種類、技能水準 事件和服務請求類型（和適當的RFC種）：各類型呼叫所需的時間期限；內部或外部的專業 知識要求 ；事故、服務請求的數量和類型 滿足需求所要提供的支援，包括： 時間範圍、非工作時間支援、支援時區、現場支

16、持、移動 的時間與地點、工作時間模式、服務等級目標 服務台反應類型：電話； E-mail/fax/voice郵件/視頻；物理席位；線上訪問/控制 訓練等級 現有技術的支援（如電話系統，遠端支援工具等） 工作人員的現有技能水準 服務台人員所應具備的技能水準 關於所需的技能水準決定往往是由目標；解決時間；複雜性和業務的代價。一般來說，目標 時間越短，成本更高，因為需要更多的資源。可以通過提供有效 的基礎知識；診斷腳本和集 成支援工具；培訓和提高認識，使第一線解決率逐步增加。 服務台人員應具備以下技能： 人際技巧，如電話技巧，溝通技巧，積極傾聽和客戶服務培訓。 商業意識：該組織的業務領域，驅動，結構

17、，優先事項等具體知識 服務意識：對企業關鍵IT服務 技術認識（和更深入的技術培訓到適當的水準，這取決於尋求解決問題的比率） 提供的支援程度而定，一些診斷技能 支援工具和技術 意識培訓和新系統上線前培訓 程式和流程 打字技能 .25 應對服務台建立衡量指標來定期考核服務台的工作效率與品質如何正確的選擇考 核指標 指標包括： 一線解決率： 服務台第一次接觸得到解決的比率，服務台一線單獨解決比率， 一線 與二線聯合解決的比率 一線解決事件平均時長 事件升級平均時長 服務台處理事件平均成本 服務台費用/受理數量計算受理成本。但不能反應不同類型事件受理的成本。 可用於規劃 服務台總費用與總受理時間計算通

18、話成本。 SLA或客戶期望時間內解決事件比率 審查、關閉已解決呼叫的平均時長 日或周呼叫接通失敗的數量與平均通話量來決定員工數量 總結與思考總結與思考 問題：服務台受理數量上升，是工作存在不穩定性，還是服務台受到認可使用 使用者上升。在選擇指標時不應單方面的去考慮問題。 關注：應關注服務台一線人員培訓和流失的問題。 服務台指標 .26 需求 開發/採購 上線 硬件/網絡 日常維護 Application層 Application/technical層 Application/technical層 technical層 Technical/Operations層 .27 對於IT運營來說IT服務

19、的管理系統是必須的。 IT運營管理的技術總需求 自助：向使用者提供自助服務相當有用，利用一些網頁形式提供一個自助服務範 圍和服務要求的功能表並與後繼流程連接 工作流：工作流程是對流程預先定義和控制。事先定義職責、活動、時間限制、 升級路徑、報警，然後自動管理 綜合配置管理系統(CMS)：CMS可以控制組織的IT基礎設施、元件、服務和任何CI 項，關聯相關屬性，在一個集中的區域並相互儲存和維護，關聯事件，已知錯誤 和變化記錄。 發現/部署/許可證技術：自動發現或審計工具能寫入或CMS資料，並且協助授權 管理。這些工具能被運行在網路任意位置並允許查詢和恢復所有組件構成、關聯、 架構等相關資料。 使

20、用過濾使資料可以延續審核和提取必要的資料。 佈置新軟體到目的地區域，讓補丁、工具等能分發給準確用戶。 允許軟體下載通過一個自助介面來完成。 遠程控制：對服務台和其他支援團隊有用，能幫助他們控制用戶桌面來進行調查 和設置設備。 診斷工具 報告 整合業務管理：將業務相關流程與IT服務管理相結合業務服務管理。 服務運營的技術需求 .28 事件管理技術要求 多環境，對整個IT基礎設施和服務組織檢測和報警 低沉本，易於部署 使用標準的代理程式對日常環境，元件，系統進行監控 使用開放通用介面來接受任何標準事件的警報輸入 所有事件集中在一個區域。 報警的症狀和影響可以程式化來判斷和處理。 允許操作者確認和升

21、級警報 事故管理技術要求 CMS能自動的維護事故、服務請求、問題、已知錯誤和其他配置項之間的 關聯 CMS能協助確定優先順序和協助調查，診斷 允許一個流程預先定義和自動控制內部團體的路徑和外部EMIAL SMS介面 自動報警和升級能力，防止事故被忽視和拖延 事件管理工具介面公開，使事件能自動升級到事故 通過WEB介面，提供自助服務和服務請求 使用KEDB記錄和查詢診斷、解決的事件和問題。幫助加快事故處理 1.易用的報告設施以便生成事故指標和方便事故分析、有助於問題管理和可 用性管理。 各流程和功能對技術的要求如下 .29 服務請求技術要求 集成ITSM技術是服務請求中必須的。使其能與事故或已發生事件相關聯。 服務請求一般被定義為事故管理的一個子集。當組織將其單獨處理時需