有关设计紧急响应策略的建议
适用于此 Power Platform Well-Architected 卓越运营清单建议：
| OE：07 年 | 制定有效的应急操作实践。 确保您的工作负载发出有意义的运行状况信号。 收集生成的数据并使用它来生成可操作的警报，这些警报通过控制面板和查询来制定紧急响应。 明确定义人员职责，例如待命轮换、事件管理、紧急资源访问和运行事后分析。 |
|---|
本指南介绍有关设计紧急响应策略的建议。 您的某些工作负载可能是任务关键型工作负载，在工作负载生命周期中出现的问题可能严重到需要宣布它们为紧急情况。 您可以实施团队可以遵循的严格控制和重点流程和过程，以确保以平静、有序的方式处理问题。 紧急情况自然会提高每个人的压力水平，如果你的团队没有做好充分准备，可能会导致混乱的环境。 为了帮助最大程度地减少压力和混淆，请设计响应策略，与组织共享响应策略，并定期执行紧急响应培训。
关键设计策略
紧急响应策略应该是一组有序、明确定义的流程和程序。 每个流程和过程都应该有脚本，以确保每个步骤都能让您的团队快速安全地解决问题。 若要制定紧急响应策略，请考虑以下概述：
- 先决条件
- 开发监控系统
- 创建事件响应计划
- 事件阶段
- 检测和遏制
- 会审
- 事后阶段
- 根本原因分析 (RCA)
- 事件调查报告
- 持续活动
- 紧急响应演练
以下部分提供了针对其中每个阶段的建议。
监控系统
要制定强大的紧急回复策略，您需要拥有强大的监控系统或可观测性平台。 可观测性平台应具有以下特征：
整体监控：确保从配置和应用程序的角度全面监控工作负载，如果工作负载的组件托管在云中或本地，则包括基础设施监控。 确保监控策略涵盖工作负载的所有组件。 例如，如果您的工作负载与 Azure 资源或本地系统交互，请将这些组件包含在您的监控中。
详细日志记录：为您的组件启用详细日志记录，以便在对问题进行分类时协助进行调查。 构造日志，使其易于管理。 自动将日志发送到数据接收器，以便准备好进行分析。
有用的仪表板：根据您的 health 模型创建为组织中的每个团队量身定制的仪表板。 不同的团队负责工作负载运行状况的不同方面。
可操作的警报：创建对工作负载团队有用的警报。 避免不需要团队采取行动的警报。 此类警报过多可能会导致用户忽略或阻止警报通知。
自动通知：确保相应的团队自动接收需要他们采取行动的警报。 例如，您的 Tier 1 支持团队应该收到所有警报的通知，而您的安全工程师应该只收到安全事件的警报。
有关更多信息，请参阅 有关设计和创建监控框架的建议。
事件响应计划
紧急响应策略的基础是事件响应计划。 与灾难恢复计划一样，要清晰、彻底地定义响应事件的角色、职责和程序。 该计划应是版本控制的文档，并定期进行评审，以确保它是最新的。
在计划中明确定义以下组件。
角色
确定事件响应经理。 此人负责事件从启动到补救再到根本原因分析的整个过程。 事件回复经理确保遵循流程，并在回复团队执行其工作时通知相关方。
确定事后领导者。 此人员确保在事件解决后不久执行事后调查。 他们应生成一份报告，帮助您应用事件的调查结果。
流程和程序
工作负载团队应该定义并理解紧急标准。 当团队确定情况严重时，可以声明灾难并启动灾难恢复计划。 在不太严重的情况下，问题可能不符合灾难的标准，但您仍应将问题视为紧急情况，这需要启动紧急回复计划。 紧急情况可能是工作负载内部的，例如应用程序代码中的错误，也可能是工作负载依赖项问题的结果，例如 API 或数据库不可用。 紧急情况也可能是由供应商中断造成的（例如 Microsoft Entra ID 或 Power Platform 的问题）。 支持团队必须能够确定问题是否符合紧急标准，即使团队无法了解潜在问题。
精确定义通信和上报计划。 根据他们收到的警报通知类型，确保您的 Tier 1 支持团队成员可以轻松联系相应的团队以解决上报的问题。
要包括的其他项
记录事件期间用于内部通信的所有标准工具，例如 Microsoft Teams，以及用于跟踪事件过程中的活动，例如票证工具或积压工作计划工具。
记录紧急凭据，也称为碎窗账户。 包括描述如何使用的分步指南。
创建紧急回复钻取说明，并记录何时进行演习。
记录任何必要的法律或监管措施，例如传达数据泄露。
事件检测和遏制
如果具有设计良好的可观测性平台，可监视异常并自动发出警报，则可以快速检测问题并确定其严重性。 如果问题被视为紧急情况，则可以启动计划。 在某些情况下，支持团队不会通过监控系统收到通知。 用户可能会使用支持团队沟通渠道向支持人员报告问题。 或者，他们可能会联系经常合作的人或他们知道正在合作 Power Platform的人，例如您的 Power Platform 服务管理员或卓越中心团队。 无论如何通知支持团队，他们都应始终遵循相同的步骤来验证问题并确定严重性。 偏离响应计划可能会增加压力和混乱。
会审
问题补救的第一步是确定导致问题的工作负载组件。 审期间遵循的步骤取决于问题的类型。 负责某个工作负载支持领域的团队应为与其工作相关的事件创建程序。 例如，安全团队应会审安全问题，并应遵循他们开发的脚本。 团队在完成会审工作时，请务必遵循定义完善的脚本。 这些脚本应该是分步说明，其中包括回滚过程，以撤消无效或可能导致其他问题的更改。 解决问题后，请遵循定义完善的流程，安全地将受影响的组件带回工作负载流路径。
根本原因分析报告
事件所有者或与他们密切合作的人员应创建根本原因分析（RCA）报告。 此策略可确保准确说明事件。 通常，组织有一个定义的 RCA 模板，其中包含有关信息呈现方式以及可以或不能共享哪些类型的信息的指导。 如果您需要创建自己的模板和指南，请确保利益相关者审查和批准它们。
事件事后调查
由公正人员应该进行无可指责的事后调查。 在事后分析环节中，每个人都会分享他们从事件中得出的结果。 参与事件回复的每个团队都应由处理事件的个人代表。 这些人应该准备好成功行动和可以改进的领域的示例来参加会议。 该会话不是为回复期间可能出现的事件或问题分配责任的论坛。 事后负责人应在会议结束时列出一份明确的行动项目清单，列出专注于改进的操作项，例如：
- 响应计划的改进。 可能需要重新评估和重写流程或程序，以更好地记录适当的行动。
- 监控系统的改进。 可能需要重新评估阈值，以便更早地获悉特定类型的事件，或者可能需要实施新的监控来发现没有考虑到的行为。
- 对工作负载的改进。 该事件可能会暴露工作负载中的漏洞，必须将其作为永久性修正来解决。
注意事项
紧急响应策略应该与整体 Power Platform 支持策略保持一致。 与您的 Power Platform 管理员和卓越中心团队合作，讨论可能已经定义的支持和紧急回复选项和流程。
在您定义支持流程和上报途径时，根据严重性对解决方案进行分类非常重要。 这种做法允许您建立流程，确保关键应用程序具有必要的护栏来支持它们，同时不会扼杀生产力方案的创新或使您的事件回复团队不堪重负。 在定义支持模式时，还要考虑升级路径。 解决方案可能一开始只需要生产力级别的支持，但功能或用户群的增长需要更高级别的支持。 确定制作者如何请求更正式的支持并将解决方案过渡到受支持的环境。
Power Platform 简化
Power Platform 与 Application Insights 集成，后者是 Azure Monitor 生态系统的一部分。 使用该集成可：
接收 Application Insights中 Dataverse 平台捕获的关于诊断和性能的遥测数据。 您可以订阅接收有关应用程序对您的 Dataverse 数据库和模型驱动应用执行的操作的遥测。 遥测提供可用于诊断和解决与错误和性能有关的问题的信息。
将您的画布应用程序连接到 Application Insights。 您可以使用这些分析来诊断问题，并可以了解用户实际对您的应用执行的操作。 您可以收集信息来帮助您做出更好的业务决策，并提高应用的质量。
配置 Power Automate 要流入 的遥测数据 Application Insights;例如，监视云端流执行并为云端流运行失败创建警报。
从 Copilot Microsoft Copilot Studio 捕获遥测数据以在 Azure Application Insights 中使用。 您可以使用此遥测来监控发送到 Copilot 和从 Copilot 发送的记录消息和事件、在用户对话期间触发的主题，以及可以从您的主题发送的自定义遥测事件。
Application Insights 是一个全面的解决方案，用于收集、分析和响应来自云和内部环境的监控数据。 它包括一个强大的警报平台，您可以针对自动通知和其他操作进行配置。
Power Platform 自动化工具包是一组工具，可促进 Power Automate 桌面版在自动化项目中的使用和支持。 此工具包提供的工具可帮助您管理自动化项目并对其进行监视，以估计节省的资金和投资回报率 (ROI)。 Automation Kit 的一部分是 控制中心，它补充了现有的 Monitor 桌面流运行功能。 控制中心的重点是业务流程协调程序视图，用于支持分析师和组织进行监视、执行操作并在必要时发出警报。