补救
正如本模块中所述，将事件响应生命周期划分为五个阶段有助于理解该过程，但这些阶段并不总是像关系图中显示的那样明确。 具体而言，响应和修正阶段之间的界限通常会开始变得模糊起来。 尤其是当旨在缓解或改善情况的操作具有相反的效果时。 在这种情况下，响应和修正往往会重叠或者两者之间会来回切换。
在本单元中，你将详细了解修正以及构成此阶段的步骤，以及一些有用的提示和工具。 需要注意的一个重要事项是：不应将此处概述的措施作为规范性清单。
如果你确实已经有了修正的清单，那通常指示是时候引入自动化了。 当你可以准确描述需要完成的任务以及修正问题的顺序时，这正是将这些步骤教给计算机的最佳时机，这样系统就可以为你执行任务。
从哪里开始
你已经了解了降低响应事件所需时间的重要性。 现在，让我们来关注一些有助于加快修正或修复问题过程的内容。
不同的团队成员可能对事情如何运作会有不同的心理模型，并且对第一步应该做什么会有不同的想法。 有的成员可能首先查看日志，而有的成员则可能首先运行查询并查看指标。 通往成功的道路不止一条。
但是，最好能为相关人员提供上下文以及从何处着手和应关注的内容的指导。
如何上报问题以及向谁上报
在制定修正起点时要回答的一个重要问题是：当你受阻时，你可以向谁上报问题？ 一般而言，你应该尝试将更多的待命责任分摊到团队身上，而不仅靠操作或站点可靠性工程团队。 所有团队成员都需要负责维持系统的稳定运行以满足可靠性目标。
哪些资源对第一个响应者有用？
下一步要考虑的是确定第一响应者可用于开始进行处理所需的内容。 这可能包括相关指标、日志和查询等。 如有可能，这些内容应提供在 Azure 工作簿/疑难解答指南中。 稍后我们将对此进行探讨。
此外，提供转到资源的简单链接也会非常有用（通常在故障排除指南中提供）。 如果你的目标是尽可能快速地响应并修正问题，那么帮助相关人员无需搜索正确的文档或 URL 即可找到问题的答案将加快处理过程。
向利益干系人报告最新进展
在修复问题时，你可以会非常专注，以至于可能会忘记还有许多人没有直接参与到事件响应，但他们希望并且需要知道发生了什么。
请务必与其他内部团队进行交流，以告知他们事件发生时所发生的情况。 如果没有向他们提供一致的最新动态，他们可能会过来询问最新的进展。 他们完全有权了解此信息，但你需要通过更好的方式让他们意识到问题，以及正在采取的处理措施。
你需要向内部团队清楚地说明当前的情况。 清楚地说明你所了解的情况以及正在采取的措施，并且告知他们何时会得到你的反馈。
与利益干系人交流的公式十分简单：
- 这是我们知道的。
- 这就是我们正在做的。
- 我们将在 X 时间内回复你。
这有助于防止利益干系人在你正在尝试修复问题时前来打断你的工作。
分发此信息的一个方式是使用易于编辑的状态网页，比如我们在上一单元中提到的一个页面。 在很多情况下，你可能希望为内部利益干系人提供一个单独且更加详细的状态页面，并为客户提供一个外部页面。 上述公式适用于这两种情况。
使用 Azure Monitor 工作簿和疑难解答指南
Azure 有两个密切相关的功能，可在修正阶段为团队带来极大的帮助：Azure Monitor 工作簿和 Application Insights 疑难解答指南。 就本模块而言，它们是可以互换的，包括具有相同的用户界面。 可以在 Azure 门户中的 Azure Monitor 下找到 Azure Monitor 工作簿。 选择 Application Insight 实例后，可以在 Azure 门户中找到 Azure Insights 故障排除指南。
可以将工作簿和故障排除指南视为你可以使用页面创建界面创建的“实时文档”。 当创建以下新的内容时，可以将它添加到页面：
- 任意文本，例如待办事项的项目列表或其他对查阅页面的人员有用的信息
- 指向其他系统的链接，例如，指向其他仪表板或文档的链接
- Kusto 查询语言 (KQL) 查询
最后一项正是文档被视为“实时”的原因。在此学习路径的上一模块中，我们探讨了内置于 Log Analytics 的 KQL 查询语言和 Azure Monitor 的其他部件。 通过使用此语言，我们可以编写我们自己的查询，从我们的应用程序和 Azure 基础设施返回并显示诊断信息。 将 KQL 查询插入到工作簿或故障排除指南后，该查询的当前结果会实时显示给文档的读者。 这意味着不仅可以在疑难解答指南上声明“请确保检查 Web 服务器上的错误率”，还可以在这些说明的旁边显示该错误率的当前关系图。 它可以有一个类似“此处为 Web 服务器重启文档”的链接，将第一响应者转至他们所需的文档。
Azure 还提供了一些现有模板，有助于开始创作你自己的文档。 以下是可能会向你提供的一些预生成的模板的屏幕截图：
工作簿和故障排除指南具有一项“高级编辑器”功能，支持访问和插入该文档的 JSON 或 Azure 资源管理器模板表示形式。 这意味着可以使用所选择的源代码管理系统跟踪和分发这些文档。 此外，使用此功能还可以实现工作簿或故障排除指南的自动预配，这在预配其他基础设施时会非常有用。 使用此最佳做法，在预配新服务时创建一组随附的自定义故障排除文档就会非常轻松。
其他有用的提示和工具
通过本模块的学习，你了解了可用于提高事件响应效率和减少响应时间的各种工具和快捷方式。 在结束这最后一个单元时，我们将简要概述一些有助于诊断系统问题的工具和技术。
- 可以使用 Application Insights 中的“应用程序仪表板”链接来自动生成一个作为起点的仪表板，以将所需的大部分关键项包含在内。 请注意，它并不包含 Azure 服务运行状况。 你应该将这固定到你的仪表板，以便检查问题是与系统有关还是与云服务本身有关。
- 可以使用 Application Insights 中的应用程序映射来深入分析导致问题的准确原因。 你可以按照痕迹导航找出错误的原因（例如，格式不正确的 URL）。
- 可以使用 Log Analytics 查询系统的任何部分。
上述所有工具在解决问题方面都是宝贵的。