你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
事件是一个非计划事件，会中断、降级或威胁到中断系统的正常运行。 事件通常会对客户或企业产生负面影响。 它们存在于一个范围中，从暂时性或局部中断到广泛的事件或灾难。 安全事件的示例包括数据泄露、法规违规、恶意软件或标识泄露。 原因包括硬件或基础结构故障、资源限制、人为错误（如部署失败或配置错误）或安全攻击等外部因素。
事件管理（IcM） 提供了一种系统的方法，用于在中断期间还原服务。 它协调检测、调查、缓解和解决，同时保持清晰的沟通和记录见解，以便持续改进。 无论事件类型，事件响应过程都遵循相同的剧本。
创建 IcM 计划时，不要仅仅关注仪表板和运行手册。 作为一名架构师，设计运营人员、流程和工具在压力下协同工作，以高效且无混乱地还原系统。 IcM 策略应根据严重性进行调整，从轻微事件的快速缓解到协调重大事件的跨团队工作。 响应也可能因原因而异。
本文重点介绍 IcM 的阶段，包括准备、主动事件响应、事后评审和持续改进。 本指南还包括一个演示设计实践的示例。 在开始之前，请查看关键策略，并选择对你的业务有意义的策略。 有关详细信息，请参阅 OE：08 体系结构策略，用于设计 IcM 过程。
本文不包括需要专门恢复工作的灾难。 有关处理此类方案的详细信息，请参阅 为多区域部署制定灾难恢复计划。
术语
| 术语 | Definition |
|---|---|
| 冲击半径 | 事件发生时受影响区域的范围，遏制策略旨在限制。 |
| 破窗帐户 | 在关键事件期间使用的紧急凭据具备提升的特权，其使用受到严格控制，并有明确的使用指南。 |
| 桥接团队 | 快速反应团队集合调查事件，也称为工程桥。 它由相关技术专家和决策者组成。 |
| 包含 | 事件修正的第一步是隔离受影响的组件，以防止问题蔓延到工作负荷的其他部分。 |
| 事件管理（IcM） | 在检测、分类处理、缓解和解决事件的过程中，同时协调沟通和总结经验。 |
| Last-known-good | 事件开始前负载的最后一个健康状态，用作回滚作业的参考点。 |
| 缓解 | 为减少或消除事件影响而采取的措施，包括回滚、故障切换、绕过或紧急修复。 |
| 回顾 | 一个无责的事后审查过程，侧重于确定吸取的教训和可作的改进，而不是分配责任。 |
| 根本原因分析 （RCA） | 一个系统的调查事件过程，以确定导致问题的根本因素，并防止重复。 |
| 严重性级别 | 分类系统（如关键、高、中和低）根据业务影响和受影响的用户确定适当的响应级别。 |
| 分流 | 分析和确定事件的优先级以确定严重性、影响和适当的响应作的过程。 |
准备工作
在事件发生之前，通过设计可观测性、定义明确的角色和流程以及准备团队所需的工具和资源，为有效响应奠定基础。 记录事件响应计划并定期更新和查看。
维护准确的、最新的架构图，这些图显示所有组件及其交互，以帮助团队快速识别瓶颈或单点故障。 此方法可在高压情况下更快地进行故障排除。
定义监视堆栈必须为整个工作负荷提供的事件数据：
收集端到端遥测数据，包括基础结构和应用程序。
为所有组件启用结构化日志记录以支持会审和调查，并将日志发送到数据接收器进行分析。 如有必要，还可以将日志转发到集中管理的汇聚点。 确保团队成员在事件期间具有时间限制的最小特权访问权限。
基于工作负荷运行状况模型创建仪表板。 仪表板显示团队监视的指标和信号。
配置可执行的警报，这些警报仅在超过阈值并检测到潜在事故时触发通知。 调整警报以避免警报过多（噪音）或警报太少。 例如，对于实时站点事件，警报应监视关键指标，例如中央处理单元（CPU）、内存、响应时间和数据库性能，以检测与性能目标相符的可作问题。
自动将警报路由到合适的团队。 例如，第 1 层支持获取所有警报，而安全工程师仅接收与安全相关的警报。
有关详细信息，请参阅 有关设计和创建可观测性框架的建议。
定义关键角色，以确保责任、决策以及事件前后的有效跟进。 创建适当的审批流程，并将其编码在明确的决策树中。 定义不同类型的严重性、缓解决策、升级路径和其他区域的授权级别。
使用以下示例作为起点，并对其进行调整以适应团队结构。
角色 职责 事件响应管理器 从检测到解决和根本原因分析的全流程负责事件。 确保遵循流程、做出决策，并告知正确的人员。 回顾领导者 领导事后评审，总结经验教训，生成可操作的报告，并确保调查结果得以应用。 值班工程师 主动缓解和解决事件。 遵循不同事件类型的责任，并根据需要与专用团队协作，以确保及时解决事件。 定义调查过程：
定义适用于工作负荷的事件类型（例如作、安全、性能和部署事件）和严重性级别（如关键、高、中和低）的类别。
记录如何评估事件的严重性、影响和紧迫性。 考虑用户影响、受影响的系统和业务关键功能。 根据严重性级别，团队针对满足灾难级别阈值的情况激活灾难恢复计划。 或者，他们遵循不太严重的事件的标准响应计划。
定义从工作负荷流路径中隔离或删除受影响组件的策略，例如关闭资源或重新路由流量。 确定哪些角色有权执行遏制措施。
设置监控系统以自动化启动用于控制已定义事件的措施。 此方法让人类参与关键决策。 系统管理员、工程师和高级开发人员应进行协作，以限制影响范围，同时保持系统在降级状态下的功能。 如果组件必须保持可用于分诊，请严格将其访问与工作负荷的其余部分隔离开来。
创建基于事件严重性（例如隔离、回滚、配置更改和解决方法）选择缓解策略的准则。
根据类型和严重性指定哪些团队或个人处理事件。 包括初始响应程序无法解决问题时的升级路径。
概述在会审期间要收集的数据，例如日志、指标、用户报告和警报，以支持调查和决策。 还包括谁应该有权访问该数据。
重要
通过建立明确的规则来保护紧急凭据或应急账户。 确定谁可以使用它们、何时和确切地使用它们。 将这些规则与应急演练配对，并记录每次演练情况。 定义团队应练习演练的频率。 在事件发生期间，目前还没有时间弄清楚。 演练提供了足够的练习和改进机会。
设置基础结构以支持解决方法：
参数化管道。 启用部署和恢复管道以接受特定版本以便快速回滚或修复部署。
确保数据平面一致性。 使密钥、机密、配置和状态数据在恢复作期间保持一致。
自动化基础设施扩展。 自动调整资源以处理流量转移或负载增加。
实现自我修复。 安全地自动响应常见事件模式，但包括适当的监视和手动替代选项。
定义通信进程。 记录明确的通信和升级计划，以便第 1 层支持人员可以快速到达正确的团队。 为内部和外部利益干系人指定适当的沟通渠道，并包括通话计划和联系人详细信息。
定义 IcM 工具的用法，并在简单工作流中捕获其应包含的标准操作程序。 工作流包括四个步骤：创建、确认、缓解和解决。 该工具为团队提供可见性、跟踪进度、维护责任，并确保始终一致的事件处理。 它集中所有活动以支持现场实时管理和值班轮换。
定义将事件正式标记为已关闭的标准：
包括明确的解决因素。 通常，解决方法意味着系统和服务在服务级别协议（SLA）中运行，性能和可靠性会恢复到可接受的级别，并立即成功完成缓解作。
包括验证检查以确认完整解决方法。 使用监视工具检查事件是否不再影响系统，受影响的用户不再遇到中断。
在关闭事件时，包括通信要求。 通知相关方，包括内部小组、支持人员和受到影响的用户，并提供已采取措施及正在进行工作的总结。
在关闭事件时，确保附上详细的文档。 记录 IcM 系统中的所有详细信息。 包括触发因素、遏制步骤、分类决策和最终解决方法。 将此文档视为 RCA 的交接和回顾，以捕获所吸取的教训。
重要
设计您的操作，以便只有指定权限（如事件响应管理器）才能关闭事件。 强制实施严格的清单以阻止过早关闭。 跳过步骤可能会使隐藏问题无法解决，这可能会使 关闭 事件变成重复灾难。
检测、调查和响应
第 2 阶段侧重于快速有效地检测和响应事件。 此阶段尽早识别问题，评估其影响，并在管理中断时实施正确的缓解策略。 此阶段还可确保分类、解决和沟通在所有团队中协调、一致、责任明确。
重要
在高压力情况下，清晰、一致的沟通保持控制和清晰。 准确定义说话人、共享内容以及频率。 标准化更新节奏、通道和消息格式，使危机期间没有人争先恐后地查找信息。 确保每个利益干系人（从工程师到高管）都知道何时需要更新，以及何时需要升级。
当警报或用户报告显示问题时，立即采取行动。 使用可观测性和性能工具将异常与系统更改相关联。 事件处理人组建了拥有合适成员的分诊团队，并就通信方式、进度跟踪以及事件资产访问达成一致。
动员工程桥梁评估影响和严重性。 使用预定义的严重性分类评估事件的影响。 使用数据来证明事件响应计划中概述的条件，例如受影响的用户数、业务功能中断、安全性和合规性影响以及对客户信任和信誉的潜在影响。 此评估确定适当的响应级别，并指导后续缓解步骤。
调查阶段从适当的工程团队参与和启动 RCA 开始。 此过程涉及深入的技术分析，以精确确定原因并控制影响。 工程师使用可观测性数据、遥测仪表板、系统日志和更改历史记录来跟踪异常并识别故障点。 他们专注于快速隔离问题，使用实时数据验证假设，并制定精确的缓解计划，以恢复服务稳定性而不引入新的风险。
折衷： RCA 可能需要很长时间。 若要关联性能问题，必须收集和存储数据。 所需的时间和基础结构可以向运营团队添加额外的工作，并为工作负荷增加成本。
风险： 如果在没有适当的安全防护措施的情况下执行 RCA，则提供对日志和数据的访问权限时，可能会公开敏感信息。遵循遏制策略来隔离受影响的组件并限制爆炸半径。 可以执行以下操作：
通过使用单独的分级路径限制对受影响组件的访问。 例如，可以关闭资源、限制流量或禁用失败的微服务。
限制事件对特定用户、区域或组件的访问。
如果可能，保持业务负载的功能处于降级状态。
选择适当的缓解策略。 根据工作负荷的当前状态、可用资源和即时约束选择缓解方法。
你的选择取决于基础结构类型、可用的绕过机制、修复的复杂性、数据敏感度和符合性要求、系统依赖项和恢复时间目标（RTO）等因素。
回滚： 将更新的系统恢复到最近的良好配置状态。 工作负荷工作组应定义“最后已知良好的状态”的含义。 它通常指的是部署开始之前工作负荷的最后一个正常状态，可能不是紧接之前的应用程序版本。 回滚可能很复杂，尤其是在涉及架构或数据更改时。 若要降低风险，请通过增量更新架构，而不是替换记录。 旧数据和新数据可以共存，直到可以安全地删除已弃用的记录。 回滚可能需要跨多个团队进行仔细的规划和协调。
回退策略：将更新后的系统从生产流量路由中移除，并将所有流量导向稳定的堆栈。 此低风险策略可解决部署问题，而不会造成进一步的中断。 根据基础结构和应用程序设计，Canary 部署中的回退可能很复杂。 在将流量切换回稳定堆栈之前，请确保其有足够的容量。 回退功能支持持续运行，并隔离出现问题的部署。
绕过冒犯函数： 使用功能标志或运行时配置属性绕过有问题的功能。 此方法允许推出得以继续并隔离问题。 评估权衡，并将其传达给利益干系人。 包括可以容忍降级状态的时长和完全解决问题的估计时间。 获得利益相关者对计划的批准。
紧急部署（热修复）： 在推出期间部署热修补程序以快速解决问题。 遵循安全部署做法，包括通过环境和质量门检验进行代码推广，但加快进度。 缩短或修改烘焙时间和测试以加快部署速度。 使用自动测试来确保可靠性。 热修复需要协调和仔细规划，以尽量减少风险并及时解决问题。
重要
确保缓解决策遵循预定义的授权规则。 事件管理器应处理所有缓解作。 要求授权人员批准影响重大的步骤并记录每个作。 在还原系统时，保持操作受控、安全并可追踪。
应用分辨率。 此步骤侧重于将系统还原到完整的操作状态，同时防止问题再次发生。 工程团队应用遵循团队特定的脚本化过程的已验证修补程序。 他们使用日志分析和监视工具来指导调查。 回滚步骤将撤消无效的更改，以确保每个操作都推动系统稳步向完全恢复迈进。
生成 RCA 报表。 解决事件后，在 SLA 时间范围内生成 RCA 报告。 事件所有者应创建报告以确保准确性；如果事件所有者不可用，则由密切参与的团队成员负责创建。 遵循定义的 RCA 模板，该模板具有有关要包含和共享的信息的明确准则，或通过利益干系人评审创建和批准新模板。
事后活动
在每个事件后进行回顾。 它们提供关键学习机会，突出响应、部署或基础结构方面的弱点，并告知改进。 记录行动项，并在待办事项积压列表中跟踪它们，以便进行迭代实现。
目标是不分配责任，而是确定可作的改进。 公正调解人应领导这一进程。 处理响应的个人必须代表参与事件的每个团队。 他们必须准备好对成功和改进方面的观察：
响应计划增强功能： 更新流程或程序，以确保更清晰、更有效的行动。
可观测性改进： 调整阈值、添加监视或实现警报，以检测之前发生的类似事件。
工作负载修正： 解决在事件中暴露出来的漏洞，并进行永久修复。
示例：部署失败响应
以下示例介绍与部署相关的事件。 即使经过仔细的规划和测试，部署有时也会引入影响系统性能或用户体验的问题。
在此示例中，工作负荷团队推出包含多个组件的搜索增强功能：
- 具有增强筛选功能的新搜索 API 终结点
- 更新的数据库架构
- 重新设计的用户界面（UI）搜索小组件
- 新的缓存逻辑
团队执行以下步骤来检测、缓解和解决事件：
检测： 团队在检测到其中一个金丝雀发布组的错误率极高时发现了问题。 团队立即使用其可观测性工具，如应用性能监测(APM)、日志记录和将用户链接到发布阶段的遥测，来查明受影响的群体。
团队通过在其部署过程中构建强大的可观测性来准备此方案。 他们在每个推出阶段运行冒烟测试和质量检查，并使用日志记录、跟踪和性能指标检测其应用程序。 遥测将用户链接到特定的推出组，以便他们能够快速确定哪些版本影响了哪些用户。 他们还在工作时间安排部署，以确保能够提供全面的支持，并确保支持人员知道如何根据紧急响应计划升级问题。 这种准备允许他们快速检测错误率的峰值，并毫不延迟地做出响应。
缓解： 团队快速决定缓解策略。 他们考虑是回滚到最后一个已知良好的版本，回退到稳定环境，使用功能标志绕过有问题的函数，还是部署热修复。 已定义决策树和审批过程。
在团队评审所有可用策略后，他们将选择范围缩小到回滚或降级，最终决定采用降级策略。 它们确定将流量重定向到稳定堆栈的速度比完全回滚更快、风险更低，这可能需要复杂的数据和架构作。 团队确认稳定堆栈有足够的容量来处理完整的生产负载，并且可以将更新的系统与生产流量路由隔离开来。
团队将多个相互依赖的更改捆绑在一起，包括 API、数据库架构、UI 组件和缓存逻辑，因此确定导致错误的特定组件比单独部署每个更改更具挑战性和耗时。
解决方案： 团队执行回退流程。 它们将流量从更新的环境移开，以隔离有问题的部署。 团队可以在不影响大多数用户的情况下解决根本问题。
备用实现揭示了操作上的差距。 他们发现两名关键团队成员的过时联系信息，升级链中的一名工程师几个月前离开了公司。 团队浪费时间去寻找负责任的个人。 当他们尝试从负载均衡器中删除更新的部署时，文档引用了最近 Azure 更新中更改的过时负载均衡器配置。 他们不得不在时间压力下找到正确的程序。
通信是缓解计划的关键部分。 该团队告知利益干系人决策及其影响，包括解决隔离环境中问题的预期时间线。 团队已经标准化了在部署事件期间提供状态更新的节奏，因此利益干系人知道何时需要进度报告和更新。 团队还定义了与用户共享的类型和详细信息级别，并确保符合部署事件通信的其他要求。 这种结构化方法可最大程度地减少混淆，并帮助保持对响应过程的信心。
回顾： 团队在缓解部署问题后，会进行回顾，以总结经验教训并改进未来的工作流程。 会议包括所有参与推出的人员，从开发人员和运营人员到支持人员和利益相关者代表。 团队审查事件序列，从检测到缓解，以了解哪些进展顺利，以及存在差距的位置。
关键要点是将搜索 API 更改、数据库架构更新、UI 重新设计和缓存层更改捆绑在一起，从而使故障排除和恢复工作变得复杂。
事后改进： 从回顾来看，团队实施了多项作改进，使将来的部署更安全，缓解措施更可靠：
较小的频繁更改： 团队转向更小的增量部署，以减少连续版本之间的差异，使缓解更容易，并降低风险。
具体而言，对于搜索增强功能，团队决定独立部署每个组件。 现在，它们先部署数据库架构更改，先进行向后兼容的更改，然后更新 API 终结点，然后再进行其他更改。 此方法使团队能够在添加下一层之前独立验证每个层，并更轻松地将问题隔离到特定组件。
常规测试和演练： 该团队建立了针对完整部署失败缓解策略频繁测试的做法。 它们引入了混沌工程和故障注入测试来模拟故障方案并验证缓解过程。 这些常规演练可以识别事件期间遇到的问题，包括过时的联系信息以及过时的运行手册流程。
Azure 便利化
Microsoft提供与 Azure 相关的事件准备培训。 有关详细信息，请参阅 Azure 事件准备情况 和 事件准备情况简介。
Azure Monitor 是一种解决方案，用于收集、分析和响应来自云和本地环境的监视数据。 它包括一个警报平台，你可以为 自动通知和其他作（如自动缩放和其他自我修复机制）进行配置。
使用 Azure Monitor 集成机器学习。 自动执行和优化事件会审和主动措施。 有关详细信息，请参阅 Azure Monitor 中的 AI运维和机器学习。
Log Analytics 是 Azure Monitor 中的分析工具。 可以使用 Log Analytics 针对聚合日志运行查询，并获取有关工作负荷的见解。
Application Insights 是 Azure Monitor 的扩展，提供 APM 功能。
Microsoft Sentinel 是一种安全信息和事件管理（SIEM）和安全业务流程、自动化和安全响应（SOAR）解决方案。 它是警报检测、威胁可见性、主动搜寻和威胁响应的单一解决方案。
Azure Pipelines 提供生成和发布服务，以支持应用程序的持续集成和持续交付（CI/CD）。
Azure 测试计划 是基于浏览器的测试管理解决方案。 此解决方案提供计划内手动测试、用户验收测试和探索测试所需的功能。 Azure 测试计划还提供从利益干系人那里收集反馈的方法。
Azure 逻辑应用是一个基于云的平台，用于运行集成应用、数据、服务和系统的自动化工作流。 可以使用逻辑应用在获取更新时创建应用程序的新版本。 Azure 维护版本的历史记录，可以还原或提升任何以前的版本。
许多 Azure 数据库服务提供时间点还原（PITR）功能，可在需要回滚时派上用场：
Azure Chaos Studio 是一项托管服务，它使用混沌工程来帮助度量、了解和改进云应用程序和服务的复原能力。