Microsoft AZ-400: 发布管理与部署策略 — 学习指南

By Laurynas Brazys · 10 August 2026 · #microsoft #az-400 #certification #exam-prep #study-guide

属于 Microsoft DevOps Engineer Expert AZ-400 — 学习指南. 使用经过验证的答案练习： Microsoft 考试中心, 或参加限时模拟考试： ExamRoll.io.

概述

Azure 上的发布管理依赖于可重复、策略驱动的交付，旨在加速反馈的同时保护可用性。掌握部署策略、门控验证、环形发布（ring-based exposure）和功能标记驱动的灰度发布（dark launches），能让团队在不牺牲安全性的前提下持续交付。Azure Pipelines、Azure Deployment Environments、Azure Front Door/Traffic Manager 和 Azure App Configuration 提供了一套统一的工具链，用于渐进式交付、多环境编排和可审计的变更控制。本节将解释何时以及如何使用这些功能，如何将它们组合在一起，以及生产级管道中应具备的回滚和文档实践。

部署策略与渐进式交付

蓝绿部署（Blue-green，也称红黑部署）将新版本部署到一个并行环境（绿色），而当前版本（蓝色）继续提供流量服务。在 Azure App Service 上，部署槽位（deployment slots）可实现蓝绿部署：部署到预演（staging）槽位，进行预热，然后执行槽位交换（slot swap）。回滚只需再次交换槽位即可瞬间完成，因此蓝绿部署是回滚速度最快的选项。将槽位交换与“预交换验证”（Swap with preview）功能结合使用，可以在流量切换前验证绑定和应用设置。

金丝雀部署（Canary）首先向一小部分用户发布，然后在健康状况保持稳定的情况下逐步增加流量。在 Azure 上，可以通过以下方式实现金丝雀部署：

• Azure Front Door 的加权路由，在应用层将流量分配到新旧后端，并结合健康探针和 WAF。
• Azure Traffic Manager 的加权终结点，当需要区域级控制时，用于基于 DNS 的全局金丝雀部署。
• AKS 金丝雀部署，通过 Ingress（例如，NGINX 的金丝雀注解）或服务网格的流量拆分来实现。在推进部署前，门控应评估错误预算、延迟百分位数和饱和度。

滚动更新（Rolling updates）逐步替换实例，避免了双倍实例成本。在 AKS 中，可配置 rollingUpdate 的 maxSurge 和 maxUnavailable 参数；确保就绪/存活探针（readiness/liveness probes）和 PDB（Pod Disruption Budgets）能够保护可用性。对于 VM Scale Sets，应使用带有应用程序健康探针的滚动升级策略。滚动更新虽然经济，但从系统性回归中恢复的速度比蓝绿部署慢。

功能标记（Feature flags）将发布与部署解耦。灰度发布（Dark launching）交付默认禁用的代码路径，从而在不暴露功能的情况下验证基础设施。使用功能标记来控制高成本的迁移、逐步揭示 UI，并快速禁用有问题的行为。这种方式补充了金丝雀部署和环形部署：先广泛部署，然后逐步启用。

环形部署（Ring-based deployment）将跨用户群体的渐进式暴露过程正式化。定义不同的环，例如 R0（内部）、R1（金丝雀客户）、R2（单个区域）和 R3+（全球）。晋级标准必须是客观的：符合 SLO、没有 Sev2+ 级别的事件，以及可接受的业务 KPI。将环形部署与流量切换（Front Door/Traffic Manager）、环境检查和审批门控相结合，以便及早停止或回滚。

Azure Front Door 与 Traffic Manager 在渐进式流量切换方面的对比：Front Door 在第 7 层运行，支持即时变更、健康探针、会话亲和性、基于路径的路由和加权拆分——是应用层金丝雀部署和 A/B 测试的理想选择。Traffic Manager 在 DNS 层运行；它更适用于地理路由、跨云故障转移或区域级别的金丝雀部署，但需要考虑 DNS TTL，并且不具备应用层功能。

环境、审批与门控

Azure Deployment Environments 通过护栏（guardrails）标准化开发/测试环境的预配。环境定义是基础架构即代码（Bicep/ARM/Terraform）模板，用于描述可重复的堆栈。这些定义存放在目录（catalogs）中——即在该服务中注册的 Git 仓库——从而实现版本化、可发现的环境蓝图。开发人员可以自助服务式地创建受企业策略（如配额、RBAC、网络）约束的开发/测试实例，从而消除“雪花”环境，并使低级环境与生产拓扑保持一致。

审批（Approvals）在需要时建立人工干预控制。在 Azure Pipelines 中：

• 部署前审批（Pre-deployment approvals）会阻塞一个阶段，直到指定的审批人同意。适用于高风险的转换，例如从预演（staging）到生产，或从金丝雀环升级到更广的环。
• 部署后审批（Post-deployment approvals）在发布被标记为完成之前，确认验证活动（如 UAT 签核、审计步骤）已完成。
• 配置审批超时，使请求自动过期；过期的审批会导致阶段失败，防止不受控制的漂移。当需要职责分离时，要求多个审批人或顺序审批。通过“审批和检查”（Approvals and checks）将审批应用于环境和服务连接，以实现一致的治理。

发布门控（Release gates）在晋级前强制执行客观证据。Azure Pipelines 支持以下检查：

• Azure Monitor 检查，用于查询指标或警报（例如，没有活动的 Sev2 警报，错误率低于阈值，p95 延迟低于目标）。门控会按定义的时间间隔重新评估，直到成功/失败或超时。
• 调用 REST API 检查，用于调用外部质量服务、负载测试或内部合规性端点。解析响应，如果不满足标准则阻止部署。
• 工作项查询检查，确保在发布前，所需的任务、Bug 或变更请求处于正确的状态（例如，所有“必须修复”的缺陷都已解决）。使用范围限定于本次发布或提交范围的查询。

在环形边界和金丝雀部署期间实施门控，可以将主观的晋级决策转变为可衡量的决策。

多环境管道、变量和依赖项

设计具有显式依赖项和环境范围的多阶段 YAML 管道。使用带有策略块（runOnce、rolling、canary）的部署作业来模拟渐进式发布，并包含用于 preDeploy、routeTraffic、postRouteTraffic 和 on: failure 的钩子以实现自动回滚。阶段应声明 dependsOn 和 conditions，以便后续环境仅在先前环境通过门禁和审批后才运行。

通过以下方式管理特定于环境的配置：

• 按环境限定范围的变量组，链接到 Azure Key Vault 以管理机密。按阶段引用变量组，并将敏感值排除在源代码管理之外。
• 使用 YAML 模板和运行时参数来标准化跨服务的部署，并传递特定于环境的值（连接字符串、功能标志默认值、Front Door 权重）。
• 对 appsettings 和 Kubernetes 清单使用令牌化或转换任务，确保实现无漂移的配置即代码。

对于到多个环境的部署，首选通过提升（一次构建，多次部署）实现的不可变构件。将工作项与提交和构建关联起来，以在同一构件从开发流向生产的过程中保持可追溯性，从而实现准确的发布说明和审计。

回滚策略和数据库注意事项

在发布前规划好回滚方案：

• 自动回滚使用健康信号来恢复，无需人工操作。在 AKS 中，保守地设置 maxSurge/maxUnavailable 并启用失败发布时的自动回滚；使用

undefined

或依赖部署策略失败钩子来触发上一个 ReplicaSet。在 Azure App Service 中，槽交换回滚是即时的；与健康检查和部署门禁结合使用以自动决策。

• 当恢复需要操作员判断时（例如存在数据风险、部分失败），手动回滚是合适的。提供一键式管道任务，用于重新路由 Front Door/Traffic Manager 权重、撤销槽交换或重新部署上一个已知良好版本。保持上一个构件随时可用，并记录决策过程。
• 数据库回滚需要格外小心。避免向后不兼容的变更。使用扩展-收缩模式：添加列/表并填充它们，同时保持读/写兼容；如果需要，部署同时写入新旧两个模式的代码；之后再移除已弃用的元素。对于 Azure SQL Database，结合使用：
  • DACPAC 或迁移框架（如 EF Core），配合幂等的、版本化的脚本以及部署前/后验证。
  • 在线操作（如可恢复的索引重建、分区切换）以最大限度地减少锁争用。
  • 将时间点还原和活动异地复制作为最后手段，并确认存在数据丢失风险。在进行任何模式降级之前，通过功能标志关闭相关功能。基于 Azure Monitor 和 Query Store 中捕获的数据库健康状况（DTU/CPU、死锁）来设置提升门禁。

使用 Azure App Configuration 实现功能标志与发行说明自动化

Azure App Configuration 通过为 .NET、Java、Node.js 等提供 SDK，集中化了功能管理。可使用标签（label）按环境或发布环（ring）来限定功能标志的范围，并启用动态刷新，使应用程序无需重新部署即可获取变更。

• 目标筛选器（Targeting filter）允许基于用户/组、声明（claim）、设备或自定义属性进行精细化启用。定义群组（cohort）（例如，内部租户、VIP 客户）以与发布环对齐。
• 百分比发布（Percentage rollout）将功能逐步暴露给一个随机的用户子集。从 1-5% 开始，验证 KPI，然后逐步增加。与 Front Door 的权重设置协同，实现用户和流量层面的分层控制。
• 紧急关闭开关（Kill switch）可在发生事故时立即禁用某个功能。使用一个全局关闭开关来保护高风险路径（如支付、数据写入），执行此操作无需任何部署。记录所有开关操作以供审计，并与事故相关联。

自动化发行说明以提供可追溯性和沟通：

• 通过要求提交信息和 PR 引用 ID 来强制执行工作项链接。Azure DevOps 会自动将构建和发布与工作项及提交关联起来。
• 在管道中使用“生成发行说明”（Generate Release Notes）任务或 REST API 调用，列出自上次成功部署到目标环境以来的变更和工作项，从而生成变更日志。输出 Markdown，其中包含功能、修复、破坏性变更和数据库迁移等部分。
• 将说明发布到项目 Wiki，将其打包为构建产物，并附加到发布中。包含部署元数据（构建号、提交 SHA、环境、审批人、通过的门禁）以满足合规性要求。

实际问题场景

Adobe 需要为其托管在 Azure 上的营销网站引入一个新的个性化引擎，同时不能在营销活动高峰期冒着转化率下降的风险。团队必须能够频繁部署、渐进式暴露该功能、验证 SLO，并在 KPI 下降时立即回滚。

1. 使用 Azure Deployment Environments 定义环境

• 在一个由 Git 支持的目录中，为应用、AKS、Azure SQL 和 Front Door 创建环境定义（Bicep）。开发人员可以安全地自服务式配置开发/测试环境，确保与生产环境的一致性，并为实验启用临时测试堆栈。ADE 强制执行配额和 RBAC 来控制开销和访问。

2. 使用多阶段 YAML 实现一次构建、多次部署

• 单个产物依次晋升通过 ring-r0、ring-r1、ring-r2 和 prod 等阶段。各阶段相互依赖，并使用带有策略（如适用，采用金丝雀和滚动策略）的部署作业，保证跨发布环的二进制文件一致性。

3. 对旧版 Web 层使用 App Service 槽位实现蓝绿部署

• 部署到预备槽（staging slot），进行预热，然后为 ring-r0 的内部用户进行交换。如果 Adobe 的 SLO 下降，反向槽位交换可提供近乎零停机的最快回滚。

4. 通过 Azure Front Door 加权路由引入金丝雀发布

• 同时注册旧版和新版个性化后端。开始时，将 1% 的流量引导至 ring-r1 中的新后端。Front Door 的健康探测和即时权重更新功能，能够根据流量模式进行安全、快速的调整。

5. 使用客观检查作为阶段晋升的门禁（Gate）

• 添加 Azure Monitor 检查，监控来自 Application Insights 的 p95 延迟、错误率和转化率 KPI。添加一个 REST API 检查，调用 Adobe 内部的实验服务以确认护栏指标。配置一个工作项查询检查，确保“必须修复”（Must Fix）的 Bug 在发布环晋升前已关闭。门禁会定期评估并设有超时，以防止变更停滞。

6. 在关键转换点要求审批

• 对 ring-r2 和 prod 的部署前审批需要市场和 SRE 团队的批准，并设置 4 小时超时以避免发布悬空。部署后审批则用于确认 UAT 和分析验证已完成，然后才关闭发布。

7. 使用 Azure App Configuration 功能标志控制暴露范围

• 实施暗启动（dark launching），使新引擎初始时存在但被禁用。使用目标筛选器为内部员工（ring-r0）和选定的客户群组（ring-r1）启用该功能。应用百分比发布来扩大暴露范围。如果出现异常，一个紧急关闭开关可以在几秒钟内全局禁用该引擎，而无需重新部署。

8. 使用扩展-收缩（expand-contract）模式迁移来保护数据

• 首先部署增量式 SQL 变更，异步回填数据，并在需要时进行双写。只有在稳定性得到证实后，才移除已弃用的模式（schema）。门禁会监控 DTU、死锁和长时间运行的查询，以防止不安全的晋升。

9. 自动化回滚路径

• 部署作业上的失败挂钩（Failure hook）会触发回滚：Front Door 中新后端的权重恢复到 0%；App Service 执行反向槽位交换；AKS 执行

undefined

。对于复杂场景，操作员仍然可以使用手动一键回滚。

10. 自动化发布文档

• 管道根据关联的工作项和提交生成 Markdown 格式的发行说明，重点说明已开启的功能、数据库变更以及通过的门禁。说明会发布到 Azure DevOps Wiki 并附加到发布中，从而满足审计要求和利益相关者的可见性。

这种方法充分利用了每种工具的优势：ADE 用于创建安全、可复现的环境；YAML 策略和审批用于实现受管控的流程；Front Door 和 App Configuration 用于分层的渐进式交付；Azure Monitor 和门禁用于客观的质量控制；自动化的回滚和发行说明则用于增强弹性和可追溯性。

← 容器化与 Kubernetes · 所有领域 · 安全、合规性与 DevSecOps →

练习这些题目 → · 在 ExamRoll.io 上限时练习 →

浏览 Microsoft →