事件後檢討流程
- 7 分鐘
事件後檢閱的關鍵部分是建構反映事件非線性性質的共享、準確的時序表。
非線性是指事件幾乎從來不是簡單的“某件事情發生，接著另一件事情發生，然後我們注意到，接著採取了一些措施，最後完成。” 而是在這個過程中，人們進進出出，不同的人注意到問題並嘗試不同的解決方法；其中一些方法有效，而另一些則無效。 如果多人同時工作，這些事情也會同時發生，所以這有點複雜。
若要建立這樣的時程表，即使是複雜的時間軸，總會有重要的第一個步驟：收集數據。
收集資料
您必須先收集數據，才能進行事件后檢閱。 具體來說，你需要盡可能收集圍繞該事件的對話和背景（包括技術與非技術層面），以便利用其中所有關鍵資料。 在中斷或事件期間發生的小組成員之間的交談將是您最豐富的資訊來源之一。
您也應該從監視系統和事件涉及人員獲取相關資訊的其他地方收集資料。 事件發生時，他們從您的系統取得哪些資訊？
最後，如果可能的話，最好能更清楚了解事件發生前後的變化，因為變化往往是事件發生時的促成因素。
我們可以將此程式視為三個不同的部分：
- 收集對話：在此學習路徑的其他課程模組中，我們提到，在事件期間為人們建立一個特定的場所進行溝通是很重要的。 在事件期間，理想情況下，人們會分享哪些有效的方法和失敗的經驗，以及他們猶豫不決嘗試的事情和他們過去曾嘗試的事情。 這種人們在努力解決問題時的對話是您最佳的學習來源。
- 判斷內容：事件中的人員正在接收來自不同地點的訊號。 其中一個主要位置是監控系統。 我們已討論在此學習路徑中，在上一個課程模塊中擁有穩固的監視系統的重要性。 在理想情況下，我們應該能夠查看監視系統，以在事件前後或與事件相關的時段內建立時間點快照集。
- 尋找變更：您可以透過活動和稽核記錄來執行此動作。
Azure 工具協助收集資料
Azure 提供多種工具協助此流程：
Azure DevOps 用來保存事件的元資料
在本學習路徑的前一單元中，我們討論過如何在 Azure DevOps 套件中使用 Azure Boards，作為從初始回應開始收集所有事件資訊的平台。 這有助於我們回答事件首次被宣布的時間、誰值班、誰被指派至事件等等的問題。 你也可以利用 Azure DevOps Wiki 作為集中式方式，整合事件本身及事件期間對話的部分資訊。
Microsoft Graph API 用於擷取對話內容
Microsoft Graph API 提供一種程式化方式，讓使用者能擷取該事件專屬 Teams 頻道內收集的對話內容。 檢索的資料包括時間戳記、作者、編輯、回覆及部分系統訊息，這些都能在建立時間順序時有所幫助。
開始使用 Microsoft Graph API 的一個簡單方法是使用 Microsoft Graph Explorer。 Microsoft Graph Explorer 是一款基於網頁的 API 瀏覽器，允許你從
在執行查詢前，請確認你使用的使用者或應用程式擁有你所選擇存取模式所需的權限與同意。 在委派情境中，列出已加入的團隊使用 Team.ReadBasic.All、列出頻道使用 Channel.ReadBasic.All，閱讀頻道訊息需要 ChannelMessage.Read.All。 如果後續使用僅限透過應用程式存取的方式將工作流程自動化，請使用GET /users/{id | user-principal-name}/joinedTeams，而非僅限委派存取的/me/joinedTeams別名，並採用Team.ReadBasic.All應用程式權限。 在與頻道相關的讀取步驟中，最低權限的僅限應用程式選項是 ChannelSettings.Read.Group 用於列出頻道和 ChannelMessage.Read.Group 用於閱讀訊息，兩者都需要資源特定授權。
我們將逐步解析一組 Microsoft Graph v1.0「Microsoft Teams」API 呼叫，以取得對話內容。 （通道訊息數年前已從 beta 升級到 v1.0，因此此情境不再需要測試端點。）在每個步驟中，我們會選擇一個查詢，執行查詢，然後從回應中選擇有助於下一步的資訊。 然後，我們會使用此資訊來建構下一個要求。 例如，首先我們查詢一份團隊 ID 清單，以顯示我們所屬的團隊。 我們從響應中選擇所需的標識碼，並將此標識元插入下一個查詢 URL，以取得該小組中的頻道清單。
以下是我們的步驟，以 Microsoft Graph v1.0 端點展示：
-
GET /me/joinedTeams（用來查找我們在委派情境中使用的隊伍 ID）或GET /users/{id | user-principal-name}/joinedTeams（在僅用應用程式的情況下做同樣的事）。 -
GET /teams/{team-id}/channels(用於找出我們針對該事件所使用通道的通道識別碼)。 -
GET /teams/{team-id}/channels/{channel-id}/messages?$expand=replies（以取得執行緒對話）。 - 請視需要跟隨
@odata.nextLink與replies@odata.nextLink，或呼叫GET /teams/{team-id}/channels/{channel-id}/messages/{message-id}/replies，以便透過分頁瀏覽較大的討論串。
如果你使用共享頻道，請注意 joinedTeams API 不會回傳用戶作為直接成員的共享頻道的主辦團隊。 此限制條件適用於無論你選擇GET /me/joinedTeams或GET /users/{id | user-principal-name}/joinedTeams。 在這種情況下，從已知的團隊和通道識別碼開始，或使用相關的團隊 API 來定位主機團隊。
在圖譜檔案管理器中，你可以直接輸入這些網址，或從內建的範例查詢面板Microsoft Teams中選擇等效條目。
如果我們稍後想要建構程式來執行上述每個步驟（事實上確實如此），要求視窗中有一個 代碼段 選項，以許多不同的程式設計語言呈現該查詢的範例程式代碼。
根據團隊如何使用 Teams，訊息歷史紀錄也可能包含系統訊息，幫助說明成員何時被加入或移除。 不過，如果需要通道會員資格或存取權變更的授權稽核軌跡，請以 Microsoft 365 稽核記錄檔來補充此資料。
用於顯示內容的儀表板與活頁簿
Azure 儀表板和 Azure Monitor 工作簿都能幫助重建操作員在事件中看到的情境。 儀表板對於 Azure 服務的營運概覽非常有幫助。 工作簿通常更適合事件分析，因為它們支援更豐富的查詢、參數、深入分析和敘述性文字，並搭配圖表。
如果你已經有一個儀表板或工作簿能捕捉到正確的訊號，可以將其時間範圍設為事件發生前後的時期，並用它來重建當時人們所看到的情況。 這在將指標、日誌和警示跨多個資源關聯時特別有用。
共享儀表板是 Azure 資源，仍然可以從入口網站匯出成 JSON。 這個匯出/匯入路徑在你想要版本化或模板化儀表板時很有用。 然而，對於大多數事件後調查情境，工作簿是更靈活的工具，因為它們允許你將視覺化、KQL 查詢與說明文本整合於單一工件中。
活動記錄、資源記錄以及用於變更探索的記錄分析
Log Analytics 工作區可以接收來自多種來源的資料，包括 Azure 活動日誌、Azure 資源日誌以及服務專屬診斷。 首先，建立一個新的 Log Analytics 工作區。 接著，在Azure入口開啟 Monitor → Activity log，並選擇面板頂端的 Export Activity Logs。 這會開啟一個診斷設定，讓你能將 Azure 訂閱的活動日誌傳送到你的工作空間。
很快地，你就能使用 Kusto 查詢語言（KQL）取得自連接資料來源以來訂閱中發生的詳細變更資訊。
例如，以下查詢顯示已變更或刪除的資源資訊。 我們可以在Logs經驗中設定時間範圍，更精確地鎖定事件發生前不久的時期。
AzureActivity
| where CategoryValue == 'Administrative'
| where OperationNameValue endswith "write" or OperationNameValue endswith "delete"
| project TimeGenerated, Level, ResourceGroup, ResourceId, OperationName, OperationNameValue, ActivityStatusValue, Caller
| order by TimeGenerated desc
此查詢對於管理層面的變更很有用，但請記住不會顯示出的內容。
AzureActivity 擷取控制平面操作，如建立、更新、刪除及策略操作。 它不會捕捉服務內的資料平面或應用層變更。 要調查這些資料，請將此查詢與 Azure 資源日誌、服務專屬稽核日誌、部署歷史，以及 CI/CD 或原始碼控制記錄搭配使用。
簡單說明：當你匯出 Azure 活動日誌時，資訊會從那個時間點開始流入 Log Analytics 工作區。 你無法追溯查詢該工作區中發生在你建立連結前的事件。
這些工具應該能夠讓您開始收集在事件後檢閱中使用時序表所需的資訊。 在您立即開始進行事後檢討之前，我們想要警告您一些常見的陷阱。 這是我們下一個單元的主題。