事件後檢討流程

事件後檢閱的關鍵部分是建構反映事件非線性性質的共享、準確的時序表。

非線性是指事件幾乎從來不是簡單的“某件事情發生，接著另一件事情發生，然後我們注意到，接著採取了一些措施，最後完成。” 而是在這個過程中，人們進進出出，不同的人注意到問題並嘗試不同的解決方法；其中一些方法有效，而另一些則無效。 如果多人同時工作，這些事情也會同時發生，所以這有點複雜。

若要建立這樣的時程表，即使是複雜的時間軸，總會有重要的第一個步驟：收集數據。

收集資料

您必須先收集數據，才能進行事件后檢閱。 具體來說，您需要盡可能地收集與事件相關的交談和背景資料，包括技術性和非技術性的內容，從而利用其中所包含的所有關鍵數據。 在中斷或事件期間發生的小組成員之間的交談將是您最豐富的資訊來源之一。

您也應該從監視系統和事件涉及人員獲取相關資訊的其他地方收集資料。 事件發生時，他們從您的系統取得哪些資訊？

最後，如果可能的話，最好能更清楚地瞭解事件之前和事件期間變更的內容，因為變更通常是在事件發生時造成因素。

我們可以將此程式視為三個不同的部分：

• 收集對話：在此學習路徑的其他課程模組中，我們提到，在事件期間為人們建立一個特定的場所進行溝通是很重要的。 在事件期間，理想情況下，人們會分享哪些有效的方法和失敗的經驗，以及他們猶豫不決嘗試的事情和他們過去曾嘗試的事情。 這種人們在努力解決問題時的對話是您最佳的學習來源。
• 判斷內容：事件中的人員正在接收來自不同地點的訊號。 其中一個主要位置是監控系統。 我們已討論在此學習路徑中，在上一個課程模塊中擁有穩固的監視系統的重要性。 在理想情況下，我們應該能夠查看監視系統，以在事件前後或與事件相關的時段內建立時間點快照集。
• 尋找變更：您可以透過活動和稽核記錄來執行此動作。

可協助收集數據的 Azure 工具

Azure 提供一些工具，可協助進行此程式：

用來保存事件相關元數據的 Azure DevOps

在此學習路徑的上一個課程模組中，我們已討論如何使用 Azure DevOps 套件中的 Azure Boards 作為收集從初始響應開始之事件的所有資訊。 這有助於我們回答事件首次被宣布的時間、誰值班、誰被指派至事件等等的問題。 您也可以使用 Azure DevOps Wiki 作為集中管理的工具，匯總事件本身和事件過程中發生的交談資訊。

Microsoft Graph API 用於擷取對話

Microsoft Graph API 提供了一種編程方式來尋找，匯出及引入在 Teams 通道中所蒐集並與該特定事件有關的對話。 擷取的數據也包含元數據，在建構時序時會很有用，包括誰聯結通道（以及何時）和交談個別部分的時間戳。

開始使用 Microsoft Graph API 的一個簡單方法是使用 Microsoft Graph 總管。 Microsoft Graph Explorer 是一個網頁介面的 API 瀏覽工具，它允許您透過選擇預填的選項來挑選 API 呼叫。 其看起來會像下面這樣：

我們將逐步執行一組「Microsoft Teams」和「Microsoft Teams（beta）」API 呼叫，以擷取交談。 我們會選擇查詢、執行查詢，然後從響應中選取資訊，以協助我們進行下一個步驟。 然後，我們會使用此資訊來建構下一個要求。 例如，我們先查詢小組標識符清單，以顯示我們所屬的小組。 我們從響應中選擇所需的標識碼，並將此標識元插入下一個查詢 URL，以取得該小組中的頻道清單。

以下是我們的步驟：

1. GET "my joined teams" (尋找我們所使用團隊的團隊 ID)。
2. GET "channels of a team which I am member of" (尋找我們用於該事件的頻道的頻道 ID)。
3. 取得「頻道中的訊息」（以擷取對話）。

如果我們稍後想要建構程式來執行上述每個步驟（事實上確實如此），要求視窗中有一個 代碼段 選項，以許多不同的程式設計語言呈現該查詢的範例程式代碼。

用於顯示內容的目標儀表板

Azure 中的儀錶板可讓我們從 Azure Monitor 收集重要的資訊，並在單一頁面上集中顯示，以提升操作意識。 使用者介面可讓我們選擇要顯示的時間區段，因此，如果我們希望在資訊不太舊而仍可在 Azure Monitor 中保留的情況下「倒轉時間」，就能顯示與事件相關的時間段儀錶板資訊。 此重新構建的使用者介面在嘗試判斷事件中的人員在期間看到的內容時非常有幫助，但需要事件回顧者手動找出正確的時間段。

Azure 儀錶板經常被忽略的一個功能，是可以使用 [下載] 按鈕，將當前顯示的儀錶板範本以 JSON 檔案格式匯出，並使用 [上傳] 按鈕再次載入匯出的範本。 這表示我們可以手動尋找正確的時間、在該狀態下下載儀錶板，並與其他人共用 JSON 檔案，或只是下載目前的儀錶板，並將 JSON 修改為我們的規格。 如果您在下載的 JSON 儀錶板檔案中搜尋字串 「時間」，您將會看到如下所示的區段：

"metadata": {
  "model": {
    "timeRange": {
      "value": {
        "relative": {
          "duration": 24,
          "timeUnit": 1
        }
      },
      "type": "MsPortalFx.Composition.Configuration.ValueTypes.TimeRange"
    },
    "filterLocale": {
      "value": "en-us"
    },
    "filters": {
      "value": {
        "MsPortalFx_TimeRange": {
          "model": {
            "format": "utc",
            "granularity": "auto",
            "relative": "24h"
          },
          "displayCache": {
            "name": "UTC Time",
            "value": "Past 24 hours"
          },

將本節修改為您的規格並重新載入。 如果您不熟悉使用中的格式，您可以手動變更儀錶板，下載並查看所需的格式。

稽核記錄和日誌分析來探索變更

Log Analytics 工作區可以從許多來源擷取數據，包括 Azure 活動記錄。 首先，建立新的記錄分析工作區。 然後，移至入口網站中的 [活動記錄] 功能，然後選擇 [ 診斷設定]。 這提供將 Azure 訂用帳戶的活動記錄傳送至新工作區的選項。

在短時間內，您將能夠使用 Kusto 查詢語言（KQL）的全部功能，來擷取自您連接資料來源以來該訂閱服務中所發生的變更詳細資訊。

例如，下列查詢會顯示已變更或已刪除之資源的相關信息。 我們可以在查詢瀏覽器中設定查詢的時間範圍，以便更精確地聚焦於事件發生前不久的時間範圍，如果我們需要這樣做的話。

AzureActivity
| where CategoryValue == 'Administrative'
| where OperationNameValue endswith "write" or OperationNameValue endswith "delete"
| project TimeGenerated, Level, ResourceGroup, ResourceId, OperationName, OperationNameValue, ActivityStatus, Caller
| order by TimeGenerated nulls first

一個快速注意事項：當您將 Azure 活動記錄設定為數據源時，資訊會從該時間點開始流入 Log Analytics 工作區。 您將無法針對在建立連接之前發生的事件，查詢該工作區以取得資料追溯。

這些工具應該能夠讓您開始收集在事件後檢閱中使用時序表所需的資訊。 在您立即開始進行事後檢討之前，我們想要警告您一些常見的陷阱。 這是我們下一個單元的主題。