事故管理的任務和目標是盡快恢復正常的業務運作並將事故對營運的負面影響減少到最小，從而確保維持服務品質和可用性的最高水準。如果無法在規定的時間內解決故障或者沒有解決方案，則應該將事故轉派給更有經驗的技術人員來處理，並協調各方面的資源來迅速解決故障。
常見的事故如下
我們先來看看 iTop 標準的 Incident Life Cycle 長怎樣。
把人物角色放上去，是不是比較容易理解了。
Dispatch Incident to a Team
此擴充功能允許事故分派給團隊，而無需將其分配給特定人員。值得注意的是，請求分配給團隊時 TTO 指標仍會繼續計算，直到實際分配給個人才會結束喔。
點選 iTop Store 找到 Dispatch Incident to a Team 外掛，選擇最新的 1.2.1 Version，點選 Install。
勾選 Instance Backup，點選 Deploy。
Dispatch Incident to a Team 安裝成功
加入 Dispatch 狀態的簡易生命週期如下
對於 New 狀態下的事故，下拉清單中提供 Dispatch to a Team 操作。
當一個事故是另一個工單的父事故時，每次修改其私有和公用日誌時，iTop 都會自動更新子工單的日誌。當父事故得到解決時，iTop 將自動解決子事故。
服務台人員便可以將事故分派至團隊
可以看到生命週期狀態從 New 變成 Dispatched 了
系統便會透過郵件通知所有的團隊成員
也可以在 Notifiactions 頁面，查看電子郵件發出事件的紀錄。
Notification
在安裝完 Dispatch Incident to a Team 模組之後，通知相關的 Trigger 與 Email Actions 我們必須自己建立。
還記得之前建立的 Dispatch Requested Trigger，Target Class 我們使用 Ticket，所以在 Incident 進行 Dispatch 也可以使用。
這邊我們就不需要再建立了，除非您有特別的需求想要將 User Request 與 Incident 分開來。
記得到該 Service 的 Contacts 頁面設定維運的團隊
Auto Dispatch Ticket to a Team
此擴充功能會根據設定的排程規則自動將工單分派給團隊，同樣地可以套用在 Incident Management。
加入 Auto Dispatch 的簡易生命週期如下
Dispatch Rule 同樣可以使用前面的設定不用再修改
支援人員處理完畢後選擇 Resolution Code，點選 MARK AS RESOVED。
使用者可以在 Resolved 分頁中找到被標示已解決的請求或事故。
使用者可以將已解決的請求或事故進行關閉或重新開啟
若選擇關閉請求，使用者可以回饋用戶滿意度，有助於之後的數據分析。
被關閉的事故就會被歸類到 Closed Requests
事故管理的相關流程圖可參考如下
對於反覆出現的的事故或者重大故障，我們可以升級到問題管理來分析根本原因，防止以後再次發生。
今天的分享就到這邊，感謝收看。
參考文件
iThome鐵人賽
看影片追技術