事件跟踪
事件有一个生命周期。 若要最有效地做出响应，你需要能够从该生命周期的一开始就跟踪事件本身的发展以及你对它做出的响应的发展。
评估你知道的内容
使用特定事件评估事件跟踪过程的一种好方法是向自己提出一系列问题：
- 你第一次知道出现问题是什么时候？ 如果你的目标是减少从事件中恢复所需的时间，你则需要从意识到问题的那一刻起开始捕获信息。
- 你是如何发现问题的？ 你的监视系统是否向你发出了事件的警报？ 你是否是从直接向你抱怨或者在社交媒体上进行抱怨的客户口中第一次得知问题的存在？
- 如果你刚好发现了问题，你是否是第一个知道的人？ 如果是，那么你需要通知谁？ 如果不是，那么谁还知道存在这个问题？
- 如果有其他人知道，那么他们已经采取了什么措施（如果有）？ 是不是所有人都假设有人正在调查问题，还是有人已经开始采取措施来解决它？
- 问题的严重程度如何？ 我们可能没有严重性或影响的概念，我们无法确定问题究竟有多严重以及谁会受到影响。
如果没有跟踪任何内容，那么这些问题可能十分难以解答。
规范将跟踪事件信息的位置
有很多可以保存并共享事件（活动或非活动）列表和与这些事件相关的所有交流的位置。 可以是包含 Word 文档的简单的共享文件区域，也可以是高度专业化的事件跟踪软件和服务一样复杂的位置。 在这两者之间，票证和工作跟踪系统分别是两个极端，可以引入到服务中来执行此任务。 实际上，选择哪个系统没有使用系统的方式那么重要。 无论使用的是哪个系统，可能与事件有任何关联的每个人（工程师、客户支持、管理层、公共关系和法务人员等）都需要知道在何处可以找到系统、如何上报事件以及在适当时如何访问数据。 如果不让提供支持的人员知道如何在需要时访问系统（“我们系统的 URL 是什么？”），那么事件跟踪必会失败。
在本模块中，我们会将 Azure DevOps 的工作项功能用于我们的示例跟踪系统。
创建对话网桥
若要回答之前的“评估你知道的内容”部分中的一些问题并开始启动事件响应过程，必须通过一种方式来与其他人交流事件相关的内容。 理想情况下，这应该是用于对话的某种类型的“团队协作”电子媒介，尽管通过电话网桥也能进行良好的沟通。 电话会议/电话网桥不太可取，因为如果使用这种交流方式，则更难以追溯方式查看事件交流内容（因此之前提到过“抄写员”角色）。
无论选择什么媒介，你应该确保划分出一个唯一的频道，此频道严格被限制为只讨论此事件相关的内容。 务必不要在此频道中讨论其他不相关的内容，因为你需要在日后的事后回顾中提取数据并进行分析。
在本模块中，我们将使用 Microsoft Teams 作为我们的事件交流方法。
自动启动事件跟踪
让我们来回顾一下已经整理好的内容。 我们有：
- 待命的人员名单（以及为他们定义的轮换）。
- 可以分配给处理事件的人员的角色。
- 我们要在其中声明事件并且进行跟踪的特定位置。
- 用于使处理事件的人员进行交流的唯一频道。
你可以并且应该尽最大可能自动化所有这些事项的创建和管理。 出现紧急问题时，你无需重新执行引发事件、确定正确的人员进行调查并进行跟踪所需的所有步骤。 你真正需要的是只需按“开始”按钮即可立即进行开始处理问题的工作。
使用逻辑应用实现无代码自动化
自动执行初始响应的一种方法是使用逻辑应用，这可以简化对任务、业务过程和工作流进行安排、自动化和协调的工作。
逻辑应用是一项 Azure 云服务，用于构建集成解决方案。 它使用“连接器”来创建自动化的工作流。 “触发器”会在特定事件发生或者在数据满足特定条件时启动逻辑应用。 “操作”是随后在逻辑应用工作流中执行的操作。
在我们的示例中，我们将使用以下逻辑应用连接器来进行事件跟踪：
- Azure Boards（Azure DevOps 的一部分），可用于创建和跟踪问题/事件。
- Azure 存储，可以在其中存储和检索待命人员的信息，使你能够分配正确的人员来对事件做出响应。 在我们的示例中，我们将使用 Azure 表存储，因为它可以提供非常简单的“键值”存储，易于存储工程师以及他们待命状态的列表。
- Microsoft Teams，可用于创建唯一的新事件频道，从而在工程团队交流特定事件时实时跟踪他们的对话内容。 这使你之后在执行事后回顾时能够保留与事件时间线相关的交互内容。
现在，我们通过逻辑应用将所有这一切关联在一起。 首先，我们来看一看逻辑应用设计器中所示的完整应用，然后我们将逐步对此进行讲解。
第一步是处理触发器，即我们提及的 HTTP 请求。 HTTP POST 请求会发送给我们的逻辑应用，其中包含随附我们希望声明的事件相关信息的 JSON 有效负载。 我们会分析此有效负载并且发回我们收到了它的确认信息：
通过使用此信息，我们会在我们的 Azure DevOps 组织中创建表示此事件的新的工作项。
随后它将为事件创建新的团队频道：
创建此频道后，我们之前创建的工作项中会更新转至此新的频道的链接。 这会将所有信息保存在同一位置（工作项），并且使稍后查看这些信息的人员能够知道在什么位置查看（如果他们想加入此频道）。
现在是时候引出待命的人员了。 我们会在 Azure 表存储中查找被列为待命人员的工程师的电子邮件地址。 这将返回一个 JSON 响应，我们随后会分析此响应。
由于我们的查询将返回列表，因此，我们下一步需要循环访问此列表中的每一项。 我们将工作项分配给每名人员（他们现在是事件的“所有者”）。
最后，我们会将消息发送到 Teams 频道，其中包含返回工作项的指针，供想要加入频道并且想知道事件的权威信息存储位置的人员使用。
这只是我们可以如何自动设置事件跟踪和交流机制的一个示例。 在下一单元中，我们将深入探讨有关事件交流的方面。