|
8：50我準時出現在公司門口。打卡、上樓梯、打開電腦。按以往的慣例我上班之前都要去服務檯轉轉，瞭解最新的服務受理情況。但現在習慣變了，不是第一時間走到服務檯瞭解服務受理，而是第一時間打開電腦查看ITSM系統的記錄。通過ITSM系統，我可以及時瞭解最新的服務受理情況及其處理進度。即使我不在服務檯也能夠對IT服務做到心中有數。
路走了一半，經過服務總監辦公室門口時我被叫了進去。“昨晚試點發布新版本的客戶在今早進行數據通訊時出故障了。”總監看來已經在ITSM系統中查閱了相關事件記錄，“你儘快協調解決此事。另外，有一家客戶投訴服務工程師的技能，你去查一查，儘快給我彙報。”“好的，我會盡快查明原因。”自從實施了ITSM工具之後，誰都可以在自己的權限範圍之內實時瞭解IT服務狀況。對我而言，有了工具減少了我的服務彙報工作，但同時也增大了工作壓力。因爲可以實時查閱事件記錄，也就意味着我的工作不能出現一點點差錯。 在之前很長一段時間裏，我的工作沒現在這麼忙，這麼累。因爲服務檯的工作只要求做好客戶報修的記錄並分配即可。問題由服務工程師處理，軟件新功能的增加有開發人員負責，投訴由投訴專員負責。服務檯只要做到服務受理的“分級、分類、不漏、不錯”就萬事大吉。但現在不一樣了,自從年初實施了ITIL，不論是工作內容，還是管理範圍都有了很大的調整。服務檯開始轉型要面向客戶提供服務，不再是簡單的記錄事件，而是要將自己看作是事件的主人。對受理的每一個事件都要做到及時跟蹤，負責到底。所以瞭解每一個事件的進展，監督事件處理，報告事件結果就成了我的日常工作。 “新版本發佈引發的故障到目前爲止有多少？都是軟件的技術問題嗎？”見到服務檯的值班長，我向她瞭解了今早的報修。“昨晚發佈新版本的客戶已經報修了60%，估計還會繼續增加。”值班長說：“他們進行數據通訊時會彈出英文的提示框，點擊後，業務系統自動退出。從這種表現來看，我覺得是屬於發佈引發的問題，這個事件已經直接升級給開發部門。”“好，你中午之前再跟進此事，儘快督促他們解決。還有一家客戶投訴工程師服務技能，你也同時跟進，瞭解具體情況2個小時內給我一個回覆。”佈置完任務，值班長開始忙碌起來，我也回到了辦公室。 10：00我收到服務檯值班長髮來的投訴情況彙報。客戶投訴的是一線工程師一週之內連續兩次上門未能解決問題。上週客戶報修但工程師上門未能解決。回來之後該事件作爲問題升級至問題管理。問題管理找到解決方法之後向變更管理提交了變更請求，並已通過變更管理的審覈。但由於方案需要的設備備件在採購環節上出現問題遲遲沒有到貨，所以發佈管理無法對客戶進行發佈。目前僅能採用維修的方式臨時處理，維持但不能保證客戶的正常使用。事情的經過已經清楚，接下來服務檯一方面需要安撫客戶，告知他們我們會盡快解決這個問題；另一方面需要督促採購部門儘快完成設備備件的採購。因爲按照ITSM系統的定義如果一個投訴事件超過一週未能關閉，該事件將自動發送至服務總監，由服務總監親自過問。今天若不及時處理這個投訴事件，也就意味着投訴要升級至最高管理層。 11：30例行檢查ITSM系統的事件記錄，當查詢發佈問題的處理進度時我發現這些事件的狀態變爲“已解決”。這時服務檯打來電話告知開發部門提交的解決方案，經變更管理審覈後，發佈管理已經通過服務器發佈新的軟件補丁解決。原因是試點區域客戶的配置信息出現錯誤，實際的硬件型號與配置庫中的記錄有出入，軟件測試時採用了錯誤型號的硬件導致在實際發佈時出錯。原因找到了，問題解決了。雖然在配置管理出了點差錯，但是整個事件處理的效率還是令人滿意。 問題解決了，但服務沒有結束。接下來需要安排服務檯做一次電話呼出，對受到影響的試點客戶進行解釋並對此致歉，同時對客戶的硬件配置信息做一次覈實。覈實之後我還要協調配置管理員對錯誤的硬件配置項信息進行修正。忙了一上午，發佈問題和投訴事情有了處理結果，這樣我也可以向服務總監彙報工作了。 13：30彙報完工作，我繼續在ITSM系統中巡視事件記錄。幾個處理超時的事件已經關閉。暫時沒有發現異常的事件。每天下午的這個時間客戶很少來麻煩我們，所以服務檯也有了一天當中最清閒的時刻。 14：30收到問題管理的mail。幾天前的服務協調會上，針對雷雨季節客戶設備的防雷擊問題，我和事件經理、問題經理商量出一個方案，由問題管理出具一份如何防範雷擊的注意事項，然後由服務檯在雷雨季節來臨之前制定防範雷擊的呼出計劃並提前通知到每一個客戶。儘可能減少因爲缺乏防範意識導致的突發性、大規模的客戶報修，減輕事件管理的服務壓力。這麼操作雖然有些麻煩，但帶來的好處也是顯而易見的。我要做的就是讓這份專業的技術指導變得易於客戶理解。這時，服務檯承擔的就是客戶與專業技術人員之間的翻譯角色。 15：30桌子上的電話想了起來。服務檯值班長打來電話。“下午的服務器可能有問題，我們在半個小時之內接到20個客戶電話報修無法與遠程服務器建立鏈接。已經分配給最近一位空閒的一線工程師到機房做檢查。”“好，我知道了。”聽完值班長的彙報，我繼續做自己的事情。這只是服務檯按規定向我做的彙報，只要事態不進一步發展，服務檯只需知會到我這個主管即可。 15：50電話再次想起。“情況不妙了，主管。工程師到了機房沒找到問題。現在又有十幾個電話報修同樣的問題。”電話那頭的值班長有點擔心：“有的客戶開始着急了。”“小王呢？”“他今天請假。我覺得可以啓動應急預案了。這次報修的影響範圍大，而且是關鍵服務受到影響，符合啓動應急預案的標準。”“好的，你啓動應急預案，我來簽發。” 15；55有關服務器故障的應急狀態正式啓動。小王是負責服務器維護的二線工程師。雖然不巧今天請假不在，但是根據應急預案的要求服務器維護設計了A/B崗，小王是A崗，小林是B崗。 16：00服務器故障的事情已經通知到服務總監、事件經理和問題經理。事件經理負責協調服務器維護人員，問題經理將作爲後方的技術支持隨時提供幫助。服務總監負責總體協調。“小林什麼時候能夠到機房？”應急會議上我簡單通報了事情經過之後問了問事件經理。“估計需要一些時間。他現在其他客戶那裏處理問題，暫時還走不開。不過，我已經安排其他工程師過去接替他的工作。一旦有人接受，他馬上趕去機房。”事件經理不緊不慢地回答我。“好，另外問題管理這邊也回顧一下之前是否有類似的故障發生，爭取在下班之前解決這個問題。”服務總監的指示讓問題管理不敢怠慢。 在等待小林前往機房的途中，問題管理查找問題的過程裏，又有客戶的報修不斷打進服務檯。雖然受到影響的客戶不斷增加，但IT服務的節奏沒有亂。一切在應急預案的指導下有條不紊的進行。我喜歡這種有序的節奏。因爲可以擺脫過去“有事就亂、越忙越亂”的處理突發事件方式。 16：20小林到達機房。問題管理員的電話也打了過去了解情況。經過大家的努力，很快找到了問題根源。半個小時後小林解決服務器無法鏈接故障。 17：00服務檯抽取部分客戶進行回訪確定故障得到解決。在隨機抽取的10家客戶100%得到業務恢復正常的反饋。 17：20 總算在下班之前結束了手裏所有的事情。原以爲是輕鬆的一天，沒想到會過的如此“充實”。 |
翰緯