1、ITIL Foundation認證研修 培訓講義,準確理解IT服務、服務質(zhì)量、服務管理、IT服務管理和ITIL等核心概念； 清晰描述ITIL框架各模塊及其之間的相互關(guān)系； 全面掌握ITIL的十個核心流程和服務臺職能及其之間的相互關(guān)系； 掌握IT服務管理的實施方法和實施效果評價方法； 獲得參加EXIN ITIL Foundation認證考試的資格； 學會如何利用ITIL來改進現(xiàn)有的系統(tǒng)運維和服務支持工作； 通過培訓，使培訓對象了解主流服務支持系統(tǒng)的相關(guān)知識，提高其操作水平、操作能力。,課程目標,IT Service Management Overview IT服務管理簡介,神舟軟件2004年工作

2、會,調(diào)查發(fā)現(xiàn)（一）：導致服務器、網(wǎng)絡和應用出現(xiàn)故障的十大原因： 病毒攻擊（57.1%） 缺乏有效的監(jiān)控制度和手段（51.7%） IT設備本身的性能問題（41.1%） 應用系統(tǒng)/數(shù)據(jù)庫本身存在Bugs（39.2%） 員工缺少技能培訓（37.5%） 維護不及時或缺乏有計劃的維護（35.7%） 缺少總體規(guī)劃/重復建設（33.9%） 不同部門的IT人員之間缺乏協(xié)調(diào)（32.1%） 缺少運營管理方法論的指導（30.4%） 員工不按規(guī)定/流程操作（28.6%）,20%的原因是技術(shù)方面的 80%的原因是管理方面的,現(xiàn)實,調(diào)查發(fā)現(xiàn)（二）：減少基礎設施故障最有效的措施： 推行流程管理（60.7%） 實行統(tǒng)一的安全

3、管理與控制（53.6%） 爭取公司高層領導的重視和支持（51.8%） 對員工進行有針對性的培訓（51.8%） 定期分析系統(tǒng)和網(wǎng)絡的性能（51.8%） 進行集中式管理（48.2%） 進行冗余備份和災備（33.9%） 加強對用戶的培訓和教育（32.1%） 設立統(tǒng)一的IT支持前臺（35.7%） 使用網(wǎng)絡、系統(tǒng)或數(shù)據(jù)庫監(jiān)控系統(tǒng)（30.4%）,管理的問題還是 需要用管理的手 段來解決！,對策,業(yè)務管理,需求管理,項目組合管理,IT服務戰(zhàn)羅管理,服務管理,技術(shù)管理,安全管理,運營管理,外包管理,其他,網(wǎng)絡,服務器,數(shù)據(jù)庫,主機,桌面,系統(tǒng),應用,其它,IT管理&服務的層次和定位,面向項目的管理和面向服務的

4、管理,項目1 項目2 項目3 項目4 ,客戶 用戶,服務 提供者,我們的解決方案?, “支離”的IT服務：, 通過流程進行整合：, 如何實行流程管理？, ITSM是最受認可的解決方案,?,IT服務管理（ITSM）的含義,一個領域，它將,文化,組織機構(gòu),流程,工具,IT 服務管理是一種以流程為導向，以客戶為中心的方法，它通過整合IT服務與企業(yè)業(yè)務，提高了企業(yè)的IT服務提供和服務支持的能力和水平。 -it SMF,IT 服務管理是一套通過SLA來保證IT服務質(zhì)量的協(xié)同流程。它融合了系統(tǒng)管理、網(wǎng)絡管理、系統(tǒng)開發(fā)管理等管理活動以及變更管理、資產(chǎn)管理、問題管理等許多流程理論和實踐。 -Gartner,進

5、行有效而合理的整合，以提供高質(zhì)量的IT服務。,ITSM的核心思想,傳統(tǒng)的IT管理 轉(zhuǎn)變 ITSM,技術(shù)導向 “救火隊” 被動 用戶 集中式，企業(yè)自己完成 孤立的、分散的 “一次性的”，混亂的 非正式的流程 從IT部門內(nèi)部考慮 具體的運營,流程導向 “保健醫(yī)” 主動 客戶 分布式，外包 集成的，企業(yè)范圍內(nèi)的 可重復的，職責明確的 正式的最佳實踐 從業(yè)務的角度考慮 面向服務的,IT組織，不管企業(yè)內(nèi)部的還是外部的，都是IT服務提供者，其主要工作就是提供低成本、高質(zhì)量的IT服務。 IT服務的質(zhì)量和成本則需從IT服務的客戶（購買IT服務的）和用和（使用IT服務的）方加以判斷。 ITSM也是一種IT管理，

6、但與傳統(tǒng)的IT 管理不同，它是一種以服務為中心的IT管理。 ITSM的“三大目標”：,以客戶為中心,服務可計量,高質(zhì)量、低成本的服務,IT服務管理（ITSM）的“范圍”,ITSM VS.ERP/CRM/SCM - ITSM主要適用于管理、而不是企業(yè)的業(yè)務管理； - 前者面向IT管理，后者面向業(yè)務管理。 ITSM VS.IT規(guī)劃 - ITSM不是通用的IT規(guī)劃方法； - ITSM的重點是IT的運營和管理，而不是IT的戰(zhàn)略規(guī)劃。 ITSM VS.技術(shù)管理 - ITSM的主要目標不是管理技術(shù)； - ITSM的主要任務是管理和用戶的IT需求； - 有關(guān)IT的技術(shù)管理是系統(tǒng)管理和網(wǎng)絡管理的任務。,價格,

7、服務內(nèi)容,語言,ITSM對IT服務的作用,“牽涉到核心業(yè)務，IT外包要誰做？IT服務商是否懂業(yè)務？有沒有安全保障？定價怎樣算合理？” - 協(xié)和醫(yī)科大學腫瘤醫(yī)院計算機室主任李懷成,通過調(diào)查，我們看到：只有1.4%的大型企業(yè)選擇將后臺系統(tǒng)外包給第三方；3.3%的大型企業(yè)將前后臺全部外包給第三方。 - 2003年度中國大型企業(yè)信息化調(diào)查報告,“支持服務真的就能滿足我們所有的需求嗎？一些IT供貨商在蔑視用戶的認知能力，把我們當小孩哄，服務價格完全由它們說了算?！?- 中國化工信息中心副主任李中,規(guī)范化,規(guī)?；?服務規(guī)模,客戶規(guī)模,在規(guī)定的時間，完成規(guī)定的任務!,“ 雙 規(guī) ”,像制造產(chǎn)品一樣生產(chǎn)服務,

8、ITSM/ITIL!,流程（Process Flow）,成本 輸入,IT 生產(chǎn)車間,服務 輸出,ITIL降低成本,ITIL提高服務質(zhì)量,如何實現(xiàn)IT服務管理（ITSM）,ITSM和ITIL之間的關(guān)系,ITSM是目標，ITIL是工具！,ITSM流程模型,ITSM的發(fā)展趨勢,服務管理的普及程度,00 01 02 03 04 05,100%,75%,50%,25%,年,數(shù)據(jù)：Gartner Group , 2001,市場成長率 - Gartner： 32% cagr - IDC： 30%cagr - Meta： 26%cagr,ITSM的發(fā)展趨勢（續(xù)）,ITSM在全球： - 15萬人獲得ITIL證書

9、 - 2000家公司加入itSMF - 15個國家成立itSMF - 10萬套itSMF Pocket Guide被售 出 - 100種ITSM類軟件 - 80%的財富500強企業(yè)實施 過ITSM項目,ITSM在中國： - 1999年進入中國 - 目前處于推廣階段 - Big4全部進入，全力推廣 - 實施ITSM項目客戶： . 上海證交所、國家統(tǒng)計局 . 中國移動、中國聯(lián)通 . 中國銀聯(lián)、中國工商銀行 . 匯豐銀行、交通銀行 . 太平洋保險、海關(guān)總署 . ,IT Infrastructure Library （ITIL）Overview,神舟軟件2004年工作會,ITIL 是什么,ITIL 是

10、： - IT Infrastructure Library的簡稱 - 英國商務辦公室從20世紀80年代開 始開發(fā)的一套IT管理方法； - 已成為事實上的行業(yè)標準，并以其為中心在全球形成了完整的產(chǎn)業(yè)； - 任何單位和個人都可免費使用的“公共框架”； - 實際上是一系列由所謂“最佳實踐”（Best Practice）形成的圖書。,ITIL 不是： - 硬件 - 軟件 - 一個可以直接使用的標準,建立一系列完全的、一致的、連貫的最佳實踐規(guī)范，以提高IT服務管理質(zhì)量，并推動采用IT技術(shù)提高業(yè)務有效性 鼓勵私營機構(gòu)開發(fā)相關(guān)服務和產(chǎn)品（培訓、咨詢和工具）以支持ITIL,OGC開發(fā)ITIL 的目標,ITIL

11、2.0框架,ITIL2.0框架（續(xù)1）,業(yè)務管理（Business Perspective） - 在提供IT服務的時候，首先應該考慮業(yè)務需求，根據(jù)業(yè)務需求來確定IT需求； - 業(yè)務管理模塊指導業(yè)務管理者以自己習慣的思維模式： 分析IT問題 了解IT基礎架構(gòu)支持業(yè)務流程的能力 了解IT服務管理在提供端到端IT服務過程中的作用。 服務管理 - 服務管理模塊是ITIL的核心模塊； - ITIL把IT管理活動歸納為十個核心流程和一些輔助流程，然后利用這些流程進行有關(guān)IT管理工作； - 一共包括十大流程和一項服務臺職能。,ITIL2.0框架（續(xù)2）,IT基礎架構(gòu)管理（ICT Infrastructure

12、 Management） - 側(cè)重于從技術(shù)角度對基礎設施進行管理； - 覆蓋了IT基礎設施管理的所有方面，包括設別業(yè)務需求、實施和部署、對基礎設施進行支持和維護等活動； - 目標是確保IT基礎架構(gòu)穩(wěn)定可靠，能夠滿足業(yè)務需求和支撐業(yè)務運作。 應用管理（Application Management） - 為了確保應用系統(tǒng)滿足客戶需求并方便對其進行支持和維護，IT服務管理的職能應該合理地延伸，介入應用系統(tǒng)的開發(fā)、測試和部署； - 應用管理模塊指導IT服務提供方協(xié)調(diào)應用系統(tǒng)的開發(fā)和維護，以使它們一致地為客戶的業(yè)務運作提供支持和服務。,ITIL2.0框架（續(xù)3）,安全管理 - 1999年新增到ITIL中

13、； - 目標是保護IT基礎架構(gòu)，使其避免未經(jīng)授權(quán)的使用； - 為確定安全需求、制定安全政策和策略以及處理安全事件提供全面指導； - 側(cè)重從政策、策略和方法的角度指導如何進行安全管理。 IT服務管理實施規(guī)劃 - “如何做”（How）； - 作用是指導如何實施上述模塊中的各個流程，包括對這些流程的整合； - 指導客戶確立遠景目標，分析和評價現(xiàn)狀； - 確定合理的目標進行差距分析； - 確定任務的優(yōu)先級，以及對流程的實施情況進行評審。,ITIL 服務支持與服務提供職能與流程,服務支持 服務臺（職能） 事件管理 問題管理 變更管理 配置管理 發(fā)布管理,服務提供 服務級別管理 IT服務財務管理 可用性管

14、理 能力管理 IT服務連續(xù)性管理,Service Support流程,Service Delivery流程,業(yè)務、 客戶和 用戶,警告和期望 調(diào)整,請求和需求,需求、目標 和績效,管理工具和 IT基礎架構(gòu),可用性 管理,能力管理,IT服務財務 管理,IT服務連續(xù)性 管理,服務級別管理,溝通、更新 和報告,為什么使用ITIL ？,IT服務提供商利用ITIL 概念和實踐可以： - 提高客戶對IT服務的滿意度 - 加強與客戶交流 - 對于關(guān)鍵系統(tǒng)和基礎架構(gòu)，使之達到更高的可靠性 - 提升服務的性價比 - 在所有員工中建立一種共識,誰在使用ITIL ？,世界范圍內(nèi)超過10，000家的公司 歐洲，加拿大

15、，和澳大利亞的IT從業(yè)者 微軟，惠普，IBM等國際廠商 IT支持服務供應商,受ITIL 影響的工具,HP Openview Service Desk “根據(jù)ITIL的最佳實踐設計” Remedy Strategic Service Suite “和ITIL的最佳實踐相兼容” CA Unicenter Service Desk “和ITIL相適應” Peregrine Service Center “基于世界范圍內(nèi)頂尖的IT從業(yè)者多年的經(jīng)驗，以及最佳實踐的全球標準，包括ITIL?！?基于ITIL 的框架,Microsoft Operations Framework （MOF ） “結(jié)合了ITIL

16、的工業(yè)標準，以及微軟產(chǎn)品與技術(shù)的特殊要求” HP IT Service Management Reference Model “建立在惠普的服務管理與流程的經(jīng)驗，以及ITIL和最佳實踐基礎之上?！?ITIL 管理者, OGC仍然擁有ITIL ISEB（信息系統(tǒng)考試委員會） EXIN（信息科學考試學院） itSMF International & Chapters,“四架馬車”,服務臺（Service Desk）,神舟軟件2004年工作會,議程,概述 基本概念 主要活動 與其它流程之間的關(guān)系 成本、效益和問題 關(guān)鍵成功因素和績效指標 總結(jié),概述,定義： - 報告事件和請求提供用戶支持的中心，它主

17、要關(guān)注運作層次的用戶支持。 目標： - 為客戶和用戶提供單一聯(lián)系點； - 協(xié)調(diào)客戶（用戶）和IT部門之間的關(guān)系，為IT服務運作提供支持，從而提高客戶的滿意度； - 作為首次聯(lián)系點，服務臺通過截取不相關(guān)問題和容易回答的問題減輕了其他IT部門的工作量。 “過濾器”、“路由器”、“應答機”、“監(jiān)控器”、“滅火器”、“傳聲機”,基本概念（1）：呼叫中心/幫助臺/服務臺,呼叫中心/幫助臺/服務臺 - 呼叫中心：組織中負責處理大規(guī)?；陔娫挼慕灰椎牟块T，這種方式在銀行和保險業(yè)中使用較多。 - 幫助臺：負責管理、協(xié)調(diào)并盡快地解決IT服務運營中發(fā)生的意外事件的部門。幫助臺需要確?？蛻舻拿總€請求不會被丟失、遺忘

18、或忽略。 - 服務臺：不僅負責處理事件、問題和詢問，同時還為其它活動和流程提供接口。這些活動包括客戶變更請求、維護合同、軟件協(xié)議、服務級別管理、配置管理、可用性管理和IT服務連續(xù)性管理等。,基本概念（2）：集中式服務臺,定義： - 由一個物理上的服務中心集中處理所有的服務請求，為用戶提供了單一聯(lián)系點。 優(yōu)點： - 降低總體運營成本； - 管理控制上得到了加強； - 提高了資源利用率。 缺點： - 靈活性較差，難以針對各地用戶的特殊情況提供個性化的服務。,基本概念（3）：分布式服務臺,定義： - 每個地區(qū)或分部都創(chuàng)建了自己的服務臺以支持自己的業(yè)務運作。 優(yōu)點： - 便于提供本土化、個性化的服務，

19、響應速度快。 缺點： - 當用戶很多且需要的服務比較相似時，這種模式容易造成重復建設，浪費人力和物力，增加服務臺運作的總體成本。,基本概念（4）：虛擬式服務臺,定義： - 和用戶保持單點聯(lián)系的一種特殊的分布式服務臺。 優(yōu)點： - 降低了運營成本； - 加強了統(tǒng)一管理； - 提高了資源利用率。 缺點： - 難以提供現(xiàn)場支持。 實施要點： - 統(tǒng)一接入方式，包括流程、規(guī)程和術(shù)語； - 統(tǒng)一數(shù)據(jù)輸入語言； - 保持客戶和用戶的單點聯(lián)系，如利用虛擬桌和呼叫自動轉(zhuǎn)移技術(shù)實現(xiàn)全球或地區(qū)統(tǒng)一電話號碼； - 適當安排服務專家或工程師出現(xiàn)在客戶服務現(xiàn)場； - 使用統(tǒng)一的事件處理和管理流程。,第三方供應商服務臺,

20、基本概念（5）：呼叫中心/非技能型服務臺,呼叫中心 - 只負責記錄呼叫請求而不提供解決； - 呼叫請求被轉(zhuǎn)發(fā)到相應的專家部門； - 在有些情況下，呼叫請求的記錄和轉(zhuǎn)發(fā)可以通過語音響應系統(tǒng)自動進行。 非技能型服務臺 - 呼叫請求被記錄下來，并用通用的術(shù)語進行描述； - 大多數(shù)被立即轉(zhuǎn)發(fā)至相應的支持人員； - 在很大程度上只是一個調(diào)度部門； - 優(yōu)點在于事件記錄被標準化了并且是代表著永恒的理由對事件進行監(jiān)控和管理的； - 其缺點是響應時間更長，首次呼叫解決率要遠低于技能型服務臺。,基本概念（6）：技能型服務臺/專家型服務臺,技能型服務臺 - 比前面的幾種服務臺具有更多的技能和經(jīng)驗； - 通過使用文

21、檔化的解決方案，它可以解決許多事件，雖然有些事件還是要轉(zhuǎn)發(fā)給相關(guān)的支持小組； - 首次呼叫解決率通常都要遠遠高于非技能型服務臺。 專家型服務臺 - 具有關(guān)于全部IT基礎架構(gòu)的專家知識以及獨立地解決大部分事件的專門技術(shù)。,主要活動,響應呼叫請求 發(fā)布信息 供應商聯(lián)絡 運營管理任務 基礎架構(gòu)監(jiān)控,主要活動：,呼叫請求 - 用戶與服務臺進行的聯(lián)系； - 所有的呼叫請求都應該記錄下來以便進行進展監(jiān)控以及為流程控制提供有關(guān)的數(shù)量指標。 呼叫請求：事件（包括標準變更） - 錯誤報告：真實的故障以及對服務的抱怨； - 服務請求：服務請求在ITIL中被歸類為事件，但它并不包括IT基礎架構(gòu)中出現(xiàn)的故障。 呼叫請

22、求：事件（非標準變更） - 不被當作服務請求處理的非標準變更； - 針對這種變更的請求必須遵循標準的變更管理流程，需要提出一項正式的變更請求（RFC）。,主要活動：,發(fā)布內(nèi)容 - 當前或預期發(fā)生的錯誤，特別是在他們受到影響之前； - 有關(guān)新的和現(xiàn)有的服務項目、服務級別協(xié)議（SLA）的供應以及定購程序和成本等方面的信息。 發(fā)布方式 - 消極的方式，如提供一個公告牌； - 積極的方式，如E-mail、屏幕上顯示的聯(lián)系消息或屏幕求助消息。,主要活動：,聯(lián)系事項 - 打印機、工作站的維修和替換； - 電信設備的維修和替換； - 對純粹感覺上的事件（干擾）以及變更和服務請求的處理。,主要活動：,進行備份

23、和恢復、提供局域網(wǎng)連接。對當?shù)胤掌鬟M行磁盤空間管理、創(chuàng)建帳號、射電和重設密碼等也是服務臺的職責。,主要活動：,服務臺可能有權(quán)進入各種工具系統(tǒng)，這些系統(tǒng)被用來估計那些影響關(guān)鍵設備的故障可能產(chǎn)生的影響，如路由器、服務器、網(wǎng)關(guān)、關(guān)鍵任務系統(tǒng)、應用系統(tǒng)以及數(shù)據(jù)庫等。 通常，這些工具在某個故障出現(xiàn)或正對基礎架構(gòu)產(chǎn)生威脅時就能自動地排除這些故障并通知時間管理。 正常情況下，使用這些工具系統(tǒng)主要是運營小組的任務，由他們將有關(guān)的信息報告給服務臺。,與其它流程之間的關(guān)系,服務臺與事件管理 服務臺致力于在錯誤發(fā)生時盡可能快地恢復約定的服務級別。 服務臺通常提供有關(guān)用戶對服務級別管理流程質(zhì)量的體驗（用戶滿意度）方

24、面的有價值的信息。 用戶滿意度VS.客戶滿意度； 服務臺協(xié)助降低服務中斷所造成的影響的響應時間和解決時間。,服務臺與變更和發(fā)布管理 服務臺為變更和發(fā)布管理接收相關(guān)的RFCs和傳達相關(guān)的發(fā)布信息。 服務臺可能還要承擔軟件和硬件的安裝工作，因而在發(fā)布管理或變更管理中也承擔了一個角色。,與其它流程之間的關(guān)系（續(xù)1）,服務臺與服務級別管理 服務臺可以告知用戶其受到支持的產(chǎn)品以及有權(quán)使用的服務。如果服務臺沒有被授權(quán)來解決用戶的請求，則應該禮貌地告知用戶這點并將請求通報服務級別管理。 服務臺在處理用戶請求時應該以服務級別協(xié)議作為雙方協(xié)調(diào)的依據(jù)。,服務臺與配置管理 當服務臺記錄有關(guān)事件和問題時，需要驗證呼叫

25、者以及相關(guān)的IT組件，這需要結(jié)合配置管理流程中的CMDB進行。,關(guān)鍵成功因素和績效指標,關(guān)鍵成功因素： - 如果呼叫請求很難到達服務臺，則用戶可能不會去聯(lián)系它轉(zhuǎn)而試圖自己解決錯誤，或在組織內(nèi)找一個可以幫助他們的人來幫忙解決。 - 如果用戶試圖直接聯(lián)系有關(guān)的專家，則他們通常應該先向服務臺詢問。 - 應該制定良好的SLA、OLA以及服務目錄以確保服務臺提供的支持有一個明確的重點。 關(guān)鍵績效指標： - 對來電是否快速接聽（如90%的呼叫在x秒內(nèi)得到響應）？ - 呼叫是否在x分鐘內(nèi)被傳到二線支持（如果它們不能在服務臺得到解決）？ - 在沒有求助其它支持層次如二線支持、三線支持或供應商的情況下事件被解決

26、的百分比； - 每個工作站/用戶被處理的呼叫的數(shù)目，以及整個服務臺該項指標的總數(shù)。,事件管理（Incident Management）,神舟軟件2004年工作會,議程,概述 基本概念 主要活動 關(guān)鍵角色 與其它流程之間的關(guān)系 成本效益及可能的問題分析 關(guān)鍵成功因素和績效指標 總結(jié),概述,定義： - 事件管理是負責記錄、歸類和安排專家處理事件并監(jiān)督整個處理過程直至事件得到解決和終止的流程。 目標： - 在給用戶和公司正常的業(yè)務活動帶來最小影響的情況下，盡快地返回到SLA中定義的正常服務級別。 - 保留事件的有效記錄以便能夠權(quán)衡并改進處理流程，給其他的服務管理流程提供合適的信息，以及正確報告進展情

27、況。,基本概念（1）：事件/服務請求,事件（Incident）： - 在某一服務中不屬于標準操作的并能導致或可能導致這個服務的中斷或服務質(zhì)量下降的任何事件； - 不僅包括軟、硬件的錯誤，還包括服務請求 。 服務請求（Service Request）： - 用戶想要獲得有關(guān)的支持、提供、信息、建議或文檔而提出的請求，它并不屬于IT基礎架構(gòu)方面的故障； - 一個服務請求可能是要求進行一個標準變更，但是只要它屬于“標準服務”的范疇，那么就應當由事件管理而不是變更請求流程進行處理； - 如果被請求的服務不是事先已經(jīng)定義好的“標準服務”，并且它將改變IT基礎設施的狀態(tài)，那么我們將據(jù)此提交一個變更請求（R

28、equest For Change，RFC）。,基本概念（2）：影響度/緊急度/優(yōu)先級,影響度： - 影響度指就所影響的用戶或業(yè)務數(shù)量而言，事件偏離正常服務級別的程度 。 緊急度： - 解決故障時，對用戶或業(yè)務來說可接受的耽擱時間。 優(yōu)先級： - 處理事件和問題的先后順序。,基本概念（3）：升級,定義： - 如果某一事件不能在規(guī)定的時間內(nèi)由一線支持小組解決，那么更多的有經(jīng)驗的人員和有更高權(quán)限的人員將不得不參與進來，這就是升級。它可能發(fā)生在事件解決過程的任何時間和任何支持級別。 職能性升級（Functional Escalation） - 需要具有更多時間、專業(yè)技能或接入特權(quán)（幾束激光）的人員來

29、參與事件的解決。 - 這種升級可能會超越部門界限而且可能會包括外部支持者。 結(jié)構(gòu)性升級（Hierarchical Escalation） - 當經(jīng)授權(quán)的當前級別的機構(gòu)不足以保證事件能及時、滿意的得到解決時，需要更高級別的機構(gòu)參與進來； - 一般情況下應優(yōu)先使用職能性升級，只有當在某些事件不能得到及時解決時才考慮使用結(jié)構(gòu)性升級。,基本概念（4）：一線、二線、N線支持,檢測和記錄,事件歸類 初步支持,事件匹配,解決？,確定解決,結(jié)束事件,調(diào)查分析,解決？,確定解決,調(diào)查分析,解決？,確定解決,繼續(xù),否,否,否,是,是,是,第1線支持（也稱為第1排支持人員）通常由服務臺來提供； 第2線的支持則由管理

30、部門提供； 第3線的支持由軟件開發(fā)人員和系統(tǒng)結(jié)構(gòu)人員提供； 第4線的支持由供應商提供。,接收和記錄 歸類和初步支持 匹配 調(diào)查和診斷 解決與恢復 終止 跟蹤與監(jiān)控,主要活動,主要活動：,Why記錄？ - 已有的事件記錄可幫助對新發(fā)生的事件進行診斷； - 問題管理可通過對事件的記錄來發(fā)現(xiàn)問題的原因； - 如果所有的來電呼叫都被記錄下來，那么對某一事件的影響度的判斷會容易一些； - 如果沒有事件記錄，那么將不能監(jiān)控經(jīng)過協(xié)商服務級別是否得到履行； - 避免在解決問題時出現(xiàn)幾個人同時解決同樣的問題，或在對某一事件的處理過程中什么工作都沒有做等情形。 Who報告？ - 由某一用戶發(fā)現(xiàn)； - 由系統(tǒng)發(fā)現(xiàn)；

31、 - 由某一服務臺員發(fā)現(xiàn)； - 由另一IT部門的人發(fā)現(xiàn)。,主要活動：,記錄What？（部分） - 事件編號（唯一的）；事件類別； - 記錄事件的時間和日期；事件記錄人（或組）的姓名（或ID）； - 有關(guān)用戶的姓名、部門、電話和工作地點； - 回復用戶的方式（如電話，電子郵件等）； - 事件癥狀描述。 How記錄？ - 分配一個事件索引序號 大多數(shù)情況下系統(tǒng)會自動分配一個唯一的事件索引序號。通常，在后續(xù)溝通過程中用戶可使用通過提供的查詢序號來查看事件狀態(tài)。 - 記錄基本的診斷信息 時間、癥狀、用戶、處理問題的人、地點以及受影響的服務或硬件等信息。 - 附加事件信息 包括與事件相關(guān)的其他信息（例如

32、一個腳本或交談程序記錄）或配置管理數(shù)據(jù)庫中的一些信息（通常以數(shù)據(jù)庫中定義的關(guān)系為基礎）。 - 警告 如果存在一個具有高影響度的事件，例如某一重要服務器的癱瘓，則應警告其他用戶和管理部門。,主要活動：,類別 - 將事件歸入某一類別或某一子類； - 如按事件發(fā)生的可能原因分類或按與事件相關(guān)的支持小組進行分類。 優(yōu)先級 = 影響度 緊急度 服務 - 按照SLA的有關(guān)要求，需要用一個列表來表示與事件相關(guān)的服務； - 這個列表同時也提供了按照SLA對相關(guān)服務的升級時間。,主要活動：,支持小組 - 如果服務臺不能在預先確定的時間范圍內(nèi)解決事件，決定應該由哪個支持小組來負責處理該事件。 時間表 - 以優(yōu)先級

33、和SLA為基礎，受影響的用戶將會被通知預計解決問題的最長時間（一個周期時間） - 以及什么時候可以進行進一步的升級。 事件索引號 工作流狀態(tài) - 新建；已接收； - 已計劃；已分配； - 活躍狀態(tài)；已暫停； - 已解決；已終止。,主要活動：,對事件進行分類之后，要檢查以前是否發(fā)生過類似的事件。如果發(fā)生過，則查看是否存在解決方法和應急措施。如果新事件與某一問題或某一已知錯誤具有相同癥狀，那么可將事件指向這些已知的問題或錯誤。,!,!,!,Disk error,Network error,Printer,Server Breakdown,Non-operational Disk,Paper,主要活

34、動：,服務臺將那些沒有快速解決方法或超過他們專業(yè)水平的時間安排給具有更高專業(yè)水平和技術(shù)能力的支持群體。 支持小組將對事件進行調(diào)查并盡快加以解決，則將其轉(zhuǎn)交給其他的支持小組。,主要活動：,成功完成對事件的分析解決之后，負責解決問題的支持小組應在系統(tǒng)中記錄故障的解決方法； 對某些解決方法來說，必須要向變更管理發(fā)送一個變更請求（Request For Change，RFC）； 如果沒有找到解決事件的方法，那么事件依然保持開放（Open）狀態(tài)。,主要活動：,一旦解決方法執(zhí)行完畢，支持小組要把事件處理情況反饋給服務臺。服務臺應聯(lián)系事件的報告人以確認問題的確已經(jīng)得到解決。 如果服務臺可以確定問題已經(jīng)得到很

35、好的解決，那么事件就可以關(guān)閉（Close）了，否則需要在適當?shù)牡胤街匦麻_始處理流程。 在事件關(guān)閉的過程中，必須要對事件的記錄進行更新以指明對事件最終的分類和優(yōu)先級，受影響的服務、用戶、客戶，以及導致事件發(fā)生的配置項（CI）等。,主要活動：,作為所有事件的擁有者（Owner），服務臺負責對事件的發(fā)展情況進行監(jiān)控以及通知用戶有關(guān)事件的狀態(tài)。 用戶在某一狀態(tài)變更后可能作出適當?shù)姆答仯缭陬A期的事件周期內(nèi)發(fā)生的進一步的事件移交安排或變更等。 在對事件進展進行跟蹤和監(jiān)控時，可能需要將事件進行職能性升級，轉(zhuǎn)派給其他支持小組來處理，或進行結(jié)構(gòu)性升級，以加強處理事件的力度。,關(guān)鍵角色,事件經(jīng)理： - 對以下事

36、情負責： 監(jiān)控處理流程的效果和效率； 控制支持小組的工作； 為改進工作提供建議； 開發(fā)并維護事件管理系統(tǒng)； - 通常指派給服務臺經(jīng)理； 支持人員： - 第一線支持負責記錄、分類、匹配、轉(zhuǎn)交、解決和終止事件； - 其它的支持小組主要參與調(diào)查、診斷和恢復工作。,與其它流程之間的關(guān)系,事件管理與配置管理 配置管理顯示基礎架構(gòu)的某一部分由誰來負責，這樣當與這一部分相關(guān)的事件發(fā)生時可以迅速地進行追蹤。 CMDB還有助于決定合適的應急措施，如轉(zhuǎn)移打印隊列，將用戶轉(zhuǎn)移到另一個服務器等。 在進行事件注冊時，配置的詳細信息也被鏈接到了事件記錄以提供更好的相關(guān)錯誤信息。,事件管理與問題管理 問題管理需要了解事件記

37、錄以便查出任何潛在錯誤。 問題管理通過提供與特定問題相關(guān)的信息、已知錯誤、應急措施以及當前修補方法等來給事件管理提供幫助。,CMDB,!,與其它流程之間的關(guān)系（續(xù)1）,事件管理與服務級別管理 服務級別管理監(jiān)控與用戶就提供的服務支持達成的協(xié)議。事件管理必須熟悉服務基本協(xié)議（SLA）以便在與用戶進行溝通時可用到這些信息。事件記錄可用來生成報告來判斷是否真正地提供了規(guī)定級別的服務。,事件管理與變更管理 可通過實施變更來解決事件，如更換監(jiān)視器等。 變更管理為事件管理提供關(guān)于預定變更及其狀態(tài)的信息。 不正確的變更實施或者包含錯誤的變更也可能引發(fā)事件。此時，事件管理也可以為變更管理提供關(guān)于這類事件的信息。

38、,SLA,事件管理與可用性管理 可用性管理需要使用由配置管理提供的事件記錄和狀態(tài)監(jiān)控。,事件管理與能力管理 能力管理關(guān)注與其職能相關(guān)的事件，如由缺少磁盤空間或響應時間過長導致的事件。 業(yè)務經(jīng)理、系統(tǒng)經(jīng)理或系統(tǒng)本身可將這些事件通報事件管理系統(tǒng)。,與其它流程之間的關(guān)系（續(xù)2）,!,!,成本效益分析和可能的問題,成本： - 初始執(zhí)行成本（如對流程和過程的定義以及相互間的溝通）； - 培訓和指導人員（顧客和支持人員）； - 選擇和購買支持流程的工具等； - 與人事和工具使用相關(guān)的成本。 可能的問題： - 用戶和IT人員故意避開事件管理程序； - 事件處理超載和堆積； - 過多的升級可能會打亂專業(yè)技術(shù)人

39、員的正常工作而產(chǎn)生負面影響； - 缺乏清楚的定義和協(xié)議； - 缺少奉獻精神。,關(guān)鍵成功因素和績效指標,成功的事件管理需要： - 及時更新的CMDB來幫助估計事件的影響度和緊急度； - 知識庫（例如一個最新的問題數(shù)據(jù)庫或已知錯誤數(shù)據(jù)庫）。幫助識別事件，以及有什么解決方法和應急措施可用使用； - 適當?shù)淖詣酉到y(tǒng)。擁有記錄、跟蹤以及監(jiān)控事件； - 與服務級別管理間的緊密聯(lián)系以確保適當?shù)膬?yōu)先級和解決時間。 事件管理流程的關(guān)鍵績效指標： - 事件的總數(shù)； - 平均解決時間； - 每個事件的平均支持成本； - 在SLA的目標之內(nèi)解決的事件所占的百分比； - 不需拜訪用戶就解決的事件數(shù)； - 每個服務臺工作

40、站或每個服務臺員工平均解決的事件數(shù)。,問題管理（Problem Management）,神舟軟件2004年工作會,議程,概述 基本概念 主要活動 關(guān)鍵角色 與其它流程之間的關(guān)系 成本、效益和問題 關(guān)鍵成功因素和績效指標 總結(jié),概述,定義： - 通過調(diào)查和分析IT基礎架構(gòu)的薄弱環(huán)節(jié)、查明事件產(chǎn)生的潛在原因并制定解決事件的方案和防止事件再次發(fā)生的措施，將由于問題和事件對業(yè)務產(chǎn)生的負面影響減小到最低的服務管理流程； - 調(diào)查是基礎架構(gòu)和所有可用信息，包括事件數(shù)據(jù)庫，來確定引起事件的真正的潛在原因以及提供的服務中可能存在的故障。 目標： - 將由IT基礎架構(gòu)中的錯誤引起的事件和問題對業(yè)務的影響減小到最

41、低程度； - 查明事件或問題產(chǎn)生的根本原因，制定解決方案和防止事件再次發(fā)生的預防措施； - 實施主動問題管理，在事件發(fā)生之前發(fā)現(xiàn)和解決可能導致事件產(chǎn)生的問題。,基本概念（1）：問題/已知錯誤/變更請求,如果出現(xiàn)了一個已知錯誤，則應當提出一個 變更請求。但是，在通過一項變更將此已知 錯誤永久性地修復之前，它將仍將作為一個 已知錯誤。,變更請求說明了變更的內(nèi)容及與變更有關(guān)的 配置項。根據(jù)請求，變更管理小組和用戶及 其它有關(guān)人員對變更實施結(jié)果進行評價并計 劃進一步的變更。,基本概念（2）：事件管理VS問題管理,事件管理VS.問題管理： - 問題管理的主要目標是要查明事件發(fā)生的潛在原因并找到解決此事件

42、的方法或防止其再次發(fā)生的措施； - 事件管理的主要目標是在事件發(fā)生后盡可能快地恢復客戶服務，即使采取的是一些應急措施而不是永久性的解決方案； - 事件管理強調(diào)速度； - 問題管理強調(diào)質(zhì)量，把速度放在第二位； - 為了發(fā)現(xiàn)事件原因和防止事件再次發(fā)生，問題管理可能需要花費更多時間解決事件且可能推遲恢復服務。,基本概念（3）： 應急措施,Workarounds（應急措施） - 解決某個事件的替代方案，這種方案可在限定的時間內(nèi)產(chǎn)生一個可接受的結(jié)果。,基本概念（4）：問題控制/錯誤控制,問題控制 - 問題控制是問題管理流程的第一項活動。問題控制負責找出問題并調(diào)查其根源，其目標是通過確定問題根源并采取應急

43、措施來把問題轉(zhuǎn)化成已知錯誤。 錯誤控制 - 錯誤控制指監(jiān)控和管理已知錯誤直到其盡可能地得到適當?shù)奶幚?。為此，它需要向變更管理提交變更請求（RFC），并在實施變更后對變更進行實施后評審以評估其效果。,基本概念（5）：實施后評審（PIR）,實施后評審（PIR） - 用于解決問題、已知錯誤及相關(guān)事件的變更一旦實施后，在終止有關(guān)記錄工作之前必須對變更進行實施后評審（Post Implementation Review，PIR）。如果變更成功實施，那么對所有問題和已知錯誤及相關(guān)事件的記錄工作都可以終止了。 - 許多公司進行實施后評審是為了確保與問題相關(guān)的所有事件終止（包括確認客戶是否同意終止事件）之后才

44、能終止此問題。如果與其相關(guān)的所有事件沒有全部終止，則需將該問題重新置為“未解決”狀態(tài)。,主要活動,問題控制（Problem Control） 錯誤控制（Error Control） 主動問題管理（Proactive Problem Management）,主要活動：,如何確定問題？舉例： - 對某一事件進行分析表明該事件可能再次發(fā)生，或者有大量發(fā)生并且加重的趨勢。 - 對基礎架構(gòu)進行分析可以找出可能會產(chǎn)生事件的薄弱環(huán)節(jié)（也可由可用性管理和能力管理來進行分析）。 - 服務級別可能會受到威脅（能力、性能、成本等）。 - 記錄下來的事件不能與一個現(xiàn)有的問題或已知錯誤發(fā)生關(guān)聯(lián)。,主要活動：,如何歸類？

45、 - 類別：確定問題的相關(guān)領域，如是硬件還是軟件問題。 - 影響度：主要指對業(yè)務流程的影響。 - 優(yōu)先級：緊急度、影響度、風險和所需資源的綜合考慮。 - 狀態(tài)：如問、已知錯誤、已解決、已關(guān)閉但正在進行實施后評審等。,主要活動：,調(diào)查和診斷 - 一旦找到問題的根源以及與此問題相關(guān)的一個或多個配置項，就可建立配置項和相應事件之間的關(guān)聯(lián)； - 之后如果找到了解決此問題的應急措施，此問題就轉(zhuǎn)變?yōu)橐阎e誤。 臨時修復措施（Temporary fixes） - 在解決問題的過程中，如果問題導致了嚴重的事件，那么找到一個臨時修復或緊急修復的方法是非常必要的。 - 但是如果臨時修復措施需要對基礎架構(gòu)進行一些改

46、動，那么必須首先提交變更請求（RFC）（這主要是指在找到問題的最終原因之前）。 - 如果特別嚴重而且不容耽擱，就必須啟動緊急變更請求處理程序。,主要活動：,主要活動：,描述： - 根據(jù)對IT基礎架構(gòu)進行的分析，問題管理可以找到可能出現(xiàn)問題的薄弱環(huán)節(jié)，在事件發(fā)生前發(fā)現(xiàn)和解決有關(guān)問題和已知錯誤，以盡量減少問題和已知錯誤對業(yè)務的影響。 趨勢分析： - 找出IT基礎架構(gòu)中不穩(wěn)定的組件，分析其原因，以便采取措施降低配置項故障對業(yè)務的影響； - 分析已發(fā)生的事件和問題，研究其變化趨勢； - 經(jīng)過其它方式和途徑分析，比如系統(tǒng)管理工具、用戶反饋等。 制定預防措施： - 提交變更請求（RFC）； - 提交有關(guān)測

47、試、規(guī)程、培訓和文檔方面的反饋信息； - 進行客戶教育和培訓； - 對服務支持人員進行教育和培訓； - 確保遵守問題管理和事件管理的規(guī)程； - 改進相關(guān)的流程和程序。,關(guān)鍵角色,問題經(jīng)理 - 開發(fā)并維護問題控制和錯誤控制流程； - 幫助提供問題控制和錯誤控制的效率和效用； - 提供管理信息并運用這些信息主動預防事件和問題的發(fā)生； - 對問題管理人員進行管理； - 獲取問題管理行為所需的資源； - 開發(fā)并改進問題控制和錯誤控制系統(tǒng)； - 對主動性問題管理的有效性進行分析和評價。 問題支持人員 - 被動性職責： 通過分析事件細節(jié)確定并記錄問題； 以問題的優(yōu)先級為基礎對其進行調(diào)查和管理； 提出RFC

48、； 監(jiān)控已知錯誤的進展情況； 為事件管理的應急措施和暫時修復提供建議； 實現(xiàn)重大問題評審。 - 主動性職責： 確認問題的發(fā)展趨勢； 提供RFC； 防止問題擴散到其他系統(tǒng)。,與其它流程之間的關(guān)系,問題管理與配置管理 配置管理提供關(guān)于基礎架構(gòu)、設計圖、硬件和軟件配置及服務等組件的重要信息。 這些關(guān)系對問題管理的調(diào)查工作至關(guān)重要，因為他們定義了整個IT基礎架構(gòu)之間的相互關(guān)系。,問題管理與變更管理 變更管理流程負責控制執(zhí)行變更，包括由問題管理為消除問題而發(fā)出的RFC。 變更管理通知問題管理關(guān)于糾正性變更的進展和完成情況。這些糾正性變更的評價需要與問題管理進行磋商。,與其它流程之間的關(guān)系（續(xù)1）,問題管

49、理與服務級別管理 服務級別管理包括就實施IT服務時的服務質(zhì)量問題進行協(xié)商和談判。 服務級別管理為問題管理提供用于定義問題的信息。 而問題管理過程應當遵守、支持規(guī)定的服務級別。,問題管理與事件管理 有效的事件記錄對成功地進行問題管理來說非常重要，因為這些信息是用于發(fā)現(xiàn)問題的。 問題管理支持事件管理流程的工作，它為事件管理提供應急措施。,與其它流程之間的關(guān)系（續(xù)2）,問題管理與可用性管理 問題管理通過照常服務失敗的原因及補救方法來支持可用性管理的工作。 可用性管理致力于基礎架構(gòu)的結(jié)構(gòu)及設計，通過優(yōu)化可用性的設計、規(guī)劃和監(jiān)控來防止問題和事件的發(fā)生。 問題管理在分析服務失敗的原因時與可用性管理一起工作

50、。,事件管理與能力管理 能力管理為問題管理提供用于定義問題的重要信息。 而問題管理找出與能力有關(guān)的問題，查明原因并進行糾正，以此來支持能力管理的工作。,成本、效益和問題,成本： - 購買支持和診斷工具成本； - 人力成本； - 從外部供應商和支持機構(gòu)雇傭額外的專業(yè)人員所需的成本。 效益： - 提高IT服務的質(zhì)量和管理水平 基礎架構(gòu)中的失敗或錯誤已被記錄并已消除； - 提高用戶的效率 服務質(zhì)量的提高； - 提高支持人員的效率 解決方法已被記錄下來，事件管理代理可更加快速有效地解決事件； - 提升IT服務的名譽 因為提高了服務的穩(wěn)定性，顧客在開展新的業(yè)務時會更加信賴IT機構(gòu)； - 加強管理，增加操

51、作知識，提高學習能力 問題管理保存的歷史信息可用于確定事件或問題發(fā)展的趨勢，因此可阻止發(fā)生新的可避免事件。歷史信息也有助于在準備RFC時的調(diào)查也診斷工作。 - 改善對事件的記錄水平 問題管理為事件的記錄和分類引入標準，以有效的找出問題及其癥狀。它同時也可提高事件的報告水平。 - 更高的第一線支持問題解決率 由于問題管理使事件和問題的解決方法和應急措施在知識庫中可用，所以事件由或問題由第一線支持人員解決的可能性更大。,成本、效益和問題（續(xù)1）,問題： - 事件管理和問題管理之間的聯(lián)系不密切 如果事件細節(jié)和問題以及已知事件細節(jié)間的界面不是很清楚，那么事件管理將很難注意到對問題采取的應急措施，同時，

52、問題管理也很難實現(xiàn)對問題的影響度進行評估和監(jiān)控。這樣還可能造成關(guān)于IT基礎架構(gòu)的專業(yè)知識記錄以及歷史數(shù)據(jù)的減少。問題管理的成功很大程度上取決于事件管理和問題管理這兩個流程之間的協(xié)調(diào)。 - 從開發(fā)環(huán)境到現(xiàn)場生產(chǎn)環(huán)境關(guān)于已知錯誤的溝通欠缺 送交到生產(chǎn)環(huán)境的軟件和技術(shù)架構(gòu)應該同時包括關(guān)于任何已知錯誤細節(jié)的相關(guān)說明。在系統(tǒng)采用這些組件時，遞交這些關(guān)于已知錯誤的信息能夠避免公司在診斷先前已經(jīng)了解的錯誤上浪費時間。因此，這兩個環(huán)境中的記錄保存系統(tǒng)之間應該保持有效的數(shù)據(jù)交換，或者建立統(tǒng)一的記錄保存系統(tǒng)。 - 缺少奉獻精神 如果公司以前采取的方法并不正規(guī)，那么在實施正規(guī)的問題管理可能會受到一部分人的抵制，特別

53、是關(guān)于文件管理和及時記錄等方面。因此，與問題管理行為相關(guān)的人員在實施過程中應當保持對于開發(fā)情況的信息通暢。,關(guān)鍵成功因素和績效指標,關(guān)鍵成功因素： - 一個定義清楚的流程框架和一系列流程的目標、接口和資源； - 一系列廣泛并詳細記錄的過程； - 良好的事件管理數(shù)據(jù)以及事件管理和問題管理間有效的合作。當分配任務時，你應該清楚的了解事件管理所作的“滅火”工作與問題管理進行的調(diào)查“火災原因”的工作之間的區(qū)別。 關(guān)鍵績效指標： - 通過管理和解決問題，使事件的數(shù)量減少； - 解決問題所需的時間減少； - 與解決故障相關(guān)的成本降低。,變更管理（Change Management）,神舟軟件2004年工作

54、會,如果沒有變更管理,怎樣才能控制變更帶來的負面影響？ 怎樣評估變更對生產(chǎn)環(huán)境的風險？ 為什么變更總會帶來意想不到的事件或問題？ 哪些人需要參與到變更管理中來？ 怎樣把所發(fā)生的事件或問題與以往的變更關(guān)聯(lián)起來？ 如果變更不成功，該怎么辦？ 怎樣才能有效管理用戶或者使用者的變更請求？,議程,概述 基本概念 主要活動 與其它流程之間的關(guān)系 關(guān)鍵角色 成本、效益和問題 關(guān)鍵成功因素和績效指標 總結(jié),定義、目標和范圍,運作變更 管理請求,變更 實施,變更 監(jiān)控,變更管理的范圍,基本概念（1）：標準變更,標準變更 - 被制造商明確定義并由他們完成的常規(guī)管理任務，不需要由變更管理來控制，這種變更被稱之為標準

55、變更； - 標準變更中的常規(guī)任務包括：新建用戶帳號，改變網(wǎng)絡連接和安裝PC等等。 - 在標準變更的情況下，活動在完整變更管理流程中不是作為變更來執(zhí)行，但是可以劃分為事件管理下的服務請求； - 這些變更定期被執(zhí)行； - 不是所有的服務請求都是變更。,基本概念（2）：非標準變更,非標準變更 - 所有其它管理基礎架構(gòu)的修改都是非標準變更。,基本概念（3）： 緊急變更,緊急變更 - 在事件管理流程中，一種應急措施可以用來解決一個嚴重的事件。但如果情況嚴重且不允許延遲，可能需要啟動緊急變更請求（RFC）程序。 - 在緊急變更發(fā)生之前可能沒有足夠的時間做正常的測試，但是之后，正常流程所有必需的步驟都必須完

56、成以保證任何以前跳過的測試現(xiàn)在都被執(zhí)行，并且文檔（變更記錄和CMDB也得到了更新。 - 在需要執(zhí)行緊急變更的情況下，如果有時間，變更經(jīng)理可以組織一次CAB/EC的緊急會議。這種會議有特定的成員需要對其評價，授權(quán)，為其分配資源。,基本概念（4）： 變更請求(RFC),定義： - 對一個或多個特定配置項實施變更的正式請求； - 說明了變更的內(nèi)容及與變更有關(guān)的配置項。 - 包括標準變更和非標準變更兩種 為什么要RFC？ - 要求解決事件或問題； - 用戶或客戶對服務不滿意； - 引入或移除某個配置項； - 升級基礎架構(gòu)組件； - 業(yè)務需求改變； - 出現(xiàn)新法規(guī)或原有法規(guī)發(fā)生改變； - 改變位置； -

57、 廠商或承包商提出改動產(chǎn)品或服務。,Sample Change Request Form,主要活動,記錄 審查 歸類 規(guī)劃和批準 協(xié)調(diào) 評價,主要活動：,RFC從哪里來？ - 問題管理；提交處理辦法以消除錯誤，維持服務的穩(wěn)定運作； - 用戶：可能請求更多，更少或者其它服務。 - 供應商：供應商發(fā)布新的版本并更新他們的產(chǎn)品，確定他們所補救的錯誤。他們可能也與相互通信，表示不在支持某些版本，或者某個版本的執(zhí)行不安全。這可能引發(fā)問題管理或可用性管理提出一個變更請求。 - 計劃：一項計劃往往會帶來大量的變更。計劃管理必須通過相關(guān)的流程有效地與變更管理協(xié)調(diào)，例如，服務級別管理，能力管理等等。 - 所有其

58、它的IT人員：原則上，任何人都可以提交意見以提高服務質(zhì)量。特別地，IT人員對程序和手冊的提高做出貢獻。,主要活動：,RFC記錄中包括哪些內(nèi)容？ - 變更請求（RFC）標識碼； - 相關(guān)聯(lián)的問題/已知錯誤碼； - 相關(guān)配置項的描述和驗證； - 變更原因及不實施變更的后果； - 要被變更的配置項當前的和新的版本； - 提交該變更請求（RFC） 的人的姓名，地點和電話號碼； - 提交建議的時間； - 估計的資源和時間計劃； - 變更優(yōu)先級。,主要活動：,當RFC被記錄后，變更管理將會作出一個初步評估以檢查是否有RFC不清楚、不合理、不可行或者不必要。 如果拒絕這項請求，需要說明原因；并給予提交請求的