運維管理制度規(guī)范V0

1、運維管理制度規(guī)范（試行）Version1.0日期2012/2/25第一章概述運維管理制度規(guī)范（試行），是針對目前數(shù)據中心現(xiàn)有體制制定的一系列運維規(guī)劃，其中包括運維項目實施、運維流程控制、第二章運維實施第一節(jié)硬件上架1,硬件上架應嚴格按照機房管理室所提供的流程進行操作，填寫機房管理室要求的相關申請文檔。2 .硬件上架后，要檢查設備標簽、網絡標簽、電源標簽是否完整。3 .硬件上架后，要檢查機柜內走線是否已整齊。4 .檢查電源、網絡配置能否符合和客戶簽定的SLA,如不符合走服務請求流程提交相關文檔。5 .機房管理室創(chuàng)建該項目的配置項文檔，并通知服務經理進度。6 .涉及流程：機器上架申請、配置管理、服

2、務級別管理、服務請求。7 .涉及文檔：設備上架申請、服務請求單、服務級別協(xié)議/服務合同、配置項文檔第二節(jié)網絡配置1 .網絡配置時，要求按照客戶的服務合同中承諾的要求一致，如合同中沒有明確說明以領導確認為準。2 .網絡配置后，錄入相關的配置項信息，以及變更相關聯(lián)的交換機、防火墻信息，并通知服務經理進度。3 .網絡配置后，要建立該業(yè)務系統(tǒng)的網絡拓撲圖，網絡拓撲圖屬于該項目的一個配置項。4,涉及流程：配置項管理5.涉及文檔：配置項目文檔第三節(jié)軟件實施1,軟件實施前要創(chuàng)建軟件實施調查表，詳細調查客戶的軟件環(huán)境、配置、版本等信息。2,軟件實施要按照軟件實施調查表進行實施。3,軟件實施后，如客戶沒有要求，

3、修改所有默認密碼，密碼規(guī)則同信息安全管理制度的口令、權限一章。4,軟件實施后，要錄入相關配置項目，并適當備份介質。5,軟件實施后，要建立該業(yè)務系統(tǒng)的邏輯拓撲圖，邏輯拓撲圖屬于該項目的一個配置項。6,涉及流程：配置項目管理7,涉及文檔：軟件實施調查表、配置項目文檔第四節(jié)運維手冊1 .運維項目在項目實施后，要依據服務合同書及相關SLA寫運維手冊。2 .運維手冊的內容包括：服務內容、服務范圍內滿足服務合同要求的相應的日檢、周檢、月檢、日常操作等規(guī)范，并提供輸出的服務報告模板。3 .運維手冊書寫后，要將運維手冊的名稱及位置記入配置項文檔4 .涉及流程：配置項目管理5 .涉及文檔：運維手冊、配置項文檔第

4、三章運維流程第一節(jié)服務級別管理1 .定義：服務級別協(xié)議（簡稱SLA）,與客戶之間簽訂的描述將要提供的一項或多項服務的一種協(xié)議，在協(xié)議期間作為評價和調整IT服務的標準。2 .說明：在運維期間，所有操作都圍繞著達成對客戶的服務級別協(xié)議與展開。3 .規(guī)范：a）定期檢查運維手冊是否符合SLA中簽訂的標準。b）在SLA發(fā)生變化時，更新現(xiàn)有的運維手冊以達到新的SLA中簽署的。c）定期對現(xiàn)有服務進行評價，以滿足SLA4 .涉及文檔：服務級別協(xié)議運維手冊以及所有該服務級別協(xié)議中包含的運維流程服務報告等。第二節(jié)配置管理（目前希望配置管理能在最初階段建立盡量全的配置項，減少將來反復錄入一些新配置項的過程）1 .定

5、義：配置項主要包含定義和維護IT基礎架構的物理組件、有關文檔，以及定義和維護這些組件之間的相互有關系和相關屬性。2 .說明：配置項管理主要針對配置項在物理關系上的構成、連接、需要，以及邏輯關系上的涉及、被使用，如某一主機與網絡接口之間的新建的關聯(lián)信息、如中間件與數(shù)據庫之間的使用關系發(fā)生變化，都會涉及到配置項的變化。3 .規(guī)范：a）配置項要有固定的模板，并定期審核心是否滿足現(xiàn)有業(yè)務需要。b）根據服務合同的SLA,確定該維護項目最初的配置項必添項目。c）在配置項發(fā)生變化時，必須及時更新配置項文檔。d）定期審核配置項文檔中與實際不符的信息。e）涉及文檔：配置項文檔第三節(jié)服務請求1 .定義：服務請求，

6、用戶想要獲得的支持、信息、建議或文檔等不屬于IT基礎架構方面的事件；2 .說明：當服務請求的輸出是一個預授權變更，記錄服務請求單和變更實施報告并反饋客戶變更結果；如果服務請求的輸出是一個故障，那么走故障管理流程進行處理。3 .流程圖4 .規(guī)范a）當用戶提出要求時必須添寫服務請求單。b）當用戶提出的要求不屬于IT基礎架構方面的事件，僅在服務請求單中記錄處理結果，并及時反饋給用戶。c）當服務請求為一個預授權變更時，記錄變更實施報告，并及時反饋給用戶。d）當服務請求輸出是一個故障時，走故障管理流程進行處理，服務請求單做為故障管理流程的輸入。5 .涉及文檔：服務請求單、變更實施報告第四節(jié)故障管理1 .

7、定義：故障，在某一服務中已經導致服務中斷或服務質量下降的情況。2 .說明：故障的來源可能是由某一用戶發(fā)現(xiàn)、管理員、由另一IT部門的人發(fā)現(xiàn)、由監(jiān)控軟件發(fā)現(xiàn)；故障管理的輸出可能是一個故障報告或分析后可能成為問題報告。4 .規(guī)范a）故障流程的輸入如果來自服務請求，那么故障流程的輸入為服務請求單；如果故障流程來自管理員、由另一IT部門的人發(fā)現(xiàn)、由監(jiān)控軟件發(fā)現(xiàn)那么故障流程的輸入為故障報告。b）首先對故障事件進行分析，該故障是否為問題，如為問題記入問題報告。c）首先判定處理該故障是否需要變更，如需要，進入提交變更申請單,d）如故障處理需要其它部門協(xié)助，填寫服務協(xié)助單給相關部門共同處理，最后提交故障報告給服

8、務經理或對客戶做出反饋。e）如該故障不需要其它部門協(xié)助，在故障處理后提交故障報告給服務經理或對客戶做出反饋。5 .涉及文檔：故障報告、問題報告、服務協(xié)助單第五節(jié)問題管理1 .定義：問題是一個或多個事件的未知潛在原因。問題分為已知問題和未知問題，已經問題就是已經查明事件根本原因和事件解決方法的。2 .說明：問題管理的主要目的是記錄問題并進行查明原因，提高已知問題的數(shù)量，減少對服務質量的影響，提高服務請求處理效率。一般問題管理流程的輸入都為故障管理流程流轉出的服務請求單和故障報告。3 .流程4 .規(guī)范a）每一個問題事件都必須詳細記錄該事件的相關線索，如系統(tǒng)信息、狀態(tài)，有解決辦法或變通措施的要詳細到

9、命令一級，以備錄入知識庫速查使用。b）要對一類的問題事件進行分析。c）定期審核已知錯誤及未知錯誤的數(shù)量。d）檢查未知錯誤是否都有變更變通措施。e）所有與業(yè)務系統(tǒng)本身相關的已知問題，計入運維手冊的問題庫一章。f）所有與技術相關的已知問題，計入知識庫。5.涉及文檔：服務請求單、故障報告、問題報告、知識庫第六節(jié)變更管理1 .定義：變更分為預授權變更、常規(guī)變更、緊急變更，預授權變更為服務合同中已明確的不需要客戶再次審核的變更；常規(guī)變更為操作手冊中明確寫明操作步驟及操作規(guī)范的變更和可以正常走變更審批流程的變更；緊急變更一般由故障引起而采用的為確?；謴头召|量或結束服務中斷現(xiàn)象，從而保證SLA的變更。2

10、.說明：預授權變更的入口目前一般為服務請求單及各管理員針對服務合同做的定期變更操作，如修改某個非關聯(lián)的管理帳號密碼；標準變更要嚴格走變更流程；緊急變更一般入口為故障報告，必須拿到領導審批授權才可以變更，后期保證文檔完整。3 .流程：4 .規(guī)范a）緊急變更必須拿到領導審批授權。b）預授權變更產生的文檔為變更實施報告。c）標準變更及緊急變更產生的文檔為變更請求單變更實施計劃變更實施報告變更結果跟蹤。d）如變更過程中會產生配置項的變更，必須在變更實施計劃中，變更配置項做為一項計劃工作寫明，并在后期的變更實施過程中嚴格執(zhí)行。e）要定期檢查變更相關報告的完整性。f）變更結束后，如需對變更結果進行驗證，要填寫變更結果跟蹤：說明變更對原有系統(tǒng)帶來的影響。5.涉及文檔：服務請求單、變更請求單、變更實施計劃、變更實施報告變更結果跟蹤第四章服務報告第一節(jié)定期報告的基本原則1 .定期報告首先借助于各類監(jiān)控工具生成。2 .定期報告格式要有數(shù)據災備中心統(tǒng)一風格，如標題樣式、頁眉頁腳、字體顏色、表格樣式等。3 .定期報告原則上分類書寫，并有匯總文檔進行說明。4 .針對不同客戶的SLA所協(xié)商的，分別定制粒度不同的服務報告。第五章文檔管理第一節(jié)命名規(guī)則1 .所有非流程流轉的文檔，如配置項目文檔、運維手冊等以項目名稱為基礎，命名方式為項目名稱-