ITIL 資治通鑑

簡單說明了 Event Management 的理論，回到現實世界，來談談我周遊許多公司資訊環境後，常見的管理問題。

個人曾經到訪過一個地方政府資訊單位，該單位規劃出不錯的 Log Center 功能，以 Web Service 為所有軟硬體環境界接的界面，去接收所有 Event 訊息，各系統依照五大類別去分類呼叫，集中整合所有 Log，最後連接 SMS 及 Mail 平台去通知相關承辦人及廠商，進行必要的處理。上述例子是不錯的 Event Management Process Design (落實度還未完整)，成本也相對昂貴，也有比較簡易平實的做法，就是寫 cron-job 全部收進來，再列印報表去審視。

無論是哪種管理流程，個人曾見過的 Event Management 問題如下，供大家參考：

Event Management Process 可以很簡單，譬如簡易的伺服器及應用系統 log 收集；當然也可以很複雜，詳如 ITIL V3 理論內容，它勾勒出完整的處理程序及流程，輔以不同狀態的子流程因應，以供有興趣之企業組織參考。

Event Management Process:

一、Event Occur, Notification and Detection
在服務設計階段，應儘量邀請各流程、角色參與討論，並針對"重要"區域及服務進行 Event 偵測及通報的機制，若預算許可，則應盡可能以自動化去收集並接受 Event 通知，降低人力維運成本。

面對一個新增的服務管理流程，首先你要評估，我們需要事件管理(Event Management)嗎?

這往往也是資訊人員在規劃導入建置預算時，老闆最常會問的問題…

在經濟大蕭條的年代，錢要用在刀口上，倘若組織資訊服務的政策，因為某些因素(如顧客未要求、預算有限等)，是屬於消極性反應型，則事件管理的導入必要性則尚待討論(註一)，可由事故管理來做消極因應；不過，若組織對於資訊服務管理，是放眼長治久安，採取積極主動態度，且希望全面性掌握每一個細節，則事件管理可以提前監測，輔以極大的幫助。根據 ITIL 理論的陳述，事件管理可為企業組織帶來下列的利益：

 近年來國內的 ITIL 研究，將 Incident Management 翻譯為「事件管理」，一路沿用下來，也沒有太多爭議，成為大家有默契慣用的專業名詞之一(註一)。不過，V3 版本問世之後，在 Service Operation 多了一個管理流程： Event Management，這就引起「事件」這個名詞認知上的爭議了…

就一般資訊業界常用的習慣，Event 通常稱為「事件」，但由於之前 V2 的年代，大家已習慣把 Incident 視為「事件」，易產生解讀上的疑惑，故在筆者手邊收到的 itSMA Taiwan 所制定的「ITIL V3 Terminology 中文翻譯」草稿版中，官方已打算正名：Event 為「事件」，而 Incident 改為「事故」，待官方正式公告之後，讀者們要開始慢慢去習慣名詞的變化。

那 Event 的定義為何呢? 與 Incident 又有何區分呢? 這就是第一篇文章中要釐清的重要概念。先讓我們來看看 ITIL 理論這兩個名詞的個別定義：