IT技術已經無處不在，各行各業都離不開它。無論是銀行、券商、傢庭、學校還是個人，都離不開IT技術。例如：

• 我們人與人之間社交的軟件，如微信、QQ、陌陌、Facebook等。
• 銀行通過IT技術為我們實現金融帳戶的管理、理財管理、計算理財產生收益等。
• 券商為我們提供針對股票的實時行情信息和股票交易的系統。
• 工業制造企業使用IT技術來實現ERP系統、財務管理系統等。
• 學校使用IT技術來管理學籍和圖書。
• 生活中，我們通過美團等平臺購買食品和訂餐等服務。
• …

這些我們看不見摸不著的“服務”在保障著我們的衣、食、住、行等各個方面。一旦這些系統出現異常事件（如網絡中斷、系統不能登錄訪問、交易失敗），就會嚴重影響我們的生活。

IT系統出現服務中斷是不可避免的。因此，在事件發生時，我們必須以消費者能夠容忍的方式來管理、分析、處置事件。

統一事件管理系統是任何一傢企業不可或缺的基礎設置。它的主要使命：與數據中心整個運維體系的工具系統進行集成、使用機器學習分析問題，並在第一時間自動采取行動解決問題。它能有效提高團隊生產力，並保障為最終用戶提供出色的數字體驗。

統一事件管理是數字化企業必不可少的基礎設施

本文將探索統一事件管理的最佳實踐，包括：

• 什麼是事件？
• 什麼是事件管理？
• 事件管理示例
• 事件管理最佳實踐

什麼是事件？

在TIL 4版本中，事件被定義為服務意外中斷或服務質量下降。

為確保客戶滿意度，企業必須采取適當的處置策略來應對不同的事件。以下是一些系統中發生服務中斷或異常的典型事件：

• 用戶無法登錄
• 每次使用您的乘車卡時，卡片莫名其妙地無法打開
• 與平常相比，進行交易時交易緩慢
• URL無法訪問…

什麼是事件管理？

事件管理的目標是通過一定的手段和方法盡快恢復正常服務來最大程度的減少事件的負面影響。

無論是用戶無法登錄、交易緩慢還是打印機無法打印，我們都應該具有針對不同事件類型擁有事件管理流程。根據事件的嚴重等級，可以由個人、團隊或多個團隊共同協作來完成對事件的處置。成功的組織會在事件或應急場景下指定事件或應急指揮員角色，負責領導師臨時跨職能團隊，集中所有團隊成員的能力快速解決問題。

事件管理的目標是通過一定的手段和方法盡快恢復正常服務，最大程度地減少事件的負面影響。

無論是用戶無法登錄、交易緩慢還是打印機無法打印，我們都應該擁有針對不同事件分類的事件管理流程。根據事件的嚴重等級，可以由個人、團隊或多個團隊共同協作來完成對事件的處置。成功的組織會在事件或應急場景下指定事件或應急指揮員角色，負責領導臨時跨職能團隊，集中所有團隊成員的能力快速解決問題。

事件管理的第一步是記錄事件。可以通過一些監控工具或由客戶電話報障的方式獲取事件，並通過一些自動化的手段獲取通知，同時可以獲取該事件的相關信息，包括描述、發生時間、告警來源、針對什麼所發生的事件（如某個主機、某個業務）。記錄的事件信息將成為後續管理事件並對其進行分析、決策、處置的基礎，包括：

• 溝通：在對事件進行分析、處置過程中，需要協調不同專業領域人員進行溝通、協作以對問題進行有效分析。
• 解決：在分析完成後，事件經理或應急團隊會做出事件處置的決策，並進行事件的快速修復。
• 升級：如果在分析處置的過程中發現事件已經超出事件響應人員的能力范圍，則需要及時對事件進行升級，這時可以將事件轉派給某個領域內的專業人員負責處理。
• 移交至其他流程：事件解決完成之後，如果事件需要建立相應的工單進行根治，則需要創建相應的問題工單，以排查問題的根本原因，並徹底解決該問題。

成功的事件管理依賴於清晰地定義客戶容忍的任何事件的持續時間和處理方式。這些通常在服務級別協議（SLA）或合同中定義，其中最重要的部分是定義響應和解決事件的時間表。

作為服務提供商，如何構建相應的組織並處理不同類型的事件是事件管理執行的主要職責：

• 針對已知的事件場景：這種事件會重復發生。在這種情況下，可以定義並使用已知事件模型來進行自動化處理和解決。已知事件模型是管理特定事件的重復發生時的重要解決方案。有助於減少新員工解決事件的時間和學習曲線，並有助於將零散的知識落地到工具系統中。
• 針對一些事件發生後不容易找到解決方案，則可以采用變通的辦法來嘗試減少影響或再次發生的可能性。在這種情況下，處置的決策權將交由人工來確認。針對當前事件，可以采用重新啟動或分流等解決方案來快速恢復。

事件管理示例

我們將通過三個不同規模的事件來說明如何使用預先定義的最佳實踐和標準來處理常見的事件。

單一用戶服務事件

某銀行的私人銀行中心經理張正在嘗試登錄銀行的私人銀行系統，以查看他所分配到的客戶名單中是否有近期的拜訪安排。然而，她的訪問認證沒有通過，盡管她嘗試瞭重置密碼，但仍然無法登錄，於是她聯系瞭IT服務臺。

IT服務臺經理小王獲取瞭張經理的詳細信息並驗證瞭她是否是該銀行的私人銀行中心經理。驗證通過後，小王登錄私人銀行系統管理員模塊並檢查瞭張經理的個人資料以及相關配置。結果發現，由於調崗的原因，個人資料中的某些更改沒有正確執行，導致瞭錯誤。

小王針對這些更改進行瞭觸發並重新執行。然後張經理重新嘗試登錄，並成功地登錄瞭系統。小王關閉瞭工作臺上的事件記錄，同時系統向張經理發送瞭滿意度調查。張經理非常滿意，給小王打瞭5星的好評。

小王繼續檢查私人銀行系統相關的更改情況，其他人的更改都已經正常運行。小王確認“不需要創建工單”。

多用戶服務事件

IT服務臺李經理註意到電話數據增加，基本上都接到同樣的事件：手機轉賬長時間沒有響應。同時從告警工作臺的值班經理處獲得某業務系統的數據庫錯誤，他們正在處理該問題。

李經理評估這是一個重要的服務事件，他立即登錄ITSM系統發佈瞭手機轉賬問題的一個公告，並立即創建瞭一個事件工單，要求所有團隊收集到的與該問題相關的事件（包括IT服務臺和統一事件管理平臺的告警工作臺）關聯起來，以便集中進行管理，而不需要浪費重復的資源分別進行處理。

10分鐘後，李經理收到瞭從IT經理那裡得到的最新消息，該系統現在恢復運行，因此他重新要求IT服務臺的多名值班人員驗證手機轉賬業務，確認他們已經恢復正常，並關閉瞭工單。

他在ITSM系統中重新更新瞭公告的內容。

重大IT服務事件

"不好瞭！"，NOC 值班工程師小李驚呼道。

統一事件管理平臺的告警工作臺發現告警風暴，屏幕上不斷有新的告警湧現。大量的虛擬機出現瞭宕機情況，這意味著要麼是核心交換機出現故障，要麼是虛擬機管理程序出現問題。

小李在 ITSM 系統上登錄瞭該事件，並將其定義為重大事件。他聯系瞭雲管理員和網絡管理員並召開瞭會議。

作為一傢公有雲服務商，公關經理也需要參與進來，因為她需要實時瞭解事件的情況、嚴重性、影響范圍等，並需要及時通知客戶以應對該事件可能造成的輿論壓力。

雲管理員很快發現這是虛擬機管理程序上的一個錯誤造成的。他們立即電話聯系瞭虛擬機管理程序的供應商。同時，雲管理員將該事件的優先級調整為最高。

由於越來越多的虛擬機出現問題，電話湧入呼叫中心，CEO 也親自介入，並親自打電話給受影響的大客戶。此時供應商還沒有盡快響應該事件，但是 CTO 已經觸發瞭應急響應，該事件在 2 小時內得到解決。

接下來的一段時間裡，CTO 組織進行瞭事件復盤，以查明事件的根本原因，供應商也參與其中。形成事件報告，針對報告的內容會發起一系列的研發、測試及變更計劃，以確保此類事件不會再次發生。

事件管理最佳實踐

從三個不同規模的示例中可以看出，在進行事件或應急響應的過程中，為瞭滿足客戶的服務需求，您的IT團隊將按照以下最佳實踐的過程執行各種活動，主要包括：

檢測事件

事件檢測通常包括以下三種方式：

• 用戶報告問題，而服務臺的值班人員將驗證是否為事件。
• 通過針對服務或相關技術組件所采集的數據進行觀測，來自動發現事件。
• 通過趨勢預測的手段來發現即將產生的事件，以便提前發現事件。

記錄事件

一般情況下，事件的記錄是通過系統來完成的，這些系統提供瞭對歷史事件的管理、總結及分析的能力，包括：

• 呼叫中心系統：外部客戶一般通過電話聯系呼叫中心系統，客戶服務人員負責在此記錄客戶的問題。
• IT工作臺：內部用戶進行問題報障時通常會訪問IT工作臺。
• 監控系統：為瞭自動化監控並發現系統的潛在問題，會對服務和相關的服務組件進行監控，以發現異常。
• 統一事件管理平臺：會統一收集不同監控系統產生的異常，並及時同步針對呼叫中心系統、IT工作臺的用戶及客戶報障至統一事件管理平臺，進行統一的管理。
• ITSM系統：如果事件被確認屬於重大事件，需要留存，則需要事後在ITSM系統中創建事件單，以備審計。

事件分類

在事件分類階段，主要根據以下內容對事件進行分類：

• 這是一個什麼類型的事件：如硬件故障、軟件故障、網絡故障或其它。
• 影響程度及范圍：如對哪些業務、客戶造成瞭影響。
• 緊急程度，取決於對客戶SLA的承諾，即恢復服務的速度。
• 優先級，針對不同的業務或客戶影響，哪些應該優先被處理。

分類有助於：

• 加速對事件的識別及處置效率
• 有效識別誰應該對該事件負責
• 降低事件處置成本
• …

診斷事件

事件診斷的核心在於確定出瞭什麼問題，以及針對該問題恢復正常服務的最快方法。

如果事件之前已經發生過且已經命中瞭事件模型，則可以由一線人員直接進行診斷即可。但是，對於更復雜或之前沒有發生過的事件，則需要跨職能團隊或由二線的專傢進行聯合調查。

解決事件

事件的解決是指診斷完成之後，針對該事件的解決方案，包括臨時修復解決方案和永久修復解決方案。一般在應急及事件處置過程中不追求永久修復，而是希望在最短的時間內通過一系列的操作盡快恢復生產。主要的操作包括以下幾種 ：

• 自動實施：一般是根據事先定義的已知事件模型，完成對事件的自動解決、自動恢復，不需要人工診斷和處置，全部有自動化來完成。
• 記錄下來供運維工程師自行解決：一般會根據事件模型或系統分析結果給出處置的建議，由運維工程師進行決策，並最終通過人工的操作來完成恢復過程。針對一些復雜場景，也可以請支持團或供應商來提供相應的解決方案，由運維工程師來執行操作過程。

關閉事件

一旦事件得到解決，就需要對該事件進行正式關閉。關閉需要完成以下動作：

• 與用戶、客戶或其他管理層及利益相關者溝通，告知業務服務已經恢復正常。
• 根據需要，更新CMDB的配置信息，例如為瞭恢復業務而增加瞭數據庫集群的規模。
• 更新計費，例如內外部人力的投入、增加新的服務器等。
• …

事後復盤

事後復盤往往被許多組織所忽略，但其是進行知識總結、優化監控、優化事件處置、優化現有事件及應用流程必不可少的重要環節。

事件復盤一般在事件發生後5個工作日內完成，在這一環節一定要設置審查崗，詳細審查運維工程師針對事件處置的總結報告，報告主要內容包括：

• 報告日期
• 報告負責人
• 事件概述：通過一兩句簡短的話，簡述事件以及根本原因、發生時間和造成的影響。如，2023.8.5日上午9:25，由於數據庫故障，造成故障時段約20%的交易出現響應時間變長，影響瞭用戶使用體驗，持續時間約15分鐘，嚴重等級為“主要”。
• 事件詳情
• 詳細描述發生瞭什麼事件
• 什對該問題的根本原因是什麼
• 針對該問題的臨時解決方案（為瞭盡快恢復業務，而制定的快速恢復解決方案）
• 針對該問題的永久解決方案
• 造成的影響：針對業務、對用戶、對交易等造成的影響，嚴重等級
• 時間線：為瞭保障SLA，需要詳細記錄發現時間、通知負責人時間、響應時間、解決時間、關閉時間等，主要參照企業內部的相應考核標準以及對最終用戶的承諾標準。
• 參與人員（應急及事件場景不同參與人員會有所不同）：
• 事件指揮官
• 記錄員
• 聯絡員
• 還有哪些參與人：如不同領域的專傢、開發或測試等
• 針對該事件我們是如何響應的
• 做的好的地方：比如在之前的應急及事件響應過程中我們從來沒有使用過的流程、方法、技術等，這些可以大大改善事件響應時效的。
• 做得不好的地方：比如在響應過程中我們發現現有的流程或方法針對特定的環節會造成阻力，需要加以改善。
• 後續行動計劃
• 任何必要的修復措施，以防止類似的問題未來再次發生。如：
• 針對特定的指標監控太敏感瞭，需要在監控源做一些調整
• 由於程序的BUG引起，同工程研發團隊一起制定BUG修復計劃，並進入排期
• …
• 如果不能永久性修復，當再次發生類似的事件時，我們是否可以通過自動化手段快速修復。如：針對特定的告警，可以配置規則和自動修復腳本，當再次發生時，可以自動修復，而無需人工幹預。
• 針對現有的流程做優化，以提高響應的效率