事件追蹤

事件有一個生命週期。為了最有效地做出回應，您需要能夠從該生命週期的一開始就追蹤事件本身的演變，以及您對事件的回應的演變。

評估你所知道的

使用特定事件評估事件追蹤程序的一個好方法是問自己一系列問題：

您第一次知道這個問題是什麼時候？如果您的目標是減少從事件中復原所需的時間，則需要從意識到問題的那一刻起就開始擷取資訊。
你是怎麼發現這個問題的？您的監控系統是否提醒您有關該事件？您首先是從客戶直接或在社交媒體上抱怨那裡聽說的嗎？
如果您剛剛發現這個問題，您是第一個知道的人嗎？如果是這樣，您需要通知誰？如果沒有，還有誰知道這個問題？
如果其他人知道，正在採取什麼措施（如果有的話）？是否每個人都認為其他人正在調查它，或者有人已經開始採取行動解決它？
有多糟糕？我們可能對嚴重性或影響沒有任何概念，也沒有地方讓我們知道問題到底有多嚴重以及誰受到影響。

如果沒有追蹤任何內容，這些問題可能很難回答。

標準化事件資訊的追蹤位置

您可以在許多可能的地方保存和共享您的事件清單（活動或其他）以及有關這些事件的所有當前信息。這些可以像帶有 Word 文檔的共享文件區域一樣簡單，也可以像高度專業化的事件跟踪軟件和服務一樣複雜。介於這兩個極端之間的是票務和工作跟踪系統，您可以將它們投入到此任務中。你選擇哪個系統實際上不如你如何使用它重要。無論您使用哪種系統，可能與事件有任何關聯的每個人（工程師、客戶支援、管理、公共關係、法律等）都需要知道在哪裡尋找系統、如何提出事件，以及如何在適當時存取資料。事件追蹤失敗的一種可靠方法是讓它將支援的人在需要時不知道如何存取系統（「我們系統的 URL 是什麼？

在本課程模組中，我們將針對範例追蹤系統使用 Azure DevOps 的工作專案功能。

建立對話橋樑

若要回答上述「 評估您所知道的內容」 一節中的一些問題，並開始事件回應程序，您必須有辦法與其他人就事件進行溝通。理想情況下，這將是某種用於對話的“團隊協作”電子媒體，儘管電話橋也確實有效。電話會議/電話橋不太受歡迎，因為追溯審查事件通信較困難（因此前面提到的“抄寫員”角色）。

無論您選擇哪種媒介，您都應該確保開闢一個獨特的管道，嚴格限於討論此事件，而不是其他內容。請務必將不相關的討論排除在此管道之外，因為您需要能夠獲取數據並在事件後審查中稍後進行分析。

在本課程模組中，我們將使用 Microsoft Teams 作為事件通訊方法。

自動啟動事件追蹤

那麼，讓我們回顧一下我們迄今為止整理的部分。我們有一個：

隨叫隨到的人員名冊（以及為他們定義的輪換）。
我們可以指派給處理事件的人員的角色。
我們將在具體地點宣布事件並對其進行跟踪。
為處理該事件的人員提供獨特的溝通渠道。

您可以而且應該盡可能自動化地建立和管理所有這些專案。當出現緊急問題時，您不想回憶提出事件、引入合適的人員並追蹤事件所需的所有步驟。您真正想做的就是能夠按下“開始”按鈕，以便工作可以立即開始處理問題。

使用 Logic Apps 進行無程式碼自動化

自動化初始回應的其中一種方式是使用 Logic Apps，這可以簡化排程、自動化和協調工作、商務程序和工作流程的工作。

Logic Apps 是用於建置整合解決方案的 Azure 雲端服務。它使用 連接器 來建立自動化工作流程。 觸發程序會在 發生特定事件或資料符合指定準則時啟動邏輯應用程式。動作是然後在邏輯應用程式工作流程中執行的作業。

在我們的範例中，我們將使用下列邏輯應用程式連接器來追蹤事件：

Azure Boards （Azure DevOps 的一部分），可用來建立和追蹤問題/事件。
Azure 儲存體，您可以在其中儲存和擷取待命人員的相關資訊，以便指派適當的人員來回應事件。在我們的範例中，我們將使用 Azure 資料表儲存體，因為它提供非常簡單的「索引鍵值」存放區，可讓您輕鬆儲存工程師清單及其待命狀態。
Microsoft Teams，您可以使用它來建立新的、獨特的事件通道，以即時追蹤工程小組在通訊特定事件時的交談。這可讓您稍後在執行事件後檢閱時保留與事件時間表相關的互動。

現在讓我們將所有這些與邏輯應用程式連結在一起。首先，查看完整的應用程式，如邏輯應用程式設計工具中所示，然後我們將逐步逐步解說。

邏輯應用程式設計工具中顯示的邏輯應用程式縮小檢視的螢幕擷取畫面。