你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。
有关设计部署失败缓解策略的建议
适用于此 Azure Well-Architected 框架卓越运营清单建议：
| OE：12 | 实施部署失败缓解策略，解决快速恢复的意外中推出问题。 结合使用多种方法，例如回滚、功能禁用或使用部署模式的本机功能。 |
|---|
本指南介绍有关设计标准化策略以有效处理部署失败的建议。 与其他工作负载问题一样，部署失败是工作负载生命周期中不可避免的一部分。 有了这种思维模式，可以通过设计精良、有意识的策略来处理部署失败，从而采取主动措施。 此类策略使工作负载团队能够有效地缓解故障，对最终用户的影响尽可能小。
缺少此类计划可能会导致对问题的混乱和潜在有害的响应，从而显著影响团队和组织凝聚力、客户信任和财务。
关键设计策略
有时，尽管开发实践已经成熟，但部署问题也会发生。 使用 安全部署做法 和操作可靠的 工作负载供应链 有助于最大程度地减少部署失败的频率。 但你还需要设计一个标准化策略，以便在失败的部署发生时处理这些部署。
将渐进式公开部署模型用作标准做法时：
- 你有适当的基础来最大程度地减少部署失败时对客户或内部用户的影响。
- 可以有效地缓解问题。
部署失败缓解策略由五个广泛的阶段组成：
检测：若要响应失败的部署，必须先检测失败。 检测可以采用多种形式，例如失败的冒烟测试、用户报告的问题或监视平台生成的警报。
决策：必须确定针对特定故障类型的最佳缓解策略。
缓解：执行标识的缓解操作。 缓解措施可以采用回退、回滚、前滚或使用运行时配置来绕过违规函数的形式。
沟通：必须让利益干系人和受影响的最终用户知道状态，因为你检测到并按照 紧急响应计划的要求处理问题。
事后分析：无责备事后调查为工作负载团队提供了机会，以识别需要改进的领域并制定应用学习的计划。
以下部分提供了这些阶段的详细建议。 这些部分假定在将更改部署到一个或多个用户组或系统之后，但在更新推出计划中的所有组之前检测到问题。
检测
若要快速识别部署问题，需要可靠的测试和 可观测性做法 ，因为它们与部署相关。 为了帮助快速检测异常，可以通过执行以下步骤来补充工作负载监视和警报：
- 使用应用程序性能管理工具。
- 通过 检测启用日志记录。
冒烟测试和其他质量测试应在推出的每个阶段进行。 一个部署组中的成功测试不应影响在后续组中进行测试的决策。
可以实现将用户问题与部署阶段关联的遥测。 然后，可以快速确定特定用户与哪个推出组相关联。 此方法对于渐进式公开部署尤其重要，因为在部署中的任何给定点，你可能在用户群中运行多个配置。
应准备好立即响应用户报告的问题。 只要可行，请在有完整的支持团队可用时，在工作时间部署推出阶段。 确保支持人员接受有关如何上报部署问题以正确路由方面的培训。 升级应与工作负载 紧急响应计划保持一致。
决策
为给定的部署问题决定适当的缓解策略涉及考虑许多因素，包括：
使用的渐进式曝光模型的类型。 例如，可以使用蓝绿模型或金丝雀模型。
如果使用蓝绿模型，回退比回滚更实用。 可以轻松地将流量转移回运行未更新的配置的堆栈。 然后，可以在有问题的环境中解决问题，并在适当的时间再次尝试部署。
你可以随意使用的方法来绕过问题。 示例包括使用功能标志、环境变量，或者可以打开和关闭的任何其他类型的运行时配置属性。
有时，可以通过关闭功能标志或切换设置来轻松绕过问题。 在这种情况下，你可能能够：
- 继续推出。
- 避免回落。
- 修复有问题的代码时回滚。
在代码中实现修补程序所需的工作量。
如果修复代码的工作量较低，则通过实施热修复向前滚动是适用于某些方案的正确选择。
受影响工作负载的关键级别。
应始终以并行方式部署业务关键型工作负载（如蓝绿模型），以实现零停机时间部署。 因此，对于这些类型的工作负载，回退是首选的缓解策略。
工作负载使用的基础结构类型-可变或不可变。
如果工作负荷设计为使用可变基础结构，则前滚是有意义的，因为它涉及到就地更新基础结构。 相反，使用不可变基础结构时，回退或回退可能有意义。
无论做出哪种选择，都应在决策过程中包括适当的审批，并将其编码到决策树中。
缓解措施
回滚：在回滚方案中，还原更新的系统进入上一个已知良好的配置状态。
对于整个工作负载团队而言，必须就 上次已知良好的含义达成一致。 此表达式是指在部署开始之前处于正常运行状态的工作负荷的最后一个状态，该状态不一定是以前的应用程序版本。
回滚可能很复杂，尤其是在它与数据更改相关时。 架构更改可能会使回滚存在风险。 安全实施它们可能需要大量的规划。 作为一般建议，架构更新应是累加的。 它们不应是替换更改，记录不应替换为新记录。 应弃用较旧的记录，并且应与新记录共存，直到可以安全地删除已弃用的记录。
回退：在回退方案中，将从生产流量路由中删除更新的系统。 所有流量都定向到未更新的堆栈。 这种低风险策略提供了一种在不引入进一步中断的情况下解决代码中的问题的方法。
使用 Canary 部署时，回退可能并不简单，甚至不可能，具体取决于基础结构和应用设计。 如果需要执行缩放来处理未更新系统上的负载，请在回退之前执行该缩放。
绕过有问题的函数：如果可以通过使用功能标志或其他类型的运行时配置属性来绕过此问题，则可以认为继续推出是解决给定问题的正确策略。
你应该清楚地了解绕过函数的权衡，并且应该能够向利益干系人传达这种权衡。 利益干系人应批准前进计划。 利益干系人需要确定在降级状态下可容忍的运行时间长度。 他们还需要根据你估计的修复和部署违规代码所需的时间来权衡这一决定。
紧急部署 (热修复) ：如果可以在推出中解决问题，则热修复可能是最实用的缓解策略。
与任何其他代码一样，热修补程序需要完成安全部署实践。 但通过热修复，时间线大大加速了。 你需要在整个环境中使用代码提升策略。 还需要在所有质量入口处检查热修复代码。 但可能需要大幅缩短烘焙时间，并且可能需要修改测试以加速测试。 确保可以在部署后尽快对更新的代码运行完整测试。 高度自动化质量保证测试有助于在这些方案中提高测试效率。
权衡：
- 能够回退通常意味着需要足够的基础结构容量来同时处理两个版本的工作负载配置。 工作负载团队还需要能够同时在生产环境中支持两个版本。
- 能够有效地回滚可能需要重构工作负载的元素。 例如，可能需要分离函数或更改数据模型。
通信
必须明确定义通信责任，以帮助最大程度地减少事件期间的混乱。 这些职责应确定工作负载团队如何与支持团队、利益干系人和紧急响应团队人员（如紧急响应经理）互动。
标准化工作负载团队在提供状态更新时遵循的节奏。 确保利益干系人了解此标准，以便他们知道何时需要更新。
如果工作负荷团队需要直接与最终用户通信，请阐明适合与用户共享的信息类型和详细信息级别。 此外，请向工作负载团队传达适用于这些情况的任何其他要求。
事件调查报告
事后调查应遵循所有失败的部署，无一例外。 每次失败的部署都是学习的机会。 事后分析有助于确定部署和开发过程中的弱点。 还可以识别基础结构中的错误配置，以及其他许多可能。
事后调查应始终是无可指责的，以便参与事件的个人在分享自己对可改进之处的看法时感到安全。 事后领导应跟进实施已确定的改进计划，并将这些计划添加到工作负载积压工作。
注意事项和一般建议
确保部署管道可以接受不同的版本作为参数，以便可以轻松部署最新已知良好的配置。
在回滚或前滚时，保持与管理和数据平面的一致性。 特定于资源和策略的密钥、机密、数据库状态数据和配置都需要在范围内并得到考虑。 例如，请注意上次已知良好的部署中基础结构缩放的设计。 确定重新部署代码时是否需要调整该配置。
首选小型、频繁的更改，而不是不频繁的大型更改，以便新部署与上次已知良好的部署之间的增量较小。
(FMA) 对持续集成和持续交付 (CI/CD) 管道执行故障模式分析，以帮助识别可能使缓解复杂化的问题。 与整个工作负载一样，可以分析管道，以识别尝试给定缓解类型时可能出现问题的区域。
谨慎使用自动回滚功能：
- 某些 CI/CD 工具（如 Azure DevOps）内置了自动回滚功能。 如果此功能提供有形价值，请考虑使用此功能。
- 只有在全面且定期地测试管道后，才应采用自动回滚功能。 确保管道足够成熟，在触发自动回滚时引入额外的问题。
- 需要相信自动化仅部署必要的更改，并且仅在必要时才会触发它。 请仔细设计触发器以满足这些要求。
在回滚期间使用平台提供的功能。 例如，备份和时间点还原有助于存储和数据回滚。 或者，如果使用虚拟机 (VM) 托管应用程序，将环境还原到事件发生前的检查点会很有帮助。
经常测试整个部署失败缓解策略。 与紧急响应计划和灾难恢复计划一样，仅当团队接受过培训并定期实践时，部署失败计划才会成功。 混沌工程和 故障注入测试 可能是测试部署缓解策略的有效技术。
Azure 简化
Azure Pipelines 提供生成和发布服务来支持应用程序的 CI/CD。
Azure Test Plans是一种易于使用的基于浏览器的测试管理解决方案。 此解决方案提供计划内手动测试、用户验收测试和探索性测试所需的功能。 Azure Test Plans还提供了一种从利益干系人那里收集反馈的方法。
Azure Monitor 是一个全面的监视解决方案，用于从云和本地环境中收集、分析和响应监视数据。 监视器包括可靠的警报平台。 可以为该系统配置 自动通知和其他操作，例如自动缩放和其他自我修复机制。
Application Insights 是 Monitor 的扩展，它 (APM) 功能提供应用程序性能监视。
Azure 逻辑应用 是一个基于云的平台，用于运行集成应用、数据、服务和系统的自动化工作流。 每当更新应用程序时，都可以使用逻辑应用创建应用程序的新版本。 Azure 维护版本的历史记录，可以还原或升级任何以前的版本。
许多 Azure 数据库服务都提供时间点还原功能，可在需要回滚时提供帮助：
Azure Chaos Studio 预览版是一项托管服务，它使用混沌工程来帮助度量、了解和改进云应用程序和服务的复原能力。
相关链接
卓越运营清单
请参阅完整的建议集。