第7章 高效处理事件响应与无指责事后复盘
章节目标
在本章中，你将了解事件响应与无指责事后复盘实践，这是 Dickerson 可靠性层次结构中提到的两大支柱。
事件无法避免；不存在100%可靠的系统，因此你的重点应放在减少这些事件可能产生的负面影响上。
学完本章后，你将能够：
- 理解事件响应（定义、生命周期/阶段及角色）
- 改进沟通实践并使用 Microsoft 工具实现 ChatOps
- 学习如何使用 Azure 检测事件
- 学习如何使用 Azure 诊断事件
- 学习如何使用 Azure 修复事件
- 理解无指责事后复盘
事件响应 (Incident Response, IR)
如前面章节所述，组织正在设计架构和自动化流程，以确保运行环境中不会出现问题。我们的 CI/CD 流程包含了 Git 分支策略、拉取请求、各类测试/安全工作负载以及现代部署实践，目标正是如此。然而，现场事件仍会不断发生，阻止所有事件是不现实的，认为“这永远不会发生在我身上”也无济于事。
转变心态是改进的关键。组织需要拥抱一种文化，让工程师相信故障/事件会发生，并据此采取行动。认为“事情永远不会出错”只会让你在这些情况下毫无准备。
实际上，如今许多组织会进行红队/蓝队演练，以便为这些情况做好准备：
- 蓝队： 蓝队负责保护组织的 IT 基础设施。他们的任务包括监控系统的可疑活动、进行定期安全评估，以及实施安全措施以防御网络威胁。他们专注于事件响应、威胁检测和修复，以确保组织系统安全。
- 红队： 红队模拟对组织 IT 基础设施的攻击，以识别漏洞和弱点。他们使用各种技术来模拟真实攻击者的行为，例如渗透测试、社会工程学和利用安全漏洞。红队活动的目标是挑战蓝队的防御，并提升组织的整体安全态势。
这些活动对于维护稳健的网络安全策略至关重要，因为它们帮助组织识别并解决潜在的安全漏洞，并在一个“模拟”的安全环境中演练事件响应实践。
回到前面章节，我们的目标是减少与问题相关的工作负担。事件响应阶段将定义我们如何处理现场问题。每个组织都需要定义一个框架，提供结构化的指导，帮助 IT 人员高效地阻止、遏制事件并从事件中恢复。
本章将重点展示公司在管理事件方面采用的最佳实践。但什么是事件？
对此并没有统一的定义。我们可以将其定义为影响客户的服务中断。事件可能是安全相关的（如拒绝服务攻击），也可能是性能相关的（例如，你的 VM 无法处理足够的请求负载）。
有许多事件框架可以帮助你定义事件响应 (IR) 指导。让我们看看一些公共 IT 组织定义的框架/模板的主要特征。
表 7-1. 事件响应框架
| NIST | ISO | SANS |
|---|---|---|
| 准备 (Preparation) | 准备 (Prepare) | 准备 (Preparation) |
| 检测与分析 (Detection and analysis) | 识别 (Identify) | 识别 (Identification) |
| 遏制、根除与恢复 (Containment, eradication, and recovery) | 评估 (Assess) | 遏制 (Containment) |
| 响应 (Respond) | 根除 (Eradication) | |
| 恢复 (Recovery) | ||
| 事后活动 (Postincident activity) | 学习 (Learn) | 经验教训 (Lessons learned) |
- 准备/就绪： 这是相关的预防活动（弹性架构、自动化流程、知识转移和主动监控）。
- 检测/识别： 收到问题通知并理解问题的本质。
- 解决阶段： 此阶段在不同框架中有所不同，但主要集中在解决该问题的响应性活动上。这可能是流程中最长、最复杂的阶段。
- 响应： 首先，我们专注于控制问题，减少影响面。
- 修复： 然后，我们致力于修复/根除：
- 测试/验证问题已修复。
- 事后/学习/分析： 这将是本章第二节（无指责事后复盘）的重点。每个问题都必须被视为一个学习机会（并避免将来出现类似问题）。
graph LR subgraph 事件生命周期 (Incident Life Cycle) A[准备/就绪<br>Preparation/Readiness] --> B[检测/识别<br>Detect/Identify]; B --> C[响应<br>Response]; C --> D[修复<br>Remediation]; D --> E[事后/学习<br>Postincident/Learning]; E --> A; end C --> E; style A fill:#f9f,stroke:#333,stroke-width:2px style B fill:#bbf,stroke:#333,stroke-width:2px style C fill:#ffb,stroke:#333,stroke-width:2px style D fill:#bfb,stroke:#333,stroke-width:2px style E fill:#fbb,stroke:#333,stroke-width:2px
图 7-1. 事件生命周期
事件响应支柱
我们的团队能够多快地执行上述阶段，将决定我们从意外场景中恢复的能力。最优秀的 SRE 团队严格遵守严格的事件响应流程。例如，Google 的事件响应系统基于事件指挥系统 (Incident Command System, ICS)，该系统由消防员于 1968 年创立，用于处理野火。
事件响应流程的基本原则包括：
- 指挥链（或明确的指挥线）。
- 清晰的职责与责任。
- 文档化： 记录调试/缓解/协作活动是进行强有力的事后复盘和反馈以改进流程的关键！
- 尽快识别并修复事件。
SRE 团队会尝试使用警报捕获最常见的事件，并使用自动化来修复重复性问题。例如，可以通过 Azure 警报规则自动检测重复性事件，可以在 Azure 自动化中触发 Runbook 来修复问题（重启服务、扩展、更改设置等），并向 SRE 发送通知，仅用于验证问题是否已修复。
让我们看看需要定义的角色。
角色
角色为事件可能造成的混乱局面带来清晰度。你将明确定义团队成员的责任。不同组织中可能发现不同的角色，但以下角色通常存在：
- 第一/第二响应人：
- 第一： 待命工程师收到通知。
- 第二： 第一工程师的备份（如果无法联系或需要更多人）。
- 记录员： 技术要求最低的角色，主要职责是记录事件：跟踪事件、活动、所做的决定、重要信息等。捕获信息的时间线有助于避免重复工作，并为缓解过程带来清晰度。
- 沟通负责人/协调人/经理： 事件响应团队的“公众形象”。它将定期向客户通报事件状态。它不仅与客户共享信息，还与未积极参与事件的利益相关者（例如，销售、客户支持、市场营销等）共享信息。它与事件指挥官紧密合作，分享客户影响并向客户提供更新。它需要访问解决计划信息以正确定义沟通策略。它还可能在社交媒体或其他沟通渠道（产品网站、LinkedIn、Twitter 等）上发布更新。
- 技术负责人/主题专家 (Subject Matter Expert, SME)： 所调查系统的负责人或技术专家。如果需要帮助，第一/第二响应人会向他们升级问题。保留与你的解决方案领域相关的 SME 列表。
- 事件指挥官/经理： 负责在事件期间推动解决方案和活动。他们协调所有事件解决工作，“发生了什么”以及“谁在做什么”；这有助于工程师保持专注。
准备阶段的关键任务
在前面提到的准备阶段，事件指挥官需要为所有相关利益相关者定义最佳的沟通渠道。在整个解决阶段，他们收集信息并管理团队成员。事件指挥官通常不具备修复问题的技术技能；他们收集来自 SME 的反馈并管理待办工作。可以说，他们扮演着敏捷团队中项目经理/负责人的角色。最后，他们将负责推动在事后/事后复盘阶段确定的改进。
待命/轮值
现在职责/角色已经确定，你需要制定一个时间表来描述团队成员的班次。在定义待命计划时需要考虑许多因素：团队/组织的规模、全球分布、服务所有权和可用性。
一个高效的待命策略力求平衡；必须为关键服务提供覆盖，但绝不能以工程师的健康为代价。例如，Google 将所有 SRE 的“运维”活动（待命、工单、手动任务等）限制在 50% 以内（https://sre.google/sre-book/introduction/）。
以下是有效/可持续轮值安排的一些主要方法：
- 跟随太阳轮班： 根据正常工作时间定义待命班次（由全球化组织使用）。
- 主/备： 定义一个解决方案，如果主要响应人未确认，通知将发送给“备用”响应人。
- 人人有责： 最大的错误之一就是只让运维团队参与。每个人都应参与并“携带寻呼机”。当涉及应用层时，开发人员也应参与。“分担痛苦”也将激励开发团队改进监控并减少“辛劳”。
- 允许灵活安排： 工作与生活平衡的关键。提前数周明确安排，并允许更改（个人紧急情况，如同事件一样，无法计划）。
- 避免无意义的警报/减少辛劳： 没有人喜欢在凌晨 2 点被叫醒去修复过去几个月反复出现的同样问题。自动化将是处理重复/无意义问题的答案。
以上所有要点都将帮助你的组织表现得更好，不仅提高员工留存率，也提高客户满意度。
事件跟踪/检测
要开始处理一个事件，很显然你需要能够检测到它。这决定了事件响应流程的第一阶段。
对于事件检测，你主要依赖你的监控工具/流程（以及云提供商提供的那些）来接收有关意外行为的通知。本书有一整章专注于监控 Azure 解决方案。但仅作提醒，可以为以下信号类型创建 Azure 警报：
- 指标： 大多数默认存储 93 天
- 日志查询 (KQL 查询)： 使用 Azure Monitor 日志和 Application Insights 收集的任何信息
- 活动日志事件： 与订阅相关的活动
第7章 高效处理事件响应与无指责事后复盘
- Azure 平台健康状况（计划内维护、服务问题以及健康/安全公告）：Azure 服务健康（https://docs.microsoft.com/zh-cn/azure/service-health/service-health-overview）
- 可用性测试（使用 Application Insights 运行）
如果必要，请回顾第6章中的所有组件（之前已说明）。
例如，假设你的解决方案中使用了 Cosmos DB。该 Cosmos DB 数据库已设置为预配吞吐量 400 RU/s（未选择自动缩放），“请求单位（RU）”是 CPU/IOPS 和内存性能的归一化指标（https://docs.microsoft.com/zh-cn/azure/cosmos-db/request-units）。如果发送到 Cosmos DB 的请求所需的计算能力超过 RU 所规定的量，则 Cosmos DB 将返回 HTTP 响应 429。让我们基于此指标创建一个警报：
- 在“操作”选项卡上，创建一个操作组，从上面提到的可用选项中进行选择。例如，你可以： a. 发送电子邮件通知。 b. 触发逻辑应用，在 Slack/Teams 上创建一个对话频道。
c. 通过执行 Azure 自动化 Runbook 或运行 PowerShell 或 Azure CLI 脚本的 Azure Functions 自动修复事件（例如，使用 https://docs.microsoft.com/zh-cn/powershell/module/az.cosmosdb/update-azcosmosdbsqldatabasethroughput?view=azps-7.5.0）。
所有讨论的选项都适用于平台或所用监控工具检测到的异常。我们可以将检测到的异常分为三大类：
- 主动警报：平台或监控工具就可能存在的问题向我们发出警报：维护窗口、服务降级、响应时间长等。例如，Application Insights 能够基于机器学习规则和历史数据作为参考提供主动警报（称为智能检测）。
- 被动警报：大多数警报规则由工程师定义；通常，我们会在事件发生后收到通知。
- 未跟踪的警报/客户通知：由我们的用户通知的警报，由于某种原因我们的监控工具未跟踪到。这些警报可能更难处理，因为你可能会缺失用于响应/修复的明确信息。
在检测阶段，你不仅希望得到通知，还希望评估事件以获取下一阶段的关键信息：
- 事件触发时间 → 捕获基于时间线的信息以确定原因。
- 受影响的用户/利益相关者。
- 被通知的待命工程师。
- 事件是否在我们的跟踪软件中记录（例如 GitHub/Azure DevOps/ServiceNow）？
- 相关技术 → 我们是否需要主题专家的帮助？
下一节将重点介绍如何为清晰的协作/沟通和事件跟踪系统创建标准化方法。
沟通与 ChatOps
沟通
- 准备：让新团队成员做好准备并从过去的宕机中学习将极其重要。需要定义共享响应计划更新、流程变更和经验教训的策略。
- 检测：将检测到的问题告知适当的相关方。
- 响应：传达有关诊断、后续步骤和任务分配的详细信息。
- 修复：公开沟通服务如何/何时恢复。
- 分析：传达经验教训和后续行动。
请查看 Azure 状态网站（https://status.azure.com/zh-cn/status/history/）上的历史事件示例。它提供了事件摘要，包括每个事件的以下要点：
- 影响摘要 → 检测到的详细信息
- 根本原因 → 响应/检测
- 缓解措施 → 修复
- 后续步骤 → 分析/后续行动
- [额外] 提供反馈：询问受影响的客户如何改进事件沟通体验
现在应该很明显，沟通是事件响应的关键支柱。以下是一个清晰的沟通策略应包含的方面：
- 使用集中的方法，确保需要信息的所有人都可以访问。例如，你可以使用 Azure DevOps 工作项或 GitHub Issues 作为跟踪软件。
- 工程师将能够搜索以前处理过的事件以获取灵感。
- 记录所有内容！
- 在早期阶段，SRE（站点可靠性工程师）依赖 SME（主题专家）的专业知识。口头共享的知识有“丢失”并需要“重新学习”的风险。
- 它将有助于新成员的入职。
- 不要相信你会记住所采取的行动/步骤；人类的短期记忆不够可靠。
- 使用工具提高沟通效率，例如为正在处理事件的人员创建专用频道。
你希望尽可能自动化这些可重复的管理/创建流程。
ChatOps
ChatOps 是当今众所周知的概念。它是一种通过使用自动化连接工具、人员和流程来定义协作工作流的模型。作为事件管理框架的一部分，它带来了以下好处：
- 有助于集中沟通关于：
- 检测
- 进展
- 修复
- 打破信息孤岛：提高可见性和意识。每个人都能访问相同的信息。
- 有助于异步对话。
- 有助于记录所有内容（对话、操作、日志、跟踪等），这对事后复盘和未来事件解决有明显帮助。
更成熟的团队将利用人工智能和定制化机器人来激励协作并缩短修复时间。本节结尾的演示将提供如何实现此类解决方案的一些思路。一些高级 ChatOps 实践示例如下：
- 自动为 IT 人员创建协作环境，并在规划工具中创建事件状态跟踪项。
- 例如，每次检测到事件时，通过使用逻辑应用/Azure Functions 等解决方案，你可以在 Microsoft Teams 中创建一个专用频道进行讨论，并在 Azure DevOps 中创建一个工作项来管理状态和事件负责人。
- 与 ITSM 工具（如 ServiceNow）创建双向集成。
- 使用机器学习和 AI 服务来创建丰富的知识库/搜索体验，这可能有助于修复未来事件（链接到过去解决的类似问题）。代理解决方案将在第9章中介绍。
根除/修复
一旦确定了问题根源并设置了适当的频道/协作，就需要开始修复活动。事件响应者在此阶段可能会在遇到困难时向 SME 升级问题。你应该根据所需专业知识，清楚地了解可以依赖的 SME，以确保修复阶段顺利。
此阶段可分为两个子阶段：
- 响应：尝试在缓解期间控制问题根源并尽可能避免对系统造成进一步后果的活动。例如，如今许多 DevOps 公司使用特性开关（www.martinfowler.com/articles/feature-toggles.html）来控制所提供功能的运行时行为。
如果电子商务网站的新支付系统开始崩溃，通过使用特性开关，你可以禁用它，将用户引导到之前的支付解决方案，并仔细修复代码，直到下一个版本经过测试/发布。
- 根除：希望事件已得到控制，现在你可以致力于该问题的永久修复。
值得重申的是，记录每个操作对于成功的事后复盘活动和为未来事件创建知识库都至关重要。
沟通负责人/经理还应使用适当的渠道（外部/内部网站、社交媒体或其他沟通工具）定期向利益相关者更新信息：
- 你知道什么？
- 正在进行中的控制/根除活动
- 下一次更新的时间
理论很好，但实践呢？如何使用 Azure 提供的工具修复问题？让我们讨论一些可用的选项。其中许多工具已在上一章中详细说明。
Azure 服务健康
Azure 服务健康将帮助你确定问题是与你的系统设计（代码/设置）有关，还是与云提供的服务有关。如前所述，可以设置警报以减少检测此类事件的时间。
Azure Monitor 日志和 KQL
如上一章所述，Azure Monitor 日志允许我们收集不同 Azure 解决方案层（订阅活动、资源日志、应用程序日志等）提供的日志。日志主要通过使用 Azure 服务的“诊断设置”选项卡并启用所提供的日志导出（取决于每个服务）到 Log Analytics 工作区来收集。
Azure Monitor 工作簿（或工作簿）
工作簿是 Azure 提供的灵活模板。你可以在单个报表中组合文本（用于指导）、日志（用于数据分析）和图表（用于可视化分析），该报表可以像 ARM 模板一样被处理，从而提供更高效的报表协作方式（还记得第一章中的 IaC 主题）。你可以包含与 Azure Monitor 兼容的数据源的信息。
Azure 提供了预定义的工作簿和空白工作簿（两者都可以编辑）。
Azure Monitor 见解（或见解）
Application Insights
Application Insights 作为 Azure Monitor 产品的一部分，是 Azure 提供的用于应用程序性能管理（APM）的工具。如上一章所述，它是一个帮助你获得解决方案 360 度视角的工具，不仅能够对检测到的事件做出反应，还能通过分析服务行为采取主动方法。对于事件响应，它提供以下功能：
- 应用程序地图：了解受影响区域。
- 失败/快照调试器：深入调查服务器/客户端问题，并在发生异常时收集调试快照，以帮助诊断生产问题。
- 警报：基于收集的遥测数据创建警报。
- 智能检测：Azure 将基于解决方案的“正常”（历史）数据提供潜在性能问题和异常的警报（机器学习驱动的警报）。
- 可用性测试：从不同的全球位置定期测试你的解决方案。
- 日志：使用 KQL 查询收集的遥测数据，并创建自定义图表/警报。
- 工作簿/故障排除指南：创建工作簿以帮助你的工程师分析运行环境。可以基于工作簿功能（预览版）创建故障排除指南。
- 性能/探查器：分析解决方案性能，并使用探查器识别“最慢”的代码路径。
第7章 高效处理事件响应与无指责事后复盘
第244页
如您所见，部分工具为被动应对方法（事件发生后）做好准备；另一些工具（如 Smart Detection）旨在帮助您在事件发生之前采取行动（主动方法）。将更多精力投入到主动工作中，将减少生产环境中引发的事件。
度量性能
第245页
- 平均失效时间（MTTF）
- 平均修复时间（MTTR）
- 平均故障间隔时间（MTBF）
组织将使用不同的指标来跟踪其状态。有时，术语和指标会重叠。例如，“修复时间”也被称为“补救时间”、“恢复时间”或“复原时间”。它们均指将服务恢复到由我们的服务水平目标定义的可操作状态所需的时间。
第246页
基于跟踪数据定义一套客观关键结果（OKR：https://en.wikipedia.org/wiki/OKR）将有助于组织团队保持一致，并朝着公司愿景共同努力。
OKR 不应仅关注服务；客户满意度和员工士气也需要考虑在内。
使用 Microsoft 工具有哪些选项来跟踪这些指标？这取决于所涉及的工具有哪些。例如，如果您使用 Azure Monitor 警报配合 GitHub Issues 进行事件跟踪（如稍后演示所示），则可以使用 Power BI 收集和度量上述指标：
- 平均修复时间：测量从警报触发（Azure Monitor 警报属性）到 GitHub Issue 关闭之间的时间差。
- 平均故障间隔时间：测量连续两个 GitHub Issue 创建时间之间的平均时间。
第247页
- 其他指标：这些将受所用工具的元数据暴露/收集能力的影响。例如，与如今的 Azure DevOps Analytics 相比，GitHub Issues 在已分配用户和状态变更方面提供的历史信息较少。
第248页
[演示] 事件响应
第249页
演示的左侧将显示，而右侧展示一个示例，说明如何将事件响应提升到更高水平：
- https://docs.microsoft.com/zh-cn/azure/logic-apps/logic-apps-overview
- 发布包含事件详细信息的自适应卡片（www.adaptivecards.io/designer/）
- https://docs.microsoft.com/zh-cn/microsoftteams/expand-teams-across-your-org/shifts-for-teams-landing-page
第250页
- 创建用于事件跟踪的 GitHub Issue
- 基于从 GitHub Issues 事件跟踪解决方案提取的数据生成 Power BI 报表
第251页
第252页
无指责事后复盘
本章前一部分专注于通过应用自动化实践来减少事件的影响，这将帮助您缩短问题的解决时间线。您需要为此做好准备，因为事件是不可避免的。
由于变更不断发生，复杂系统永远无法达到 100% 的可靠性。事件通常被视为负面事件；没有人愿意在问题影响业务运营的压力环境中工作。然而，您也应该关注这些事件所提供的学习机会，因为它们暴露了未知的漏洞，并为您提供了防止未来再次发生的机会。它们可以被视为改进我们系统的机遇。
无指责事后复盘是一个流程，由以下理念和基于诚实、学习和问责制的文化转变组成：
- 构建事件补救行动的时间线并收集所有文档对于理解根本原因至关重要，从而创建成功的学习过程（使用“事件响应（IR）”部分中涵盖的技术）。
- 警报详情
- 涉及的轮值工程师
- 基于 Azure DevOps 工作项和 GitHub Actions 等工具的事件跟踪历史与数据
- 基于 Microsoft Teams 和 Slack 等工具的讨论
第253页
- 关注系统，而非个人。这是组织中最困难的变化，但其影响最大。请记住第1章中提到的 Westrum 组织文化（见表 7-2）。根据 DevOps 研究与评估（DORA），组织文化确实影响信息流。这一理念同样适用于 SRE 团队。
表7-2. Westrum 组织文化
| 病态型（权力导向） | 官僚型（规则导向） | 生成型（绩效导向） |
|---|---|---|
| 低合作 | 适度合作 | 高合作 |
| 信使被射杀 | 信使被忽视 | 信使被培训 |
| 责任推卸 | 责任狭窄 | 风险共担 |
| 禁止沟通 | 容忍沟通 | 鼓励沟通 |
| 失败 → 找替罪羊 | 失败 → 追求公正 | 失败 → 探究 |
| 创新被压制 | 创新成问题 | 创新被实施 |
从上表可以得出结论，生成型文化环境将在事后复盘活动中带来诸多益处：
- 高合作/鼓励沟通 → 更好的协作，打破孤岛，跨职能团队。
- 信使被培训/失败导致探究 → 员工在识别潜在问题时将立即分享；信使不受惩罚；消除指责；失败引发问题。
- 风险共担 → 质量、可用性、可靠性和安全性是每个人的责任。
第254页
如您所见，“指责”对企业有害。它会阻碍工程师在发现潜在问题时发声，因为他们害怕对自己产生负面影响。结果，沉默增加了承认和解决事件的平均时间，从而扩大了影响。Google 发现（www.inc.com/justin-bariso/after-years-of-research-google-discovered-secret-weapon-to-building-a-great-team-its-a-lesson-in-emotional-intelligence.html），具有强大心理安全感的高绩效团队拥有许多优势：例如，更多的对话轮流发言。如果每个人都分享观点，集体智慧就会增加。此外，Margaret Heffernan 在她的 TED 演讲（https://www.ted.com/talks/margaret_heffernan_forget_the_pecking_order_at_work?language=en）中讨论了一项实验，证明了高效能团队是那些成员平等参与且多样性鼓励帮助文化的团队。
在无指责对话中，问题的提出应聚焦于技术而非工程师（避免间接“指指点点”的行为）。例如：
- “谁修改了数据库模式？”
- 应改为：“修改数据库模式导致故障的原因是什么？”
学习成果将通过 Azure DevOps Wiki 和 GitHub Wikis 等工具在组织内捕获和共享，作为学习/最佳实践的集中存储库。事后复盘还可能产生后续行动，重点关注避免未来发生类似事件。
第255页
最佳实践/提示
以下提示可能有助于成功的事后复盘流程：
- 负责人/角色：事件指挥官/经理（先前定义的角色）将负责推动讨论并提供收集的数据/反馈。
- 并非所有事件都需要事后复盘：仅高严重性事件或耗时超出预期的事件（定义一个阈值）可能需要。
- 提出恰当的问题。记住要关注系统而非个人。问“如何”/“什么”优于“为什么”（“为什么”倾向于评判）。一些组织喜欢使用“5个为什么”技术（https://sixsigmastudyguide.com/5-whys/）进行根本原因分析（RCA）；请注意，“为什么”问题往往间接地“指指点点”。
- 注意对话中使用的语言。规范性的语言（例如“不满意”或“不负责任地”）通常用于评判。
第256页
- 不要只关注出错的地方；也要关注做对了什么；这些经验可用于后续事件（协作、行动、决策等）。
- 会议时长控制在 60–90 分钟。
- 庆祝学到的经验。
总结
本章介绍了 Dickerson 可靠性层级中提到的两个主要实践：事件响应和无指责事后复盘。
每个组织都需要定义事件响应框架，以指导员工完成事件补救流程。本章定义了事件响应过程中应包含的阶段、活动和角色。没有系统是 100% 可靠的，完善上述实践将帮助您减少这些问题的影响。
由于事件将不断出现，让我们将其视为学习和改进现有解决方案的机会。无指责事后复盘将专注于通过基于事件响应过程中收集的数据推动对话来找出事件的根本原因，并营造一种工程师不因其行为而受指责的文化。
下一章将重点介绍 Azure 提供的用于主动测试解决方案弹性的有趣工具，为真实事件场景做好准备。
第7章 结束