事后回顾的过程
事后回顾的关键部分之一是构造一个共享的准确时间表，来反映事件的非线性本质。
“非线性”的意思是，事件几乎从来不是“发生了这件事，然后发生了那件事，然后我们注意到了，并采取了某些操作，然后就结束了”。系统中人来人往，不同的人会注意不同的情况、尝试不同的操作；有点操作会奏效，有的不会。 如果有多个用户同时工作，这些操作也可能同时发生，因此这有点复杂。
要创建这样的时间表，即使是复杂的时间表，总是存在重要的第一步：收集数据。
收集数据
首先需要收集数据，然后才能进行事后回顾。 具体来说，需要尽可能地收集有关事件的对话和（技术性和非技术性）上下文，以便使用其中包含的所有重要数据。 团队成员在中断或事件期间的对话是最有价值的信息来源之一。
还应从监视系统和引发事件的上下文所涉及的其他位置和人员那里收集数据。 事件发生时，他们正在从系统获取哪些信息？
最后，如果有可能，更好地了解事件前和事件中发生的变化会很有帮助，因为变化经常是导致事件发生的因素之一。
我们可以将此过程看作三个独立部分：
- 收集对话：在本学习路径所含的其他模块中，我们曾提到过，留出特定的位置让人们在事件过程中进行交流非常重要。 理想情况下，人们会在事件过程中分享有效和无效的操作，以及让他们犹豫和他们过去尝试过的操作。 人们经历和解决问题时进行的这种对话是最好的学习资源。
- 确定上下文：事件中的人会接收来自四面八方的信号。 其中一个主要位置是监视系统。 我们已在在此学习路径所含的前置模块中讨论了拥有可靠监视系统的重要性。 理想情况下，我们应该能够依赖监视系生成事件前后或相关时段的时间点快照。
- 找到变化：可以通过活动和审核日志来找到变化。
可帮助收集数据的 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 是一种基于 web 的 API 浏览器，使用它，你可以通过选择预填充的选项来选取 API 调用。 它的外观如下所示：
我们将逐步介绍一组用于检索会话的“Microsoft Teams”和“Microsoft Teams (beta)”API 调用。 在每一步中，我们都会选择一个查询，运行该查询，然后从响应中选择可帮助我们执行下一步操作的信息。 然后，我们使用此信息来构造下一个请求。 例如，我们首先会查询一个团队 ID 列表，以显示我们所属的团队。 我们会从响应中选择需要的团队，然后将此 ID 插入到下一个查询 URL，以获取该团队中的频道列表。
操作步骤如下：
- GET "my joined teams"（找出我们所用团队的团队 ID）。
- GET "channels of a team which I am member of"（查找我们用于讨论该事件的频道的频道 ID）。
- GET "messages in a channel"（检索会话）。
如果我们稍后想要构造一个程序来执行以上每个步骤（我们确实要这么做），请求窗口中有一个代码片段选项，其中显示了各种编程语言进行该查询的示例代码。
用于显示上下文的目标仪表板
使用 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 工作区。 无法查询该工作区以回溯性地获取在建立连接前发生的事件的数据。
这些工具应该能为你提供一个良好的开端，让你可以收集必要的数据，创建时间表以便在事后回顾中使用。 在你开始进行事后回顾之前，我们想提醒你警惕一些常见的陷阱。 这就是下一单元的主题。