有关设计紧急响应策略的建议
适用于此 Power Platform Well-Architected 卓越运营清单建议：
| OE:07 | 制定有效的应急操作实践。 确保您的工作负载发出有意义的运行状况信号。 收集生成的数据，并使用它来生成可操作的警报，这些警报通过仪表板和查询来执行紧急响应。 明确定义人员职责，例如待命轮换、事件管理、紧急资源访问和运行事后分析。 |
|---|
本指南介绍有关设计紧急响应策略的建议。 您的某些工作负载可能是任务关键型的，在工作负载的生命周期过程中出现的问题可能严重到需要将其宣布为紧急情况。 您可以实施团队可以遵循的严格控制和重点流程和过程，以确保以平静、有序的方式处理问题。 紧急情况自然会提高每个人的压力水平，如果你的团队没有做好充分准备，可能会导致混乱的环境。 为了帮助最大程度地减少压力和混淆，请设计响应策略，与组织共享响应策略，并定期执行紧急响应培训。
关键设计策略
紧急响应策略应该是一组有序、明确定义的流程和程序。 每个流程和程序都应该有脚本，以确保每个步骤都能帮助团队快速安全地解决问题。 若要制定紧急响应策略，请考虑以下概述：
- 先决条件
- 开发监控系统
- 创建事件响应计划
- 事件阶段
- 检测和遏制
- 会审
- 事后阶段
- 根本原因分析 (RCA)
- 事件调查报告
- 持续活动
- 紧急响应演练
以下部分提供了针对其中每个阶段的建议。
监控系统
要制定强大的应急响应策略，您需要有一个强大的监控系统或可观测性平台。 可观测性平台应具有以下特征：
整体监控：确保从配置和应用程序的角度全面监控您的工作负载，如果工作负载的组件托管在云中或内部，还应包括基础架构监控。 确保监视策略涵盖工作负荷的所有组件。 例如，如果您的工作负载与 Azure 资源或本地系统交互，请在监视中包含这些组件。
详细日志记录：为组件启用详细日志记录，以便在会审问题时协助调查。 构造日志，使其易于管理。 自动将日志发送到数据接收器，以便准备好进行分析。
有用的仪表盘：根据您的健康模式创建仪表盘，为组织内的每个团队量身定制。 不同的团队负责工作负载运行状况的不同方面。
可操作警报：创建对工作负载团队有用的警报。 避免不需要团队采取行动的警报。 此类警报过多可能会导致用户忽略或阻止警报通知。
自动通知：确保适当的团队自动接收需要其采取措施的警报。 例如，第 1 层支持团队应获取所有警报的通知，而安全工程师应仅获取安全事件的警报。
了解更多信息，请参阅设计和创建监控框架的建议。
事件响应计划
紧急响应策略的基础是事件响应计划。 与灾难恢复计划一样，清晰、彻底地定义响应事件的角色、职责和过程。 该计划应是版本控制的文档，并定期进行评审，以确保它是最新的。
在计划中明确定义以下组件。
角色
确定事件响应经理。 此人负责事件从启动到补救再到根本原因分析的整个过程。 事件响应经理确保遵循流程，并在响应团队执行其工作时通知相关方。
确定事后领导者。 此人员确保在事件解决后不久执行事后调查。 他们应生成一份报告，帮助您应用事件的调查结果。
流程和程序
工作负载团队应该定义并理解紧急标准。 当团队确定情况严重时，可以声明灾难并启动灾难恢复计划。 在不太严重的情况下，该问题可能不符合灾难的标准，但您仍应将该问题视为紧急情况，这需要启动应急响应计划。 紧急情况可能是工作负载的内部问题（例如应用程序代码中的错误），也可能是工作负载依赖项问题造成的（例如 API 或数据库不可用）。 紧急情况也可能是由供应商中断造成的（例如 Microsoft Entra ID 或 Power Platform 的问题）。 支持团队必须能够确定问题是否符合紧急条件，即使团队无法了解根本问题。
精确定义通信和上报计划。 根据他们收到的警报通知类型，确保您的第 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；例如，监控云端流执行情况并为云端流运行失败创建警报。
从您的 Microsoft Copilot Studio 代理捕获遥测数据，供 Azure Application Insights 使用。 您可以使用这些遥测数据来监控向代理发送或从代理发送的记录消息和事件、在用户对话期间触发的主题以及可从主题发送的自定义遥测事件。
Application Insights 是一个全面的解决方案，用于收集、分析和响应来自云和内部环境的监控数据。 它包括一个强大的警报平台，您可以针对自动通知和其他操作进行配置。
Power Platform 自动化工具包是一组工具，可促进 Power Automate 桌面版在自动化项目中的使用和支持。 此工具包提供的工具可帮助您管理自动化项目并对其进行监视，以估计节省的资金和投资回报率 (ROI)。 自动化工具包的一部分是控制中心，是为了补充现有的监视桌面流运行功能。 控制中心的重点是业务流程协调程序视图，用于支持分析师和组织进行监视、执行操作并在必要时发出警报。