-問題管理流程設(shè)計說明書.doc

文檔標題問題管理2020年1月8日1 問題管理1.1 問題管理的目標問題管理的目標是最小化事故的不利影響以及由于IT基礎(chǔ)設(shè)施中的錯誤造成的業(yè)務(wù)上的問題，阻止與這些錯誤相關(guān)的事故的重復(fù)發(fā)生。為了達到這個目標，問題管理尋求找到事故的根本原因，采取行動改善或糾正這種狀況。問題管理流程具有主動和被動兩個方面。被動的問題管理關(guān)注于解決問題以響應(yīng)一個或多個事故。主動問題管理關(guān)注于在事故首次出現(xiàn)前就能識別和解決問題以及知名錯誤。1.2 問題管理的范圍問題控制、錯誤控制以及主動問題管理都屬于問題管理流程的范圍。較為正式的定義是，問題是一個或多個事故未知的底層原因，知名錯誤是已經(jīng)成功診斷出來的問題，并且為之定義了臨時措施。圖1 問題管理的范圍問題管理流程的輸入是：v 來自事故管理的事故詳細信息v 來自配置管理數(shù)據(jù)庫的詳細配置信息v 任何定義的臨時措施（來自事故管理）問題管理的主要活動包括：v 問題控制v 錯誤控制v 問題的主動預(yù)防v 識別問題趨勢v 從問題管理數(shù)據(jù)中獲得管理信息v 完成主要問題的評估問題管理流程的輸出：v 知名錯誤v 變更請求（RFC）v 更新后的問題記錄（包括解決方案和/或任何可用的臨時措施）v 關(guān)閉問題記錄（對于解決的問題）v 與問題和知名錯誤匹配的事故的響應(yīng)v 管理信息1.3 基本概念在事故的早期階段，能夠得到相應(yīng)的而且容易應(yīng)用的建議，對于組織有效地解決事故的能力來說，這是最重要的。服務(wù)臺接收到的事故，對于支持員工很少是初見的或是神秘的。相似地，處于二線或三線的支持員工中的專家也已經(jīng)解決了許多困難和原始事故和問題?；ㄙM在這些解決方案上的資源的最好使用方式就是將它制作成文檔，這樣一線的員工就可以應(yīng)用它們了。問題管理流程試圖降低影響業(yè)務(wù)的事故和問題的數(shù)量及危害，因此，問題管理的部分職責(zé)是確保以前的信息被記錄在檔，這樣對一線及其它二線支持員工就已經(jīng)是準備好可用的了。它不是簡單地記錄文檔的問題，它要求：v 信息應(yīng)該建立索引，以便根據(jù)來自新事故的簡單的線索就能容易地查找；v 進行例行檢查，以確保持續(xù)的文檔記錄與變更相一致：u 技術(shù)u 可用的外部解決方案u 業(yè)務(wù)實踐和需求u 內(nèi)部技巧u 重復(fù)事故的頻度和影響u 闡明內(nèi)部最佳實踐v 進行詳細評估的流程；v 訓(xùn)練員工使用信息，理解可用信息的深度和作用，以及怎樣訪問和理解信息，在提供反饋方面，信息的相關(guān)性和易于使用；v 存貯信息的知識庫典型地基于集成的服務(wù)管理工具，使得在登錄后或者在事故處理流程的初始分析階段就能使用知識。一般地使用“專家系統(tǒng)”軟件來發(fā)揮問題管理流程的作用。然而，重要的是包括專家知識，讓使用系統(tǒng)的員工根據(jù)反饋來更新：v 被識別的問題和知名錯誤；v 分析他們遇到的事故（被動問題管理）；v 按時間段分析事故（主動問題管理）；v 分析IT基礎(chǔ)架構(gòu)；v 提供知識庫；v 引進新產(chǎn)品時的開發(fā)人員和提供商。一般情況下，問題是多個展現(xiàn)出共同特征的事故的結(jié)果。有時問題也可以根據(jù)單個明顯的事故來識別，由單個錯誤引起，雖然原因未知，但影響明顯。知名錯誤是對問題的根本原因成功診斷后識別的，后續(xù)將開發(fā)一個臨時措施。IT基礎(chǔ)架構(gòu)的結(jié)構(gòu)化分析、來自支持軟件的報告以及用戶組會議有助于問題和知名錯誤的識別。這就是主動問題管理。問題控制重點在于將問題轉(zhuǎn)化為知名錯誤，錯誤控制重點在于通過變更管理流程結(jié)構(gòu)化地解決知名錯誤。1.3.1 事故管理和問題管理的不同問題管理不同于事故管理，它的主要目標是事故底層原因的檢測，提供后續(xù)的解決方案，阻止事故的發(fā)生。在許多情況下，這個目標可能與事故管理的目標有直接的沖突，因為事故管理的目標是盡可能快的為客戶恢復(fù)服務(wù)，經(jīng)常通過臨時措施，而不是通過徹底地解決。因此在這個方面，找到解決方案的速度是次要的。底層問題的調(diào)查需要花費時間，這樣會推遲服務(wù)的恢復(fù)，但阻止了事故的重復(fù)發(fā)生。1.3.2 問題控制問題控制流程關(guān)注于以有效地方式處理問題。問題控制的目標是識別根本原因，諸如存在錯誤的配置項，向服務(wù)臺提供可用的關(guān)于臨時措施的信息和建議。問題控制流程很相似于，且高度依賴于事故控制流程的質(zhì)量。事故控制重點在于解決事故，提供臨時措施，對特定的事故臨時修復(fù)。如果對于一個或一組事故，識別出了問題，可用的臨時措施和臨時修復(fù)應(yīng)該由問題控制流程記錄在問題記錄中。問題控制流程也對問題建議最佳的可用臨時措施。因為問題控制關(guān)注于阻止事故的重復(fù)發(fā)生，因此流程的方法應(yīng)該被仔細地管理和規(guī)劃。管理和規(guī)劃的程度要高于事故控制，因為它的目標只是盡快地恢復(fù)正常的服務(wù)。優(yōu)先權(quán)應(yīng)該分配組那些可能引起嚴重業(yè)務(wù)中斷的問題的解決。在事故控制中的活動包括：v 問題識別和記錄；v 問題分類；v 問題調(diào)查和診斷；1.3.3 錯誤控制錯誤控制包括的流程是，在變更管理流程的控制下，能過成功地實施變更，使知名錯誤得以消除。錯誤控制的目標是發(fā)現(xiàn)錯誤、監(jiān)控錯誤、在成本合理且可行的時候排除錯誤。錯誤控制是開發(fā)（包括應(yīng)用開發(fā)、功能擴展和維護）和生產(chǎn)環(huán)境的橋梁。在開發(fā)階段產(chǎn)生的軟件錯誤會影響生產(chǎn)運營，在開發(fā)和維護環(huán)境識別的知名錯誤會被移交到生產(chǎn)環(huán)境。錯誤控制中的活動包括：v 錯誤鑒定和記錄；v 錯誤評估；v 記錄錯誤的解決（方案調(diào)查、提出變更請求）；v 關(guān)閉錯誤；v 監(jiān)控問題和錯誤的解決進展。在實踐中，問題管理的每個流程要求仔細的管理和控制，不同的操作對象應(yīng)用在不同的流程中。1.3.4 主動問題管理主動問題管理中各項活動的目的是，在事故發(fā)生前識別和解決問題。這些活動有：趨勢分析；定位支持行動；向組織提供信息；通過將IT部門的作用從被動地解決大量事故，重定位到阻止事故，它將向客戶提供更好的服務(wù)，使得IT支持部門的資源得到更有效地利用。1.3.5 主要問題評價通過對主要問題進行事后的評價，有助于服務(wù)的提升。1.4 問題管理的益處采取正式的方法進行問題管理帶來以下益處：* 提升IT服務(wù)質(zhì)量問題管理有助于形成迅速提高IT服務(wù)質(zhì)量良性循環(huán)。高質(zhì)量可靠的服務(wù)有益于IT的業(yè)務(wù)用戶、有益于生產(chǎn)力的提高、有益于IT服務(wù)提供者的士氣。* 事故數(shù)量下降問題管理是降低造成業(yè)務(wù)中斷的事故數(shù)量的利器。* 永久的解決方案隨著問題和知名錯誤被解決，它們的數(shù)量及影響會逐步減少。* 提高了組織的知識問題管理流程基礎(chǔ)于從過去的經(jīng)驗獲得知識的概念。這些流程提供了歷史數(shù)據(jù)來識別趨勢，阻止錯誤的出現(xiàn)，降低錯誤的影響，從而提高了用戶生產(chǎn)力。* 提高服務(wù)臺第一時間修復(fù)率在客戶打進電話時，服務(wù)臺通過存貯在知識庫中事故解決方案和臨時措施，在第一時間在服務(wù)臺解決事故。相反地，沒有實施問題管理流程的成本可能包括：v 一個純粹的被動支持的組織，只有在客戶的服務(wù)被中斷時才面對問題；v 面對重復(fù)發(fā)生的事故，IT用戶部門會對IT支持部門的服務(wù)質(zhì)量失去信任；v 因為相似的事故不得不反復(fù)地被解決，而沒有提供結(jié)構(gòu)化的解決方案，所以成為一個高成本、缺乏員工積極性、無效率的支持部門。1.5 規(guī)劃與實施1.5.1 時機和規(guī)劃時機和規(guī)劃是很重要的，因為：v 良好的問題管理在很程度上依賴已經(jīng)實施且有效的事故管理流程。因此，與事故管理流程并行或在它之后實施問題管理是明智的；v 如果缺乏資源，建議首先實施問題和錯誤控制（被動問題管理）。當(dāng)這些活動成熟時，資源可以直接轉(zhuǎn)向主動問題管理。主動問題管理的質(zhì)量非常依賴成功地實施了服務(wù)監(jiān)控活動以及因此獲得的基礎(chǔ)數(shù)據(jù)；v 較小規(guī)模的組織通過聚集于日常的“前十名”事故實現(xiàn)被動問題管理。這被證明有有效的，因為經(jīng)驗表明20%的問題引起了80%的服務(wù)降低。1.5.2 關(guān)鍵成功因素考慮要點包括：v 有效的事故自動登記、有效的事故分類，是問題管理成功的基礎(chǔ)；v 設(shè)置可完成的目標，利用既有員工解決問題的才能是個關(guān)鍵的活動?？紤]“兼職”問題管理，讓員工看到隨著問題的解決，他們遠離每天“救火”的壓力；v 考慮事故管理和問題管理間潛在的沖突，在兩個流程間進行良好的協(xié)調(diào)是必要的。同時兩者又都有可能彼此幫助的配合。參與兩個流程的支持職員應(yīng)該意識到平衡兩者的活動的重要性；1.5.3 風(fēng)險問題管理的益處會被以下因素減弱：v 沒有良好的事故控制流程，這樣就缺乏關(guān)于事故的詳細信息（這對正確的問題識別是必要的）；v 不能夠?qū)⑹鹿视涗浥c問題/錯誤記錄連接起來，意味著失去了許多潛在的益處。在從被動支持向更有規(guī)劃和主動支持轉(zhuǎn)移方面，這是關(guān)鍵的功能；v 缺乏管理，因此支持職員（通常也參與在被事故控制流動中）不能分配充分的時間在結(jié)構(gòu)化的問題解決活動中；v 削弱服務(wù)臺的角色。問題管理職員應(yīng)該僅從授權(quán)的發(fā)起者那里接受支持請求。如果流程處理來自許多發(fā)起者的請求就會出現(xiàn)困難，因為相同原因的多個事故報告可能會被以不同的方式來解釋；v 不能留出時間來建立和維護知識庫將限制問題管理的益處；v 沒有能力準確地判斷事故和問題的業(yè)務(wù)影響，導(dǎo)致對業(yè)務(wù)而言關(guān)鍵的事故和問題沒有給予正確的優(yōu)先級。1.6 問題控制的活動實際上，由于計算機設(shè)備和通信線路的偶然出錯，發(fā)生事故是不可避免的。許多其它事故不是由隨機產(chǎn)生的故障引起的，而是由組織日益復(fù)雜的IT基礎(chǔ)架構(gòu)某處錯誤造成的。即使可預(yù)料的計算或通信設(shè)備故障也會由于提供商的產(chǎn)品中的錯誤，導(dǎo)致無法接受的影響。被動問題控制關(guān)注于識別事故真正的底層原因，以阻止將來的重復(fù)發(fā)生。在問題控制流程中有三個階段：v 問題的識別和記錄；v 問題的分類根據(jù)對業(yè)務(wù)的影響；v 問題的調(diào)查和診斷。圖2 問題控制當(dāng)檢測到根本原因時，就開始錯誤控制流程。1.6.1 問題識別和記錄問題識別發(fā)生在：v 在事故的初始支持和分類階段，不能夠找到匹配的既有問題和知名錯誤；v 事故數(shù)據(jù)的分析揭示了重復(fù)發(fā)生的事故；v 事故數(shù)據(jù)的分析揭示了還存在沒有與能夠與既有的問題和知名錯誤匹配的事故；v IT基礎(chǔ)架構(gòu)的分析表明存在可能導(dǎo)致事故的問題；v 重大或明顯的事故（對客戶的服務(wù)具有嚴重的不利影響）發(fā)生，需要找到結(jié)構(gòu)化的解決方案。注意有些問題可能在問題管理小組之外被某個識別，如在能力管理中。無論如何，所有的問題應(yīng)該通知問題管理流程被記錄?？捎眯怨芾砹鞒痰脑S多方面關(guān)注于IT基礎(chǔ)架構(gòu)中的問題和事故的檢測和避免，這兩個領(lǐng)域的配合對提高服務(wù)質(zhì)量具有重大的價值。* 要點問題管理要求效力和資源，因此是昂貴的。組織要能夠判定對某些類型的未能匹配的事故付出努力和成本是劃算的例如能夠快速解決，影響較小或重復(fù)發(fā)生的可能性很小的事故。在這種情況下，可以在CMDB中引入虛構(gòu)的問題記錄，關(guān)聯(lián)到所有有聯(lián)系的事故、知名錯誤、變更請求以及配置項。問題記錄需要記錄在數(shù)據(jù)庫（理想情況下是CMDB），這一點類似于事故記錄。它們通常不包括某些不適用的標準事故數(shù)據(jù)（如用戶數(shù)據(jù)）。然而問題記錄應(yīng)該連接到所有相關(guān)的事故記錄。事故的解決方案和臨時措施應(yīng)該被記錄在相關(guān)的問題記錄中，以便另外相關(guān)的事故發(fā)生時能夠訪問。圖3 事故匹配處理流程問題識別的流程如上圖所示，包括基本的問題分類。受影響的配置項的數(shù)據(jù)應(yīng)該準確地追加到這個基本分類數(shù)據(jù)中。理想情況下，這些配置可被單獨修改的最低層的項目例如，應(yīng)用代碼塊或硬件組件。然而在問題識別階段對于有問題的配置項的識別達到這個層次經(jīng)常是不可能的。1.6.2 問題的分級當(dāng)問題被識別時，需要較大的努力來檢測和恢復(fù)斷定存在故障的配置項。因此意識到問題對既有服務(wù)水平的影響是很重要的。這個流程被稱為“分級”（classification）。在實踐中，支持努力被分配到連接到單個事故的小面積的問題上。問題分級的步驟類似于事故分級的步驟，這些步驟決定：v 類別v 影響v 緊急程度v 優(yōu)先級問題被歸類到相關(guān)的組或域（例如硬件、軟件、支持軟件以及相應(yīng)的其它種類）。這些組能夠與機構(gòu)的職責(zé)匹配，或者以用戶和客戶為基礎(chǔ)歸類，是將問題分配給支持職員的基礎(chǔ)。附錄A給出一個簡單但對問題歸類有效的結(jié)構(gòu)。新問題的識別應(yīng)該在受其影響的對象（也就是它對業(yè)務(wù)的影響）分析之后。登記在CMDB中的IT基礎(chǔ)架構(gòu)中的組件間的關(guān)系有助于判斷問題的影響。組織應(yīng)該根據(jù)它們的業(yè)務(wù)需要設(shè)計自己的影響代碼系統(tǒng)。影響代碼對于有效地分配支持力度是最有用的機制。更進一步包括優(yōu)先級、從屬影響，提供了全面的控制機制。當(dāng)判斷問題的影響時，登記在CMDB中的IT基礎(chǔ)架構(gòu)中組件間的關(guān)系是個極大的幫助。通過查詢CMDB，可能識別事故涉及到IT基礎(chǔ)架構(gòu)中的配置項，以及同樣的或依賴的配置項。緊急程度是指問題或錯誤的解決所能承受的延遲程度，它不應(yīng)該與優(yōu)先級混淆。優(yōu)先級指明一系列項目無論是事故、問題、變更或錯誤應(yīng)該被解決的相應(yīng)次序。這會受到風(fēng)險的考慮和資源可用性的影響，但更主要地是由緊急程度和影響的組合來決定。盡管較低的業(yè)務(wù)影響，但要求緊急解決的事情經(jīng)常要放在較高的潛在業(yè)務(wù)影響但較低的緊急程度的事情之前處理。為每個方面分配數(shù)字值有幫助的，由此衍生出數(shù)字優(yōu)先級，但是，對于所有的服務(wù)管理，這樣的數(shù)字是憑人的直覺和業(yè)務(wù)意識來修改的。然而，對每個問題的緊急程度和影響賦予14的數(shù)值，對它們求和給出相應(yīng)的優(yōu)先級，是一個簡單而實用的起點。那樣做了，組織應(yīng)該精密地監(jiān)控和檢查計算出的優(yōu)先級，監(jiān)控對應(yīng)需求的功能。影響緊急程度的方面如：v 臨時修復(fù)的可用性；v 存在臨時措施；v 計劃推遲解決的可能性；v 對業(yè)務(wù)未來影響的意識，如支持月末處理的設(shè)備需求。每個事故、問題和變更將都會對業(yè)務(wù)服務(wù)和緊急程度有影響：v 影響描述了業(yè)務(wù)受到破壞的可能；v 緊急程度表明了可用來轉(zhuǎn)移或降低影響的時間。* 要點在最早的時機為所有問題分配影響代碼。當(dāng)這項工作完成后，重要的是在詳細調(diào)查開始前，使所有問題歸屬到被管理的職員分配流程。被分配的人負責(zé)問題的解決，成為協(xié)調(diào)問題解決活動的中心。根據(jù)影響計劃工作量，重要問題要立即引起注意。對低影響的問題可以允許超出特定的時間限制。影響分析流程遭遇一個重大的約束：它只反映當(dāng)時的看法。雖然一個問題被正確地分配了低影響代碼，但接下來屬于該問題的事故數(shù)量陡然上升可能要求這個問題需要立即引起注意。需要設(shè)置事故限制來解決這個困難。如圖3所示，問題管理流程被設(shè)計要維護與問題（和知名錯誤）記錄匹配的事故的數(shù)量。問題和錯誤控制系統(tǒng)周期性掃描這個數(shù)值，將它與預(yù)先定義的限制值比較。當(dāng)數(shù)量等于或超出這個限制，這樣的問題/知名錯誤應(yīng)該被升級到立即注意。然而，注意數(shù)量并不總是等于重要：當(dāng)你發(fā)現(xiàn)訂單不能輸入超過$999,999.99的值，即使這樣的情況只有0.5%，也必須被看做是關(guān)鍵的問題。1.6.3 問題調(diào)查和診斷問題調(diào)查流程類似于事故調(diào)查流程但是這兩個流程的基本目標明顯不同。事故管理的目的是迅速恢復(fù)服務(wù)，而問題管理的目的是診斷出底層原因。調(diào)查活動應(yīng)該包括與該問題相關(guān)事故可用的臨時措施，它登記在事故記錄數(shù)據(jù)庫。問題管理活動還包括更改問題記錄中推薦的臨時措施，以支持事故控制。診斷結(jié)果經(jīng)常表明問題的原因不是登記的配置項（硬件、軟件、文檔或程序）的錯誤，而是過程上的。例如，發(fā)布的程序版本不正確。這種情況下，問題以適當(dāng)?shù)姆诸惔a來關(guān)閉，但不會達到有知名錯誤的狀態(tài)。為了確保這類問題有章可循，采取措施解決它們，考慮為這種過失過程創(chuàng)建虛構(gòu)的配置項，作為一個知名錯誤重新分級問題，或產(chǎn)生變更請求。診斷揭示了原因是登記的配置項的錯誤，這時應(yīng)該自動將問題的狀態(tài)轉(zhuǎn)成知名錯誤，由錯誤控制系統(tǒng)和過程接管。正如前面所指出的，問題調(diào)查的目標經(jīng)常會與事故解決的目標相沖突。例如，問題調(diào)查可能要求詳細的診斷數(shù)據(jù)，這些數(shù)據(jù)只有在事故出現(xiàn)時才能得到，而獲得這些數(shù)據(jù)可能會明顯地推遲正常服務(wù)的恢復(fù)。確保將事故控制與計算機操作或網(wǎng)絡(luò)控制功能緊密聯(lián)系，對于此類的活動給予適當(dāng)?shù)臅r間平衡。1.6.4 問題分析的方法一些文獻對于結(jié)構(gòu)化問題分析和診斷提供了許多方法。這樣的文獻有：v Kepner and Tregoe (參見附錄B) v Ishikawa diagrams (參見附錄C) v 頭腦風(fēng)暴會話v 流程圖方法 問題管理應(yīng)該選擇最適合本組織目的的方法。1.6.5 問題控制的要點以下是在問題控制中值得記住的要點：v 事故分類是向問題定義發(fā)展的第一步，因此問題管理應(yīng)該與事故管理緊密關(guān)聯(lián)，考慮建立公用的事故和問題分類。對于報告的事故以及最終檢測的原因應(yīng)該給予適當(dāng)?shù)姆诸悾鹿史诸悜?yīng)該用“客戶術(shù)語”，而檢測的原因歸類用“IT術(shù)語”來表達。v 如果可能的話，建立具有不同經(jīng)驗的人的小組，例如問題管理，在調(diào)查的時候，大家盡可能從不同的角度來參與。v 為了參與的支持專家能夠有效地執(zhí)行他們的任務(wù)，確保他們有合適的工具和診斷協(xié)助工具。v 如果問題不是由系統(tǒng)組件中的錯誤引起的，而是由于沒有對用戶培訓(xùn)引起的，解決并關(guān)閉問題記錄。另外，創(chuàng)建新的配置項記錄在這個例子中是“培訓(xùn)問題”按照通常的方法將問題轉(zhuǎn)化為知名錯誤。確保檢測的原因反映實際狀況，例如，缺乏用戶知識培訓(xùn)。v 在事故或問題控制流程的診斷過程中，要求IT基礎(chǔ)架構(gòu)中的所有產(chǎn)品的文檔可用，以支持職員在處理過程中作為參考。這些文檔包括：u 應(yīng)用系統(tǒng)u 系統(tǒng)軟件u 內(nèi)部工具程序u 網(wǎng)絡(luò)硬件和軟件u 全局配置/網(wǎng)絡(luò)圖表v 除了產(chǎn)品信息，具有有效的過程來收集診斷以解決問題也是必要的。支持職員熟悉這些過程特別重要，因為在事故處理的過程中不適當(dāng)?shù)氖褂脮七t正常IT服務(wù)的恢復(fù)。因此需要這些過程來支持和加強流程的需求這些過程可能包括適當(dāng)?shù)呐嘤?xùn)、認證等。v 支持專家會經(jīng)常同時參與事故管理流程和問題管理流程，切記這兩個流程的目標不同（快速解決對結(jié)構(gòu)化解決），在這兩個流程中，將專家的時間按固定的百分比分配證明是有用的，可能是事故管理占80%，問題管理占20%。這可以防止支持專家完全陷入被動事故管理。v 在事故和問題的診斷過程中，問題管理職員也要求精確地記錄最近的變更，因為這些可能是問題的原因。1.7 錯誤控制的活動錯誤控制包括了成功地糾正知名錯誤的流程。其目標是變更IT組件，消除影響IT基礎(chǔ)架構(gòu)中知名錯誤，防止事故的重復(fù)發(fā)生。許多IT部門關(guān)注于生產(chǎn)環(huán)境和開發(fā)環(huán)境的錯誤控制，它直接與變更管理流程接口。圖4示例了錯誤控制的三個階段。監(jiān)控和跟蹤階段包括全部的問題/錯誤生命周期。圖4 錯誤控制1.7.1 錯誤識別和記錄當(dāng)有故障的配置項（引起或可能引起事故的配置項）被檢測到就識別了錯誤。當(dāng)問題的根本原因被發(fā)現(xiàn)就被賦予知名錯誤的狀態(tài)，同時開發(fā)臨時措施。流入錯誤控制系統(tǒng)的知名錯誤有兩個來源，一個是生產(chǎn)系統(tǒng)中的問題控制子系統(tǒng)，另一個是相應(yīng)的開發(fā)環(huán)境。在生產(chǎn)操作中發(fā)現(xiàn)的錯誤，就如在問題控制活動調(diào)查和診斷中所描述的，被識別和記錄。在這種情況下，問題記錄形成了知名錯誤記錄的基礎(chǔ)（事實上，它確實只是狀態(tài)的改變）。知名錯誤的第二來源是開發(fā)活動。例如，新應(yīng)用或打包發(fā)布的實施可能包括了在開發(fā)階段形成的已知但未解決的錯誤。當(dāng)應(yīng)用或發(fā)布包實施時，來自于開發(fā)的知名錯誤相關(guān)的數(shù)據(jù)應(yīng)該對生產(chǎn)環(huán)境的管理人員可用。許多IT部門參與過這樣一系列事件。問題管理系統(tǒng)應(yīng)該記錄所有解決活動，向支持職員提供監(jiān)控與跟蹤工具。也應(yīng)該提供全面的審計記錄，從事故到問題、到知名錯誤、到變更請求或重大變更實施。1.7.2 錯誤評估問題管理職員協(xié)同專業(yè)職員，對解決錯誤的方法進行初始的評估。如果必要，接下他們根據(jù)變更管理過程，完成變更請求。變更請求的優(yōu)先組根據(jù)錯誤在業(yè)務(wù)上的緊急程度和影響來決定。變更請求的標識符應(yīng)該被包括在知名錯誤記錄中，以便維護一個完全的審計路徑，或者將兩者連接。錯誤解決的最終進程影響分析、需要執(zhí)行的解決步驟的詳細評估、配置項錯誤的改正、變更的測試要在變更管理的控制下執(zhí)行。在極端情況下，緊急的解決方案，進行授權(quán)執(zhí)行是必要的。* 第三方產(chǎn)品中的錯誤賣方維護的產(chǎn)品中的問題可能被問題管理或?qū)＜抑С中〗M識別，應(yīng)該向賣方支持的負責(zé)人報告。應(yīng)該監(jiān)控賣方支持，確保在合理的時間內(nèi)收到對問題報告的響應(yīng)。在設(shè)置了軟件維護的目標諸如修復(fù)的合理和最長時間，以及IT基礎(chǔ)架構(gòu)相關(guān)的可靠性和可服務(wù)性應(yīng)該在合同或許可條件中明確，應(yīng)該由第三方發(fā)起補救措施，以免受到抱怨。當(dāng)購買軟件時，特別是在業(yè)務(wù)上具有競爭的情況下，明確維護目標的可能性應(yīng)該具備。注意解決軟件錯誤的必要的變更歸屬于變更管理，與內(nèi)部產(chǎn)品一樣。* 軟件環(huán)境中的錯誤控制在生產(chǎn)環(huán)境和開發(fā)環(huán)境中的問題和錯誤控制流程在本質(zhì)上是一樣的。前面對生產(chǎn)環(huán)境中的問題管理所描述的支持工具，也適合于開發(fā)環(huán)境中所要求的。圖5顯示了在生產(chǎn)和開發(fā)環(huán)境中的錯誤控制間的循環(huán)關(guān)系。協(xié)同集成的問題管理系統(tǒng)促進這種情況的處理。圖5 生產(chǎn)與開發(fā)環(huán)境中的錯誤周期在生產(chǎn)運營期間發(fā)現(xiàn)的錯誤導(dǎo)致變更求的積累，發(fā)布策略（參見發(fā)布管理）允許最終創(chuàng)建一個發(fā)布協(xié)同授權(quán)的變更修正系統(tǒng)中的錯誤。開發(fā)職員應(yīng)該注意與打包發(fā)布相關(guān)的所有知名錯誤和問題，當(dāng)知名錯誤被改正后要求被刪除，加入到修訂的錯誤數(shù)據(jù)庫（或CMDB）。當(dāng)完成新的發(fā)布，這個修訂的錯誤數(shù)據(jù)庫替換以前版本的數(shù)據(jù)庫作生產(chǎn)版本。當(dāng)新的錯誤在生產(chǎn)運營中被發(fā)現(xiàn)，重復(fù)這個周期。1.7.3 記錄錯誤解決方案每個知名錯誤的解決過程應(yīng)該記錄在問題管理系統(tǒng)。與所有知名錯誤相關(guān)的配置項數(shù)據(jù)、癥狀、解決方案或防止措施保存在知名錯誤數(shù)據(jù)庫是很關(guān)鍵的。這些數(shù)據(jù)對于事故匹配、在將來的診斷解決事故以及防止事故方面提供指導(dǎo)、提供管理信息等方面都是有用的。1.7.4 關(guān)閉錯誤在成功地實施變更解決錯誤后，相應(yīng)的知名錯誤記錄被關(guān)閉，同時任何相關(guān)的事故或問題記錄也一起被關(guān)閉?？梢钥紤]在事故、知名錯誤和問題記錄中插入一個中間狀態(tài)“關(guān)閉但未進行實施后評價（Closed pending PIR）”，確保修正已經(jīng)實際起作用。實施后評價（Post-Implementation Review,PIR）能確認最終關(guān)閉前解決的效果。對于事故，除了打電話給用戶確保他們已經(jīng)滿意就沒有別的了，對于嚴重的問題和知名錯誤，要求進行正式的評價。1.7.5 監(jiān)控問題/錯誤的解決變更管理負責(zé)處理變更請求，同時錯誤控制負責(zé)監(jiān)控解決知名錯誤的進展。在整個的解決過程中，問題管理應(yīng)該從解決問題和錯誤的變更管理進展中獲得日常報告。問題管理應(yīng)該監(jiān)控問題和知名錯誤對用戶服務(wù)的持續(xù)影響。在影響變得嚴重的事件中，問題管理應(yīng)該升級問題，可能要咨詢變更咨詢委員會提升變更請求的優(yōu)先級，在適當(dāng)?shù)臅r候?qū)嵤┚o急變更。問題解決的進展應(yīng)該結(jié)合SLA一起被監(jiān)控。典型地，SLA規(guī)定在每個測量間隔內(nèi)（一般為四周）在每個嚴重級別上不應(yīng)該有特定數(shù)量的突出錯誤。如果在某個嚴重級別上問題或錯誤的數(shù)量達到預(yù)先定義的限制，可能引起與SLA的不一致，就必須升級。1.7.6 錯誤控制的要點在錯誤控制中切記以下要點：v 不是所有的知名錯誤需要被解決。組織能夠決定允許保留知名錯誤例如，因為解決的成本太高、技術(shù)上不可能或要求太多的時間來解決。實踐中，錯誤控制關(guān)注于選擇合理的投資來解決問題；v 準備變更請求是錯誤控制的責(zé)任之一。解決方法經(jīng)常是技術(shù)上的調(diào)整，但不要忘記，變更請求也可能需要包括對過程、工作方法和/或組織結(jié)構(gòu)的修正；v 對于日常的硬件故障，考慮根據(jù)特定的設(shè)備或設(shè)備分類創(chuàng)建標準的錯誤記錄。使用這些來維持對故障鑒定的快速指導(dǎo)盡管多數(shù)信息（例如故障和宕機間的平均時間）來自于事故數(shù)據(jù)；v 許多硬件故障的糾正在事故控制下執(zhí)行，并不通過錯誤控制和變更管理。然而對硬件規(guī)格的任何改變應(yīng)該從屬于正常的變更管理過程；v 理想情況下，應(yīng)該在生產(chǎn)和開發(fā)環(huán)境中的事故、問題和錯誤控制中使用公用工具。如果因為在開發(fā)環(huán)境使用特定的CASE工具而使這不可能，那么設(shè)計和開發(fā)一個可行的轉(zhuǎn)移機制是必要的；v In practice, the level of detail usually required for development Configuration Management often precludes a viable shared system. The key thing is to share the data, especially in terms of passing to the live environment information on Problems, Known Errors and ongoing Changes that are being handed over with any new or changed software. 1.8 主動問題管理迄今為止在問題和錯誤控制中所描述的活動主要是被動的。主動問題管理活動涉及到在事故出現(xiàn)前識別和解決問題和知名錯誤，這樣最小化對服務(wù)的不利影響，最小化業(yè)務(wù)相關(guān)的成本。問題防止的范圍從單個問題的防止到策略的決定。后者可能要求較大的開銷來實施，例如投資優(yōu)化網(wǎng)絡(luò)。問題防止也包括向客戶提供信息以消除將來請求幫助的需求。問題分析集中在為問題解決人員提供改進的建議，例如，在線技術(shù)工具的提供減少了解決問題花費的時間，因此使電話時間的長度明顯減短。主動問題管理流程中的主要活動是趨勢分析和定位防止措施。1.8.1 趨勢分析事故和問題的分析報告為采取主動措施提高服務(wù)質(zhì)量提供信息。其目標是識別IT基礎(chǔ)架構(gòu)中“脆弱”的組件，調(diào)查其脆弱的原因在這里“脆弱”是相對于如果配置項出錯對業(yè)務(wù)的影響而言的。事故和問題分析能夠識別：v 趨勢，諸如特定問題類型變更后出現(xiàn)的情況；v 特定類型的初期故障；v 特定類型或某個配置項重復(fù)出現(xiàn)的問題；v 客戶對培訓(xùn)的需求或?qū)Ω梦臋n的需求；事故和問題的分類，以及積極的分析可以揭露趨勢，識別出需要進一步調(diào)查的特定（或潛在）的問題區(qū)域。例如，分析可能指出與最近安裝的客戶服務(wù)器系統(tǒng)相關(guān)的事故是個問題區(qū)域，對客戶業(yè)務(wù)的負面影響增長最快。分析例如對來自系統(tǒng)管理工具的事件的分析，對文獻的分析，對來自用戶組的討論和反饋的分析也能夠揭示可能的問題，需要進一步的調(diào)查。組織與重要客戶的討論會或進行客戶調(diào)查也能識別趨勢和（潛在的）問題區(qū)域。問題管理數(shù)據(jù)的分析可以揭示：v 在一個平臺出現(xiàn)的問題可能在另一個平臺出現(xiàn)例如，在一個中型系統(tǒng)上的網(wǎng)絡(luò)軟件的問題也可以是主機系統(tǒng)上的明顯的問題；v 存在重復(fù)出現(xiàn)的問題例如，如果因為同樣的故障，三個路由器被連續(xù)替換，它可能表明這種路由器類型不合適，應(yīng)該用另一種類型替換，或者當(dāng)or when a software application is involved then complete redevelopment might be necessary which would be classed as a major Change. 1.8.2 定位防止措施趨勢分析能夠識別IT基礎(chǔ)架構(gòu)中的故障，接下來正如在問題和錯誤控制中所描述的能夠被分析和糾正。趨勢分析也能夠識別需要支持人員注意的問題區(qū)域。按照組織的財務(wù)成本來表達，可以做出有意義的比較。為了將不足的資源最有效地用于服務(wù)支持（從中獲得最大的業(yè)務(wù)利益），調(diào)查哪個問題區(qū)域最需要支持人員注意是值得的。對于主動問題管理，這是個典型的任務(wù)。為了能夠估計特定問題區(qū)域的事故對業(yè)務(wù)的影響，事實證明引入事故的“pain factor”這個概念作為衡量是很有用的。使用這個概念，對每個事故分類給予一個pain value作為公式的基礎(chǔ)，用于記帳，例如：v 事故的數(shù)量v 受影響的客戶數(shù)量v 解決事故的持續(xù)時間和相關(guān)的成本v 業(yè)務(wù)成本這可能是所有因素中最重要的這個方法避免將精力集中放在這樣一組事故上，相對而言數(shù)量較大，而對提供的服務(wù)水平?jīng)]有較高的影響；相反地，將精力放在調(diào)查一小組而更有益的事故上，它可能對組織的業(yè)務(wù)有很高的影響。在需要注意的問題區(qū)域被識別后，問題管理應(yīng)該啟動適當(dāng)?shù)拇胧＿@些措施包括：v 提出變更請求v 提供關(guān)于測試、過程、培訓(xùn)和文檔的反饋v 啟動客戶教育和培訓(xùn)v 啟動服務(wù)支持職員教育和培訓(xùn)v 確保問題管理和事故管理過程相連接v 改進流程或過程1.8.3 主動問題管理的要點下面的要點值得注意：v 當(dāng)積累了充分的歷史數(shù)據(jù)，在配置項的強壯度方面的趨勢分析才會有增值；v 來自許多廠商的操作系統(tǒng)的操作報告提供了系統(tǒng)中固有問題的信息。這些報告應(yīng)該經(jīng)常檢查，以便在問題出現(xiàn)前識別潛在的硬件問題。理想情況下，提供商職員應(yīng)該做這項工作（可能通過遠程的方式），但是在任何事件中，還是由問題管理負責(zé)確保完成這項工作。這些報告能夠用于在硬件配置項實際出現(xiàn)故障前，引發(fā)對它們的修復(fù)和替換；v 主動問題管理不必作為一個全職的任務(wù)，對于較小的IT服務(wù)組織，每半年分配一個支持專家兩周的時間來分析事故和問題數(shù)據(jù)，再花兩周的時間啟動變更請求，這就足夠了。1.8.4 主要問題回顧當(dāng)每個主要問題的解決完成后，問題管理應(yīng)該完成主要問題的回顧。解決過程中參與的適當(dāng)?shù)娜艘黄饋砘仡櫍_定：v 哪些做得正確；v 哪些做得錯誤；v 哪些能夠下次做得更好；v 怎樣防止問題再次發(fā)生。1.9 向支持部門提供信息問題管理提供有關(guān)識別的問題、知名錯誤和發(fā)出的變更請求的信息。這些信息可以是隨機的或周期性的。這些信息和報告經(jīng)常是為了在管理中監(jiān)控問題管理流程的質(zhì)量。然而，提供給業(yè)務(wù)和IT管理的報告也有助于組織內(nèi)的決策支持。除此之外，報告也可以傳遞給其它流程和服務(wù)臺。1.9.1 提供管理信息管理信息應(yīng)該使了解組織花費在調(diào)查、診斷和解決問題及知名錯誤上的努力和資源。除此，了解到問題處理的進展和結(jié)果也是很重要的。度量方式必要仔細地選擇，只有通過仔細和有目的的度量才能形成關(guān)于流程質(zhì)量的意見。1.9.2 將信息分級臨時措施、永久修正或關(guān)于解決進展的簡要信息應(yīng)該分級給報告問題的人。這些信息也必須分級給其它客戶，因為影響許多人的問題可能僅由一個人報告。傳播這些信息是服務(wù)臺的基本任務(wù)。問題管理應(yīng)該為此向服務(wù)臺提供充分的信息和支持。通過將這些信息輸入到既有的服務(wù)管理工具和數(shù)據(jù)庫，問題管理能夠發(fā)布相應(yīng)的信息給服務(wù)臺和支持部門。為了有效地傳播信息，問題管理流程應(yīng)該訪問配置管理信息，諸如，誰在使用什么，什么時候使用，他們處在什么位置，加上所有必要的聯(lián)系人明細。問題管理要求的某些明細能夠從事故管理流程的電話記錄中的獲得，然而，對于問題管理，在問題出現(xiàn)前，使用約定的聯(lián)系地圖和正式的溝通渠道經(jīng)常是更有效果。這種類型的信息也經(jīng)常在協(xié)商（或重協(xié)商）SLA的時候獲得。另一個來源是日常服務(wù)回顧，它是服務(wù)水平管理的一部分。1.10 度量通過維護來自事故控制和問題/錯誤控制的信息，從而可能得到表示服務(wù)質(zhì)量和流程效率的度量標準。1.10.1 問題/錯誤控制報告關(guān)于這方面的管理信息包括：v 提出的RFC的數(shù)量以及這些RFC在涉及到的服務(wù)的可用性和可靠性方面的影響；v 根據(jù)問題類型劃分，每個部門或廠商花費在調(diào)查和診斷上的時間；v 在根本問題被關(guān)閉或知名錯誤被確認前，事故發(fā)生的數(shù)量和影響；v 在問題管理中，被動的支持效果與計劃的支持效果的比率；v 解決問題的資源規(guī)劃：u 人u 其它使用的資源u 成本（相對于預(yù)算）v 所采取行動的簡單描述關(guān)于IT基礎(chǔ)架構(gòu)中不牢固的組件的信息、違背與業(yè)務(wù)協(xié)定的服務(wù)水平的信息以及與廠商定的服務(wù)水平信息都涉及到可用性管理。問題出現(xiàn)的頻度和持續(xù)時間是相對于服務(wù)水平的效率的度量標準。要求的信息包括：v 根據(jù)以下方面劃分的問題和錯誤的數(shù)量：u 狀態(tài)u 服務(wù)u 影響u 分類u 用戶組v 關(guān)閉問題上花費的全部時間；v 重大問題花費的時間；v 從產(chǎn)生問題記錄開始，到關(guān)閉問題或確認知名錯誤，花費的平均時間和最長時間，可以根據(jù)影響代碼和支持組（包括提供商）劃分；v 任何臨時解決行動；v 重大問題期望的解決時間；定期審計流程要求要求對所有操作和過程進行定期審計。審計的目的是確認問題管理和支持小組執(zhí)行了預(yù)定義的過程。審計應(yīng)該分析主要的問題回顧，檢查：v 根據(jù)協(xié)定的計劃產(chǎn)生和分析報告；v 具有代表性的事故例子，校驗相關(guān)的問題已經(jīng)被正確地識別和記錄；v 具有代表性的問題例子，校驗問題被正確診斷，而且是在規(guī)定的時期內(nèi)；v 具有代表性的知名錯誤的例子，校驗知名錯誤已經(jīng)被授權(quán)的對配置的變更所清除，并且在規(guī)定的時期內(nèi)；v 升級的限制被堅持執(zhí)行；v 文檔被正確地維護由問題管理職員更新，被接收的人執(zhí)行；v 管理報告有規(guī)律地生成，并且有明確的目的；v 對于趨勢分析表明的跡象，采取了防止措施；v 職員培訓(xùn)記錄。1.10.2 度量的要點下面是有關(guān)度量的要點：v 在制定規(guī)范期間，為流程定義想要達到的效果的度量。計劃在問題管理運營開始的時候使用它們作為控制，以評估效果，并客觀地估計趨勢。如果可能的話，提前或都在運營開始的前幾周設(shè)置實際的目標。如果可能，還可以從當(dāng)前支持活動中獲得統(tǒng)計數(shù)據(jù)，作為設(shè)置目標的基礎(chǔ)。這些有助于以后鑒定引入問題管理后所增加的益處；v 不要設(shè)置不可衡量的目標；v 當(dāng)購買支持工具時，在產(chǎn)品評估和系統(tǒng)設(shè)計階段，拿相應(yīng)的度量來估計，盡量獲得能夠提供必要統(tǒng)計的工具；v 對于關(guān)鍵效果標準，開發(fā)生產(chǎn)報表的過程。問題管理應(yīng)該有規(guī)律地（如一月一次）將實際達到的效果與所有設(shè)置的目標比較回顧。記錄每次回顧的結(jié)果，以用于審計。如果目標必須降低，要確認原因是目標太高，而實際運營太差。問題管理運營中的任何不足應(yīng)該被回溯，使之在源頭恢復(fù)正常；v 規(guī)劃設(shè)立正式的流程效果和效率的回顧，特別注意客戶的需求。確保運營中的流程能夠滿足所有支持需求；v 規(guī)劃逐步設(shè)置更困難的目標，這要與引入問題管理流程預(yù)期的益處一起考慮；v 監(jiān)視成功的問題管理系統(tǒng)對職員工作量的影響，經(jīng)驗表明有效的流程，特別是再加上有效的變更管理和發(fā)布質(zhì)量控制，迅速地降低了事故和問題的影響范圍。事故數(shù)量的降低，以及由此來的支持請求的減少，導(dǎo)致了職員人數(shù)的下降。新的應(yīng)用和新的用戶會增加問題和事故，因此，問題管理應(yīng)該被告知任何影響工作量的預(yù)期的變更，以便做