设计部署失败缓解策略的建议
适用于此 Power Platform Well-Architected 卓越运营清单建议：
| OE：11 | 实施部署失败缓解策略，通过快速恢复解决意外的推出中期问题。 结合使用多种方法，例如回滚、功能禁用或使用部署模式的本机功能。 |
|---|
本指南介绍设计标准化策略以有效处理部署失败的建议。 与其他工作负载问题一样，部署失败是工作负载生命周期中不可避免的一部分。 有了这种心态，您可以制定精心设计的有目的的策略来应对部署失败，做到积极主动。 这种策略使您的工作负载团队能够有效地缓解故障，同时尽可能减少对用户的影响。
缺乏这样的计划可能会导致对问题进行混乱和潜在有害的响应，这可能会严重影响团队和组织的凝聚力、客户信任和财务。
关键设计策略
有时，虽然您的开发实践已经成熟，但仍会出现部署问题。 使用安全的部署实践和运行强大的工作负荷供应链可以帮助您将失败部署的频率降到最低。 您还需要设计一个标准化策略，以便在部署失败时对其进行处理。
部署失败缓解策略由五个主要阶段组成：
- 检测：要响应失败的部署，您必须首先检测失败。 检测可以采取多种形式，例如冒烟测试失败、用户报告或监控平台生成的警报。
- 决策：您必须确定针对特定故障类型的最佳缓解策略。
- 缓解措施：您必须执行已确定的缓解措施。 缓解可以采取回退、回滚或前滚的形式。
- 沟通：根据紧急回复计划的要求，在您检测和解决问题时，必须让利益相关者和受影响的用户了解状态。
- 事后分析：无指责的事后分析为工作负载团队提供了确定需要改进的领域并制定应用学习成果的计划的机会。
以下各节为这些阶段提供了详细建议。
检测
要快速识别部署问题，您需要与部署相关的强大测试和监控实践。 为了帮助快速检测异常，您可以通过使用应用程序性能管理工具并通过检测进行日志记录来补充工作负载监控和警报。
冒烟测试和其他质量测试应在推出的每个阶段进行。 一个部署组的成功测试不应影响后续组的测试决定。
您可以实现将用户问题与部署阶段相关联的遥测。 然后，您可以快速确定特定用户与哪个推出组关联。 此方法对于渐进式公开部署尤其重要，因为您可能会在部署的任何给定点跨用户群运行多个配置。
您应该准备好立即响应用户报告的问题。 只要可行，在工作时间部署您的推出阶段，这时您会有一个完整的支持团队。 确保支持人员接受培训，了解如何上报部署问题以实现正确路由。 升级应与您的工作负荷应急响应计划保持一致。
决策
为部署问题确定适当的缓解策略涉及考虑以下因素：
您使用的渐进式公开模型的类型。 例如，您可以使用蓝绿色模型或淡黄色模型。 如果您使用蓝绿色模型，回退比回滚更实用。 您可以轻松地将流量转移回运行未更新配置的堆栈。 然后，您可以在有问题的环境中解决问题，之后在适当的时间再次尝试部署。
您随时可以使用的绕过问题的方法。 示例包括使用功能标志、环境变量或可以打开和关闭的任何其他类型的运行时配置属性。 有时，您可以通过关闭功能标志或切换设置来轻松绕过问题。 在这种情况下，您可能能够：
- 继续推出。
- 避免回退。
- 在修复有问题的代码时回滚。
在代码中实现修复所需的工作量。 如果修复代码的工作量较低，则在某些情况下，通过实施修补程序前滚是正确的选择。
受影响工作负荷的关键度级别。 业务关键型工作负荷应始终以并排方式（如在蓝绿色模型中）部署，以实现零停机部署。 因此，对于这些类型的工作负荷，回退是首选的缓解策略。
缓解
以下是一些常见的缓解策略：
回滚：在回滚方案中，将更新的系统还原到上次已知的良好配置状态。
对于整个工作负载团队来说，就“last known good”的含义达成一致非常重要。此表达式是指部署开始之前 healthy 的工作负载的最后状态，不一定是以前的应用程序版本。
回滚可能很复杂，尤其是当涉及数据更改时。 架构更改可能会降低回滚风险。 安全地实施更改可能需要大量的计划。 一般建议是架构更新应该是累积的。 记录不应替换为新记录。 旧记录应该弃用，并且应该与新记录共存，直到可以安全地删除弃用的记录为止。
Fallback：在回退方案中，更新的系统将从生产流量路由中删除。 所有流量都会被定向到未更新的堆栈。 这种低风险策略为您提供了一种解决代码中问题的方法，而不会带来进一步的中断。
对于淡黄色部署，根据您的基础结构和应用设计，回退可能并不简单，甚至不可能。 如果您需要执行扩展来处理未更新的系统上的负荷，应在回退之前执行扩展。
绕过有问题的功能：如果可以通过使用功能标志或其他类型的运行时配置属性来绕过问题，则可能会决定继续推出是解决问题的正确策略。
您应该清楚地了解绕过功能的权衡，并且应该能够将这种权衡传达给利益干系人。 利益干系人应该批准推进计划。 利益干系人需要确定在降级状态下运行的可接受时间长度。 他们还需要将这一决定与您对修复和部署问题代码所需时间的估计进行权衡。
紧急部署（修补程序）：如果您可以在推出过程中解决问题，则修补程序可能是最实用的缓解策略。
与任何其他代码一样，修补程序需要遵循您的安全部署实践。 但是通过热修复，时间表会大大加快。 您需要在各个环境中使用代码提升策略。 您还需要在所有质量关卡中检查修补程序代码。 但是，您可能需要显著缩短烘培时间，并且可能需要修改测试来加快速度。 确保您可以在部署后尽快对更新的代码运行完整的测试。 在很大程度上自动化质量保证测试可帮助在这些场景中提高测试效率。
通信
明确定义通信责任以帮助最大限度地减少事件期间的混乱，这一点很重要。 这些责任应确定工作负荷团队如何与支持团队、利益干系人和应急响应团队人员（如应急响应经理）互动。
标准化工作负荷团队在提供状态更新时所采取的节奏。 确保利益干系人了解此标准，以便他们知道何时会进行更新。
如果工作负载团队需要直接与用户通信，请阐明适合共享的信息类型和详细程度。 另外还应向工作负荷团队传达适用于这些案例的任何其他要求。
检视
事后分析应跟随所有失败的部署，无一例外。 每个失败的部署都是一个学习机会。 事后分析可以帮助您识别部署和开发流程中的弱点以及基础设施中的错误配置。
检视应该始终是无可指责的，这样当事件涉及的个人分享他们对可以改进的方面的看法时，他们会感到安全。 事后分析领导者应跟进实施已确定的改进的计划，并将这些计划添加到工作负载积压工作中。
注意事项和一般性建议
确保您的部署管道可以接受不同的版本作为参数，以便您可以轻松地部署最后已知良好的配置。
在回滚或前滚时与管理和数据平面保持一致。 特定于资源和策略的密钥、机密、数据库状态数据以及配置都需要在范围内并加以说明。 例如，注意最后已知良好的部署中的基础结构扩展设计。 确定在重新部署代码时是否需要调整该配置。
首选小的、频繁的更改，而不是不频繁的大更改，这样新的部署和上次已知的良好部署之间的差异就会很小。
对持续集成和持续交付（CI/CD）管道执行故障模式分析，以帮助识别可能使缓解工作复杂化的问题。 与整个工作负载一样，可以分析您的管道，以确定在尝试给定缓解类型时可能存在问题的区域。
明智地使用自动回滚功能：
- 有些 CI/CD 工具（如 Azure DevOps）内置了自动回滚功能。 如果此功能为您提供切实的价值，考虑使用它。
- 应仅在对管道进行彻底和定期的测试之后再采用自动回滚功能。 确保您的管道足够成熟，能够在触发自动回滚时引入额外问题。
- 您需要相信自动化只部署必要的更改，并且只有在必要时才会被触发。 仔细设计触发器来满足这些要求。
在回滚期间使用平台提供的功能。 例如，备份和时间点还原可以帮助实现存储和数据回滚。 或者，如果您使用虚拟机来托管应用程序，则将环境还原到事件发生前的检查点可能会很有帮助。
经常测试您的整个部署失败缓解策略。 与应急响应计划和灾难恢复计划一样，只有您的团队经过相关培训并定期实践，您的部署失败计划才会成功。 混沌工程和故障注入测试 是测试部署缓解策略的有效技术。
Power Platform 推进
管道旨在通过 Power Platform 将 ALM 自动化以及持续集成和持续交付（CI/CD）功能引入服务，为 Power Platform Dynamics 365 客户实现应用程序生命周期管理（ALM）的大众化。
Microsoft Power Platform Build Tools for Azure DevOps 可用于自动执行与所构建 Power Platform应用程序相关的常见构建和部署任务。
GitHub Actions 使 Power Platform 开发人员能够构建自动化的软件开发生命周期工作流。 借助适用于 Microsoft Power Platform 的 GitHub Actions，您可以在存储库中创建工作流来构建、测试、打包、发布和部署应用；执行自动化；以及管理基于 Microsoft Power Platform 构建的机器人和其他组件。
ALM Accelerator 是一个开源工具，由一组应用程序、脚本和管道组成，旨在自动化持续集成/持续交付过程。
使用 Azure Pipelines 自动执行测试。
使用 Power CAT Copilot Studio Kit 配置 Copilot 和测试。 通过针对 Copilot Studio API（）Direct Line 运行单个测试，将根据预期结果评估 Copilot 响应。
解决方案 中的环境变量存储参数键和值，然后将其用作其他应用程序对象的输入。 将参数与使用的对象分开可以在同一环境中或在将解决方案迁移到其他环境时更改值。
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 发送的记录消息和事件、在用户对话期间触发的主题，以及可以从您的主题发送的自定义遥测事件。
卓越运营清单
请参考整套建议。