it運維、it服務(wù)與itil(編輯修改稿)
2025-03-13 22:15 本頁面
【文章內(nèi)容簡介】 anisation Measures WBS, Scheduling ... 衡量(Measures) 讓我們衡量 ServiceDesk... 定量： ? 首次呼叫解決率 [%] ? 所有問題解決率 [%] ? 客戶滿意度 [rating range] ? 升級到二線的問題 [%] ?… 定性： ?完備的審計功能使責(zé)任到人 ,摒棄了工作中的推諉 ?問題自動升級上報機制大大提高整體服務(wù)水平等級 ?知識共享減少了大量的重復(fù)工作 服務(wù)臺服務(wù)質(zhì)量參數(shù)（舉例） 27 如何評估服務(wù)臺的工作 （舉例） ? 每天 – 需要升級的事件 – 可能違背 SLA的地方 – 所有顯著 /特別的事件 ? 每周 – 一周內(nèi)經(jīng)常發(fā)生的，占用員工最多處理時間的事件 – 需生成問題記錄的事件 – 已知錯誤與變更請求 – 違背 SLA的地方 – 客戶滿意度 – 影響業(yè)務(wù)的趨勢 – 員工工作量 ? 每月 – 服務(wù)可用性 – 整體績效、成績與趨勢分析 – 客戶感受與滿意度級別 – 最終客戶培訓(xùn)與教育需求 – 員工績效 – 技術(shù)性能 – 回顧評審報告的內(nèi)容 – 提供服務(wù)的成本 28 事件管理 Incident Management 定義 任務(wù) 目標(biāo) ? 盡快將服務(wù)恢復(fù)到正常狀態(tài) ? 最小化突發(fā)事件對業(yè)務(wù)運作的負(fù)面影響 ? 確保服務(wù)質(zhì)量和可用性滿足 SLA指標(biāo) ? 突發(fā)事件（ Incident） – 會引起或可能引起服務(wù)中斷、服務(wù)質(zhì)量下降的任何事件 – 硬件故障、軟件故障、服務(wù)請求 ? 探測和記錄 ? 分類和在線支持 ? 確認(rèn)優(yōu)先級 (影響和緊急度 ) ? 調(diào)查和診斷 ? 解決和恢復(fù) ? 結(jié)束 ? 職責(zé)、監(jiān)控、跟蹤和交流 29 事件管理 Incident Management ? 變通方案－應(yīng)急方案 – 舉例：計算機重啟；打印機故障，將打印任務(wù)分配到其他打印機上； ? 服務(wù)請求：除了 IT基礎(chǔ)設(shè)施（硬件、軟家）故障外的事件都是服務(wù)請求 ? 思考： ? 舉例：郵件收得慢，是否算突發(fā)事件？ ? 答：要根據(jù)事先約定的閥值來判斷 – 事先約定，能收下來即可，不算突發(fā)事件 – 事先約定， 10M郵件 3秒鐘下載完成，有可能算 30 突發(fā)事件生命周期 突發(fā)事件 突發(fā)事件探測和記錄 分類和在線支持 服務(wù)請求 調(diào)查和診斷 解決和恢復(fù) 結(jié)束突發(fā)事件 服務(wù)請求流程 是 否 思考：事件發(fā)生并得到處理后，由誰來結(jié)束事件？為什么？ ——強調(diào)責(zé)任、避免客戶請求丟失 31 事件管理 Incident Management 32 事件管理 Incident Management 并非所有的事件都能由服務(wù)臺和一線支持加以解決。在不能解決的情況下，事件必須轉(zhuǎn)交給后續(xù)支持組。為了及時獲得后續(xù)支持組的協(xié)助，我們需要建立事件升級機制 ? 思考：以什么標(biāo)準(zhǔn)決定是否需要升級？ ? 時間－自動觸發(fā) ? 分工－事先確定 ? 舉例：有一天一線人員很忙，有一些應(yīng)該由一線處理的到時仍未處理，應(yīng)否升級？ ? －從客戶視角看 33 突發(fā)事件流程的輸入和輸出 該流程的輸入為： ? 來源于服務(wù)臺、網(wǎng)絡(luò)和計算機等事件的詳細(xì)信息 ? 相關(guān)操作 ? 來自配置管理數(shù)據(jù)庫 (CMDB)的詳細(xì)配置信息 ? 事件與問題或已知錯誤是否匹配的反饋 ? 以往相關(guān)解決方案的詳情 ? 相關(guān)事件變更請求（ RFC）的反饋 該流程的輸出是以某種方式盡快恢復(fù)服務(wù)，例如： ? 事件解決方案的變更請求 ? 更新的事件記錄（包括解決方案和／或臨時解決措施） ? 已解決和結(jié)束的事件 ? 與客戶交流的相關(guān)信息 ? 管理信息（報告） ? 思考：如何提高記錄的效率？ ? ——不是記錄而是匹配 34 事件管理中可能發(fā)生的問題 a、用戶繞過事件管理的程序 ? 如果用戶沒接收該流程的培訓(xùn)，他們可能不遵循正確的程序，而是自己試圖去解決錯誤。結(jié)果，事件記錄不能準(zhǔn)確的更新。 b、事件超負(fù)荷 ? 出現(xiàn)以下情況，可能超負(fù)荷 ? 沒有對事件進行清楚歸類。 ? 沒有正確分配和轉(zhuǎn)送事件。 c、事件升級（ escalation）的增加 ? 如果支持團隊不具備適當(dāng)?shù)募寄芎唾Y源，事件可能迅速升級到更高級別的支持團隊。這將給專家支持團隊增加不必要的工作量。 d、服務(wù)級別協(xié)議沒有清楚定義 ? 如果事件管理流程支持的服務(wù)沒有在服務(wù)級別協(xié)議 (SLAs) 中清楚地定義，事件管理人員不知道哪些報告的錯誤和需求可以作為事件。 e、組織中文化的變更 ? 組織中實施事件管理流程需要以流程為導(dǎo)向。結(jié)果，更多的任務(wù)、責(zé)任和更嚴(yán)格的紀(jì)律要求可能超出員工的預(yù)料，一些人就會產(chǎn)生抵觸情緒。 35 事件管理最佳實踐 1 ?? 1. 除非在服務(wù)級別協(xié)議說明，不可繞過服務(wù)臺（單一聯(lián)絡(luò)點）。 ?? 2. 服務(wù)臺軟件工具將包括與問題管理、變更管理、配置管理系統(tǒng)的高度集成。 ?? 3. 所有呼叫的解決必須在系統(tǒng)中存檔。 ?? 4. 需要為判斷突發(fā)事件，使用配置管理數(shù)據(jù)庫。 ?? 5. 突發(fā)事件解決的進度必須主動通知最終客戶，應(yīng)由服務(wù)臺人員完成。 36 事件管理最佳實踐 2 6. 為了統(tǒng)一和經(jīng)濟，服務(wù)臺可作為 IT的主要通訊手段來與最終客戶交互：突發(fā)事件 /服務(wù)狀態(tài)，正在解決的問題，變更管理狀態(tài)，服務(wù)停止和服務(wù)可用性。 ?? 7. 呼叫升級的過程必須存在?；跇I(yè)務(wù)影響的自動呼叫升級必須存在。 ?? 8. 服務(wù)臺應(yīng)對計劃的和最近已實施的變更高度感知。 ?? 9. 來自監(jiān)控報警的輸入將自動輸入系統(tǒng)。 ?? 。 37 問題管理 Problem Management 定義 任務(wù) 目標(biāo) ? 最小化由于 IT基礎(chǔ)架構(gòu)錯誤引起的突發(fā)事件和問題的
環(huán)評公示相關(guān)推薦
鄂ICP備17016276號-1