通过

你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

有关设计紧急响应策略的建议

  • 项目

适用于此 Azure Well-Architected 框架卓越运营清单建议：

OE：08 制定有效的紧急行动实践。 确保工作负载跨基础结构和代码发出有意义的运行状况信号。 收集生成的数据，并使用它生成可操作的警报，通过仪表板和查询发出紧急响应。 明确定义人工责任，例如待命轮换、事件管理、紧急资源访问和运行验尸。

本指南介绍有关设计紧急响应策略的建议。 在工作负载生命周期过程中出现的一些问题非常严重，足以保证将其声明为紧急情况。 你可以实施团队可以遵循的严格控制和重点流程和过程，以确保以平静、有序的方式处理问题。 紧急情况自然会提高每个人的压力水平，如果你的团队没有做好充分准备，可能会导致混乱的环境。 为了帮助最大程度地减少压力和混淆，请设计响应策略，与组织共享响应策略，并定期执行紧急响应培训。

关键设计策略

紧急响应策略应该是一组有序、明确定义的流程和程序。 每个过程和过程都应有脚本，以确保每个步骤都有助于团队快速安全地解决问题。 若要制定紧急响应策略，请考虑以下概述：

  • 先决条件
    • 开发可观测性平台
    • 创建事件响应计划
  • 事件阶段
    • 检测
    • Containment
    • 会审
  • 事后阶段
    • RCA) (根本原因分析
    • 事件调查报告
  • 正在进行的活动
    • 紧急响应演练

以下部分提供了针对其中每个阶段的建议。

可观察性

若要制定可靠的紧急响应策略，需要有一个可靠的可观测性平台。 可观测性平台应具有以下特征：

  • 整体监视：确保从基础结构和应用程序角度全面监视工作负荷。

  • 详细日志记录：为组件启用详细日志记录，以便在会审问题时协助调查。 构造日志，使其易于管理。 自动将日志发送到数据接收器，以便准备好进行分析。

  • 有用的仪表板：创建针对组织中每个团队定制的基于运行状况模型的仪表板。 不同的团队负责工作负载运行状况的不同方面。

  • 可操作警报：创建对工作负荷团队有用的警报。 避免不需要团队采取行动的警报。 此类警报过多可能会导致用户忽略或阻止警报通知。

  • 自动通知：确保适当的团队自动接收需要其采取措施的警报。 例如，第 1 层支持团队应获取所有警报的通知，而安全工程师应仅获取安全事件的警报。

有关详细信息，请参阅 有关设计和创建可观测性框架的建议。

事件响应计划

紧急响应策略的基础是事件响应计划。 与灾难恢复计划一样，明确而彻底地定义事件响应计划的角色、职责和过程。 该计划应是版本控制的文档，并定期进行评审，以确保它是最新的。

在计划中明确定义以下组件。

角色

确定事件响应管理器。 此人拥有从启动到修正到根本原因分析的事件。 事件响应管理器确保遵循流程，并在响应团队执行其工作时通知相应的各方。

确定事后领导。 此人员确保在事件解决后不久执行事后调查。 它们生成一份报告，帮助你应用事件得出的结果。

流程和过程

工作负荷团队应定义并理解紧急条件。 当团队确定情况严重时，可以声明灾难并启动灾难恢复计划。 在不太严重的情况下，该问题可能不符合灾难标准。 但你仍应将此问题视为紧急情况，这需要启动紧急响应计划。 紧急情况可能是工作负荷内部的问题，也可能是工作负荷依赖项问题造成的。 支持团队必须能够确定外部用户报告的问题是否满足紧急条件，即使他们无法了解潜在问题。

精确定义通信和上报计划。 根据他们收到的警报通知类型，确保第 1 层支持人员可以轻松联系相应的团队，将问题上报到。 确保他们知道哪种类型的通信适合内部和外部方。 在通信和上报计划中，包括待命计划和人员列表。

在总体计划中，包括包含和会审脚本。 团队在执行其遏制和会审功能时，会遵循这些分步过程。 包括定义事件关闭的内容的说明。

要包括的其他项

记录事件期间将用于内部通信的所有标准工具，例如 Microsoft Teams，以及用于跟踪事件过程中的活动的所有标准工具，例如票证工具或积压工作规划工具。

记录紧急凭据，也称为 破窗帐户。 包括一个分步指南，描述应如何使用它们。

创建紧急响应演练说明，并记录执行演练的时间。

记录任何必要的法律或法规措施，例如传达数据泄露。

事件检测

如果具有设计良好的可观测性平台，可监视异常并自动发出警报，则可以快速检测问题并确定其严重性。 如果问题被视为紧急情况，则可以启动计划。 在某些情况下，不会通过可观测性平台通知支持团队。 客户可能会使用支持团队沟通渠道向支持人员报告问题。 或者，他们可能会联系经常与之合作的人员，例如客户主管或 VP。 无论如何通知支持团队，他们都应始终遵循相同的步骤来验证问题并确定严重性。 偏离响应计划可能会增加压力和混乱。

Containment

问题修正的第一步是包含问题以保护其余工作负载。 遏制策略取决于问题类型，但它通常涉及从工作负载流路径中删除受影响的组件。 例如，可以关闭资源或将其从网络路由路径中删除。 系统管理员、工程师和高级开发人员应共同设计遏制策略。 遏制应限制问题的爆炸半径，并在问题解决之前保持工作负荷功能处于降级状态。 如果需要访问受影响的组件来执行会审，则必须阻止其访问其余工作负荷。 应尽量只通过与工作负载和系统其余部分分开的路径访问组件。

会审

成功包含问题后，可以开始会审工作。 会审期间遵循的步骤取决于问题的类型。 特定工作负载支持领域的团队应为与其团队相关的事件创建过程。 例如，安全团队应会审安全问题，并应遵循他们开发的脚本。 团队在完成会审工作时，请务必遵循定义完善的脚本。 这些脚本应是包含回滚进程的分步过程，以撤消无效或可能导致其他问题的更改。 使用现成的日志聚合和分析工具有效地调查需要深入分析的问题。 解决问题后，请遵循定义完善的流程，安全地将受影响的组件带回工作负载流路径。

RCA 报告

(与客户) SLA 的服务级别协议可能规定，必须在事件解决后的某个时间段内发布 RCA 报告。 事件所有者应创建 RCA 报告。 如果这是不可能的，另一个与事件所有者密切合作的人员可以创建 RCA 报告。 此策略可确保准确说明事件。 通常，组织有一个定义的 RCA 模板，其中包含有关信息呈现方式以及可以或不能共享哪些类型的信息的指导。 如果需要创建自己的模板和指南，请确保它们由利益干系人审阅和批准。

事件事后调查

一个公正的个人应该领导无责备的验尸。 在事后会议中，每个人都会分享他们从事件中得出的结果。 参与事件响应的每个团队都应由处理事件的个人代表。 这些人应该参加会议，准备有成功的领域和可以改进的领域的例子。 该会话不是为响应期间可能出现的事件或问题分配追溯的论坛。 事后负责人应在会话中留下一个明确列表，其中列出了专注于改进的操作项，例如：

  • 响应计划的改进。 可能需要重新评估和重写进程或过程，以更好地捕获适当的操作。

  • 可观测性平台的改进。 可能需要重新评估阈值以提前捕获特定类型的事件，或者可能需要实施新的监视来捕获未考虑的行为。

  • 对工作负载的改进。 该事件可能会暴露工作负载中的漏洞，必须将其作为永久性修正来解决。

注意事项

过于激进的响应策略可能导致误报或不必要的升级。

同样，积极实施自动缩放或其他自我修复操作来响应阈值违规可能会导致不必要的支出和管理负担。 你可能不知道要为警报和自动操作（如缩放）设置的确切阈值。 在较低环境和生产环境中执行测试，以帮助你确定满足要求的正确阈值。

Azure 简化

Azure Monitor 是一个全面的解决方案，用于收集、分析和响应来自云和本地环境的监视数据。 它包括一个可靠的警报平台，你可以针对 自动通知和其他操作（如自动缩放和其他自我修复机制）进行配置。

使用 Monitor 集成机器学习。 自动执行和优化事件会审和主动措施。 有关详细信息，请参阅 Monitor 中的 AIOps 和机器学习。

Log Analytics 是一种内置于 Monitor 的可靠分析工具。 可以使用 Log Analytics 针对聚合日志运行查询，并获取有关工作负荷的见解。

Microsoft 提供与 Azure 相关的事件准备情况培训。 有关详细信息，请参阅 Azure 事件准备情况简介 和 事件准备情况。

卓越运营清单

请参阅完整的建议集。

卓越运营清单