你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
设计应急策略的建议
适用于此 Azure 精心构建的框架卓越运营清单建议：
| OE：08 | 制定有效的应急操作实践。 确保工作负荷跨基础结构和代码发出有意义的运行状况信号。 收集生成的数据，并使用它生成可操作的警报，通过仪表板和查询执行紧急响应。 明确界定人员职责，例如呼叫轮换、事件管理、紧急资源访问和运行事后调查。 |
|---|
本指南介绍了设计应急策略的建议。 工作负荷生命周期过程中出现的一些问题至关重要，足以保证声明它们出现紧急情况。 你可以实施严格控制和集中的过程和过程，你的团队可以遵循这些流程和过程，以确保以平静、有序的方式处理问题。 紧急情况自然会提高每个人的压力水平，如果你的团队没有做好充分的准备，可能会导致混乱的环境。 为了帮助最大程度地减少压力和混乱，请设计响应策略，与组织共享响应策略，并定期进行应急响应培训。
关键设计策略
应急策略应该是一组有序、定义完善的流程和程序。 每个过程和过程都应有脚本，以确保每一步都有助于团队快速安全地解决问题。 若要制定紧急响应策略，请考虑以下概述：
- 先决条件
- 开发可观测性平台
- 创建事件响应计划
- 事件阶段
- 检测
- 遏制
- 会审
- 事后阶段
- 根本原因分析 （RCA）
- 事件调查报告
- 正在进行的活动
- 紧急响应演练
以下各部分提供了每个阶段的建议。
若要制定可靠的应急响应策略，需要建立可靠的可观测性平台。 可观测性平台应具有以下特征：
整体监视：确保从基础结构和应用程序的角度全面监视工作负荷。
详细日志记录：为组件启用详细日志记录，以便在对问题进行会审时协助调查。 结构日志，使其易于管理。 自动将日志发送到要准备进行分析的数据接收器。
有用的仪表板：创建基于运行状况模型的仪表板，这些仪表板专为整个组织中的每个团队定制。 不同的团队负责工作负荷运行状况的不同方面。
可操作的警报：创建对工作负荷团队有用的警报。 避免不需要团队操作的警报。 此类警报过多可能导致人们忽略或阻止警报通知。
自动通知：确保相应的团队自动接收需要其操作的警报。 例如，第 1 层支持团队应获取所有警报的通知，而安全工程师应仅获取安全事件的警报。
有关详细信息，请参阅 有关设计和创建可观测性框架的建议。
创建事件响应计划
应急策略的基础是事件响应计划。 与灾难恢复计划一样，明确和彻底地定义事件响应计划的角色、职责和过程。 该计划应该是版本控制的文档，该文档受定期评审的约束，以确保它保持最新状态。
在计划中明确定义以下组件。
角色
标识事件响应管理器。 此人拥有从启动到修正到根本原因分析的事件。 事件响应管理器可确保遵循流程，并在响应团队执行其工作时通知相应的参与方。
确定事后领导。 此人确保事后验尸在事件解决后不久执行。 它们会生成一个报告，帮助你应用事件中得出的发现。
流程和过程
工作负荷团队应定义并了解紧急条件。 当团队确定案例严重时，可以声明灾难并启动灾难恢复计划。 在不太严重的情况下，此问题可能无法满足灾难的标准。 但是，你仍应考虑这个问题，这是一个紧急问题，这需要启动应急计划。 紧急情况可能是工作负荷内部的问题，也可能是工作负荷依赖项问题造成的。 支持团队必须能够确定外部用户报告的问题是否符合紧急条件，即使他们无法了解基础问题。
精确定义通信和升级计划。 根据他们收到的警报通知类型，确保第 1 层支持人员可以轻松联系相应的团队，将问题升级为。 确保他们知道哪种类型的通信适用于内部和外部方。 在通信和升级计划中，包括待命计划和员工列表。
在总体计划中，包括包含和会审脚本。 团队在执行包含和会审函数时，会遵循这些分步过程。 包括定义事件关闭的内容的说明。
要包含的其他项
记录将在事件期间用于内部通信（如 Microsoft Teams）的所有标准工具，以及跟踪事件过程中的活动，例如票证工具或积压工作规划工具。
记录紧急凭据，否则称为 “破窗帐户”。 包含描述应如何使用它们的分步指南。
创建紧急响应演练指令，并记录执行演练的时间。
记录任何必要的法律或法规措施，例如通信数据泄露。
对可观测性触发器执行操作
如果具有设计良好的可观测性平台，可监视异常情况并自动对其发出警报，则可以快速检测问题并确定其严重性。 如果问题被视为紧急问题，则可以启动该计划。 在某些情况下，不会通过可观测性平台通知支持团队。 客户可能会使用支持团队沟通途径向支持报告问题。 或者，他们可能会联系他们经常与之合作的人员，例如客户主管或 VP。 无论如何通知支持团队，他们都应始终遵循相同的步骤来验证问题并确定严重性。 偏离响应计划可能会增加压力和混乱。
定义包含过程
问题修正的第一步是包含用于保护其余工作负荷的问题。 包含策略取决于问题的类型，但通常涉及到从工作负荷流路径中删除受影响的组件。 例如，可以关闭资源，或者将其从网络路由路径中删除。 系统管理员、工程师和高级开发人员应共同努力，设计包含策略。 遏制应限制问题的爆破半径，并在问题解决之前保持工作负荷功能处于降级状态。 如果需要访问受影响的组件来执行会审，则必须阻止对其余工作负荷的访问。 应尽可能多地通过独立于工作负荷和系统其余部分的路径访问组件。
定义会审过程
成功包含问题后，可以开始会审工作。 会审期间执行的步骤取决于问题类型。 工作负荷支持特定领域的团队应为与团队相关的事件创建过程。 例如，安全团队应会审安全问题，并且应遵循他们开发的脚本。 团队在经过会审工作时，必须遵循明确定义的脚本。 这些脚本应该是分步过程，其中包括回滚进程以撤消无效或可能导致其他问题的更改。 使用现成的日志聚合和分析工具有效调查需要深入分析的问题。 解决问题后，请遵循定义完善的进程，安全地将受影响的组件带回工作负荷流路径。
生成 RCA 事件报告
客户的服务级别协议（SLA）可能会指示必须在事件解决后的某个时间段内发出 RCA 报告。 应由事件所有者创建 RCA 报告。 如果不可能，可由与事件所有者密切共事的其他人创建 RCA 报告。 此策略可确保对事件的准确说明。 通常，组织有一个定义的 RCA 模板，其中包含有关如何显示信息以及哪些类型的信息可以或无法共享的指南。 如果需要创建自己的模板和指南，请确保利益干系人审查和批准它们。
保留事件事后验尸
公正的个人应该导致无罪的验尸。 在验尸会议中，每个人都分享了事件的结果。 参与事件响应的每个团队都应由处理事件的个人表示。 这些人应该参加会议，并准备一些成功领域和可以改进的领域的示例。 会议不是为事件或响应期间可能出现的问题分配责任的论坛。 验尸主管应离开会议，并列出侧重于改进的操作项目，例如：
对响应计划的改进。 可能需要重新计算和重写进程或过程，以便更好地捕获适当的操作。
对可观测性平台的改进。 可能需要重新评估阈值才能捕获早期特定类型的事件，或者可能需要实施新的监视来捕获未考虑的行为。
对工作负荷的改进。 该事件可能会暴露工作负荷中必须作为永久修正的漏洞。
注意事项
过于咄咄逼人的响应策略可能导致误报或不必要的升级。
同样，积极实施自动缩放或其他自我修复操作以响应阈值违规可能导致不必要的支出和管理负担。 你可能不知道要为警报和自动操作（如缩放）设置的确切阈值。 在较低环境和生产环境中执行测试，以帮助确定所需的适当阈值。
Azure 便利化
Azure Monitor 是一个全面的解决方案，用于收集、分析和响应来自云和本地环境的监视数据。 它包括一个可靠的警报平台，可以针对 自动通知和其他操作（例如自动缩放和其他自我修复机制）进行配置。
使用 Monitor 集成机器学习。 自动执行和优化事件会审和主动措施。 有关详细信息，请参阅 Monitor 中的 AIOps 和机器学习。
Log Analytics 是内置于 Monitor 中的可靠分析工具。 可以使用 Log Analytics 针对聚合日志运行查询，并获取有关工作负荷的见解。
Microsoft提供与 Azure 相关的事件准备培训。 有关详细信息，请参阅 Azure 事件准备情况 和 事件准备情况简介。
相关链接
卓越运营清单
请参阅完整的建议集。