【文章內(nèi)容簡介】 突發(fā)事件管理的目標是盡可能迅速地根據(jù) SLA 中定義的普通服務(wù)級別作出 反應(yīng)， 使產(chǎn)生問題后對業(yè)務(wù)行為及組織和用戶的影響最小。突發(fā)事件管理也應(yīng)該 保留對事件的有效記錄，以便于衡量和改進流程，并向其它流程匯報。 突發(fā)事件流程如下圖所示：第 11 頁XX 技術(shù)有限公司問題管理對于突發(fā)事件有兩種處理方法，一種是對其做出服務(wù)快速響應(yīng)，盡快恢復其 正常運行，另一種是鑒別和解決問題根源。這兩種方法之間存在微妙的區(qū)別，而 且經(jīng)常被互相混淆。對其做好區(qū)分具有重要意義。 如果問題被懷疑存在于 IT 架構(gòu)內(nèi)部， 問題管理流程將會瞄準其潛在的根源。 一個問題可能是被突發(fā)事件暴露出來的，但是顯然，問題管理的目標是解決問題 根源，預(yù)防其可能產(chǎn)生的干擾，而不是迅速恢復系統(tǒng)運行。 當問題被識別后(被識別的問題通常稱之為已知錯誤)，通常需要進行一個業(yè) 務(wù)決策， 決定是否采取永久性措施改進系統(tǒng)架構(gòu)， 以預(yù)防再次發(fā)生新的突發(fā)事件。 如果需要，提交一個變更請求來實現(xiàn)改進。 為了有效和高效地識別突發(fā)事件背后的問題根源及其發(fā)展趨勢， 問題管理流第 12 頁XX 技術(shù)有限公司程需要準確全面的突發(fā)事件的記錄。 問題管理流程同樣需要和可用性管理流程密 切聯(lián)絡(luò)，以確定這些趨勢并明確補救措施的重要性。 流程：配置管理配置管理致力于控制一個變化中的 IT 架構(gòu)(標準化和狀態(tài)監(jiān)控)，鑒別配置 項目(清冊，相互關(guān)聯(lián)，審核與注冊)，收集和管理有關(guān) IT 架構(gòu)的文檔，為所有 其它流程提供 IT 架構(gòu)的相關(guān)信息。 配置管理是所有其它服務(wù)管理流程不可分割的一部分。 擁有當前架構(gòu)中所有 部件的最新的，準確的，全面的和詳細的信息，并管理其變更，使這些信息有效 而高效地支持其它流程運行。變更管理可以與配置管理集成。至少，建議在配置 管理系統(tǒng)中控制變更的登錄和實施， 并自在配置管理系統(tǒng)的幫助下對變更影響做 出評估。因此所有變更請求應(yīng)該被輸入配置管理數(shù)據(jù)庫(CMDB)，并隨著變更請 求的進展隨時更新記錄，直至其實施。 配置管理系統(tǒng)識別一個變更項目和架構(gòu)中其它部件的關(guān)系， 將這些部件的所 有人召集到影響評估流程中來。 不管一個變更是否在架構(gòu)中實施，相互關(guān)聯(lián)的配 置管理記錄應(yīng)該在 CMDB 中得到更新。最好在變更發(fā)生時，使用集成工具自動 地更新記錄。第 13 頁XX 技術(shù)有限公司CMDB 應(yīng)該開放給整個服務(wù)支持組，使所有人理解部件失效可能的原因， 從而使突發(fā)事件和問題可以被更容易地解決。CMDB 還應(yīng)當被用來把突發(fā)事件 及問題記錄和其它記錄聯(lián)系起來，比如失效的配置項目(ConfigurationItemCI)和 用戶之間的聯(lián)系。如果缺少了配置管理流程的集成，發(fā)布管理將難以實現(xiàn)，并可 能錯誤連連。 服務(wù)交付流程同樣依賴于 CMDB 中的數(shù)據(jù)。例如： 服務(wù)級別管理需要識別相互結(jié)合在一起的部件，并在此基礎(chǔ)上設(shè)置支持協(xié) 議，交付服務(wù)。 IT 財務(wù)管理需要知道每個業(yè)務(wù)部門使用的 IT 架構(gòu)部件，尤其是對于收費的 項目。 IT 服務(wù)持續(xù)性和可用性管理需要識別部件，用于問題風險分析和部件失效 影響分析。 下圖顯示了配置管理和其它服務(wù)管理流程之間的關(guān)系：圖：能力管理，變更管理，配置管理和發(fā)布管理之間的關(guān)系變更管理變更管理專注于對 IT 架構(gòu)實施可控的變更。此流程的目標是確定所需的變 更，并決定這些變更如何在對 IT 服務(wù)產(chǎn)生最小的不利影響的范圍內(nèi)得以實施。第 14 頁XX 技術(shù)有限公司同時確保其變更是可追溯的， 而且是經(jīng)過整個組織內(nèi)部有效地磋商和協(xié)調(diào)的。在 客戶組織提交變更請求后， 由配置管理流程監(jiān)控其狀態(tài)，與問題管理和若干其它 流程進行協(xié)調(diào)。變更實施履行一特定的路徑，包括定義，計劃，建立，測試，接 受，實施，和評估。 變更管理流程依賴于配置數(shù)據(jù)的準確性，以確保獲知所有實行 變更造成的影響。因此變更管理與配置管理之間有密切的聯(lián)系。 變更流程的詳細內(nèi)容應(yīng)在 SLA 中存檔， 確保用戶知道提交變更申請的程序， 項目目標及時間，以及實施變更造成的影響。 變更的詳細內(nèi)容需要通知服務(wù)臺。即使變更經(jīng)過了全面測試，仍然很有可能 存在實施變更的過程中發(fā)生各種困難， 這些困難可能緣于變更沒有按需求或預(yù)期 運行，或者對變更對功能造成的影響產(chǎn)生質(zhì)疑。 變更咨詢會議(ChangeAdvisoryBoardCAB)由可向變更管理小組提供專家意 見的人員組成。這個會議很可能由來自于所有領(lǐng)域的 IT 及業(yè)務(wù)單位的人參與。發(fā)布管理發(fā)布是指一組配置項目(ConfigurationItems–CI)經(jīng)過測試被引入處于活動狀 態(tài)的環(huán)境中。 發(fā)布管理的主要目標是確保發(fā)布信息被成功地公布， 包括歸納綜合，第 15 頁XX 技術(shù)有限公司測試與存檔。 發(fā)布管理確保只有經(jīng)過測試和正確授權(quán)的軟硬件版本才能提供給 IT 運行環(huán) 境。 發(fā)布管理與配置管理和變更管理的行為密切相關(guān)。真實的變更實施經(jīng)常通過 發(fā)布管理行為得以貫徹。 變更的結(jié)果可能經(jīng)常來自于新硬件，新版本軟件，以及新的文檔(自行建立， 或購買而來)等。對它們進行控制，并打包和頒發(fā)。有關(guān)存檔安全和公布程序應(yīng) 該和變更管理和配置管理流程緊密集成。 發(fā)布的程序也可能作為突發(fā)事件管理和 問題管理流程中不可分割的一部分，同時還和 CMDB 密切相連，以維護及時更 新的記錄。 服務(wù)提供服務(wù)提供主要包括：服務(wù)級別管理、IT 服務(wù)財務(wù)管理、能力管理、持續(xù)持 續(xù)管理、可用性管理等。第 16 頁XX 技術(shù)有限公司服務(wù)級別管理服務(wù)級別管理的目標是縷清與客戶之間有關(guān) IT 服務(wù)的協(xié)議，并付諸實施。 因此， 服務(wù)級別管理需要收集客戶需求， IT 服務(wù)組織可提供的設(shè)施，以及可 用的財務(wù)資源。 服務(wù)級別管理針對提供給客戶的服務(wù) (聚焦客戶的)。因此是基 于客戶需求建立服務(wù) (需求拉動)，而非單純基于現(xiàn)有技術(shù)所及(供應(yīng)驅(qū)動)，從 而使 IT 服務(wù)組織提高客戶滿意度。服務(wù)級別管理闡述的內(nèi)容有： ? 如何在服務(wù)級別協(xié)議(Service Level Agreement – SLA)中清楚地定 義條款， 使其可優(yōu)化 IT 服務(wù)成本， 并為用戶所接受。 ? ? 如何監(jiān)控和討論所提供的服務(wù)。 如何管理 IT 服務(wù)組織的供應(yīng)商及其下包合同。服務(wù)級別管理(Service Level Management －SLM)流程是用來確保服 務(wù)級別協(xié)議， 并支持運行級別協(xié)議及其它合同，保證所有對服務(wù)質(zhì)量的影響減少 到最小。此流程在服務(wù)質(zhì)量和 SLA 基礎(chǔ)上評估各種變更造成的影響，包含預(yù)期 變更前的影響， 也包含評估實施變更后的影響。SLA 中某些最重要的目標和服 務(wù)可用性、以及在容許周期內(nèi)對突發(fā)事件形成決策有關(guān)。 SLM 是服務(wù)支持和服務(wù)交付的關(guān)鍵。由于它依賴于其它流程的存在性， 有 效性及運行效率， 它不可孤立存在。一個缺乏基礎(chǔ)支持流程的 SLA 是沒有意義 的， 缺乏支持的 SLA 就失去了承認其內(nèi)容的基礎(chǔ)。IT 服務(wù)的財務(wù)管理財務(wù)管理針對于 IT 服務(wù)的謹慎從事。 例如， 當所提供的 IT 服務(wù)在進行中時， 財務(wù)管理將提供其導致的成本信息。 這樣使考慮 IT 架構(gòu)或 IT 服務(wù)的改變時， 能 夠合理地考慮成本和利益(價格和性能)之間的關(guān)系。財務(wù)管理中對成本的鑒別、 分配、預(yù)測和監(jiān)控使成本成為可知因素，減少成本和預(yù)算的差距。 重點結(jié)合 IT第 17 頁XX 技術(shù)有限公司服務(wù)組織的贏利， IT 服務(wù)的財務(wù)管理描述了多種支付方法，包括設(shè)立支付和定 價的目標，以及預(yù)算計劃。 財務(wù)管理負責對成本及 IT 服務(wù)投資回報的會計核算，并管理任何來自于客 戶的成本。財務(wù)管理需要與能力管理(Capacity Management)，配置管理 (Configuration Management，包含資產(chǎn)數(shù)據(jù))，以及 SLM 的良好接口， 來 確定服務(wù)的真實成本。 在 IT 組織預(yù)算談判階段和客戶的 IT 耗費核算階段， 財 務(wù)管理很可能與業(yè)務(wù)關(guān)系管理(Business Relationship Management)及 IT 組織密切相關(guān)。能力管理能力管理是優(yōu)化成本，獲得時間，以及開發(fā) IT 資源的流程，來支持與客戶 簽訂的服務(wù)條款。能力管理針對資源管理，性能管理，需求管理，建模，能力計 劃， 負載管理，以及應(yīng)用軟件能力推測。能力管理強調(diào)用計劃來確保所簽訂的 服務(wù)級別可以被履行和成長。 能力管理負責確保在所有時間具備足夠的可用能力，以滿足業(yè)務(wù)需求。 能 力管理不是簡單地與系統(tǒng)部件的性能相關(guān)， 而是直接與業(yè)務(wù)需求相關(guān)。 在那些 與能力問題相關(guān)的困難面前， 能力管理在突發(fā)事件決策和問題鑒別過程中被引 入。 能力管理提交變更請求以確保得到適當?shù)目捎媚芰Α?這些 RFC 被提交給變 更管理流程， 其實施可能影響若干 CI， 包括硬件， 軟件和文檔，并需要提供 有效的版本管理。 能力管理應(yīng)該在評估所有變更時被引入， 用來確定變更導致的在能力和性 能上的影響。 這種影響在變更實施前后都有可能出現(xiàn)。 能力管理應(yīng)該特別關(guān)注 變更在一定周期后引起的累積性變化。 容易被忽略的單個的變更往往在經(jīng)過累 積后， 引起響應(yīng)時間衰減， 文件存儲問題， 和對處理能力的過度需求。第 18 頁XX 技術(shù)有限公司IT 服務(wù)持續(xù)性管理此流程在業(yè)務(wù)中斷時對 IT 服務(wù)進行災(zāi)難恢復措施的準備和計劃。 業(yè)務(wù)持續(xù) 性管理為客戶組織遇到災(zāi)難時準備好緊急預(yù)案， 根據(jù)此預(yù)案采取與 IT 服務(wù)相關(guān) 的預(yù)防災(zāi)難發(fā)生的措施。 IT 服務(wù)持續(xù)性管理流程對技術(shù)， 財務(wù)和管理資源需 求做好計劃和協(xié)調(diào)， 確保災(zāi)難發(fā)生后可持續(xù)提供服務(wù)， 并就其內(nèi)容達成客戶同 意。 IT 服務(wù)持續(xù)性管理與一個組織在業(yè)務(wù)中斷后在某個可允許范圍內(nèi)繼續(xù)運作 的能力密切相關(guān)。 至少要保證最基本的業(yè)務(wù)運行所需要的 IT 服務(wù)， 預(yù)先對其 服務(wù)級別作出規(guī)定， 并和客戶達成一致。 有效的 IT 服務(wù)持續(xù)性需要一個平衡 的風險縮減措施， 例如有彈性的系統(tǒng)和備份恢復設(shè)施。 配置管理流程中的數(shù)據(jù) 被用來輔助其計劃和預(yù)防措施。 需要對架構(gòu)和業(yè)務(wù)變更對持續(xù)性計劃造成的潛 在影響進行評估。 有關(guān) IT 和業(yè)務(wù)的計劃應(yīng)該提交變更管理程序。 在持續(xù)性管 理流程中， 服務(wù)臺承擔著重要角色?？捎眯怨芾砜捎眯怨芾硎谴_保資源， 方法和技術(shù)得以適當拓展的流程， 以支持與客戶 簽訂的 IT 服務(wù)條款。 可用性管理針對所遇到的問題， 如優(yōu)化維護等， 并且設(shè) 計測量指標， 最大程度減少意外突發(fā)事件的數(shù)量。 可用性管理與 IT 服務(wù)的設(shè)計， 實施， 測量和管理相關(guān)， 確保規(guī)定的業(yè)務(wù) 需求中有關(guān)可用性的內(nèi)容被貫徹。 可用性管理需要理解 IT 服務(wù)失效發(fā)生的原因 和恢復服務(wù)所需的事件。 突發(fā)事件管理和問題管理提供了關(guān)鍵輸入 SLA 中描述的可用性的目標在可用性管理流程中被監(jiān)控， 并包含在其報表 中。 此外， 在支持服務(wù)核查制度所提供的測量和報表中， 可用性管理對服務(wù) 級別管理(SLM)流程提供了支持。第 19 頁XX 技術(shù)有限公司 運維服務(wù)管理規(guī)劃 第一階段：服務(wù)磨合階段第一階段，又稱為運維服務(wù)磨合階段，工作目標主要是通過服務(wù)管理，將客 戶現(xiàn)有的無序救火式突發(fā)事件服務(wù)有序化，實現(xiàn)突發(fā)事件管理，所有的突發(fā)事件 將運用技術(shù)、管理與流程相結(jié)合的方式，做到統(tǒng)一管理，統(tǒng)一任務(wù)分發(fā)，安排合 適的人員處理合適的事件。所有的突發(fā)事件全過程可控制、跟蹤、即時回饋，讓 每一個客戶能夠隨時查詢到事件處理過程，不會出現(xiàn)焦慮、服務(wù)要求長時間無人 響應(yīng)或服務(wù)要求根本無人響應(yīng)的情況， 從而提高客戶滿意度， 提高運行維護效率， 提高客戶使用業(yè)務(wù)信息系統(tǒng)的效率，從而做到提高總體生產(chǎn)力。第 20 頁XX 技術(shù)有限公司現(xiàn)今客戶大都沒有真正意義上的配置管理系統(tǒng)。配置管理系統(tǒng)，顧名思義， 含有業(yè)務(wù)信息系統(tǒng)及終端設(shè)備詳細清單，配置情況，針對于業(yè)務(wù)信息系統(tǒng)的操作 系統(tǒng)服務(wù)運行情況，終端運行軟件情況，使用軟件資產(chǎn)情況等，以及每一次配置 改變的記錄，做到配置的改變都有跡可查，將軟硬件資產(chǎn)系統(tǒng)化的管理起來。 用一句話概括我們上述兩項服務(wù)：將無序的突發(fā)事件有序化，將紙制的配置 管理信息化。就是我們突發(fā)事件管理以及配置管理的目標。 ITSM 所定義處理突發(fā)事件的工作目標是規(guī)避與盡快恢復。 運維服務(wù)的目標 不是盡可能多，盡可能快的完成服務(wù)，而應(yīng)該是盡量避免事件的發(fā)生，當然，這 不是一步可以到位的，因此，在第一階段，我們需要做到盡快恢復客戶的正常使 用，故：在處理突發(fā)事件時，我們不分析事件發(fā)生的原因，只收集有價值的事件 /故障信息，并在最短的時間內(nèi)將客戶的設(shè)備恢復到正常使用狀態(tài)。針對于重復/ 頻繁發(fā)生的突發(fā)事件，我們需要轉(zhuǎn)問題管理流程，予以處理。問題管理，也就是 事件的原因分析以及根除此事件的解決方法管理， 我們需要對突發(fā)事件發(fā)生的原 因，使用專業(yè)的方式予以分析，如使用國際 QA 標準，使用魚骨圖，使用柏拉圖 等方式來分析出可能的原因， 并對原因予以檢測和測試，提出根本解決事件的方 案。 魚骨圖分析法柏拉圖分析法第 21 頁XX 技術(shù)有限公司問題管理，僅提出解決問題之道，也就是根除某突發(fā)事件的方案，具體的處 理步驟，交由實施管理來執(zhí)行。 實施管理，又叫做發(fā)布管理，因根除故障特別是信息系統(tǒng)缺陷時，需要嚴格 處理過程， 避免在線運行業(yè)務(wù)受到不可預(yù)計的影響。我們在發(fā)布過程中都會預(yù)計 到一些可能的影響， 如更改交換機配置可能導致部分終端無法使用網(wǎng)絡(luò)；修改某 一個數(shù)據(jù)庫字段可能導致數(shù)據(jù)混亂； 修改某段代碼可能導致整個程序陷入死循環(huán) 等。 因此實施管理必須能有效并切實的分析大部分存在或者隱含的風險。試想我 們在更改交換機配置前經(jīng)歷過充分測試， 將中斷網(wǎng)絡(luò)時間縮短為五分鐘并且通知 到全部/大部分可能受影響的客戶；修改數(shù)據(jù)庫字段或代碼前在虛擬測試平臺或 訪真數(shù)據(jù)庫中反復測試， 而后予以發(fā)布； 將發(fā)布的時間定在非使用高峰期。 這樣， 可以規(guī)避大量風險，保證問題解決的安全可靠。 越維風險控制模型風險識別風險分析風險應(yīng)對計劃編制風險監(jiān)控