XX運維服務方案模板參考模板_第1頁
XX運維服務方案模板參考模板_第2頁
XX運維服務方案模板參考模板_第3頁
XX運維服務方案模板參考模板_第4頁
XX運維服務方案模板參考模板_第5頁
已閱讀5頁,還剩80頁未讀, 繼續(xù)免費閱讀

下載本文檔

版權說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權,請進行舉報或認領

文檔簡介

1、1 / 85XX 運維服務方案運維服務方案第第 1 章章 .項目概況項目概況41.1項目背景 .41.2項目目標 .41.3需求分析 .4第第 2 章章 .運維服務管理體系建設運維服務管理體系建設62.1IT 服務管理概述.62.2運維服務管理流程體系 .72.2.1服務支持.82.2.2服務提供.142.3運維服務管理規(guī)劃 .182.3.1第一階段:服務磨合階段.182.3.2第二階段:主動服務階段.212.3.3第三階段:戰(zhàn)略規(guī)劃階段.242.4運維服務質(zhì)量管理 .242.5建立運維管理規(guī)范 .262.5.1運維管理規(guī)范概要.26第第 3 章章 .信息系統(tǒng)運行保障方案信息系統(tǒng)運行保障方案2

2、83.1統(tǒng)一服務臺建設 .283.2建立文檔管理制度 .293.3一般信息化設備及相關軟件運維管理 .333.3.1一般信息化設備服務范圍.333.3.2一般信息化設備運維.333.3.3例行維護流程圖.343.3.4一般設備服務方案.353.4防(殺)病毒服務 .403.4.1防病毒服務需求.403.4.2制定合理的防病毒策略和安全管理制度。.403.4.3客戶端防病毒升級軟件.413.4.4防毒組件及時更新.413.4.5每周防毒系統(tǒng)部署情況統(tǒng)計.423.4.6每周對產(chǎn)生的病毒事件進行評估.423.5信息資產(chǎn)巡檢及普查服務 .423.5.1主動巡檢.423.5.2信息資產(chǎn)普查.433.6其

3、它有關說明及要求 .43第第 4 章章 .運維服務計劃方案運維服務計劃方案454.1運維服務準備 .454.1.1簽定必要的協(xié)議和約定.454.1.2人員準備.454.1.3工具準備.454.2項目人員組織 .464.2.1人員結構.464.2.2人員職責與崗位要求.474.3服務計劃 .484.3.1服務時間.484.3.2進場初始階段.484.3.3第一個服務階段.494.3.4第二個服務階段.494.3.5服務總結和延續(xù)階段.50第第 5 章章 .應急服務方案應急服務方案515.1災難應急措施 .515.1.1應急措施體制圖與總則.515.1.2大型災難緊急行動方案.525.2運行服務應

4、急方案 .555.2.1啟動應急流程.555.2.2成立應急小組.585.2.3應急處理過程.585.2.4應急處理結果評估.595.2.5統(tǒng)計和報告.59第第 6 章章服務水平質(zhì)量承諾及服服務水平質(zhì)量承諾及服務管理務管理 .626.1服務水平體系 .626.1.1報告服務.626.1.2管理類服務.626.1.3主動式服務.636.1.4響應式服務.636.2服務承諾.646.2.1服務級別承諾.646.2.2服務質(zhì)量承諾.656.3服務管理.656.3.1服務管理總則.656.3.2服務流程管理.666.3.3服務臺支持管理.676.3.4事件管理.696.3.5問題管理.706.3.6知

5、識庫管理.716.3.7服務記錄管理.71第第 1 章章 項目概況項目概況1.1 項目背景項目背景近年來為適應業(yè)務發(fā)展的需求,XX 企業(yè)進行了大規(guī)模的電子商務建設,包括采購桌面 PC 約 300 臺,打印機約 100 臺,這些應用系統(tǒng)及硬件設備的投入使用極大的推動了 XX 企業(yè)信息化建設的進程。隨著 XX 局對整體 IT 系統(tǒng)(硬件、軟件、網(wǎng)絡通訊)的可用性要求日益提高,系統(tǒng)運行保障和維護管理就成為確保業(yè)務系統(tǒng)安全穩(wěn)定可靠運行的最有力的手段。XX 企業(yè)主要有一棟 N 層的辦公環(huán)境,現(xiàn)階段對設備維護主要采用自主維護的方式。由于人力有限,建設任務繁重,中心技術人員在接手新項目及日常工作的同時往往需

6、要做大量的維護工作,不少技術人員長期處于滿負荷,嚴重影響了工作效率。在當前有限的人力物力資源下,為了保障和提高 IT 服務質(zhì)量,XX 企業(yè)有必要將計算機、外設及網(wǎng)絡的運行維護進行外包,派駐 2 名工程師進行維護,以解決當前 IT 服務個方面日益增長的需求和有限的提供能力之間的矛盾,提高 XX 企業(yè)辦公區(qū)域內(nèi)的軟、硬件、業(yè)務應用軟件的運行維護效率,確保信息系統(tǒng)正常運行。1.2 項目目標項目目標結合 XX 企業(yè)業(yè)務工作及信息化建設實際,完善運維管理體系的建設,加強信息系統(tǒng)正常運行保障, “以流程為導向,以服務為核心”提高服務質(zhì)量水平、轉變服務理念、拓寬服務范圍、提高服務效率、提升用戶服務滿意度。1

7、.3 需求分析需求分析本次項目 XX 企業(yè)需求主要包括兩個部分,1、運維管理體系建設要求;2、信息系統(tǒng)正常運行保障服務。其中運維管理體系建設應完善服務內(nèi)控制度即服務質(zhì)量管理,逐步建立起一套符合 XX 企業(yè)自身實際的運維管理標準及應用制度;建設 IT 運營維護管理平臺,采用標準的 IT 運維管理流程,提供準確、詳盡、專業(yè)的報告制度,通過客觀分析運維過中出現(xiàn)的各種障礙及問題,為 XX 企業(yè)信息化建設提供決策依據(jù)。信息系統(tǒng)正常運行保障涵蓋了1、一般信息化設備及軟件的運維管理; 2、防病毒服務;3、辦公區(qū)域內(nèi)設備及軟件巡檢普查;4、提供符合 XX 企業(yè)實際的服務響應水平及質(zhì)量保障;5、信息化資產(chǎn)管理第

8、第 2 章章 運維服務管理體系建設運維服務管理體系建設2.1 IT 服務管理概述服務管理概述現(xiàn)今,隨著計算機技術,特別是網(wǎng)絡技術的飛速發(fā)展,對于許多行政單位,許多企業(yè)而言,IT 技術越來越深入到核心業(yè)務,影響策略制定和企業(yè)的發(fā)展。從而對 IT 環(huán)境的可靠性,可用性和快速適應性提出了越來越高的要求,與此同時,IT 環(huán)境(包括軟/硬件及相關技術)卻變得越來越復雜。因此,對于一個單位而言: 如何把有限的 IT 資源最有效的作用于核心業(yè)務的發(fā)展 如何最快地獲取專業(yè)的支持能力 如何實現(xiàn)對系統(tǒng)的完善管理,提高系統(tǒng)的可靠性和可用性 如何提高用戶的工作效率,增加最終用戶滿意度 如何跟上 IT 技術的發(fā)展,及時

9、更新相關技術 如何提高對 IT 系統(tǒng)利用的靈活性 如何更好地管理 IT 運營成本 以提高服務能力,將會是單位可能面臨的問題。 IT 服務管理(服務管理(ITSM)是一套幫助企業(yè)對)是一套幫助企業(yè)對 IT 系統(tǒng)的規(guī)劃、研發(fā)、實施和運系統(tǒng)的規(guī)劃、研發(fā)、實施和運營進行有效管理的方法,是一套指導營進行有效管理的方法,是一套指導 IT 服務的方法論服務的方法論。ITIL 是英國國家電腦局(CCTA)于八十年代開發(fā)的一套 IT 業(yè)界的服務管理標準庫,它把業(yè)界在 IT管理方面最好的方法歸納起來,形成規(guī)范,旨在為企業(yè)的 IT 部門提供一套從計劃、研發(fā)、實施到運維的標準方法。它一經(jīng)提出,便被歐洲各大公司紛紛采納

10、,隨后在澳洲,美洲和亞洲流行開來,目前已成為 IT 服務管理事實上的標準。通過參考這些標準,我們可以充分借鑒國際化標準的 IT 服務管理最佳經(jīng)驗,使我們“站在巨人的肩膀上”來設計、規(guī)劃及運維 IT 服務,盡可能少走彎路,有效提高 IT 服務的質(zhì)量。 ITIL 框架圖ITIL 是基于流程的方法論。IT 部門可用其檢查是否用一種可控的和可訓練有素的方法為最終用戶交付所需的 IT 服務。ITIL 合并了一套最佳的實踐慣例,可適用于幾乎所有 IT 組織,無論其規(guī)模大小,或采取何種技術。ITIL 對 IT 服務管理實踐中涉及的許多重要問題進行了系統(tǒng)的分析,包括全面的檢查清單、任務、程序、責任等與任何 I

11、T 服務組織密切相關的問題。這些概念的定義也涵蓋了大多數(shù) IT 服務組織的主要行為。IT 服務組織可以借助ITIL 的指導建立和拓展自己的 IT 服務流程。2.2 運維服務管理流程運維服務管理流程體系體系運維務管理最核心的是“服務支持” (ServiceSupport)和“服務提供”(ServiceDelivery)兩個模塊。各流程相互貫穿和作用,形成有機整體,共同建立一個健全的服務管理體系。 如下圖所示: 2.2.1 服務支持服務支持服務支持的內(nèi)容描述了一個客戶如何訪問適當?shù)姆?,以支持其業(yè)務。服務支持包含以下內(nèi)容:2.2.1.1服務臺服務臺我們?yōu)槠髽I(yè)建設服務臺,提供統(tǒng)一報障電話,統(tǒng)一報障、

12、統(tǒng)一維修接口,越秀工商可以通過統(tǒng)一的報障電話申請服務、查詢服務處理進程,監(jiān)控服務質(zhì)量。服務臺(ServiceDesk)是 IT 服務組織和用戶相互聯(lián)系的接入點。服務臺曾經(jīng)被稱為幫助臺(HelpDesk)。HelpDesk 的主要任務是記錄,分解和監(jiān)控提出的問題。一個服務臺可以具備更寬范的角色,如接收變更請求(RFC),并且可以支撐多種流程中的操作。服務臺是服務提供者和用戶之間的日常工作的單一聯(lián)系點。它也是報告突發(fā)事件和提交服務請求的焦點。正因為如此,服務臺的職責是保持將服務相關信息,行為和契機通知用戶,并追蹤了解用戶每日的行為。例如,服務臺可能扮演用戶提交變更請求的聯(lián)系點,基于變更管理流程傳達

13、變更實施計劃,并保持將變更實施進程通知用戶。變更管理應該確保服務臺隨時保持對變更行為情況的掌握。在任何對 SLA 產(chǎn)生影響的事件面前,服務臺處于第一線,并維護高速的信息流通道。圍繞突發(fā)事件,服務臺有可能在其權限范圍被授權實施變更。此類變更的范圍可能被預先定義。當所有相關變更發(fā)生時,變更管理流程將被告知?;旧希攲θ魏?CI 的規(guī)范做出修改之前,變更流程都需要對其進行預先審批。2.2.1.2突發(fā)事件管理突發(fā)事件管理突發(fā)事件管理流程致力于解決突發(fā)事件,并快速恢復服務供應。突發(fā)事件被記錄下來,并且事件記錄的質(zhì)量決定了相關的其它流程的效力。服務臺接近于突發(fā)事件管理流程和問題管理流程,并處于它們之間。

14、如果沒有適當?shù)目刂?,變更有可能引入新的突發(fā)事件。因此需要建立有效途徑對變更進行跟蹤。這是為什么建議持續(xù)不斷地將突發(fā)事件記錄在同一個 CMDB 中,并分類為“問題”, “已知錯誤”, “變更記錄”等信息,以促進服務臺界面的信息溝通能力,簡化事件調(diào)查和報告。突發(fā)事件的優(yōu)先權及其升級需要作為服務級別管理流程中的一部分進行協(xié)商,并在 SLA 中備案。突發(fā)事件管理的目標:突發(fā)事件管理的目標是盡可能迅速地根據(jù) SLA 中定義的普通服務級別作出反應,使產(chǎn)生問題后對業(yè)務行為及組織和用戶的影響最小。突發(fā)事件管理也應該保留對事件的有效記錄,以便于衡量和改進流程,并向其它流程匯報。突發(fā)事件流程如下圖所示:2.2.1

15、.3問題管理問題管理對于突發(fā)事件有兩種處理方法,一種是對其做出服務快速響應,盡快恢復其正常運行,另一種是鑒別和解決問題根源。這兩種方法之間存在微妙的區(qū)別,而且經(jīng)常被互相混淆。對其做好區(qū)分具有重要意義。如果問題被懷疑存在于 IT 架構內(nèi)部,問題管理流程將會瞄準其潛在的根源。一個問題可能是被突發(fā)事件暴露出來的,但是顯然,問題管理的目標是解決問題根源,預防其可能產(chǎn)生的干擾,而不是迅速恢復系統(tǒng)運行。當問題被識別后(被識別的問題通常稱之為已知錯誤),通常需要進行一個業(yè)務決策,決定是否采取永久性措施改進系統(tǒng)架構,以預防再次發(fā)生新的突發(fā)事件。如果需要,提交一個變更請求來實現(xiàn)改進。為了有效和高效地識別突發(fā)事件

16、背后的問題根源及其發(fā)展趨勢,問題管理流程需要準確全面的突發(fā)事件的記錄。問題管理流程同樣需要和可用性管理流程密切聯(lián)絡,以確定這些趨勢并明確補救措施的重要性。流程:2.2.1.4配置管理配置管理配置管理致力于控制一個變化中的 IT 架構(標準化和狀態(tài)監(jiān)控),鑒別配置項目(清冊,相互關聯(lián),審核與注冊),收集和管理有關 IT 架構的文檔,為所有其它流程提供 IT 架構的相關信息。配置管理是所有其它服務管理流程不可分割的一部分。擁有當前架構中所有部件的最新的,準確的,全面的和詳細的信息,并管理其變更,使這些信息有效而高效地支持其它流程運行。變更管理可以與配置管理集成。至少,建議在配置管理系統(tǒng)中控制變更的

17、登錄和實施,并自在配置管理系統(tǒng)的幫助下對變更影響做出評估。因此所有變更請求應該被輸入配置管理數(shù)據(jù)庫(CMDB),并隨著變更請求的進展隨時更新記錄,直至其實施。配置管理系統(tǒng)識別一個變更項目和架構中其它部件的關系,將這些部件的所有人召集到影響評估流程中來。不管一個變更是否在架構中實施,相互關聯(lián)的配置管理記錄應該在 CMDB 中得到更新。最好在變更發(fā)生時,使用集成工具自動地更新記錄。CMDB 應該開放給整個服務支持組,使所有人理解部件失效可能的原因,從而使突發(fā)事件和問題可以被更容易地解決。CMDB 還應當被用來把突發(fā)事件及問題記錄和其它記錄聯(lián)系起來,比如失效的配置項目(ConfigurationIt

18、em-CI)和用戶之間的聯(lián)系。如果缺少了配置管理流程的集成,發(fā)布管理將難以實現(xiàn),并可能錯誤連連。服務交付流程同樣依賴于 CMDB 中的數(shù)據(jù)。例如:服務級別管理需要識別相互結合在一起的部件,并在此基礎上設置支持協(xié)議,交付服務。IT 財務管理需要知道每個業(yè)務部門使用的 IT 架構部件,尤其是對于收費的項目。IT 服務持續(xù)性和可用性管理需要識別部件,用于問題風險分析和部件失效影響分析。下圖顯示了配置管理和其它服務管理流程之間的關系:圖:能力管理,變更管理,配置管理和發(fā)布管理之間的關系2.2.1.5變更管理變更管理變更管理專注于對 IT 架構實施可控的變更。此流程的目標是確定所需的變更,并決定這些變更

19、如何在對 IT 服務產(chǎn)生最小的不利影響的范圍內(nèi)得以實施。同時確保其變更是可追溯的,而且是經(jīng)過整個組織內(nèi)部有效地磋商和協(xié)調(diào)的。在客戶組織提交變更請求后,由配置管理流程監(jiān)控其狀態(tài),與問題管理和若干其它流程進行協(xié)調(diào)。變更實施履行一特定的路徑,包括定義,計劃,建立,測試,接受,實施,和評估。變更管理流程依賴于配置數(shù)據(jù)的準確性,以確保獲知所有實行變更造成的影響。因此變更管理與配置管理之間有密切的聯(lián)系。變更流程的詳細內(nèi)容應在 SLA 中存檔,確保用戶知道提交變更申請的程序,項目目標及時間,以及實施變更造成的影響。變更的詳細內(nèi)容需要通知服務臺。即使變更經(jīng)過了全面測試,仍然很有可能存在實施變更的過程中發(fā)生各種

20、困難,這些困難可能緣于變更沒有按需求或預期運行,或者對變更對功能造成的影響產(chǎn)生質(zhì)疑。變更咨詢會議(ChangeAdvisoryBoard-CAB)由可向變更管理小組提供專家意見的人員組成。這個會議很可能由來自于所有領域的 IT 及業(yè)務單位的人參與。2.2.1.6發(fā)布管理發(fā)布管理發(fā)布是指一組配置項目(ConfigurationItemsCI)經(jīng)過測試被引入處于活動狀態(tài)的環(huán)境中。發(fā)布管理的主要目標是確保發(fā)布信息被成功地公布,包括歸納綜合,測試與存檔。發(fā)布管理確保只有經(jīng)過測試和正確授權的軟硬件版本才能提供給 IT 運行環(huán)境。發(fā)布管理與配置管理和變更管理的行為密切相關。真實的變更實施經(jīng)常通過發(fā)布管理行

21、為得以貫徹。變更的結果可能經(jīng)常來自于新硬件,新版本軟件,以及新的文檔(自行建立,或購買而來)等。對它們進行控制,并打包和頒發(fā)。有關存檔安全和公布程序應該和變更管理和配置管理流程緊密集成。發(fā)布的程序也可能作為突發(fā)事件管理和問題管理流程中不可分割的一部分,同時還和 CMDB 密切相連,以維護及時更新的記錄。2.2.2 服務提供服務提供服務提供主要包括:服務級別管理、IT 服務財務管理、能力管理、持續(xù)持續(xù)管理、可用性管理等。2.2.2.1服務級別管理服務級別管理服務級別管理的目標是縷清與客戶之間有關 IT 服務的協(xié)議,并付諸實施。 因此, 服務級別管理需要收集客戶需求, IT 服務組織可提供的設施,

22、以及可用的財務資源。 服務級別管理針對提供給客戶的服務 (聚焦客戶的)。因此是基于客戶需求建立服務 (需求拉動),而非單純基于現(xiàn)有技術所及(供應驅動),從而使 IT 服務組織提高客戶滿意度。服務級別管理闡述的內(nèi)容有: 如何在服務級別協(xié)議(Service Level Agreement SLA)中清楚地定義條款, 使其可優(yōu)化 IT 服務成本, 并為用戶所接受。如何監(jiān)控和討論所提供的服務。如何管理 IT 服務組織的供應商及其下包合同。 服務級別管理(Service Level Management SLM)流程是用來確保服務級別協(xié)議,并支持運行級別協(xié)議及其它合同,保證所有對服務質(zhì)量的影響減少到最小

23、。此流程在服務質(zhì)量和 SLA 基礎上評估各種變更造成的影響,包含預期變更前的影響, 也包含評估實施變更后的影響。SLA 中某些最重要的目標和服務可用性、以及在容許周期內(nèi)對突發(fā)事件形成決策有關。SLM 是服務支持和服務交付的關鍵。由于它依賴于其它流程的存在性, 有效性及運行效率, 它不可孤立存在。一個缺乏基礎支持流程的 SLA 是沒有意義的, 缺乏支持的 SLA 就失去了承認其內(nèi)容的基礎。2.2.2.2IT 服務的財務管理服務的財務管理財務管理針對于 IT 服務的謹慎從事。例如,當所提供的 IT 服務在進行中時,財務管理將提供其導致的成本信息。這樣使考慮 IT 架構或 IT 服務的改變時,能夠合

24、理地考慮成本和利益(價格和性能)之間的關系。財務管理中對成本的鑒別、分配、預測和監(jiān)控使成本成為可知因素,減少成本和預算的差距。 重點結合 IT 服務組織的贏利, IT 服務的財務管理描述了多種支付方法,包括設立支付和定價的目標,以及預算計劃。財務管理負責對成本及 IT 服務投資回報的會計核算,并管理任何來自于客戶的成本。財務管理需要與能力管理(Capacity Management),配置管理(Configuration Management,包含資產(chǎn)數(shù)據(jù)),以及 SLM 的良好接口, 來確定服務的真實成本。 在 IT 組織預算談判階段和客戶的 IT 耗費核算階段, 財務管理很可能與業(yè)務關系管

25、理(Business Relationship Management)及IT 組織密切相關。2.2.2.3能力管理能力管理能力管理是優(yōu)化成本,獲得時間,以及開發(fā) IT 資源的流程,來支持與客戶簽訂的服務條款。能力管理針對資源管理,性能管理,需求管理,建模,能力計劃, 負載管理,以及應用軟件能力推測。能力管理強調(diào)用計劃來確保所簽訂的服務級別可以被履行和成長。能力管理負責確保在所有時間具備足夠的可用能力,以滿足業(yè)務需求。 能力管理不是簡單地與系統(tǒng)部件的性能相關, 而是直接與業(yè)務需求相關。 在那些與能力問題相關的困難面前, 能力管理在突發(fā)事件決策和問題鑒別過程中被引入。能力管理提交變更請求以確保得到

26、適當?shù)目捎媚芰Α?這些 RFC 被提交給變更管理流程, 其實施可能影響若干 CI, 包括硬件, 軟件和文檔,并需要提供有效的版本管理。能力管理應該在評估所有變更時被引入, 用來確定變更導致的在能力和性能上的影響。 這種影響在變更實施前后都有可能出現(xiàn)。 能力管理應該特別關注變更在一定周期后引起的累積性變化。 容易被忽略的單個的變更往往在經(jīng)過累積后, 引起響應時間衰減, 文件存儲問題, 和對處理能力的過度需求。2.2.2.4IT 服務持續(xù)性管理服務持續(xù)性管理此流程在業(yè)務中斷時對 IT 服務進行災難恢復措施的準備和計劃。 業(yè)務持續(xù)性管理為客戶組織遇到災難時準備好緊急預案, 根據(jù)此預案采取與 IT 服

27、務相關的預防災難發(fā)生的措施。 IT 服務持續(xù)性管理流程對技術, 財務和管理資源需求做好計劃和協(xié)調(diào), 確保災難發(fā)生后可持續(xù)提供服務, 并就其內(nèi)容達成客戶同意。IT 服務持續(xù)性管理與一個組織在業(yè)務中斷后在某個可允許范圍內(nèi)繼續(xù)運作的能力密切相關。 至少要保證最基本的業(yè)務運行所需要的 IT 服務, 預先對其服務級別作出規(guī)定, 并和客戶達成一致。 有效的 IT 服務持續(xù)性需要一個平衡的風險縮減措施, 例如有彈性的系統(tǒng)和備份恢復設施。 配置管理流程中的數(shù)據(jù)被用來輔助其計劃和預防措施。 需要對架構和業(yè)務變更對持續(xù)性計劃造成的潛在影響進行評估。 有關 IT 和業(yè)務的計劃應該提交變更管理程序。 在持續(xù)性管理流程

28、中, 服務臺承擔著重要角色。2.2.2.5可用性管理可用性管理可用性管理是確保資源, 方法和技術得以適當拓展的流程, 以支持與客戶簽訂的 IT 服務條款。 可用性管理針對所遇到的問題, 如優(yōu)化維護等, 并且設計測量指標, 最大程度減少意外突發(fā)事件的數(shù)量??捎眯怨芾砼c IT 服務的設計, 實施, 測量和管理相關, 確保規(guī)定的業(yè)務需求中有關可用性的內(nèi)容被貫徹。 可用性管理需要理解 IT 服務失效發(fā)生的原因和恢復服務所需的事件。 突發(fā)事件管理和問題管理提供了關鍵輸入SLA 中描述的可用性的目標在可用性管理流程中被監(jiān)控, 并包含在其報表中。 此外, 在支持服務核查制度所提供的測量和報表中, 可用性管理

29、對服務級別管理(SLM)流程提供了支持。2.3 運運維服務管理規(guī)劃維服務管理規(guī)劃2.3.1 第一階段:服務磨合階段第一階段:服務磨合階段第一階段,又稱為運維服務磨合階段,工作目標主要是通過服務管理,將客戶現(xiàn)有的無序救火式突發(fā)事件服務有序化,實現(xiàn)突發(fā)事件管理,所有的突發(fā)事件將運用技術、管理與流程相結合的方式,做到統(tǒng)一管理,統(tǒng)一任務分發(fā),安排合適的人員處理合適的事件。所有的突發(fā)事件全過程可控制、跟蹤、即時回饋,讓每一個客戶能夠隨時查詢到事件處理過程,不會出現(xiàn)焦慮、服務要求長時間無人響應或服務要求根本無人響應的情況,從而提高客戶滿意度,提高運行維護效率,提高客戶使用業(yè)務信息系統(tǒng)的效率,從而做到提高總

30、體生產(chǎn)力?,F(xiàn)今客戶大都沒有真正意義上的配置管理系統(tǒng)。配置管理系統(tǒng),顧名思義,含有業(yè)務信息系統(tǒng)及終端設備詳細清單,配置情況,針對于業(yè)務信息系統(tǒng)的操作系統(tǒng)服務運行情況,終端運行軟件情況,使用軟件資產(chǎn)情況等,以及每一次配置改變的記錄,做到配置的改變都有跡可查,將軟硬件資產(chǎn)系統(tǒng)化的管理起來。用一句話概括我們上述兩項服務:將無序的突發(fā)事件有序化,將紙制的配置管理信息化。就是我們突發(fā)事件管理以及配置管理的目標。ITSM 所定義處理突發(fā)事件的工作目標是規(guī)避與盡快恢復。運維服務的目標不是盡可能多,盡可能快的完成服務,而應該是盡量避免事件的發(fā)生,當然,這不是一步可以到位的,因此,在第一階段,我們需要做到盡快恢復

31、客戶的正常使用,故:在處理突發(fā)事件時,我們不分析事件發(fā)生的原因,只收集有價值的事件/故障信息,并在最短的時間內(nèi)將客戶的設備恢復到正常使用狀態(tài)。針對于重復/頻繁發(fā)生的突發(fā)事件,我們需要轉問題管理流程,予以處理。問題管理,也就是事件的原因分析以及根除此事件的解決方法管理,我們需要對突發(fā)事件發(fā)生的原因,使用專業(yè)的方式予以分析,如使用國際 QA 標準,使用魚骨圖,使用柏拉圖等方式來分析出可能的原因,并對原因予以檢測和測試,提出根本解決事件的方案。魚骨圖分析法柏拉圖分析法問題管理,僅提出解決問題之道,也就是根除某突發(fā)事件的方案,具體的處理步驟,交由實施管理來執(zhí)行。實施管理,又叫做發(fā)布管理,因根除故障特別

32、是信息系統(tǒng)缺陷時,需要嚴格處理過程,避免在線運行業(yè)務受到不可預計的影響。我們在發(fā)布過程中都會預計到一些可能的影響,如更改交換機配置可能導致部分終端無法使用網(wǎng)絡;修改某一個數(shù)據(jù)庫字段可能導致數(shù)據(jù)混亂;修改某段代碼可能導致整個程序陷入死循環(huán)等。因此實施管理必須能有效并切實的分析大部分存在或者隱含的風險。試想我們在更改交換機配置前經(jīng)歷過充分測試,將中斷網(wǎng)絡時間縮短為五分鐘并且通知到全部/大部分可能受影響的客戶;修改數(shù)據(jù)庫字段或代碼前在虛擬測試平臺或訪真數(shù)據(jù)庫中反復測試,而后予以發(fā)布;將發(fā)布的時間定在非使用高峰期。這樣,可以規(guī)避大量風險,保證問題解決的安全可靠。越維風險控制模型風險監(jiān)控風險應對計劃編制

33、風險分析風險識別凡涉及到解決問題,必然關聯(lián)到變更。變更管理的作用,是保證每一步的配置更改,都有跡可查,有人可尋。在工作中是否遇到過有人修改了系統(tǒng)代碼,您卻不知道是誰改動了哪些地方?驗收后提供的系統(tǒng)原代碼不知道是否與在線系統(tǒng)原代碼相符?有哪些地方不同?是哪些人修改的?您的設備是否與剛采購的時候配置情況相同?保修情況始終保持不變?變更后的資產(chǎn)是否已經(jīng)更新配置庫?變更管理將為您解答上述問題。第一階段的服務,就涵蓋上述五個方面的服務內(nèi)容,總結描述:將無序的突發(fā)事件有序化,將紙制的配置管理信息化,問題管理科學化,實施管理風險可控制化,以及變更管理記錄化。2.3.2 第二階段:主動服務階段第二階段:主動服

34、務階段重點是在改良前一階段的服務基礎上,將前一階段的大量響應式服務,部分主動式服務,轉換為主動服務為主導,科學的規(guī)避故障發(fā)生,做到故障可控制化。因此,第二階段的服務內(nèi)容,主要包括:實施&測試、安全管理、IT 服務規(guī)劃,以及規(guī)模管理、可用性管理、服務級別管理和成本管理。實施&測試:前面我們講實施管理,包含有上線前的充分測試等工作,那這一個實施&測試是否重復呢?此處的實施&測試,是與業(yè)務信息系統(tǒng)開發(fā)質(zhì)量管理相關的實施管理和測試管理工作。隨著業(yè)務信息化需求的不斷提高,業(yè)務系統(tǒng)的升級也隨之產(chǎn)生。是 Down掉原有系統(tǒng)建設新的,還是在原有系統(tǒng)基礎上進行修改?是用新的服務器

35、替換掉原有服務器,還是在原有服務器上升級?這些處理,都面臨一個必不可少的階段:切換??蛻敉辉敢飧鼡Q已經(jīng)使用習慣了的系統(tǒng),除非系統(tǒng)已經(jīng)不能滿足他的實際工作需求,但老系統(tǒng)總是存在大量缺陷,且運行效率低下,導致業(yè)務部門的工作效率也隨之下降。那么,為什么客戶不愿意更換系統(tǒng)?原因是不熟悉。已經(jīng)開順手的車不會容易出事故,已經(jīng)用順手的手機可以方便的找到每一個聯(lián)系電話,而新系統(tǒng)的培訓,是否進行得完善?新的業(yè)務流程講解,是否讓每一個業(yè)務部門人員熟悉了?新系統(tǒng)是否有這樣那樣的缺陷而導致更低下的效率?新系統(tǒng)是否能夠承載足夠多的用戶訪問?新采購的硬件是否能夠保證質(zhì)量?業(yè)務系統(tǒng)可以通過分析代碼來找尋缺陷,但是需要的

36、時間過長,可以在測試平臺上對每一個功能進行測試,但是無法滿足壓力測試,只有將多種測試手段有機結合起來,才能保障新系統(tǒng)的質(zhì)量,如使用 Winruner 予以界面測試,使用 Loadruner 進行壓力測試,并管理好開發(fā)商的培訓工作,將給實施與測試工作帶來實質(zhì)性效果。另外,選擇合適的發(fā)布時間,做好發(fā)布計劃,也是實施管理工作的重點。安全管理,指服務過程的安全類服務、風險控制以及與客戶的數(shù)據(jù)安全協(xié)議。安全類服務如網(wǎng)絡病毒防治,網(wǎng)絡反黑,入侵檢測等技術類服務,風險控制如服務過程中各種風險的分析、規(guī)避等管理。技術類工作可以通過軟件等工具來實現(xiàn),如系統(tǒng)補丁分發(fā),防病毒軟件升級及策略優(yōu)化,網(wǎng)絡安全性優(yōu)化,增加

37、入侵檢測系統(tǒng)(IDS)等,這些服務也能夠在第一階段中開始,而風險控制和客戶數(shù)據(jù)安全性協(xié)議,則完全通過人員管理、流程管理來實現(xiàn)。標準的ITSM 流程是能夠做到 0 風險的,但在實際處理過程中卻往往不可能做到 0 風險。畢竟流程是靠人來運轉,而人員是否能夠完全遵照流程的指導來執(zhí)行,就是管理方法的問題了。運維被稱為 People Business,就證明人員管理猶在流程管理之上。因此,運維人員素質(zhì)是一個至關重要的條件。越維人員穩(wěn)定,且大都經(jīng)歷過保密培訓,這些都是實現(xiàn)安全管理的必要條件。另外,我們在項目啟動前將與客戶簽定保密協(xié)議,確保客戶數(shù)據(jù)的安全。IT 服務規(guī)劃:此時我們對客戶的情況已經(jīng)有所了解,且

38、積累的部分維護服務數(shù)據(jù),如果進行了業(yè)務系統(tǒng)維護,更應該對客戶的業(yè)務流程有了一定了解,此時可以針對客戶目前使用的信息系統(tǒng)或設備提出服務規(guī)劃,包括如何建立與推廣運維服務系統(tǒng)平臺,如何與多方監(jiān)控軟件整合形成集中管理,如何將運維部門由產(chǎn)出部門轉換為產(chǎn)入部門等。規(guī)模管理:客戶除本部外,還設有系列分部,分布地理位置比較接近,在第一期項目中即可以組成 2 級服務結構,使用集中式服務臺(Service Desk)統(tǒng)一報障以及任務分發(fā),這在資源的充分利用上有很大意義。如越維的某客戶單位正在策劃將越維設立在總部的統(tǒng)一故障受理平臺(Service Desk)服務范圍擴充到涵蓋全市范圍內(nèi)全市各區(qū)分局及所轄下屬單位的集

39、中式運維服務管理平臺。同樣,規(guī)模的擴充將不限于服務臺,整體的運維服務也可以在全市服務環(huán)境的建立基礎上發(fā)揮其集中管理覆蓋面廣的特色??捎眯怨芾恚和ㄟ^對客戶系統(tǒng)環(huán)境的了解與熟悉,以及在磨合階段的系統(tǒng)改良,我們此時充分根據(jù)客戶實際需求,做出符合客戶成本,盡可能高的可用性管理承諾??捎眯怨芾淼哪繕耸呛侠碚{(diào)配有限的資源,采用應急預案等手段保障核心系統(tǒng)的正常運行,可用性承諾是服務方對客戶方系統(tǒng)情況的熟悉度結合自身技術承載能力所做出的質(zhì)量保證。目前,越維對某客戶做出的系統(tǒng)可用性承諾高達 98%。服務級別管理:同可用性管理,服務級別管理的目標是保證服務的提供按照服務級別協(xié)議(SLA)約定執(zhí)行,如 2 小時響應

40、 4 小時解決。通常在項目初始階段會有一個初始服務級別(SLA)這是對服務商自身技術承載能力,服務初始資源安排以及客戶基本需求的約定,不可能完全符合客戶實際情況,那么在第二階段,已有充分的時間分析客戶實際需求,審視自身技術承載能力,兩者相結合做出真正符合客戶實際的服務級別承諾,并由服務級別調(diào)配相關資源。如越維與某客戶的一期項目服務級別為所有故障 2 小時響應 4 小時解決,而在二期的 2005 年 7 至 9 月中,越維的平均故障恢復時間,僅為 18 分鐘!成本管理:前面提到了很多“資源”的調(diào)配問題,隨著對客戶系統(tǒng)環(huán)境的熟悉,我們能夠分析出客戶更為實際的需求。如核心業(yè)務不能發(fā)生故障,而某臺不常

41、被使用的普通終端也許兩天內(nèi)修復也不會影響工作,因此不需要提供過多的資源進行緊急維護,成本管理的目標是在客戶能夠接受的預算內(nèi)盡可能高的提高系統(tǒng)可用性。運維不是多做突發(fā)事件處理,而是降低突發(fā)事件的發(fā)生率,因此善用工具,減少緊急事件,也能夠有效控制成本;做好規(guī)模管理,有效合理使用整體資源,更是控制成本的好方案。綜上,成本管理的意義,就在于資源的合理,充分使用。2.3.3 第三階段:戰(zhàn)略規(guī)劃階段第三階段:戰(zhàn)略規(guī)劃階段 第三階段,客戶已經(jīng)與服務商緊密結合為戰(zhàn)略合作伙伴關系,能夠為客戶制定 IT 戰(zhàn)略規(guī)劃,能夠對客戶業(yè)務投資建設的信息系統(tǒng)使用所創(chuàng)造的業(yè)務價值予以計算與評估,并能夠協(xié)助業(yè)務部門對最終客戶予以

42、管理。2.4 運維服務質(zhì)量管理運維服務質(zhì)量管理與 “產(chǎn)品”不同,“服務”的提供貫穿于和客戶的互動中。 只有當服務被提供時,才能體現(xiàn)其存在和價值。 服務的質(zhì)量取決于服務提供者與其客戶間互動過程中某些協(xié)議的實現(xiàn)程度。 客戶如何感知服務的優(yōu)劣, 服務提供者如何考慮所提供的服務,兩者都很大程度上取決于他們的經(jīng)驗和期望。提供服務的流程是生產(chǎn)和使用的一種組合方式,通過流程使服務提供者和客戶同時參與服務的過程??蛻魧Ψ盏母兄饕獊碜杂诜展倪^程。客戶通常用以下問題評價服務的質(zhì)量:所提供的服務是否達到期望?(質(zhì)量可衡量性)能否在多次服務中得到同樣的質(zhì)量?(質(zhì)量穩(wěn)定性)服務所需成本是否合理?(質(zhì)量與成本)

43、服務是否達到客戶期望主要取決于客戶在多大程度上贊同所交付的服務內(nèi)容, 而不是服務提供者提供了多“好”的服務。 因此開展有效的和持續(xù)的客戶對話機制極為重要。服務質(zhì)量取決于服務完成客戶需求和期望的程度。為了能夠提供所需的質(zhì)量, 服務提供者應該持續(xù)評估服務經(jīng)驗, 了解客戶對未來的期望。不同客戶考慮的內(nèi)容和方式都不盡相同。因此優(yōu)質(zhì)服務都是為客“戶量身定做”的,這也是服務區(qū)別于產(chǎn)品的主要特點。ISO-8402 對質(zhì)量的定義是:“質(zhì)量是一個產(chǎn)品或服務就其具有的能力滿足確定的或暗示的需求的總體特性?!辟|(zhì)量“高”往往意味著產(chǎn)品或服務在某種程度上超過了客戶的期望。在質(zhì)量得以保證的同時,成本也是客戶同時考慮的因素

44、。或者說在就其對服務的期望達成協(xié)議之后緊接著的步驟就是對成本達成協(xié)議。服務成本必須是合理的 - 對于服務提供者來說體現(xiàn)其實施成本與合理利潤,對于客戶來說是建立在對服務市場的合理理解與選擇之上??蛻魧Ψ召|(zhì)量評估的另一重要依據(jù)是服務的一貫性。如果服務提供者偶然能夠提供超出客戶期望的服務, 但在其它時間卻常常讓客戶失望, 則顯然不能稱之為質(zhì)量合格者。 “持續(xù)的質(zhì)量”是最為重要的, 也常常是服務業(yè)最難以實現(xiàn)的目標。服務(或產(chǎn)品)的提供是通過交付行為實現(xiàn)的。 而其質(zhì)量很大程度上取決于組織這些行為的方式。 Deming 質(zhì)量輪提供了一個簡單有效的質(zhì)量控制模型:這一模型假設要實現(xiàn)有效的質(zhì)量控制, 必須重復

45、履行以下步驟:計劃(Plan): 應該做什么?什么時候做?誰去做?如何做?借助什么去做?執(zhí)行(Do): 實施計劃的行為。檢查(Check): 確定執(zhí)行行為是否提供了預期的結果。效果(Act): 基于檢查得到的信息修正計劃。有效和適時地推動此輪旋轉, 意味著服務行為被按照各自的計劃和檢查機制分為各子流程。 必須清楚誰在組織中負有責任, 他們被授權修改哪些計劃和程序, 不僅為某一個行為, 而且為每一個流程。質(zhì)量管理(Quality Management)是在提供服務的組織中工作的每一個人的責任。 每一個員工必須明白他對組織作出的成果如何影響工作質(zhì)量, 影響其他同事作出的工作質(zhì)量, 并且最終如何影響

46、整個組織提供的服務質(zhì)量。 質(zhì)量管理同時意味著持續(xù)地尋找改進組織的機會,實施能夠改進質(zhì)量的行為。質(zhì)量保證(Quality Assurance)是組織內(nèi)部的重要政策,用來保證質(zhì)量管理的實施。 它集中體現(xiàn)了一整套質(zhì)量衡量標準和履行程序,保證組織能夠提供持久滿足客戶期望及相關協(xié)議的服務。質(zhì)量保證確保質(zhì)量管理所實施的成果處于可維護的狀態(tài)。綜上所述,本次越秀工商運維項目的服務質(zhì)量管理,圍繞質(zhì)量系統(tǒng)的服務流程是保證服務質(zhì)量持久延續(xù)的有效方法。2.5 建立運維管理規(guī)范建立運維管理規(guī)范2.5.1 運維管理規(guī)范概要運維管理規(guī)范概要我門與 XX 企業(yè)共同學習 ITIL、ITSM、BS15000、ISO20000 與

47、ISO9000 等國內(nèi)外先進標準,運維管理規(guī)范采用 ISO9000 模式編寫,涵蓋服務管理體系、服務級別管理、服務臺管理流程、突發(fā)事件管理、問題管理、變更管理、發(fā)布管理、配置管理等方面,如下圖所示:如上圖所示,是一個金字塔結構。處于最高層的,是客戶滿意度指引,一切服務均以“保證客戶最大滿意度”為前提展開。與之同級的還有服務管理體系文件與總體文件,用以與服務管理體系相結合,并且維持服務管理規(guī)范的改良性原則。處于中層的,是 ITIL 核心的 11 個標準流程,均根據(jù) XX 企業(yè)實際情況進行了修訂和優(yōu)化,以確保在 XX 企業(yè)實際工作中能夠得到實際應用,運維管理規(guī)范是各種操作指南與巡檢制度,包括日常管

48、理制度等,確保提供給客戶的服務,是統(tǒng)一形象的規(guī)范化標準服務。巡檢制度的建立,為 XX 企業(yè)信息系統(tǒng)“提高系統(tǒng)可用性、提高系統(tǒng)健壯性、提高各級人員技能素質(zhì)”的“三提高”目標奠定了堅實的基礎。第第 3 章章 信息系統(tǒng)運行保障方案信息系統(tǒng)運行保障方案 3.1 統(tǒng)一服務臺統(tǒng)一服務臺建設建設提供統(tǒng)一報障電話,統(tǒng)一報障、統(tǒng)一維修接口,XX 企業(yè)可以通過統(tǒng)一的報障電話申請服務、查詢服務處理進程,跟蹤處理進度,確保服務時效、控服務質(zhì)量、調(diào)查用戶滿意度。這個統(tǒng)一的服務接口,在國際上有個標準的稱呼:服務臺(Service Desk) 。我們將為 XX 企業(yè)建立統(tǒng)一服務臺,提供優(yōu)質(zhì)、專業(yè)的報障受理、跟進服務;服務臺

49、總體架構如下:服務臺(服務臺)在服務支持中扮演著一個極其重要的角色。完整意義上的服務臺可以理解為其他 IT 部門和服務流程的“前臺” ,它可以在不需要聯(lián)系特定技術人員的情況下處理大量的客戶請求。對用戶而言,服務臺是他們與 IT 部門的唯一連接點,確保他們找到幫助其解決問題和請求的相關人員。服務臺不僅負責處理事故、問題和客戶的詢問,同時還為其它活動和流程提供接口。這些活動和流程包括客戶變更請求、維護合同、服務級別管理、配置管理、可用性管理和持續(xù)性管理等,服務臺還負責事件快速響應,使用已知問題、已知事件知識庫對終端用戶的突發(fā)事件予以快速恢復或規(guī)避事故發(fā)生。3.2 建立文檔管理制度建立文檔管理制度文

50、檔管理的目標是通過對運維服務過程中使用的文檔進行統(tǒng)一管理,達到充分利用文檔提升服務質(zhì)量的目的,確保運維資源符合運維服務的要求。文檔資源包括運維體系文檔、項目(軟硬件)文檔資料、服務質(zhì)量管理文檔以及服務報告文檔等。雙方的職責為:XX 企業(yè):負責批準運維文檔的更改、刪除和發(fā)布。XX 企業(yè)運維部組織編寫及更改運維文檔;批準文檔的借閱申請。運維服務商負責更新文件目錄清單;負責保管文檔資料;負責備份文檔資料;檢查各類在用文件的有效性,防止使用無效版本;負責定期提交服務質(zhì)量管理文檔以及服務報告文檔等。文檔資源管理流程圖文檔資源管理流程圖運維文檔是否需要更改?結束圖4-4 文檔資源管理流程圖是否是否需要刪除

51、?是否運維部組織編寫是否通過信息中心審批?運維文檔發(fā)布,更新文件目錄清單文件更改提出人填寫文件更改申請單是否通過運維部、信息中心審批?是否運維部組織人員進行文檔更改,記錄更改過程和結果是否通過運維部、信息中心審批?更新文件目錄清單是否相關人員填寫報廢申請單是否通過運維部、信息中心審批?是否在文件目錄清單向將該文檔刪除項目文檔【配置管理】流程中對項目文檔的配置項進行登記更新文件目錄清單其他文件資料登記文件登記表更新文件目錄清單是否通過運維部審批?是否借閱文檔?是否填寫文件借閱申請單是否通過運維部審批?是否借閱文檔,并按期歸還是否是否需要備份?是否運維服務商對文檔資料進行備份,填寫文件備份記錄運維

52、服務商不定期全面檢查各類在用文件的有效性,防止使用無效版本文檔資源管理文檔資源管理的工作程序的工作程序文檔資源管理包括對以下五類文檔進行管理:運維文檔:指運維體系文檔,包括運維手冊、程序文件、相關支持文件及表單格式等。項目文檔:指交付運維的軟硬件系統(tǒng)相關的文檔。質(zhì)量管理文檔服務報告文檔其他文件資料:指文件、傳真、外來資料等。A A、運維文檔編碼規(guī)則、運維文檔編碼規(guī)則文檔分級文檔編號規(guī)則說 明示 例一級文件(總體)A+兩位一級文件序列號 兩位一級文件序列號從 01起順序遞增A01:術語表A02:總綱二級文件(程序文件)B+兩位二級文件序列號 兩位二級文件序列號從 01起順序遞增B01:服務級別管

53、理程序文件B02:服務臺管理程序文件三級文件(支持性文件)C+二級文件序列號+兩位三級文件序列號三級文件均從某個二級文件產(chǎn)生,此處的二級文件序列號是指與本文件對應的二級文件序列號;兩位三級文件序列號從 01 起遞增C0101:服務等級規(guī)劃C0102:服務目錄四級文件(表單)D+二級文件序列號+兩位四級文件序列號四級文件均從某個二級文件產(chǎn)生,此處的二級文件序列號是指與本文件對應的二級文件序列號;兩位四級文件序列號從 01 起遞增D0201:運維工作單D0302:工單跟蹤記錄無關聯(lián)記錄四級文件編號-日期+兩位序列號四級文件編號指該記錄對應的四級文件的編號;日期按“yyyy+mm+dd”格式編寫;兩

54、位序列號從 01 起遞增D0201-2005031401:運維工作單記錄記錄編號關聯(lián)記錄四級文件編號-關聯(lián)記錄編號四級文件編號指該記錄對于的四級文件的編號;關聯(lián)記錄編號指與本記錄的產(chǎn)生相關聯(lián)的記錄的編號D0302-D0201-2005031401:工單跟蹤記錄B B、運維文檔的更改、刪除、運維文檔的更改、刪除運維文檔由運維部負責組織編寫,經(jīng) XX 企業(yè)信息主管部門批準后頒布執(zhí)行。所有運維文檔經(jīng)批準后,由運維服務商統(tǒng)一歸入文件目錄清單中。文件目錄清單的內(nèi)容包括文檔類型、文檔名稱、編號、版本號、發(fā)布時間、內(nèi)容說明、保管位置、保存期限等。運維文檔需要更改時,由文件更改提出人填寫文件更改申請單 ,說明

55、更改原因和更改內(nèi)容。經(jīng)運維部、信息中心批準后,由運維部組織人員進行文檔的更改,并記錄更改過程、更改內(nèi)容、更改結果等。更改結果經(jīng)運維部、信息中心確認后由運維服務商更新文件目錄清單 。若需刪除運維文檔,則需由相關人員填寫報廢申請單 ,說明刪除內(nèi)容、刪除原因等,經(jīng)運維部、信息中心批準后由運維服務商在文件目錄清單中將該文檔刪除。C C、質(zhì)量管理文檔的應用、質(zhì)量管理文檔的應用服務質(zhì)量管理文檔主要分為服務回訪文檔、服務滿意度調(diào)查文檔、服務投訴處理文檔三類。三種文檔均為保障與提高客戶滿意度為目標所制訂的客戶滿意度指引中的部分,屬于運行服務管理體系最高層指導文件,以確?!皬姆盏慕嵌瘸霭l(fā)”為客戶提供五星級的運

56、行服務。根據(jù) ITIL 標準與規(guī)范的要求,所有的事件均由服務臺受理,服務工程師處理完畢后,由服務臺完成回訪并關閉事件流程,因此回訪動作將直接獲得客戶對當次服務的評價,并由客戶的評價獲得服務質(zhì)量改良的依據(jù)。在 ISO20000 戴明環(huán)的指引下,服務團隊質(zhì)量管理小組將分析運行服務過程中成功回訪的客戶對當次服務的直接評價,并收集盡可能完整的評價信息,通過每周的部門例會對客戶的評價進行匯總分析,并提出可能的原因和可能的改進辦法,回訪與總結例會記錄樣本如下:3.3 一般信息化設備及相關軟件運一般信息化設備及相關軟件運維管理維管理3.3.1 一般信息化設備服務范圍一般信息化設備服務范圍本次項目的服務范圍包

57、括 XX 企業(yè)辦公區(qū)域內(nèi)的臺式機、打印機以及客戶端所有常用的辦公軟件(包括操作系統(tǒng)軟件、系統(tǒng)應用軟件、系統(tǒng)管理軟件、辦公軟件、工具軟件等)。3.3.2 一般信息化設備運維一般信息化設備運維1、 根據(jù)實際需要,經(jīng) XX 企業(yè)同意準備相應數(shù)量的維護零配件,協(xié)助XX 企業(yè)進行備件庫的管理,并在零配件不足時及時補倉。2、定期對計算機設備進行保養(yǎng)維護,定期進行用戶滿意度調(diào)查;對一般信息化設備硬件進行定期巡檢、保養(yǎng),以保障設備運行正常;按照越秀工商要求進行硬件設備普查工作,建設可實現(xiàn)動態(tài)維護的硬件設備檔案庫,并實現(xiàn)與 XXX 企業(yè)的資產(chǎn)管理系統(tǒng)的銜接。定期對公用信息化設備消毒除塵;檢查硬件實際配置與設備登

58、記表是否相符。3、對故障設備的維修在響應時間內(nèi)完成故障設備的維修,維修人員應嚴格遵守維修規(guī)程。建立硬件應急維修小組,對關鍵重點崗位及緊急的故障及時響應并及時匯報,對于故障設備的維修由越秀工商指定的具體技術人員組織監(jiān)督進行;對處于保修期內(nèi)的故障設備,供應商在廣州市工商局越秀分局授權的范圍內(nèi)代表越秀工商協(xié)調(diào)產(chǎn)品供貨商予以維修,并監(jiān)督維修時效和質(zhì)量;對處于保修期外的故障設備維修,如需更換零配件,可由供應商提供多家的報價,經(jīng)用戶選擇審核確認后,方可進行更換;3.3.3 例行維護流程圖例行維護流程圖運維服務商每月進行一次巡檢運維工程師制定巡檢工作計劃,說明采巡檢時間安排、巡檢內(nèi)容、巡檢地點、資源配合等是

59、否通過服務主管、運維部、信息中心審批?運維工程師在完成巡檢工作后,對巡檢結果進行評估,并提出意見和建議,形成巡檢報告結束運維工程師按照巡檢工作計劃執(zhí)行巡檢工作,并將巡檢過程和結果記錄在巡檢記錄表中是否圖4-3 例行維護流程圖是否通過服務主管、運維部、信息中心審批?巡檢過程中是否發(fā)現(xiàn)問題?巡檢過程是否有不符合的配置項?轉【問題管理】流程中系統(tǒng)存在問題流程處理轉【配置管理】流程處理是否是否是否3.3.4 一般設備服務方案一般設備服務方案3.3.4.1信息化設備資產(chǎn)調(diào)查及管理信息化設備資產(chǎn)調(diào)查及管理資產(chǎn)標簽應含有上圖所注所有信息,包括資產(chǎn)名稱、合同采購號、產(chǎn)品序列號、保修期限、IP 地址、系統(tǒng)序列號

60、以及供應商、聯(lián)系人名稱、電話,使用條形編碼統(tǒng)一進行資產(chǎn)記錄。條形碼記錄號應與數(shù)據(jù)庫中記錄對應,關聯(lián)使用人、資產(chǎn)配件(如顯示器、鍵盤、鼠標、打印機、音箱等型號信息),所有資產(chǎn)應落實到具體責任人,共用設備按照編碼順序先后指定責任人。設備封條統(tǒng)一為純白色易碎貼,使用設備封條將有效的保障客戶設備的完整性,明確區(qū)分設備保管的責任性。服務工程師上門服務時一旦發(fā)現(xiàn)設備封條破損,將現(xiàn)場進行設備現(xiàn)狀與資產(chǎn)清單的對比,避免出現(xiàn)保管責任不清的狀況發(fā)生。3.3.4.2一般設備軟件安裝及維護一般設備軟件安裝及維護此部分主要解決在用戶使用當中遇到的軟件各種問題,在進行軟件維護時應做好用戶數(shù)據(jù)的備份,建立軟件維護流程,通過現(xiàn)場解決及用戶培訓的多種方式提

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預覽,若沒有圖紙預覽就沒有圖紙。
  • 4. 未經(jīng)權益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負責。
  • 6. 下載文件中如有侵權或不適當內(nèi)容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論