通过

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

有关安全部署实践的建议

  • 项目

适用于此 Azure 精心构建的框架卓越运营清单建议：

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

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

关键设计策略

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

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

  • 渐进式曝光：通过采用渐进式曝光部署模型，可以最大程度地减少部署原因问题的潜在爆炸半径。

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

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

以下各部分提供有关上述每个点的详细建议。

确保部署的安全性和一致性

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

频繁的小型部署更可取于不经常的大型部署。 当出现问题且频繁部署有助于团队建立对部署过程的信心时，小更改更易于解决。 在部署过程中遇到异常情况时，请务必通过查看工作负荷进程来了解生产环境。 在基础结构设计或推出方面可能会发现弱点。 在部署期间出现问题时，请确保 无 责后验尸是 SDP 过程的一部分，以捕获有关事件的教训。

采用渐进式曝光模型

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

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

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

开发可靠的工作负荷运行状况模型

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

实现故障检测机制

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

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

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

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

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

为紧急部署建立协议

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

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

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

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

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

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

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

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

紧急 SDP 协议

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

  • 促销和审批阶段加速。

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

  • 烘焙时间减少。

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

注意事项

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

Azure 便利化

示例

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

卓越运营清单

请参阅完整的建议集。

卓越运营清单