事后评审过程
- 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 资源管理器是一种基于 Web 的 API 浏览器，它允许你通过选择预填充的选项来选取 API 调用。 如下所示：
我们将逐步介绍一组用于检索会话的“Microsoft Teams”和“Microsoft Teams (beta)”API 调用。 每一步，我们将选择一个查询，运行查询，然后从响应中选择信息，帮助我们完成下一步。 然后，我们将使用此信息构造下一个请求。 例如，首先查询团队 ID 列表，以显示我们所属的团队。 我们从响应中选择所需的 ID，并将此 ID 插入到下一个查询 URL 中，以获取该团队中的频道列表。
下面是我们的步骤：
- GET "my joined teams"（找出我们所用团队的团队 ID）。
- GET "channels of a team which I am member of"（查找我们用于讨论该事件的频道的频道 ID）。
- 获取“通道中的消息”（用于检索对话）。
如果以后想要构造一个程序来执行上述每个步骤（确实如此），则请求窗口中有一个 代码片段 选项，该代码片段以许多不同的编程语言提供该查询的示例代码。
用于显示上下文的目标仪表板
通过 Azure 仪表板，我们可以将对我们运营意识至关重要的信息从 Azure Monitor 收集到一起，并集中在一个页面上展示。 用户界面允许我们选择显示的时间段，因此可以“倒回时间”，以便在选定时，显示事件关联时间段的仪表板信息，只要这些信息没有过期，不会从 Azure Monitor 中删除。 在尝试确定事件期间事件中人员看到的内容时，此重新构造的用户界面非常有用，但需要执行事件评审的人员手动查找正确的时间段。
Azure 上经常被忽视的仪表板的一项功能是，他们能够使用 “下载 ”（向下箭头）按钮将任何仪表板显示的模板转储到 JSON 文件中，并使用 “上传 ”（向上箭头）按钮重新加载它们。 这意味着，我们可以手动调整至合适的时间点，下载此状态下的仪表板，并将 JSON 文件与他人共享，或者直接下载当前的仪表板，并按照我们的规范修改 JSON。 如果在下载的 JSON 仪表板文件中搜索字符串“time”，你将看到如下所示的部分：
"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，用于浏览更改
Log Analytics 工作区可以从多个源（包括 Azure 活动日志）中获取数据。 首先，创建新的 Log Analytics 工作区。 然后，转到门户中的活动日志功能，然后选择 “诊断设置”。 这提供了将 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 工作区。 无法查询该工作区以回溯性地获取在建立连接前发生的事件的数据。
这些工具应该能够为收集在事后评审中使用的时间线所需的信息提供一个良好开端。 在深入探讨事后审查之前，我们希望向你发出警告，了解一些常见的陷阱。 这是我们下一单元的主题。