你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

安全部署做法建议

  • 项目

适用于此 Azure Well-Architected 框架卓越运营清单建议：

OE：11 明确定义工作负载的安全部署做法。 强调小型、增量、质量门控的发布方法的理想。 使用新式部署模式和渐进式曝光技术来控制风险。 考虑例程部署和紧急部署或修补程序部署。

本指南介绍使用 SDP) (安全部署做法的建议。 安全部署过程和过程定义如何安全地对工作负载进行更改和部署。 实现 SDP 需要从管理风险的角度考虑部署。 可以通过实施 SDP 来最大程度地降低部署中人为错误的风险，并限制有问题的部署对用户的影响。

关键设计策略

实施安全部署做法时，需要牢记四个重要准则：

  • 安全性和一致性：对生产工作负荷的所有更改本质上都是有风险的，必须专注于安全性和一致性。

  • 渐进式曝光：可以通过采用渐进式曝光部署模型，将部署引起的问题的潜在爆炸半径降到最低。

  • 运行状况模型：部署必须通过运行状况检查，然后才能开始渐进式曝光的每个阶段。

  • 问题检测：检测到问题后，应立即停止部署并启动恢复。

以下各节提供了有关其中每一点的详细建议。

安全性和一致性

无论是将更新部署到应用程序代码、基础结构即代码 (IaC) 、功能标志还是配置更新，都给工作负载带来风险。 没有 低风险 部署到生产环境。 每个部署都必须遵循标准模式，并且应自动执行，以强制实施一致性并最大程度地降低人为错误的风险。 工作负荷供应链和部署管道必须可靠、安全且具有明确定义的部署标准，这一点至关重要。 将每个部署视为可能的风险，并将每个部署都设置为相同的风险管理级别。 尽管存在风险，但应继续对工作负载进行定期更改。 未能部署常规更新会带来其他风险，例如必须通过部署解决的安全漏洞。 有关详细信息，请参阅 设计工作负载开发供应链的建议。

频繁的小型部署比不常见的大型部署更可取。 当出现问题时，小更改更容易解决，频繁部署有助于团队在部署过程中建立信心。 在部署期间遇到异常时，通过查看工作负载流程，从生产中学习也很重要。 你可能会发现基础结构设计或推出方面的弱点。 在部署过程中出现问题时，请确保 无责备 的事后分析是 SDP 过程的一部分，以捕获有关事件的教训。

渐进式公开部署

发生部署问题时，目标是尽早捕获这些问题，以尽量减少对最终用户的影响。 实现逐步推出部署模型（也称为 渐进式曝光模型）以实现此目标。 金丝雀部署是渐进式曝光的常见示例。 在此部署模型中，一小组内部或外部用户首先接收新功能。 第一个组在没有问题的情况下运行新版本后，该功能将连续部署到更大的组，直到整个用户填充运行新版本。 功能标志通常用于为 Canary 部署中的目标用户启用新版本。

另一种常见的部署模型是蓝绿方法。 在此模型中，部署了工作负载基础结构的两个相同集或池。 这两个池都能够处理完整的生产负载。 第一个 (蓝色) 池运行所有用户登录的当前部署版本。 第二个 (绿色) 池使用新功能进行更新，并在内部测试。 内部测试后，生产流量的子集从蓝色池路由到绿色池。 与金丝雀部署一样，随着你在连续更大的推出波中将更多的流量转移到绿色池，推出是渐进式的。 完成推出后，更新池将成为蓝色池，绿色池已准备好进行下一次部署。 这两个池在逻辑上彼此分离，以防止发生故障。 可以通过一次在一个标记上部署，在使用 部署图章 设计模式的工作负荷中部署蓝绿模型变体。

在这两个模型中，每个推出阶段之间的时间应该足够长，以便能够监视工作负载的运行状况指标。 应提供充足的 烘焙时间、推出组之间的时间，以帮助确保来自不同区域的用户或执行不同任务的用户有时间以正常容量使用工作负载。 烘焙时间应以小时和天而不是分钟为单位。 每个推出组的烘焙时间也应增加，以便可以考虑一天中的不同时区和使用模式。

运行状况模型

开发可靠的运行状况模型作为可观测性平台和可靠性策略的一部分。 运行状况模型应提供对工作负载组件和整体运行状况的深入可见性。 在推出期间，如果收到与最终用户相关的运行状况更改警报，应立即停止推出，并应执行警报原因调查以帮助确定下一个操作过程。 如果最终用户未报告任何问题，并且所有运行状况指标在整个烘焙过程中保持绿色，则应继续推出。 请务必在运行状况模型中包括使用情况指标，以帮助确保缺少用户报告的问题和负面运行状况信号不会隐藏问题。 有关详细信息，请参阅 生成运行状况模型。

问题检测

当部署导致某个推出组中的问题时，必须立即停止推出。 必须在收到警报后立即对问题原因和影响严重性进行调查。 从问题中恢复可能包括：

  • 通过撤消在部署中所做的更改并还原回上一个已知工作配置来回滚部署。

  • 在推出期间通过解决问题来推进部署。 可以通过应用修补程序或其他最小化问题来解决推出中的问题。

  • 使用上一个已知工作配置部署新基础结构。

回滚更改（尤其是数据库、架构或其他有状态组件更改）可能很复杂。 SDP 指南应提供有关如何根据工作负载的数据资产设计处理数据更改的明确说明。 同样，必须仔细处理前滚，以确保 SDP 不会被忽略，并且修补程序或其他最小化工作安全执行。

常规 SDP 建议

  • 跨生成项目实现版本控制，以帮助确保可以在必要时回滚和前滚。

  • 使用发布流或基于中继的分支结构，该结构在开发团队中强制实施紧密同步的协作，而不是基于 Gitflow 或环境的分支结构。

  • 尽可能多地自动执行 SDP。 有关自动化 IaC 和应用程序持续集成和持续交付 (CI/CD) 流程的详细指南，请参阅 实现自动化的建议。

  • 使用 CI 做法定期将代码更改集成到存储库中。 CI 做法可帮助你识别集成冲突，并降低发生大型风险合并的可能性。 有关详细信息，请参阅 持续集成指南。

  • 使用功能标志有选择地启用或禁用生产中的新功能或更改。 功能标志可以帮助你控制新代码的公开，并在出现问题时快速回滚部署。

  • 将更改部署到镜像生产环境的过渡环境。 练习环境允许在部署到实时环境之前测试受控设置中的更改。

  • 建立预部署检查，包括代码评审、安全扫描和合规性检查，以帮助确保更改是安全的部署。

  • 实现断路器以自动停止向遇到问题的服务的流量。 这样做有助于防止系统进一步降级。

紧急 SDP 协议

建立规范性协议，用于定义如何针对修补程序或紧急问题（如安全漏洞或漏洞暴露）调整 SDP。 例如，紧急 SDP 协议可能包括：

  • 升级和审批阶段加速。

  • 冒烟测试和集成测试加速。

  • 减少烘焙时间。

在某些情况下，紧急情况可能会限制质量和测试入口，但仍应尽快运行门作为带外练习。 请确保定义谁可以在紧急情况下批准 SDP 加速，以及加速批准所必须满足的条件。 使紧急 SDP 协议与 紧急响应计划 保持一致，以帮助确保根据相同的协议处理所有紧急情况。

注意事项

构建和维护安全部署做法十分复杂。 能否完全实施可靠的标准取决于你在许多软件开发领域做法的成熟度。 自动化的使用、基础结构更改的仅限 IaC、分支策略的一致性、功能标志的使用以及许多其他做法都有助于确保安全部署。 使用本指南优化工作负载，并随着实践的发展，告知改进计划。

Azure 便利化

示例

有关如何使用此部署模型的示例，请参阅蓝绿部署 Azure Kubernetes 服务 (AKS) 群集体系结构指南。

卓越运营清单

请参阅完整的一组建议。

卓越运营清单