年4月19日運維服務部門管理流程文檔僅供參考，不當之處，請聯(lián)系改正。運維服務部管理流程說明目錄TOC\o"1-4"\h\z1 引言 41.1 編寫目的 41.2 編寫說明 42 維護理念 42.1 維護宗旨 42.2 維護范圍 42.3 響應服務速度 53 維護保證 53.1 提供統(tǒng)一接口 53.2 提供標準化的服務質(zhì)量 53.3 服務支持手段 64 維護類型 64.1 主動式服務 64.1.1 維護質(zhì)量審計 64.1.2 客戶滿意度調(diào)查 64.2 被動式服務 74.2.1 電話及郵件應答服務 74.2.2 遠端服務 74.2.3 現(xiàn)場服務 74.3 人性化服務 75 維護制度 85.1 值班制和專人維護制 85.2 服務監(jiān)督機制 85.3 客戶回訪制度 85.4 故障定義及報告制度 85.4.1.1 故障級別 85.4.1.2 支持響應時間 95.5 節(jié)假日服務保障制度 96 維護管理流程 106.1 運維組周例會 106.1.1 說明 106.1.2 提交文檔 106.2 運維人員周報 106.2.1 說明 106.2.2 提交文檔 106.3 規(guī)范使用 116.4 維護審計 116.4.1 維護過程審計 116.4.2 軟件管理審計 126.4.3 硬件管理審計 126.4.4 文檔審計 127 客服流程 137.1 定期類維護 147.1.1 每日 147.1.1.1 工作內(nèi)容 147.1.1.2 提交文檔 157.1.2 每周 157.1.2.1 工作內(nèi)容 157.1.2.2 提交文檔 167.1.3 每月 177.1.3.1 工作內(nèi)容 177.1.3.2 提交文檔 187.1.3.3 注意事項 187.2 不定期類維護 187.2.1 需求變更 197.2.1.1 工作流程 197.2.1.2 提交文檔 207.2.2 割接上線 227.2.2.1 工作流程 227.2.2.2 提交文檔 247.2.3 程序優(yōu)化 247.2.3.1 工作流程 257.2.3.2 提交文檔 257.3 故障類維護 267.3.1 故障處理流程 267.3.1.1 工作流程 277.3.1.2 提交文檔 297.3.1.3 故障響應 297.3.2 HA切換流程 297.3.2.1 工作流程 307.3.2.2 提交文檔 308 維護性能指標 308.1 系統(tǒng)主機部分 308.2 應用系統(tǒng)部分 31引言編寫目的本文檔將指導各地運維組有效、高質(zhì)的實施服務。包括：維護理念、維護類型、維護制度等。在維護工作未開展之前，需各個運維主管認真閱讀本文檔，并對運維人員進行必要的培訓，使運維人員熟悉維護的流程及相關制度。在維護過程中，運維主管要嚴格按照此文檔的流程組織維護工作，以提高、增強維護質(zhì)量。 在項目維護過程中，運維主管或運維人員若發(fā)現(xiàn)流程有缺陷或需要補充的，請及時反饋至公司，確保流程能夠及時得到更新，以達到規(guī)范性、可操作性。編寫說明本文檔的閱讀對象包括：公司領導運維主管項目組運維人員維護理念維護宗旨與客戶緊密配合，盡公司所能，為客戶提供快捷、優(yōu)質(zhì)的服務，讓客戶省心，讓客戶放心。維護范圍為客戶提供熱線、現(xiàn)場服務及業(yè)務覆蓋范圍內(nèi)的服務實施。響應服務速度在用戶工作期間提供服務電話或郵件、現(xiàn)場支持，在系統(tǒng)出現(xiàn)嚴重故障時提供24小時支持。維護保證提供統(tǒng)一接口駐點維護作為公司服務的對外窗口，為客戶提供服務，確保所有客戶在工作期間，在任何時候、任何地方、出于任何原因，都能夠方便地與維護項目組進行聯(lián)系，獲得滿意的服務。提供標準化的服務質(zhì)量客戶的每次要求，都將在《維護記錄庫》建立，并一直被監(jiān)控，直到問題得到圓滿的解決?？蛻舨恍枰貜屯粋€問題，也不用擔心自己的問題有如石沉大海。每一類問題的處理將建立標準的時限要求，如果超出規(guī)定時限，公司會對相關人員做出處理。公司會對維護項目組整個維護工作進行監(jiān)控和定期考核。服務支持手段維護類型主動式服務維護質(zhì)量審計建議公司額外組建QA組，定期開展質(zhì)量審計工作，對在用系統(tǒng)進行全面檢查并現(xiàn)場分析問題，發(fā)現(xiàn)問題及其隱患，及時予以解決?？蛻魸M意度調(diào)查經(jīng)過電話、信函、現(xiàn)場、傳真、e-mail等方式向客戶發(fā)放調(diào)查問卷，了解客戶對公司所開發(fā)系統(tǒng)的技術支持情況、系統(tǒng)運行情況等各方面的滿意度評價，并對調(diào)查結果進行統(tǒng)計分析，對于存在的問題及時尋求處理解決辦法，以逐步提高客戶滿意度。被動式服務電話及郵件應答服務當客戶出現(xiàn)問題或故障后需要尋求幫助,首先能夠經(jīng)過電話或郵件請求支持幫助和指導，及時解決問題或排除故障。遠端服務當客戶應答服務無法排除故障時，在最終客戶授權的前提下，可根據(jù)客戶方提供的問題現(xiàn)象和故障描述，經(jīng)過接入客戶在用系統(tǒng)來指導客戶方技術人員或直接處理系統(tǒng)故障。在登錄訪問系統(tǒng)前，客戶需給出必要的口令?，F(xiàn)場服務在維護工作中，電話應答服務及遠端服務是解決問題、處理故障的第一步，因為在時效上電話應答及遠程服務將明顯高于現(xiàn)場服務。但當電話應答服務及遠程服務無法解決客戶提出的服務請求時，我們將指定運維人員在盡可能短的時間內(nèi)在現(xiàn)場進行服務，以求問題的最終解決。人性化服務每個人都喜歡與眾不同的東西，這是人的本性。人性化服務就是要尊重以人為本的服務理念，尊重客戶個性，尊重客戶的習慣，尊重客戶的喜好。人性化服務就是要求提供的服務能被客戶所接受和喜愛，超出客戶的期望值。當與無法滿足客戶的期望值時，需要進行分析原因并采取糾正措施，給客戶一個滿意的回復。維護制度值班制和專人維護制運維組人員將設立值班表，每日值班人員將負責系統(tǒng)的日常檢查及日常維護。運維人員在接到客戶服務請求或問題投訴，無論是否屬于自己工作職責范圍，都會做出反應，并將問題詳細記錄下來，及時解決，爭取不讓客戶打第二次電話。服務監(jiān)督機制為保證各維護項目組的維護質(zhì)量，對此工作設定關鍵績效指標，每月進行考核，集中進行獎優(yōu)罰劣，確保維護流程得到有效地執(zhí)行，從而提高維護質(zhì)量。客戶回訪制度經(jīng)過雙方建立起良好的關系，增進與客戶之間的溝通交流，收集、整理完整準確的客戶資料信息，建立起客戶檔案庫，是開展客戶關系管理的重要前提，以逐步形成一套完整的客戶信息平臺。

確定客戶類型，并針對不同類型的客戶，制定相應的回訪頻次及回訪方式。經(jīng)過電話、現(xiàn)場等方式回訪客戶，收集在用系統(tǒng)的問題及需求，了解客戶對我公司維護工作的意見和建議，以逐步改進我們的軟件質(zhì)量和維護水平。故障定義及報告制度根據(jù)系統(tǒng)維護經(jīng)驗，對系統(tǒng)故障做了明確的故障級別定義并確定相應的故障確診時限，并采取上報制度，保證給予客戶最有效的解決方案。故障級別根據(jù)故障性質(zhì)的嚴重性及對客戶造成的影響程度，把故障分為三級：一級故障

指非常嚴重的故障，如系統(tǒng)崩潰，主機癱瘓等，對最終客戶有直接影響，系統(tǒng)已不能正常工作。

二級故障

指次嚴重的故障，如系統(tǒng)設備不穩(wěn)定，但在客戶的合理使用下能夠正常工作；又如系統(tǒng)部分性能存在問題，但不影響系統(tǒng)主要功能操作；以及系統(tǒng)運行效率極低訪問速度非常慢等情況。

三級故障

除以上故障以外的所有故障。包括如：由于某種原因?qū)е聭贸绦蚧蛴布O備損壞，系統(tǒng)部分功能不能使用，等暫時不影響系統(tǒng)正常運行的情況。支持響應時間針對故障的不同級別，響應方式及時間也做進一步的明確：

一級故障：

在運維組無法解決故障時，公司立即召開技術協(xié)調(diào)會分析故障原因，如確認遠程不能解決故障，立即派工程師以最快的速度，不超過24小時趕到客戶現(xiàn)場解決故障。

二級故障：

在運維組無法解決故障時，公司立即召開技術協(xié)調(diào)會分析故障原因，采取以下三種措施解決故障：

1、經(jīng)過電話指導運維組自己解決故障。

2、公司技術小組遠程解決故障。

3、工程師到客戶現(xiàn)場解決故障。

三級故障：

經(jīng)過電話指導運維組自己解決。如客戶解決不了的，必須提交書面報告由我方派技術人員到用戶現(xiàn)場解決。具體故障上報制度可另出規(guī)則。節(jié)假日服務保障制度節(jié)假日主要是指國家法定假日，包括元旦、春節(jié)、五一、國慶。在節(jié)假日期間，系統(tǒng)運行過程中出現(xiàn)問題時能夠及時得到技術人員的支持，使在用系統(tǒng)得以正常運行，為客戶提供放心周到的服務。維護管理流程運維組周例會說明運維主管組織項目組運維人員在每周一下午14:00召開周例會，討論處理上周遺留問題及本周需要解決的問題。提交文檔序號文檔名稱命名規(guī)則文檔說明提交時間/接受人1會議紀要項目名稱_會議紀要_年月日每次項目組的會議記錄，包括：周例會、小組討論會每周一下班前/公司維護經(jīng)理運維人員周報說明項目運維人員應于每周日晚提交項目TimeSheet給運維主管，總結本周工作。運維主管也應于每周日晚提交項目TimeSheet給維護經(jīng)理，總結本周維護組工作情況。提交文檔序號文檔名稱文檔說明1問題日志提交至運維部門經(jīng)理，記錄本周存在問題2工時記錄提交至運維部門經(jīng)理，記錄本周工作情況規(guī)范使用文檔規(guī)范所有文檔都遵循模板，文檔中非標題部分全部采用正文格式。會議紀要每次運維組的討論，需要指定人員進行會議記錄，一般在例會后分發(fā)給相關人員，最晚不要超過當天。備份項目涉及的代碼程序、文檔、會議紀要等資料需要由各運維主管統(tǒng)一保管。維護審計為幫助各運維組在維護工作上能夠提高工作質(zhì)量，將由QA人員不定期對各運維組進行檢查及審計。維護過程審計運維組審計維護組的大小是否適應系統(tǒng)的規(guī)模和要求。維護組中人員的職責分工是否明確。維護組是否有一套科學的內(nèi)部管理機制和協(xié)調(diào)工作機制。系統(tǒng)總體審計維護過程是否按維護規(guī)范進行。運維人員的交替是否按照維護規(guī)范進行。是否能把握住系統(tǒng)運行狀況達到性能管理及資源的有效利用。是否記錄事故及故障內(nèi)容，并向用戶負責人及公司維護經(jīng)理報告。是否找出事故及故障的原因，并采取措施防止再次發(fā)生。軟件管理審計系統(tǒng)需求變更審計有關系統(tǒng)的任意修改，是否按維護規(guī)范進行修改。系統(tǒng)的修改是否按割接計劃進行，是否在得到用戶負責人的同意后實施。在需求修改前是否對修改內(nèi)容與影響范圍進行了調(diào)查與分析，明確了解需求變更后將造成的影響。割接上線審計修改程序的測試是否按測試計劃進行。修改的程序是否進行了與新開發(fā)的程序同等程度的測試。修改程序的測試是否由用戶參加。修改程序的測試結果是否得到開發(fā)、運行、維護及用戶負責人的認可。修改的程序的測試結果是否記錄下來，并進行保管。割接前是否向用戶提交割接計劃，割接后是否向用戶反饋割接報告。割接上線后系統(tǒng)的運行審計是否對修改前的程序及數(shù)據(jù)做好了備份。運行負責人是否驗證其系統(tǒng)不受影響。運行中若出現(xiàn)問題是否及時恢復到修改前程序，是否對數(shù)據(jù)進行備份。硬件管理審計是否有硬件的故障對策。是否對硬件的利用狀況進行記錄，并定期進行分析。文檔審計文檔編制的審計要點是否遵守文檔編制規(guī)范。文檔的種類、目的、制作方法等是否明確。文檔管理的審計要點是否制定和遵守文檔管理規(guī)則。文檔更新是否得到相關人員認可。在系統(tǒng)需求更新時，文檔內(nèi)容是否進行更新，并留下更新記錄。文檔的拷貝及廢除是否有對不正當行為的防范及機密保護的對策?？头鞒虨榱吮Ｕ舷到y(tǒng)的正常、可靠運行，必須有一整套客服流程來保障系統(tǒng)維護的操作。根據(jù)維護操作對于系統(tǒng)的影響，我將客戶服務分為三類：第一類是定期維護，其主要操作是監(jiān)測系統(tǒng)的運行狀況、對客戶的支持等，但不影響和干涉系統(tǒng)的正常運行，只執(zhí)行“讀”操作；第二類是不定期維護，其主要操作是系統(tǒng)有新的需求需要修改并割接到正式系統(tǒng)中，或因用戶量、文檔量增多時對程序的優(yōu)化。屬于“寫”操作。由于該操作將影響系統(tǒng)的運行，需要謹慎對待；第三類是故障類處理，對系統(tǒng)出現(xiàn)的故障及時予以排除。流程圖如下：圖表SEQ圖表\*ARABIC1軟件維護流程定期類維護定期類維護按以下階段進行分類：每日、每周、每月。下面的文檔提到的日報，周報，月報模板我可根據(jù)運維具體內(nèi)天制定圖表2定期類維護每日工作內(nèi)容系統(tǒng)及應用的每日檢查每天的值班人員早晨到達辦公室后，首先要做所有系統(tǒng)的日常檢查。日常檢查包括：硬件檢查及軟件檢查。硬件方面主要是檢查系統(tǒng)各項指標是否正常，軟件方面主要是檢查系統(tǒng)是否能夠正常登陸，相關模塊是否能夠正常進入。并填寫《系統(tǒng)日報》?？蛻糁С纸勇犽娫?、郵件支持或現(xiàn)場解決用戶提出的問題，主要工作有：當用戶發(fā)生變化時，及時調(diào)整系統(tǒng)內(nèi)部參數(shù)設置，保障系統(tǒng)數(shù)據(jù)的即時性；當客戶流程發(fā)生變化時，及時調(diào)整配置文件，保證系統(tǒng)正確流轉。協(xié)助用戶解決在使用當中遇到的問題；發(fā)生災難性事故時，迅速完成系統(tǒng)的恢復；數(shù)據(jù)的備份及恢復；維護記錄客戶問題解決后將所解決的問題及時記入《維護記錄庫》中。提交文檔序號文檔名稱命名規(guī)則文檔說明提交時間/接受人1系統(tǒng)日報項目名稱_系統(tǒng)日報系統(tǒng)每日運行情況每天下班前/維護主管維護主管每周合周報一并提交每周工作內(nèi)容系統(tǒng)全面檢查在本周結束時，要對系統(tǒng)做階段檢查。并填寫《系統(tǒng)周報》。檢查包括：1、系統(tǒng)使用情況CPU和Memo的平均空閑、利用率磁盤使用系統(tǒng)備份2、應用系統(tǒng)的使用情況 *：具體的軟件系統(tǒng)具體再說，因我現(xiàn)在不了解具體各的服務內(nèi)容。新增哪些應用和需求，割接上線后使用情況存在問題及解決方案、已解決問題對于用戶要求的響應時間系統(tǒng)運行中出現(xiàn)的錯誤應立即修改；需求的變更和增加，需運維人員對其工作量進行評估后答復用戶。答復的時間不得晚于三天。*****其它，根據(jù)個地軟硬件的服務內(nèi)容定。對于應用系統(tǒng)在本周中存在的問題，修改時間有如下約定：系統(tǒng)中出現(xiàn)的簡單錯誤，由運維人員自行解決，記入《維護記錄庫》中。對于較小程度的修改在星期一、星期二、星期三晚上進行。對于較大程度的修改在周五晚上及周末進行。屬于比較重大的問題，例如系統(tǒng)宕機、系統(tǒng)發(fā)生錯誤等，由運維主管安排相關人員盡快處理。故障發(fā)生后，必須查明原因，要及時將故障處理報告上報用戶負責人及公司維護經(jīng)理。從中吸取經(jīng)驗教訓，采取有效措施防止再次發(fā)生。更換管理員ID密碼運維人員必須每周將管理員ID文件的密碼更換，以防管理員身份被她人盜用。管理員Admin口令使用記錄為防止admin的ID文件流失，被多人使用，必須在使用Admin口令后對此進行記錄。提交文檔序號文檔名稱命名規(guī)則文檔說明提交時間/接受人1系統(tǒng)周報項目名稱_系統(tǒng)周報系統(tǒng)每周運行情況每周日之前/公司維護經(jīng)理及用戶負責人2Admin口令使用記錄項目名稱_Admin口令使用記錄管理員Admin口令使用情況每月工作內(nèi)容系統(tǒng)全面檢查在每月未要對系統(tǒng)做全面檢查。并填寫《系統(tǒng)月報》。匯總當月系統(tǒng)的狀況，提前預見、發(fā)現(xiàn)可能出現(xiàn)的問題，并針對系統(tǒng)情況、問題提出合理化建議。檢查包括：1、系統(tǒng)使用情況：CPU和Memo的平均空閑、利用率磁盤使用系統(tǒng)備份2、應用系統(tǒng)使用情況：（月統(tǒng)計）電話受理客戶端的IE升級和配置人員組織調(diào)整各應用數(shù)據(jù)庫狀態(tài)存在問題及解決方案、已解決問題等，具體了解了各地服務內(nèi)容可增減統(tǒng)計維護記錄將本地的《維護記錄庫》，傳送給公司維護經(jīng)理，以便公司掌握各運維組的系統(tǒng)日常運行過程中出現(xiàn)問題的頻率及類型，從而為優(yōu)化和完善系統(tǒng)提供信息，維護經(jīng)理將提交公司研發(fā)中心加以改進，并將改進方法通知各運維主管，使系統(tǒng)越來越完善。發(fā)布公告將本月系統(tǒng)中人員調(diào)整、新增功能、問題解決辦法以公告的形式在系統(tǒng)中向用戶公布，增強客戶對系統(tǒng)的信任度。月度總結由運維人員填寫《月度工作狀況總結表》提交給運維主管，運維主管也需要填寫，最后由運維主管以項目組的方式提交給公司維護經(jīng)理。維護值班表提交用戶負責人下月維護值班表，和用戶說明每天的值班人員。提交文檔序號文檔名稱命名規(guī)則文檔說明提交時間/接受人1系統(tǒng)月報項目名稱_系統(tǒng)月報系統(tǒng)每月運行情況每月月未/公司維護經(jīng)理及用戶負責人2統(tǒng)計維護記錄項目名稱_維護記錄_月份以excel方式將本月的維護記錄進行統(tǒng)計3月度工作狀況總結表姓名_月度工作情況總結表運維人員每月工作狀況總結4維護值班表項目名稱_月份_維護值班表下月運維人員值班表記錄注意事項日常維護中如在工作時間若發(fā)現(xiàn)系統(tǒng)故障，非客戶要求下決不能進行更改。非工作時間發(fā)生故障，應立即解決。若故障影響到系統(tǒng)使用，在經(jīng)得用戶負責人同意的情況下，進行故障處理。若故障不會對系統(tǒng)使用造成大的影響，故障的解決時間為當日的非工作時間。若當日的非工作時間不能解決故障。安排在當周的休息日進行解決。如發(fā)現(xiàn)辦公系統(tǒng)的服務器進行了HA切換，則應在用戶下班后再切換回正確的服務器。決不能在用戶上班時進行切換，以防對用戶的工作造成影響。不定期類維護不定期類維護包括：需求變更流程、割接上線流程及程序優(yōu)化流程。圖表3不定期類維護需求變更工作流程需求變更過程主要是依據(jù)用戶或項目人員提出的需求變更請求與用戶進行協(xié)調(diào)，以確認需求更改的可行性、合理性、工作量和影響范圍。圖表4需求變更流程圖提交文檔序號文檔名稱命名規(guī)則文檔說明提交時間/接受人1需求變更申請單需求變更申請單此文檔由用戶提供，用戶在提出需求變更時需提供此單給運維人員1需求變更分析項目名稱_需求變更分析運維主管根據(jù)需求變更的內(nèi)容分析其對項目各個方面的影響需求變更分析后/公司維護經(jīng)理2需求變更記錄單項目名稱_需求變更記錄單記錄需求變更需求變更修改完畢/公司維護經(jīng)理割接上線工作流程圖表5割接上線流程提交文檔序號文檔名稱命名規(guī)則文檔說明提交時間/接受人1測試用例及報告項目名稱_測試用例及報告_年月日在開發(fā)服務器上的對新開發(fā)功能的測試描述新增功能測試后/用戶負責人2割接計劃項目名稱_割接計劃_年月日在生產(chǎn)系統(tǒng)上進行割接工作之前制定的割接計劃割接上線前/用戶負責人及公司維護經(jīng)理3割接申請割接申請_年月日申請在生產(chǎn)系統(tǒng)上進行割接工作割接上線前/用戶負責人4割接報告項目名稱_割接報告_年月日在生產(chǎn)系統(tǒng)上割接成功后向用戶負責人提供的報告割接上線后/用戶負責人及公司維護經(jīng)理5《割接失敗報告》項目名稱_割接失敗報告_年月日在生產(chǎn)系統(tǒng)上割接失敗后向用戶負責人提供的報告程序優(yōu)化由于應用系統(tǒng)在使用過程中會不斷的有需求變更和需求增加，這些增加和變更的程序迫于時間壓力上線后可能會存在一些問題，為系統(tǒng)的穩(wěn)定運行造成一些隱患。因此要定期對運行的程序進行優(yōu)化，并形成相應的版本。定期檢查各個應用數(shù)據(jù)庫的大小，使用百分比。優(yōu)化首先應當在測試服務器上進行，當確定運行沒有問題后，以報告形式報用戶負責人批準，在用戶下班后在生產(chǎn)系統(tǒng)中進行割接。工作流程圖表6程序優(yōu)化流程提交文檔序號文檔名稱命名規(guī)則文檔說明提交時間/接受人1系統(tǒng)運行報告項目名稱_系統(tǒng)運行報告_年月日在開發(fā)服務器上的對新開發(fā)功能的測試描