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