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