ISO20000體系文件-服務級別管理程序(DOC)

1、服務級別管理程序(#CP-0010)目的本過程描述公司采用的過程方法以有效地管理服務級別管理過程。該文件表明公司IT部門符合IS0 20000中對服務級別管理過程(IS0 20000-1:2005 6.1)的要求。范圍IT服務管理體系中的服務級別管理覆蓋Internet服務、管理網(wǎng)絡服務、管理安全服務和數(shù)據(jù)中心服務。1.服務級別管理過程1.1服務級別管理策劃（計劃）開發(fā)服務級別管理并以ITSM計劃為目標。1.2定義服務級別管理（執(zhí)行）SLM建立框架使IT部門通過計劃、實施和進行服務交付管理關(guān)注客戶。服務級別管理管理和協(xié)調(diào)服務級別，包括：服務要求、服務目標和期望的協(xié)議測量和報告達到的服務級別調(diào)查

2、糾正措施和正在進行的服務改進項目1.3 SLM的控制和評審（檢查）為符合IS0 20000-1:2005, IT部門引入框架檢查服務級別管理過程的結(jié)果。IT部門有責任每月評審可用性級別并提交關(guān)鍵績效報告。1.4 SLM反應行動（改進）IT部門應按月評審不同服務的服務級別并指定員工評估和監(jiān)控服務級別。如果沒有達到服務級別，IT部門應采取改進措施確定問題。2.服務級別管理程序2.1服務目錄服務目錄定義IT部門提供的所有服務。（略）2.2服務級別協(xié)議服務級別協(xié)議是IT部門需要達到的正式文件。2.2.1有效期有效期在相關(guān)SLA文件中明確。在有效期內(nèi)，SLA有效，直到新的協(xié)議簽定為止。2.2.2授權(quán)2.

3、2.3 溝通2.2.4聯(lián)系2.2.5服務時間所有服務需要7*24小時的服務。這在服務目錄中有描述。2.2.6計劃和協(xié)定的中斷2.2.7客戶職責2.2.8沖擊和分級指南2.2.9升級和告知過程2.2.10投訴程序2.2.11服務目標2.2.12工作負載限制下述工作負載限制由lT部門提供并被客戶接受。2.2.14財務管理2.2.15內(nèi)務工作程序2.2.16例外2.2.17可用性初始評審報告可用性初始評審報告必須附在相應的SLA后面作為記錄。2.3服務級別管理(SLM)過程SLM是一個持續(xù)改進循環(huán)過程。由于業(yè)務變更、增長、業(yè)務重組或合并造成的要求變更，服務級別需要重新定義或臨時暫停。IT部門引入的S

4、LM過程能靈活的應對這些變更。2.3.1服務需求的協(xié)議在SLA中，IT部門將滿足客戶要求的服務級別。每年定期由IT部門和客戶進行評審。變更可以在任何時間（非預定會議）根據(jù)SLA變更管理提出。2.3.2服務目標服務目標由服務級別協(xié)議描述。更新的服務目標將列入服務管理委員會的日程。如果達到服務目標存在困難（如目標無法達到），IT部門和客戶將定期評審以解決問題。2.3.3測量和報告IT部門并每月向客戶報告服務級別的達成情況。下面的例子用來說明如何計算量測指標：例如：一個郵件服務器宕機影響1/3的用戶2小時，則網(wǎng)絡可用性：Network Availability =100%*( (30 days24

5、hours 60 mins) -(2 hours60 mins) 1/3customer impacted) /(30 days 24 hours 60 mins)=99.9074%2.3.4糾正和預防措施糾正和預防措施過程如下：每天進行異常和趨勢檢測。根據(jù)事件的性質(zhì)，問題將被提升到管理層。一般問題將在月度問題管理會議給予關(guān)注。2.3.5服務改進計劃SLM過程負責人每月監(jiān)控SLA2.3.6 SLA變更管理如果需要變更，需要通過下述過程：召開會議討論SLA，兩方代表必須參加。E-mail溝通是另外的討論SLA的渠道。變更可以通過會議和電子郵件評估和決定。3.0 參考 無4.0 批準技術(shù)總監(jiān) 日期

6、：信息安全管理（#cp-0011）目的：本方針的目標是保護公司的客戶的信息資產(chǎn)免受威脅，無論此威脅來自內(nèi)部還是外部，蓄意的還是無意的：目標：方針的實施對于在處理客戶和供應商有關(guān)事務時，維護和展示我們的完整性非常重要；此方針確保：信息不被非授權(quán)訪問信息的機密性得到保證信息不會被無意或故意泄露給未授權(quán)人員需要時，信息對于授權(quán)人員具備可用性。法律法規(guī)的要求得到滿足制定和保持業(yè)務持續(xù)計劃，并進行實際的測試所有員工能夠得到信息安全的培訓教育所有違反信息安全的事件和潛在的弱點得以匯報和檢查。適用范圍公司所有人員和供應商，以及其他合約規(guī)定下的受雇傭者，只要可能接觸到信息安全管理體系范圍內(nèi)的信息資產(chǎn)，都有責任

7、遵守這一信息安全政策。本政策由IT管理部批準，并支持。目的遁過適當?shù)娘L險評估，識別信息資產(chǎn)價值，明確那些會讓其暴露于風險之中的弱點和威脅。通過設計、實施和維護一套規(guī)范的信息安裝管理制度將風險減低到可接受的程度。需要遵守的法律法規(guī)包括：公司法數(shù)據(jù)保護法計算機使用保護法版權(quán)、設計和專利保護法通信法縱上均為現(xiàn)行有效版本應遵從合同條款中關(guān)于信息安全方面的條款；應遵從公司的要求；符合IS020000:2005標準的6.6條款的要求；其他規(guī)定其它方面的規(guī)定包括：物理安全對系統(tǒng)和數(shù)據(jù)的訪問控制安全教育和培訓員工行為準則豆聯(lián)網(wǎng)和郵件數(shù)據(jù)備份便攜設備的使用存儲和處理機密數(shù)據(jù)病毒防護和偵測業(yè)務連續(xù)計劃參考 無批準

8、技術(shù)總監(jiān) 日期：變更管理程序(#CP-0014)1目的定義職責和流程，管理變更請求的批準、實施、監(jiān)控和測量。2范圍本程序適用于所有公司使用的硬件和軟件產(chǎn)品變更需求，這些在配置管理數(shù)據(jù)庫中列出。這包括標準桌面軟件，如微軟XP標準版，微軟Office2003, Symantec防病毒企業(yè)版9.0等等。3定義3.1變更：任何在配置管理數(shù)據(jù)庫中配置項的變化。3.2變更記錄：一個授權(quán)的變更對于哪些配置項有影響，以及影響的程度的細節(jié)性記錄。3.3配置項：被配置管理所控制的基礎設施或者其條目的組件。3.4配置管理數(shù)據(jù)庫(CMDB)：包含每個配置項的相關(guān)細節(jié)和它們之間重要關(guān)系的細節(jié)的數(shù)據(jù)庫。3.5變更請求：請

9、求一個變更的過程需要使用在線表格(#CF-0013)，以便記錄對于服務或者基礎設施的任何配置項的變更請求的細節(jié)。4.職責4.1 變更經(jīng)理負責對在公司CMDB列出的配置項(Cls)的所有變化。變更經(jīng)理一定要在發(fā)布前批準所有的變更Cls，并確保每次Cls變更后更新CMDB。在公司內(nèi)，變更經(jīng)理默認是IT部門經(jīng)理(IT部門經(jīng)理或高層管理者可以根據(jù)情況指定其他人擔任變更經(jīng)理)。4.2 變更請求者通過識別IT業(yè)務需求，啟動變更流程。4.3 變更指導委員會(CSC)負責響應、實施和監(jiān)控變更請求。CSC成員被視為變更技術(shù)專家。5.變更管理過程5.1 當業(yè)務相關(guān)的IT新需求被識別時，公司的員工必須填寫在線變更請

10、求表(#CF-0013)觸發(fā)一個變更。通過變更管理工具軟件自動把變更請求以E-mail方式發(fā)送給變更經(jīng)理。5.2 收到變更請求通知后，變更經(jīng)理負責登錄變更管理工具軟件，評審所有遞交的變更申請表(#CF-0013)，然后變更經(jīng)理必須：5.2.1 把所有評審過的變更請求標注為“收到”。5.2.2 把所有的不完全的變更請求標注為“由于不完全而拒絕”5.2.3 指派CSC成員負責某個變更請求。5.2.4 將變更分類為“緊急的”、“應急的”，“重大”或“輕微”。5.2.5 轉(zhuǎn)發(fā)所有的完整變更請求發(fā)送到CSC并標注為“審核中”。5.3 CSC必須評審變更請求而且開始完成在線變更分析表格(#CF-0014)

11、，確定變更的范圍。5.4 CSC必須完成變更請求的風險分析，評估風險、沖擊和業(yè)務收益。結(jié)果必須被記錄在在線變更分析表(#CF-0014)。5.5 如果風險可接受，CSC必須識剮變更實施后不滿意的回退或補救方法，結(jié)果必須被記錄在在線變更分析表(#CF-0014)。5.6 CSC必須制訂正式實施計劃一包括變更日期，以及在變更分析表(#CF-0014)記錄變更結(jié)果。5.7完成以上步驟后，CSC必須把在線變更分析表(#CF-0014)標注為“等待批準”。5.8變更經(jīng)理必須評審和批準在線變更分析表(#CF-0014)，并與所有受影響（正面的或者負面的）部門的負責人溝通實施日期和步驟。5.9 批準后，CS

12、C可以所定義的范圍內(nèi)、在線變更分析表(#CF-0014)中約定之下，依照發(fā)布管理程序(#RM-0003)實施變更。5.10 由于變更而導致的所有問題，必須記錄于在線變更分析形表(#CF-0014)中。5.11 CSC負責聯(lián)絡所有受影響的團體，確定他們的滿意度并把結(jié)果記錄在線變更分析表(#CF-0014)中。5.12 問題或客戶抱怨必須記錄于在線變更分析表(#CF-0014)中追蹤，并由CSC來解決。基于問題或抱怨的種類，新的變更或糾正措施可能被CSC提出。5.13 變更經(jīng)理一定要在CMDB中記錄所有執(zhí)行的變更。6.溝通和培訓6.1 變更經(jīng)理有責任確保IT部門的所有員工和所有部門領導們接受培訓，

13、了解他們在變更管理流程中的角色和職能。7.0參考變更請求表(#CF-0013)變更分析表(#CF-0014)變更管理流程圖(#FL-014)變更管理流程圖8.0 批準技術(shù)總監(jiān) 日期配置管理程序(#CP一0017)1. 目的定義管理硬件、軟件和相關(guān)文檔的配置職責和過程。2. 范圍本程序適用于所有硬件、軟件、相關(guān)文檔和其它被公司使用的配置項(Cls)的配置管理，這些CI由IT部門依照服務級別協(xié)議(SLA)管控。員工個人購買使用的軟件不在配置管理范圍內(nèi)，此外，不影響系統(tǒng)功能和完整性的內(nèi)容或數(shù)據(jù)的變更也不在此范圍中。3. 定義3.1基線：指定時刻的服務或個別的配置項狀態(tài)的快照。3.2變更：對配置管理數(shù)

14、據(jù)庫內(nèi)列出的配置的條目的改變。3.3配置項(CI)：被配置管理所控制的基礎設施或者其條目的組件。3.4配置管理數(shù)據(jù)庫：包含每個配置項的相關(guān)細節(jié)和它們之間重要關(guān)系的細節(jié)的數(shù)據(jù)庫。3.5發(fā)布：新的配置項，和變更的配置項，在經(jīng)過測試和引進實體環(huán)境的集合。4. 責任4.1醌置經(jīng)理負責評審和批準所有的正常情況下的基線配置并批準對CMDB的建議變更。在合適時，配置經(jīng)理可以委派此責任給IT支持人員。4.2不論是對IT硬件、軟件或是文檔所做的變更，變更經(jīng)理或其代表負責此流程的符合性。5. 配置管理策略5.1配置項包括被公司所使用的軟件、硬件和文檔，由IT部門按照所適用的服務級別協(xié)議管控。必須根據(jù)這個程序執(zhí)行配

15、置管理，確保受控，和有效的策劃、實施、維護和改進IT系統(tǒng)。6. 配置管理過程6.1當Cls發(fā)生改變，變更經(jīng)理或其代表必須訪問“http:/Log_nphp”登錄到CMDB（如果變更經(jīng)理或其代表沒有口令，必須聯(lián)系配置經(jīng)理要求口令）。6.2登錄后，變更經(jīng)理或代表必須根據(jù)在線提示完成CMDB的變更，并按下“同意按鈕。6.3配置經(jīng)理必須登錄CMDB，評審和批準所有提出的對CMDB的更新。如果提出的CMDB的更新可接受，配置經(jīng)理必須選擇“同意更新”按紐，正式接受對CMDB的變更。6.4配置經(jīng)理必須每月回顧CMDB，驗證其準確性，在每月的lT部門會議介紹變更摘要。如果CMDB和實際檢測到的配置項存在差異，

16、必須觸發(fā)糾正措施過程。6.5配置經(jīng)理負責更新CMDB，展示文檔手冊和硬件與軟件之間的聯(lián)系。6.6當變更經(jīng)理提出需求，配置經(jīng)理必須提供信息，表明一個CI的變更對其它服務或基礎設施配置的可能沖擊。6.7配置經(jīng)理必須保證所有數(shù)字Cls的完整性，例如電子手冊。配置經(jīng)理必須對CMDB中的Cls在系統(tǒng)中分類，僅配置經(jīng)理有該操作的讀寫權(quán)限。配置經(jīng)理根據(jù)實際狀況，決定誰對該操作和其中的數(shù)據(jù)Cls有讀權(quán)限6.8 IT服務支持人員負責執(zhí)行和驗證CMDB與其它公司的信息服務器的正常備份。7. 溝通和培訓7.1配置經(jīng)理負責對IT部門的所有員工和所有部門領導進行培訓，確保他們了解其在配置管理流程內(nèi)角色和職能。8.0參考

17、無9.0批準技術(shù)總監(jiān) 日期：問題管理程序(#CP-0019)1.目的 定義管理問題和幫助請求的責任與過程。2.范圍該程序覆蓋所有問題和幫助請求，包括那些用戶通報給IT部門的，或者由IT部門自行發(fā)現(xiàn)的。3.定義3.1變更：任何對配置管埋數(shù)據(jù)庫所列配置項的更改。3.2嚴重問題：完全失去正常操作任何重大業(yè)務功能的能力。（例如：服務器或者網(wǎng)絡硬件的故障）3.3配置項(CI)：被配置管理所控制的基礎設施或者其條目的組件。3.4配置管理數(shù)據(jù)庫：包含每個配置項的相關(guān)細節(jié)和它們之問重要關(guān)系的細節(jié)的數(shù)據(jù)庫。3.5高風險問題：一個嚴重限制應用程序、系統(tǒng)或一個設備的使用的問題，顯著影響業(yè)務功能（如，備份服務器問題。

18、）3.6突發(fā)事件：任何不屬于服務標準操作部分的事件，造成或可能造成服務質(zhì)量的中斷或降低。3.7問題：造成一個或多個突發(fā)事件的未知原因。3.8常規(guī)問題：只影響一個人，而且并不會影響個人執(zhí)行重要業(yè)務操作能力的問題。3.9發(fā)布：新的配置項，和變更的配置項，在經(jīng)過測試和引進實體環(huán)境的集合。4.0責任4.1 IT經(jīng)理負責保證所有的問題都被及時和有效地解決5.0問題管理程序5.1發(fā)現(xiàn)配置項(CI)問題的人，必須在問題管理數(shù)據(jù)庫(PMD)中明確地描述問題，PMD可以通過“http:/Login.php.訪問。5.2IT經(jīng)理必須每天檢查PMD,在PMD中對登錄在案的問題劃分優(yōu)先級。問題被劃分為“常規(guī)”，“高風險”或“嚴重”。5.2.1嚴重問題必須立即處理。5.2.2高風險問題在嚴重問題解決后處理。5.2.3常規(guī)問題可以在時間允許的情況下解決。5.3 IT經(jīng)理必須分配問題給IT服務人員，要求分析根本原因并提供解決方案。5.4 IT服務人員必須立即采取措施，控制問題并最小化問題帶來的進一步?jīng)_擊。5.5基于根本原因分析，IT服務人員可以根據(jù)變更管理程序(#CP-0014)，提出變更請求