事件追蹤
事件具有生命週期。 若要以最有效率的方式回應，則必須能夠從事件生命週期一開始就追蹤事件本身的發展，以及您對事件回應的發展。
評定所知的資訊
使用特定事件來評估事件追蹤程序的一種好方法就是詢問自己一系列問題：
- 您是什麼時候知道這個問題的？ 如果目標是要縮短從事件復原所需的時間，則必須在發現問題時就立即開始擷取資訊。
- 您是如何找出問題的？ 監視系統是否對事件發出了警示？ 您是否因客戶抱怨 (不論是直接或透過社交媒體) 才得知問題？
- 如果您剛剛才發現這個問題，則您是否為第一個知道的？ 如果是，您需要通知誰？ 如果不是，還有誰知道這個問題？
- 如果其他人知道，他們採取了什麼行動 (如果有的話)？ 是否所有人都認為其他人會深入了解問題，或有人已開始採取行動來解決此情況？
- 情形如何？ 我們可能對嚴重性或影響沒有概念，也無從了解問題實際上有多嚴重以及哪些人受到影響。
若沒有進行任何追蹤，這些便可能會是難以回答的問題。
標準化將追蹤事件資訊的位置
您可在許多可能的位置保存和共用事件清單 (使用中或非使用中)，以及所有與這些事件相關的目前資訊。 這些可以像 Word 文件的共用檔案區域一樣簡單，也可以像高度特殊化的事件追蹤軟體和服務一樣複雜。 介於這兩個極端之間的即為票證和工作追蹤系統，您可利用其完成這項工作。 實際上，您選擇哪個系統並不重要，重要的是使用方法。 無論您使用的系統為何，每個可能與事件相關的人員 (工程師、客戶支援、管理、公關、法務等) 都需要知道到哪裡尋找系統、如何提出事件，以及如何在適當的時機存取資料。 其中一個使事件追蹤失敗的確切方法便是讓其所支援對象在需要時不了解如何取得系統 (「我們系統的 URL 是什麼？」)。
在本課程模組中，我們會針對範例追蹤系統使用 Azure DevOps 的工作項目功能。
建立對話橋樑
若要回答上一節「評定您所了解項目」中的一些問題，並開始進行事件回應流程，您必須有方法可就該事件與其他人員進行溝通。 在理想情況下，這會是用於對話的某種「小組共同作業」電子媒介，雖然電話橋接器也能正常運作。 電話會議/電話橋接器是較不建議的方式，因為其較難以透過追溯方式檢閱事件通訊 (因此才會有先前提到的「抄寫員」角色)。
無論選擇的媒介為何，您應該確保有一個唯一的頻道，並嚴格限制在其中只能進行與此事件相關的討論。 將不相關的討論排除在此頻道以外相當重要，因為您稍後需要在事件後檢閱中擷取資料並進行分析。
在本課程模組中，我們會使用 Microsoft Teams 作為事件通訊方式。
自動化事件追蹤啟動
因此，讓我們先來檢閱到目前為止已收集到的部分。 我們有：
- 待命的人員名冊 (以及為這些人員定義的輪替)
- 我們可指派給事件負責人員的角色。
- 我們將宣告事件和進行追蹤的特定位置。
- 讓負責該事件的人員就事件進行溝通的唯一頻道。
您可以並應該盡可能將所有這些事情的建立和管理自動化。 當發生緊急問題時，您不會希望回想引發事件、將正確的人員帶至其中，以及進行追蹤所需要的所有步驟。 您只會想要按下「開始」按鈕，使其可立即開始處理問題。
使用 Logic Apps 以進行無程式碼自動化
其中一種自動化初始回應的方式是使用 Logic Apps，其可簡化排程、自動化及協調工作、商務流程和工作流程的作業。
Logic Apps 是一種用於建置整合解決方案的 Azure 雲端服務。 其會使用「連接器」來建立自動化工作流程。 「觸發程序」會在特定事件發生或資料符合指定準則時啟動 Logic Apps。 「動作」則是接著會在邏輯應用程式工作流程中執行的作業。
我們將針對範例使用下列 Logic Apps 連接器來進行事件追蹤：
- Azure Boards (Azure DevOps 的一部分)，您可將其用於建立和追蹤問題/事件。
- Azure 儲存體，您可在其中儲存並擷取待命人員資訊，以指派正確的人員來回應事件。 我們在範例中會使用 Azure 表格儲存體，因為其提供非常簡單的「機碼值」存放區，可輕鬆儲存工程師的清單及其待命狀態。
- Microsoft Teams，其可用於建立新的唯一事件頻道，在工程小組針對特定事件進行通訊時，以即時方式追蹤其對話。 這可讓您稍後在執行事件後檢閱時，保留與事件時間軸相關的互動。
現在讓我們使用邏輯應用程式，將這所有項目繫結在一起。 首先，讓我們來看看 Logic Apps 設計工具中顯示的完整應用程式，然後再引導您逐步進行。
第一個步驟是處理觸發程序，即我們提到的 HTTP 要求。 邏輯應用程式會收到 HTTP POST 要求，其中包含具備我們所希望宣告事件相關資訊的 JSON 承載。 我們會剖析該承載，並傳回及確認已收到該承載：
使用這項資訊，我們會在 Azure DevOps 組織中建立代表這個事件的新工作項目。
其接著會針對事件建立新的 Teams 頻道：
一旦頻道建立之後，先前建立的工作項目即會更新，並具備新頻道的連結。 這可將所有的資訊都保存在同一個位置 (工作項目)，並讓之後查看的人員了解若要加入頻道應前往何處。
現在我們該讓待命人員了解情況了。 我們會在 Azure 表格儲存體上查閱列為「待命」工程師的電子郵件地址。 這會傳回 JSON 回應以供剖析。
因為查詢會傳回清單，所以在下一個步驟中將需要逐一查看該清單中的每一個項目。 我們會將工作項目指派給每一名人員 (現在這些人員是事件的「擁有者」)。
然後是最後一個步驟，我們會傳送訊息至 Teams 頻道及工作項目指標給那些加入頻道且希望了解該事件權威資訊儲存位置的人員。
這只是其中一個我們如何將設定事件追蹤及通訊機制自動化的範例。 在下一個單元中，我們會進一步深入探討事件溝通的層面。