ITILv3核心讀物圖解集之問題管理流程

1、前 言 隨著ITIL v3在國(guó)內(nèi)的普及和應(yīng)用，越來(lái)越多的讀者希望更進(jìn)一步地提升對(duì)ITIL v3核心圖書的學(xué)習(xí)，為此，上海翰緯信息管理咨詢有限公司作為中國(guó)領(lǐng)先的專注于IT服務(wù)管理研究和咨詢的機(jī)構(gòu)，于2010年11月啟動(dòng)翰緯ITIL v3圖解集的開發(fā)工作。翰緯ITIL v3圖解集的開發(fā)將采取“Open Source”的方式，希望廣大的“ITIL”迷們積極地與翰緯聯(lián)系，參與本圖解集的開發(fā)指導(dǎo)工作，分享自己的最佳實(shí)踐。翰緯ITIL v3圖解集力圖通過較短的篇幅，結(jié)合翰緯自身豐富的咨詢研究經(jīng)驗(yàn)，深入淺出地對(duì)ITIL v3原書中的重要圖表進(jìn)行解釋說明和點(diǎn)評(píng)，能讓讀者更加深入的理解和應(yīng)用ITIL

2、v3的重要內(nèi)容。翰緯ITIL v3圖解集按輯發(fā)布，本文為第三輯問題管理流程圖解，接下來(lái)即將推出第四輯，敬請(qǐng)留意：²  第四輯IT服務(wù)連續(xù)性管理   ITIL v3核心讀物 圖解集之問題管理流程1.0      圖解概述 問題管理是負(fù)責(zé)管理所有問題生命周期的流程。問題管理的目的是IT基礎(chǔ)架構(gòu)中的錯(cuò)誤引起的故障和問題對(duì)業(yè)務(wù)的負(fù)面影響，并且防止再次發(fā)生與這些錯(cuò)誤有關(guān)的故障。圖1是問題管理的流程圖（ITIL原書Service Operation 的Figure4.

3、4），該圖說明了從問題識(shí)別、記錄開始到問題關(guān)閉整個(gè)問題管理流程所涉及的各個(gè)活動(dòng)及其關(guān)系。2.0      圖解說明問題管理包括診斷故障根本原因的活動(dòng)，及確定這些問題的解決方案。它還負(fù)責(zé)確保方案通過合適的控制流程實(shí)施，特別是變更和發(fā)布流程。問題管理還維護(hù)關(guān)于問題、適當(dāng)?shù)囊?guī)避措施和解決方案的信息，以便組織能夠減少故障的數(shù)量和影響。這方面，問題管理應(yīng)該與知識(shí)管理和KEDB類的工具軟件有一個(gè)緊密的接口。盡管故障和問題管理是獨(dú)立的流程，但它們緊密相關(guān)，一般都使用相同的工具軟件，并使用相似的分類、影響和優(yōu)先級(jí)代碼系統(tǒng)。這樣，在處理相關(guān)的故障和問題

4、時(shí)，可以確保有效的溝通。問題管理流程圖中的每一個(gè)活動(dòng)的詳細(xì)說明如下：2.1      問題檢測(cè)和記錄在不同的組織，可能存在不同的問題檢測(cè)手段，包括：l  服務(wù)臺(tái)懷疑或檢測(cè)到一個(gè)或多個(gè)原因未知的故障，會(huì)建立問題記錄。有時(shí)候是服務(wù)臺(tái)已經(jīng)解決了故障，但不能確定引起故障的原因并懷疑它可能會(huì)再次出現(xiàn)，因此會(huì)建立問題記錄，以便解決根本原因；或者，從一開始就可以明顯發(fā)現(xiàn)一個(gè)故障或多個(gè)故障是由一個(gè)重大問題所引起，因此可以立即建立問題記錄。l  技術(shù)支持小組在進(jìn)行故障分析時(shí)，揭示了存在或可能存在的問題。l

5、0; 自動(dòng)檢測(cè)基礎(chǔ)設(shè)施或應(yīng)用故障，事件/報(bào)警工具軟件自動(dòng)地發(fā)起故障并提示需要進(jìn)行問題記錄。l  供應(yīng)商或廠商通知存在問題，需要解決。l  對(duì)故障進(jìn)行主動(dòng)式問題管理分析，這需要建立問題記錄，以便可以進(jìn)一步調(diào)查根本原因。無(wú)論通過哪種檢測(cè)手段，所有問題的相關(guān)信息都必須進(jìn)行記錄，以便保留完整的歷史記錄。一般包括以下信息：l  用戶詳細(xì)情況l  服務(wù)詳細(xì)情況l  設(shè)備詳細(xì)情況l  最初記錄的日期/時(shí)間l  優(yōu)先級(jí)和分類詳細(xì)情況l  故障

6、描述l  所有診斷或企圖采取的恢復(fù)措施的詳細(xì)情況2.2      問題分類和優(yōu)先級(jí)問題的分類，可使用和故障相同的分類編碼系統(tǒng)，以便將來(lái)容易跟蹤問題的真正本質(zhì)，并容易獲得有意義的管理信息。問題的優(yōu)先級(jí)類似于故障的優(yōu)先級(jí)，但是需要考慮問題的相關(guān)故障的頻率和影響，并設(shè)計(jì)關(guān)于為什么這是一個(gè)問題的定義、解決問題的支持人員、與問題相關(guān)聯(lián)的服務(wù)等。問題優(yōu)先級(jí)應(yīng)該考慮問題的嚴(yán)重性。這里的嚴(yán)重性是指從基礎(chǔ)架構(gòu)角度看問題有多嚴(yán)重。比如：l  系統(tǒng)能夠恢復(fù)嗎？或它需要替換嗎？l  它要花費(fèi)多少？l

7、  修復(fù)這個(gè)問題需要多少人？需要哪些技能？l  修復(fù)這個(gè)問題需要多少時(shí)間？l  問題的擴(kuò)展性如何？（受影響的CI有多少？）由IT組織中的職能部門進(jìn)行問題的分類并評(píng)估其緊急程度和影響程度，進(jìn)而確定優(yōu)先級(jí)。2.3      問題調(diào)查和診斷需要進(jìn)行調(diào)查以診斷問題的根本原因，調(diào)查的速度和性質(zhì)會(huì)隨問題的影響、嚴(yán)重性和緊急性而不同。但應(yīng)投入適當(dāng)?shù)馁Y源和專門技術(shù)查找與優(yōu)先級(jí)及相應(yīng)的服務(wù)目標(biāo)相稱的解決方案。配置管理系統(tǒng)（CMS）幫助確定影響程度并幫助查明和診斷故障的確切部位。如果該問題曾經(jīng)出

8、現(xiàn)過，還要訪問KEDB(已知錯(cuò)誤數(shù)據(jù)庫(kù))并使用問題匹配技術(shù)（比如關(guān)鍵字搜索）查找解決方案。嘗試重現(xiàn)此故障通常很有效，這樣能知道發(fā)生什么錯(cuò)誤，然后通過不同的方法去尋找最合適的和最經(jīng)濟(jì)的解決方案。為了避免引起進(jìn)一步的中斷，需要一個(gè)與生產(chǎn)環(huán)境鏡像的測(cè)試系統(tǒng)。很多問題分析、診斷和解決技術(shù)可用，并且都已經(jīng)進(jìn)行過研究。一些比較有用且用的較多的技術(shù)如下：l  時(shí)序分析（Chronological Analysis）：在處理一個(gè)困難問題時(shí)，通常會(huì)針對(duì)具體發(fā)生情況和發(fā)生時(shí)間建立沖突報(bào)告。因此按時(shí)序簡(jiǎn)要記錄所有事件，即提供事件發(fā)生時(shí)間表是非常有幫助的。通常這可以支持查看哪些事件被其他事件觸發(fā)，

9、或者忽視了哪些與事件發(fā)生順序不符的聲明。l  痛值分析（Pain Value Analysis）：這不只是分析特定時(shí)期特殊類型故障/問題的數(shù)量，而是進(jìn)行更深入地分析，來(lái)確定這些故障/問題具體給組織和業(yè)務(wù)帶來(lái)哪種級(jí)別的痛值?？梢栽O(shè)計(jì)一個(gè)公式來(lái)計(jì)算痛值級(jí)別。一般這可能包括要考慮：ü  受影響人員的數(shù)量ü  引起的中斷持續(xù)時(shí)間ü  企業(yè)耗費(fèi)的成本l  頭腦風(fēng)暴（Brainstorming）：通常，有效的辦法是將所有相關(guān)人員實(shí)地或通過電子方式聚集到一起對(duì)問題展開“頭腦風(fēng)暴”

10、，即所有人員就潛在原因和潛在的問題解決措施提出自己的想法。頭腦風(fēng)暴會(huì)議具有很大的建設(shè)性和創(chuàng)新性，但同樣重要的是一些人，或許是問題經(jīng)理會(huì)記錄結(jié)果和任何約定的措施，并在會(huì)議中保持一定的程度控制。l  排列(帕累托)分析（Pareto Analysis）：這是一種用于在很多瑣碎問題中區(qū)分出重要潛在原因的技術(shù)。一般采取以下步驟：ü  建立一個(gè)表，列出原因以及發(fā)生的頻率（百分比）；ü  按原因重要性的降序安排，即發(fā)生頻率最高的原因列在前面；ü  在表中添加樣本累積百分比欄。如表1（ITIL原書S

11、ervice Operation 的Table 4.2），闡述了某組織中出現(xiàn)網(wǎng)絡(luò)故障的十大原因。表1 Pareto原因排行表  網(wǎng)絡(luò)故障原因占總數(shù)的百分比計(jì)算累積%網(wǎng)絡(luò)控制器350+35%35文件破壞2635%+26%61解決沖突1961%+19%80服務(wù)器操作系統(tǒng)680%+6%86腳本錯(cuò)誤586%+5%91未測(cè)試的變更391%+3%94操作員錯(cuò)誤294%+2%96備份故障296%+2%98入侵嘗試198%+1%99磁盤故障199%+1%100ü  按照原因占總數(shù)的百分比，創(chuàng)建原因條形圖。ü  疊加累積百

12、分比線性圖。如圖2（ITIL原書Service Operation 的Figure4.5）顯示了完整圖表。ü  在y軸80%的點(diǎn)，畫一條與x軸平行的線。一直畫到與x軸曲線交叉的地方。X軸上的這一點(diǎn)將將重要原因與非重要原因區(qū)分開來(lái)。這一線條在圖2中以虛線顯示。從圖2中可以看出有三個(gè)主要原因?qū)е铝私M織中的網(wǎng)絡(luò)故障。因此這些原因應(yīng)得到最先解決。2.4      規(guī)避措施有時(shí)候可能需要為由問題引起的故障找出一種規(guī)避措施，作為臨時(shí)問題解決方法。比如，手工輸入一個(gè)文件使得程序能夠成功運(yùn)行。但是，仍需要繼續(xù)尋

13、找永久性解決方案。在找到規(guī)避措施的情況下，還需要做的一項(xiàng)工作是，保持問題記錄處于開放狀態(tài)，并且確保在問題記錄中詳細(xì)記錄規(guī)避措施的信息。2.5      創(chuàng)建已知錯(cuò)誤記錄診斷一旦完成，特別是規(guī)避措施已找到（即使不是一個(gè)永久性解決方案）的情況下，應(yīng)該創(chuàng)建一條已知錯(cuò)誤記錄，并記錄到已知錯(cuò)誤數(shù)據(jù)庫(kù)（KEDB, Known Errors Database），這樣如果以后繼續(xù)出現(xiàn)同樣的故障和問題，它們就能被快速識(shí)別，服務(wù)也能更快地恢復(fù)。2.6      問題解決理想地，一旦找到解決方案，

14、就應(yīng)該馬上用于解決問題，但現(xiàn)實(shí)中需要采取一定的安全保護(hù)措施以免導(dǎo)致進(jìn)一步出現(xiàn)問題。如果需要進(jìn)行功能方面的變更，這就需要在實(shí)施解決方案之前發(fā)起和批準(zhǔn)RFC。如果問題很嚴(yán)重或者由于業(yè)務(wù)原因需要緊急修復(fù)，則緊急變更申請(qǐng)(RFC)需要得到CAB/EC(Change Advisory Board Emergency Committee)的處理。否則，RFC應(yīng)該按照既定的變更管理流程處理，并且只有在變更得到批準(zhǔn)和排期后，變更才能得到實(shí)施。同時(shí)，KEDB用于幫助快速解決故障/問題的再次發(fā)生。2.7      問題關(guān)閉當(dāng)變更實(shí)施完成（并已完成審查），

15、且應(yīng)用了解決方案，問題記錄應(yīng)正式關(guān)閉，其他相關(guān)的、打開的故障記錄也應(yīng)該關(guān)閉。這時(shí)，應(yīng)該進(jìn)行檢查以確保記錄包含所有事件的完整的歷史描述。所有已知錯(cuò)誤記錄的狀態(tài)也應(yīng)該更新，以顯示已應(yīng)用了解決方案。2.8      主要問題審查在每個(gè)主要問題完成后（由組織的優(yōu)先級(jí)系統(tǒng)確定），當(dāng)大腦還記憶猶新時(shí)，應(yīng)該進(jìn)行回顧以便為將來(lái)吸取一些教訓(xùn)。特別地，回顧應(yīng)該包括：l  哪些事情做對(duì)了l  哪些事情做錯(cuò)了l  什么事情將來(lái)可以做的更好l  如何防止再次發(fā)生l 

16、60;是否存在第三方責(zé)任、是否需要采取后續(xù)的行動(dòng)這種回顧可以作為員工培訓(xùn)和意識(shí)教育的一部分，任何經(jīng)驗(yàn)教訓(xùn)都可以記錄到適當(dāng)?shù)倪^程、工作指引、診斷腳本和已知錯(cuò)誤記錄中。問題經(jīng)理應(yīng)該推動(dòng)這些工作并記錄所同意采取的行動(dòng)?；仡欀袑W(xué)習(xí)的知識(shí)應(yīng)該在服務(wù)回顧會(huì)議上向業(yè)務(wù)客戶匯報(bào)，使客戶知道為了防止主要故障再次發(fā)生而采取了什么行動(dòng)和計(jì)劃。這有助于提高客戶滿意度，并使業(yè)務(wù)部門知道服務(wù)運(yùn)營(yíng)部門正在負(fù)責(zé)地處理主要故障，并積極地進(jìn)行工作以防再次發(fā)生。2.9      開發(fā)環(huán)境中的錯(cuò)誤監(jiān)測(cè)新應(yīng)用、系統(tǒng)或軟件發(fā)布時(shí)完全沒有錯(cuò)誤是不大可能的。鑒于組織一方面需要在最短

17、的時(shí)間內(nèi)向企業(yè)交付新的功能，另一方面需要確保代碼或組件不含錯(cuò)誤。為了在這二者之間取得平衡，通常在測(cè)試此類新應(yīng)用、系統(tǒng)或軟件期間，組織會(huì)根據(jù)優(yōu)先級(jí)根除最嚴(yán)重的錯(cuò)誤，但一些微小錯(cuò)誤可能未被糾正。當(dāng)決定向生產(chǎn)環(huán)境發(fā)布某些仍存在缺陷的組件時(shí)，應(yīng)該將這些作為已知錯(cuò)誤記錄到KEDB中，并提供詳細(xì)的規(guī)避措施或解決方案。在測(cè)試完畢時(shí)，組織應(yīng)采取一個(gè)正式步驟來(lái)確保進(jìn)行移交。經(jīng)驗(yàn)表明，如果不這樣做，當(dāng)用戶開始遇到這個(gè)故障且不得不重新診斷和解決這個(gè)故障時(shí)，將導(dǎo)致很高的支持成本。3.0      點(diǎn)評(píng)故障管理的目的是快速解決故障，在很多情況下為了快速恢復(fù)那些

18、產(chǎn)生故障的服務(wù)，我們會(huì)利用一切可能的手段，例如變通的解決辦法。而問題管理的目標(biāo)是尋找出故障背后的真正原因，主要目的是找到故障產(chǎn)生的原因，并防止故障的再次發(fā)生。在很多企業(yè)中，花費(fèi)了很多精力去建立和推行問題管理流程，卻面臨這樣的問題，即問題管理流程建立了，可是創(chuàng)建的問題數(shù)卻非常少，要么因?yàn)榱鞒踢\(yùn)作成本太高或者因?yàn)榉止げ幻鞔_導(dǎo)致流程無(wú)法執(zhí)行下去，要么就是運(yùn)行一段時(shí)間后沒有起到降低故障發(fā)生率的預(yù)期效果，甚至到后來(lái)，故障管理和問題管理逐漸地混成一個(gè)流程了，往往導(dǎo)致問題管理流程名存實(shí)亡，從而沒有充分實(shí)現(xiàn)問題管理流程本該發(fā)揮的作用。結(jié)合眾多企業(yè)實(shí)施問題管理實(shí)踐經(jīng)驗(yàn)來(lái)看，可以歸納以下因素為確保問題管理流程被有效地執(zhí)行的關(guān)鍵成功因素：l