NO IMAGE

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  半個小時的時間內沒有接到一個伺服器無法連結的報修電話。我宣佈應急狀態結束並以email通知到服務總監、事件經理和問題經理。當然還有服務檯值班長。

總算在下班之前結束了手裡所有的事情。原以為是輕鬆的一天,沒想到會過的如此“充實”。