你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
适用于此 Azure Well-Architected 框架卓越运营清单建议：
| OE:08 | 使用定义的角色、记录的过程和体系结构建立明确的结构化事件管理过程，旨在快速检测、诊断和恢复。 |
|---|
发生事件时，工作负荷团队应准备好明确的结构化过程。
事件响应有两个关键方面。 第一种是体系结构，侧重于设计支持有效响应过程的系统，并防止故障跨组件级联。 第二种是过程性，包括检测、遏制和会审，以快速管理问题，然后是根本原因分析和事后分析，以防止重复。 定期演练有助于保持就绪状态，并确保能够有效地执行计划。
本文概述了设计有助于响应的体系结构的成熟策略，以及使团队保持冷静、协调和控制的计划。 有关详细的实施指南，包括逐步的流程和操作指南，请参阅配套文章：创建有效的事件管理计划来管理中断。
定义
| 术语 | Definition |
|---|---|
| 混沌工程 | 故意将故障或不利条件注入系统，以测试其复原能力和恢复过程。 |
| 封锁 | 限制事件的影响，以防止它影响其他组件或系统。 |
| 检测 | 确定事件已发生或正在发生。 |
| 事后分析 | 对涉及所有相关团队的事件进行结构化的无责审查，总结所吸取的教训，并定义可操作的改进措施，以提高流程、工具和系统。 |
| RCA （根本原因分析） | 调查和识别事件的根本原因，包括促成因素，以防止重复。 |
| RPO（恢复点目标） | 按时间度量的最大可接受数据丢失量。 |
| RTO （恢复时间目标） | 在造成不可接受的影响之前，系统或服务在事件发生后可能会关闭的最大可接受时间。 |
| 会审 | 评估和确定事件的优先级以确定相应的响应。 |
记录事件响应计划
事件可能与部署、安全性或性能问题相关。 无论如何，创建涵盖整个过程的核心事件响应计划。 为每个事件类型定义补充过程，这些事件类型描述了不同的检测方法、包含和恢复步骤，以及特定于该类型的事件的相关利益干系人。 例如，安全事件计划可能具有与涉及安全运营中心（SOC）相关的流程，这不适用于部署事件。
事件响应计划应定义管理事件和每个事件的责任所涉及的 关键角色 。 明确所有权可减少混淆，并确保行动从检测到解决阶段得以协调。 确定事件经理、技术主管和通信线索等角色，以设置责任和支持一致的决策。
该计划必须包含 沟通和升级结构 ，其中概述了如何报告事件、通知者以及通过哪些渠道报告事件。 这可确保信息快速移动到正确的人员，并在关键时刻防止差距或重复。
该计划还必须包括团队在检测、会审、隔离和恢复期间将遵循的核心程序。 这些步骤提供了一个可预测的响应框架，有助于保持作稳定性。 定期审查这些过程，使计划与系统更改和从以前的事件中吸取的教训保持一致。
权衡。 过于咄咄逼人的响应策略可能会触发虚假警报或不必要的升级。
同样，由阈值超出触发的自动操作（例如缩放或自我修复）可能会产生额外的成本和操作开销。 由于最佳阈值可能并不明显，因此请通过较低环境中的测试来验证这些阈值，并仔细监视生产试验，以符合实际要求。
为事件响应基础结构、流程和员工分配足够的资源
规划足够的资源，以便在需要回退时同时运行至少两个工作负荷配置，以避免服务中断。 工作负荷团队应准备好在需要时支持生产中的这两种配置。 这可能涉及重构工作负荷，例如分离组件或更新数据模型。
从人类资源的角度来看，团队需要平衡其常规责任与事件响应工作。 可能需要增加人数或吸引外部资源。 这些可以是来自 Azure、第三方供应商或中心 IT 团队的平台支持，这些团队专门负责事件管理，并具有有效的支持合同。 事件响应计划应清楚地记录每个参与方涵盖的内容、排除项、升级过程以及预期的响应时间。
注释
请与组织协作，提前准备这些支持合同，以便在事件期间随时可用。
即使存在这些外部依赖项，也希望一些团队成员直接与供应商合作，而另一些团队成员则继续进行内部会审和修正。
使内部和供应商人员的联系信息保持最新。 使用日志和生产环境的适当权限建立安全和简单的过程，以便对外部或来宾访问进行身份验证和授权。
AI 机会：在向外部供应商过渡支持之前，AI 可以根据供应商提供的文档、操作手册、运行健康模型和升级路径来模拟为供应商团队工作。 它测试历史事件，以揭示差距，如缺少系统知识或配置不当的阈值，或依赖部落知识。 这使团队能够主动修复差距，确保顺利交接。
在架构中构建隔离和包容
事件是不可避免的，因此设计体系结构来 限制故障并限制其爆炸半径。 确保组件发生故障时，影响会隔离，并且不会级联到系统的其他部分。
通过诸如资源分段、将组件与微服务分离以及应用设计中的分页板或发布者/订阅者等设计模式等技术来实现此目的。 此外，请考虑使用外部资源（如果适用）。 例如，使用外部配置存储区管理应用程序代码或部署包外部的设置，而不是硬编码应用程序内的配置值。
生成用于快速检测的监视功能
强事件响应计划取决于设计良好的监视堆栈。 结构化日志记录、目标仪表板和可作警报等功能可帮助团队快速响应、尽量减少噪音并避免警报疲劳。
风险： 过于咄咄逼人的响应或自动化策略，例如触发警报、升级或自动缩放太频繁可能会导致误报、不必要的作中断、由于定义不力的阈值而增加成本。
通过在较低环境和受控的生产方案中进行彻底测试来缓解该风险，以优化警报和缩放阈值。
有效的监视具有两个关键维度。 首先，响应过程应及时从 Azure 收到有关服务运行状况、依赖项状态、安全漏洞和数据完整性等关键指标的通知。 其次，解决方案本身必须能够发出丰富的、结构化的遥测、日志、指标和跟踪信息，以实现深入分析、分类和根本原因识别。
关键业务 工作流应是可跟踪的端到端工作流 ，因此可以准确地重新构造事件。 例如，在订单处理系统中，团队应该能够跟踪何时收到订单、尝试付款授权以及发生失败的位置。 设计组件，以便通过可配置的日志详细程度、内存转储以及跨环境安全地共享诊断数据进行调试。 这些功能提供快速有效的事件响应所需的可见性和上下文。
支持诊断数据和操作方法
设计解决方案，使诊断和解决问题更快、更可靠。 此方法是将可调试性和可观测性嵌入到系统的设计中。
首先，正确收集所有相关诊断数据，例如故障和内存转储。 确保已准备好必要的工具，以便安全地收集、存储和共享此数据，以便进行有效的关联和分析。 应集成网络跟踪器和符号服务器等工具以支持更深入的调试功能。 最后，确保通过安全存储、受限访问和适当的数据管理控制来保护所有诊断数据免受篡改。
系统还应包括支持事件管理的内置挂钩和切换。 这些机制可用于实时禁用或隔离故障组件，而无需重新部署。 此外，应将失败的资源保留为隔离状态，以便进行取证分析，而不是立即放弃。
在单个玻璃窗格中可视化事件数据
构建集中式事件管理仪表板或门户，用于实时状态更新、可见性和知识共享。 仪表板应充当共享的权威数据来源，确保每个人对优先级、当前行动和依赖项保持一致。 事故对团队来说是紧张的情境，需充分的信息来保持专注，并帮助及时做出决策。 它还强化了问责和持续学习的文化。
关键组件应包括可观测性数据、时间线、所有权详细信息和严重性指示器。 可见性应特定于角色，具有适当的安全控制措施（如 RBAC），确保用户可以访问所需的信息，而无需公开敏感数据或客户数据。 包括相关资源的链接和明确的说明，指导用户执行后续步骤及其职责。 （可选）支持按需订阅或警报，以在事件状态发生更改时通知利益干系人。
捕获和存储审核线索
将审核作为核心需求设计解决方案，以支持事件响应。 虽然审核线索通常主要被视为安全措施，但它们同样对作分析至关重要。 系统应捕获配置更改、管理操作和运行过程（例如部署、备份和调优活动）的详细记录。
测试计划
使用干运行或混乱工程练习定期测试事件响应过程。 模拟现实事件以验证可恢复性、验证 RTO 和 RPO 目标，并确保通信和升级计划在压力下正常运行。
如果没有这些测试，小型故障可能会迅速升级为长时间的中断或严重的数据丢失，使团队手忙脚乱，业务运营面临风险。 通过测试，可以在发生实际事件之前识别差距，改进协调。
将 RCA 发现转化为系统改进
在每个事件后，进行彻底的 RCA 来识别根本原因和促成因素。 ** 遵循这一点，由一个公正的调解人领导无责后解析会，会上每个团队都分享观察、成功和改进的机会。
持续将课程馈送回系统可减少重复事件的可能性。 请确保在三个方面捕获和分类可作项：优化事件响应计划、增强可观测性以检测类似问题以及改进工作负荷设计。
AI 可以通过自动生成分析问题、汇总事件上下文以及跨数据源发现模式来提高效率。 它还可以分析追溯笔记和过去的事件数据，以建议优先积压工作项，减少手动工作量。 实现此功能需要将 AI 与 ICM 和 SDLC 工具集成。 评估 PowerAutomate 和 LogicApps 等工具来管理工作流。
通过自动化实现敏捷性和一致性
在整个事件响应工作流中整合自动化，以减少手动工作并加快响应速度。 使用 Azure Batch、Runbook、Functions 和逻辑应用等工具，尽可能多地 自动检测、包含、警报和通信。 维护用于恢复、验证、故障排除和根本原因分析的脚本和基础结构即代码模板库。 确保记录并可访问这些自动化，以便团队能够在事件期间可靠地执行这些自动化。 自动化越多，响应就越一致。
Azure 便利化
Azure Monitor 是一个全面的解决方案，用于收集、分析和响应来自云和本地环境的监视数据。 它包括一个可靠的警报平台，可以针对 自动通知和其他操作（例如自动缩放和其他自我修复机制）进行配置。
使用 Monitor 集成机器学习。 自动化和优化事件分类和主动措施。 有关详细信息，请参阅 Monitor 中的 AIOps 和机器学习。
Log Analytics 是内置于 Monitor 中的可靠分析工具。 可以使用 Log Analytics 针对聚合日志运行查询，并获取有关工作负荷的见解。
Microsoft提供与 Azure 相关的事件准备培训。 有关详细信息，请参阅 Azure 事件准备情况 和 事件准备情况简介。
使用 Azure 网络观察程序中 的连接监视器 持续跟踪 Azure 资源的网络连接和性能。 在紧急事件期间，连接监视器中的自定义工作簿提供对连接运行状况、延迟趋势和警报状态的实时可见性。 若要执行有效的 RCA 并更快地解决问题，请使用网络观察程序套件中的诊断工具中的 连接故障排除 。
使用 流量分析 分析虚拟网络流日志和图面见解，例如阻止的流量、恶意流和公开的端口。 在流量分析中创建工作簿可让团队监视实时流量行为、接收警报，以及使用时间线和拓扑视图快速识别受影响的网段并有效响应。
使用Microsoft的 AI 和 DevOps 工具，团队可以自动将追溯见解转换为可作积压工作项。 考虑用于 AI 模型操作的 Azure AI Foundry、用于积压工作管理的 Azure DevOps、Power Automate 或用于自动化的 Logic Apps。
相关链接
卓越运营清单
请参阅完整的建议集。