「那個情況絕非你想面對。不過,那就是我們的工作,才有錢拿。」..Aaron Crow
重新整理一下,在MIS[異常管理]的部分,含本篇我一共寫了3篇:
項次|DAY|系列文章名稱| 管理問題及主題
------------- | -------------
1|16|使用者問題回報系統 | User回報問題給MIS
2|17|資安事件及異常紀錄 | MIS對異常及資安事件進行紀錄及依規定通報
3|18|整理及管理分享 | 整理及小結
處理異常其實是MIS的日常...所以老實說,實務上我們不大會真的在系統上將MIS的業務區分為日常和異常的作業類別。
舉例來說,機房工作日誌的點檢絕對是日常作業,但若點檢過程過程發生Server主機燈號出現紅色,就進入異常作業處理程序。
網管業務的表單設計,如果被要求機房工作日誌及異常紀錄都要有,設計上我們會將這二件事情設計整合成一個表單進行管理,而不會硬為了區分日常及異常作業而分成二種紀錄。
本系列文章這樣的分法是為了從MIS的作業性質工作去理解MIS的管理,以及為了管理需要所提出的IT Solution所舉的範例。希望讀者能理解。
從資安管理的角度,IT的異常管理其實是ISMS必須管理的重點。
對照到ISO27001,就是附錄A.16資訊安全事故管理,
所以資安事故通報單/處理單的設計,最完美的就是一個表單要能解決上述7個控制項要求。請再回過程看上一篇資安事件及異常紀錄的設計,有符合上述的要求嗎?能回答ISO27001的稽核員在A.16稽核上的問題嗎? 若無法完全滿足,你會怎麼去修改或重新設計這個管理表單?
異常事件單或資安事件單就是trouble ticket,而Redmine本來就是軟體開發的Issue Tracking System,就算應用在營運問題的追蹤及處理也非常適合。如何透過Redmine對MIS的異常處理進行更細膩的管理,並符合ISO 27001 A.16的控制項要求,這留給大家更進一步去發揮及實作設計。
處理IT的異常事件就是管理「問題的生命週期」,所以用Issue Tracking System來管理是再適合不過了。
MIS的KPI我們在[日常管理]整理及管理分享有比較完整全面的整理。以下將異常處理的部分再整理如下,給大家參考。
作業別|KPI|定義/公式| 目標(範例啦)
--|--
Help desk|User服務需求單處理效率|(希望完成日<=實際完成日)之件數 / 總申請件數|>95%
系統及網路維護能力|系統可用性|(總上班時間-系統中斷時間)/總上班時間|>99%
系統及網路維護能力|系統故障處理效率|系統中斷時間<=RTO(定義的復原時間目標)|100%
本系列文章因為在分享表單的設計,雖然寫的不多,但已經把重要的幾個議題列入設計,整個管理設計應該算完整:
還可利用平台再進行更細膩的管理,更精進的議題留給邦友們思考設計。
2013年6月大聯盟老虎和皇家的一場球賽,有一則報導一直在我記憶中。
當時的情境是:二壘上有追平分、一壘上有超前分,輪由「三冠王」Miguel Cabrera上場打擊,1分落後的老虎隊,7局上出現逆轉契機。不過這個契機,毀在皇家隊中繼投手Aaron Crow手上,K掉Cabrera,瓦解老虎隊攻勢。最後皇家隊以3比2贏球,拿下本季最長6連勝。
Crow賽後回憶那個關鍵三振,:
「那可能是我今年最棒的滑球。」
「其實那個球路,我投得並不好,那個情況絕非你想面對。不過,那就是我們的工作,才有錢拿。」
我好愛那句話:「那個情況絕非你想面對。不過,那就是我們的工作,才有錢拿。」
就像MIS面對每一個緊急的資安事件、資安事故,就是發揮我們平常磨練出來的專業技術和經驗知識,冷靜面對、專業處理、有效解決,讓企業正常運作,就是MIS人員的專業。
更現實的理由是,這樣我們也才有錢拿啊!
明天開始將以MIS一個大專案,說明如何在Redmine進行專案管理。之前都是用牛刀殺雞,明天開始的專案管理才是可以發揮Redmine平台在專案管理上強大功能可以充分發揮。