ITILv3-服务运营篇

1、ITIL v3-服務運營篇服務運營篇Continual ServiceImprovementServiceStrategyDemand ManagementService Portfolio ManagementServiceDesignFinancial ManagementService Catalog ManagementService Level ManagementAvailability ManagementCapacity ManagementSupplier ManagementInformation Security ManagementIT Service Continui

2、ty ManagementServiceTransitionTransition Planning & SupportChange ManagementConfiguration ManagementRelease ManagementService Validation & TestingEvaluationKnowledge ManagementServiceOperationEvent ManagementIncident ManagementRequest FulfillmentProblem ManagementAccess ManagementService DeskTechnic

3、al ManagementIT Operations ManagementApplications ManagementService MeasurementService ReportingService Improvement目的：是為了交付已商定的服務級別給客戶和用戶，並且管理支持服務交付的應用程序、技術和框架。服務：是為業務實現價值，服務運營的人員有責任保証該價值是否實現。對於服務運營、平衡目標間的沖突是非常重要的：1、內部IT與外部業務的觀點2、穩定與響應3、服務質量與服務成本4、被動與積極主動的行動 服務運營人員需盡可能使兩者保持平衡，過分強調某一部分都會使服務的質量降低。概 述S

4、ervice DeskAccessManagementRequestfulfilmentUserTechnicalManagementApplicationManagementIT OperationsProblemmanagementEventManagementCMSIncidentmanagementKnow ErrordatabaseCMDBService OperationEvent、Incidents and Service RequestIncidentsEventService DeskServiceRequestIncident management（事故管理） 事故 ( I

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

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

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

8、比如重置口令，對某個特殊的工作站進行額外軟體安裝的請求等；另一類為資訊諮詢請求。因為這些請求是經常發生、低風險，因而需要採取一個 單獨的流程來進行管理，而不是混雜于正常的事件和變更管理流程，變成一種累贅和障礙。 請求實現流程的主要目標是：請求實現流程的主要目標是： 對於某些預定義的申請和需求，為用戶提供一個管道來獲得這些標准服務； 為客戶和使用者提供服務請求管理流程服務和程式資訊； 獲得和交付請求的標準服務元件； 協助處理一般資訊、抱怨或者投訴。 服務請求流程圖問題管理問題管理 問題：是一個或多個不知原因的事件。 問題管理流程的主要目標目標是預防問題和事故的再次發生，並將未能解決的事故的影響降

9、低到最小。 事故管理關注解決事件的速度。 問題管理強調找事件出根源，定制解決方案預防再次發生。 問題管理與知識管理，以及諸如已知錯誤資料庫等工具有著緊密聯繫 問題管理流程由兩個主要類型的流程： 被動問題管理是服務運營通常執行部分 主動問題管理是由服務運營發起的，但通常是由服務改進驅動的 重復發生的事件或重大事故一般升級為問題管理。 在尚未查明事故產生的原因前，事故所對應的潛在原因被稱為問題，而找到事故產生的根本原因後，問題就成為一個已知錯誤，隨後可以提出一個變更請求來消除該已知錯誤和防止類似事故再次發生。ProblemWorkaroundKnown ErrorRFCSolution問題管理指標

10、問題管理指標下列指標應該用來判斷問題管理有效性和效率：一段期間問題總數量 百分比的問題，解決的SLA目標（及百分比是沒有）超出目標解決時間問題的數目。（用百分比表示） 未關閉問題數量和發展趨勢（靜態，減少或增加）處理問題的平均成本問題的數目（打開和關閉和積壓）有多少已知錯誤添加到已知錯誤資料庫（KEDB）已知錯誤資料庫（KEDB）準確程度的百分比主要問題評價順利完成的百分比，並列出明細分類：處理時間，影響的嚴重性，緊急度和優先級。訪問管理訪問管理流程是授權給合適的使用者合理的使用服務，同時也限制未授權使用者的訪問。訪問管理也被稱為許可權管理或者身份管理。 訪問管理流程提供使用者權限能夠使用一項

11、或一組服務。因而，它是對安全和可用性管理定義的政策和行動的執行。訪問管理流程是可用性和資訊安全管理有效地執行。訪問管理不是一個單獨的職能，所有的技術和應用程式管理職能都應該執行該流程。為了能對訪問管理的協調有 一個單一控制點，經常由運作管理或服務台來控制。訪問管理也能由服務台的服務請求發起。訪問管理流程的主要活動如下： 訪問請求 驗證：許可權提供 監控身份狀態 記錄和跟蹤訪問 移除或限制許可權組策略服務台(Service Desk)在用戶支持方面扮演了重要的角色。一個成熟的服務台可作為其他IT 部門的前臺，能夠在無需聯繫專家的情況下處理一些客戶詢問。對於使用者來說，服務台為他們提供了聯繫IT

12、部門的單一聯繫點，從而可以確保他們能找到合適的支持人員來幫助解決其問題或請求。換句話說，使用者再也不需要不停地尋找能夠解決其問題的支持人員。通常， 服務台也負責跟蹤來自IT 部門內部的呼叫。“服務台類似一個路由器+應答機+滅火器+發布機”服務台目標目標：儘快恢復使用者正常服務記錄事件、服務請求、分配優先順序提供一線調查和診斷解決事件、服務請求向用戶通報進展關閉解決事件、服務請求及其他請求開展用戶滿意度調查更新CMS服務台服務台結構：有多種選擇。常見的方式包括：集中式服務台：作為所有用戶的單一聯繫點，可能還單獨設立了一個服務台來處理使用者在業務應用系統方面的問題。本地式：服務台分佈在多個地方。通

13、常，將服務台劃分為多個本機服務台將會導致更加難以管理。虛擬式服務台：並沒有實質性的位置，這是由於使用了通信技術。這裡具體討論集中式服務台。集中式服務台是企業最實用最多的一種類型。這種方式可以與運營組織的其他功能組織緊密結合使用以方便服務台和運營管理(生產、運營)之間的直接溝通，這裡所指的生產(Production)包括網絡管理、電腦運營等。這種直接溝通可以保證在出現服務台不能立即解決錯誤的情況下仍然能夠作出快速回應。服務台角色 服務台經理服務台主管服務台支援超級用戶服務台對技術要求電話：自動呼叫分配系統電腦電話介面系統：自動從CMS記錄中識別呼叫者和調用詳細資訊VOPI：降低國際和遠端使用者通

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

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

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

17、呼叫的平均時長日或周呼叫接通失敗的數量與平均通話量來決定員工數量總結與思考總結與思考問題：服務台受理數量上升，是工作存在不穩定性，還是服務台受到認可使用使用者上升。在選擇指標時不應單方面的去考慮問題。關注：應關注服務台一線人員培訓和流失的問題。服務台指標需求開發/採購上線硬件/網絡日常維護Application層Application/technical層Application/technical層technical層Technical/Operations層對於IT運營來說IT服務的管理系統是必須的。IT運營管理的技術總需求自助：向使用者提供自助服務相當有用，利用一些網頁形式提供一個自助服務

18、範圍和服務要求的功能表並與後繼流程連接 工作流：工作流程是對流程預先定義和控制。事先定義職責、活動、時間限制、升級路徑、報警，然後自動管理 綜合配置管理系統(CMS)：CMS可以控制組織的IT基礎設施、元件、服務和任何CI項，關聯相關屬性，在一個集中的區域並相互儲存和維護，關聯事件，已知錯誤和變化記錄。 發現/部署/許可證技術：自動發現或審計工具能寫入或CMS資料，並且協助授權管理。這些工具能被運行在網路任意位置並允許查詢和恢復所有組件構成、關聯、架構等相關資料。 使用過濾使資料可以延續審核和提取必要的資料。 佈置新軟體到目的地區域，讓補丁、工具等能分發給準確用戶。 允許軟體下載通過一個自助介

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