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 上的發行管理，其關鍵在於可重複、受原則治理的交付流程，此流程能在加速回饋的同時保護可用性。精通部署策略、閘道驗證、環形部署以及功能旗標的暗黑啟動，能讓團隊在不犧牲安全性的前提下持續交付。Azure Pipelines、Azure Deployment Environments、Azure Front Door/Traffic Manager 和 Azure App Configuration 提供了一套緊密整合的工具鏈，用於實現漸進式交付、多環境協調以及可稽核的變更控制。本節將說明何時及如何使用這些功能、如何將它們串連起來，以及在生產等級的管線中，應具備哪些回滾和文件記錄實務。

部署策略與漸進式交付

Blue-green (或稱 red/black) 部署會將新版本部署到一個平行的環境 (綠色)，而當前版本 (藍色) 則繼續服務流量。在 Azure App Service 上，deployment slots 可用來實現 Blue-green 部署：先部署到預備 (staging) 環境、進行暖機，然後執行位置交換 (slot swap)。回滾只需再次交換位置即可瞬間完成，這也是為什麼 Blue-green 是最快的回滾選項。將位置交換與「Swap with preview」功能搭配使用，可以在流量轉移前驗證繫結和應用程式設定。

Canary 部署會先將新版本部署給一小部分使用者，然後在健康狀態穩定的情況下，逐步增加流量。在 Azure 上，可透過以下方式實現 Canary 部署：

Azure Front Door 的加權路由 (weighted routing)：在應用程式層，利用健康狀態探查 (health probes) 和 WAF，將流量分割到新舊後端。
Azure Traffic Manager 的加權端點 (weighted endpoints)：當需要區域層級的控制時，可用於基於 DNS 的全球性 Canary 部署。
AKS 的 Canary 部署：透過 Ingress (例如 NGINX 的 canary annotations) 或服務網格 (service mesh) 的流量分割來實現。在推進到下一階段前，閘道應評估錯誤預算 (error budgets)、延遲百分位數 (latency percentiles) 和飽和度 (saturation)。

滾動更新 (Rolling updates) 會逐步替換執行個體，避免了雙機隊的成本。在 AKS 中，可設定 rollingUpdate 的 maxSurge 和 maxUnavailable 參數；並確保 readiness/liveness probes 和 PDBs 保護可用性。對於 VM Scale Sets，則使用滾動升級策略搭配應用程式健康狀態探查。滾動更新雖然經濟，但從系統性退化中恢復的速度比 Blue-green 部署慢。

功能旗標 (Feature flags) 將發行與部署解耦。暗黑啟動 (Dark launching) 會交付預設為停用的程式碼路徑，在不暴露功能的情況下驗證基礎設施。使用旗標來控制昂貴的遷移作業、逐步揭露 UI，以及快速停用有問題的行為。這與 Canary 和環形部署相輔相成：先廣泛部署，然後再逐步啟用。

環形部署 (Ring-based deployment) 將跨群體的漸進式暴露流程正式化。定義如 R0 (內部)、R1 (金絲雀客戶)、R2 (單一區域) 和 R3+ (全球) 等環。晉級標準必須是客觀的：符合 SLO、沒有 Sev2+ 等級的事件，以及可接受的業務 KPI。將環形部署與流量轉移 (Front Door/Traffic Manager)、環境檢查和核准閘道結合，以便及早停止或回滾。

比較 Azure Front Door 與 Traffic Manager 於漸進式流量轉移的應用：Front Door 運作於第 7 層，具備即時變更、健康狀態探查、工作階段親和性 (session affinity)、基於路徑的路由 (path-based routing) 和加權分割等功能——非常適合應用程式層的 Canary 部署和 A/B 測試。Traffic Manager 則運作於 DNS 層；它更適合地理路由 (geo-routing)、跨雲端容錯移轉或區域層級的 Canary 部署，但需要考量 DNS TTL，且不具備應用程式層的功能。

環境、核准與閘道

Azure Deployment Environments 透過防護機制 (guardrails) 將開發/測試環境的佈建標準化。環境定義是基礎設施即程式碼 (IaC) 的範本 (Bicep/ARM/Terraform)，用以描述可重複的技術堆疊。這些定義存放在目錄 (catalogs) 中——即註冊到服務裡的 Git 儲存庫——從而實現了版本化、可被探索的環境藍圖。開發人員可以在企業原則 (配額、RBAC、網路) 的限制下，自助服務取得開發/測試執行個體，藉此消除「雪花」環境，並使較低階的環境與生產拓撲保持一致。

核准 (Approvals) 在需要時建立人工介入的控制點。在 Azure Pipelines 中：

部署前核准 (Pre-deployment approvals) 會阻擋一個階段，直到指定的核准人同意為止。適用於高風險的轉換，例如從預備環境到生產環境，或環形部署中超越 Canary 階段的升級。
部署後核准 (Post-deployment approvals) 用於在發行標記為完成前，確認驗證活動 (如 UAT 簽核、稽核步驟) 已完成。
設定核准逾時，讓請求自動過期；過期的核准會導致階段失敗，防止不受控的漂移。當需要職責分離 (separation of duties) 時，可要求多位核准人或依序核准。透過「Approvals and checks」將核准應用於環境和服務連線 (service connections)，以實現一致的治理。

發行閘道 (Release gates) 在晉級前強制要求客觀的證據。Azure Pipelines 支援以下檢查：

Azure Monitor 檢查：查詢指標或警示 (例如，沒有作用中的 Sev2 警示、錯誤率低於閾值、p95 延遲低於目標)。閘道會以定義的間隔重新評估，直到成功/失敗或逾時。
叫用 REST API 檢查：呼叫外部品質服務、負載測試或內部合規性端點。解析回應，若不符合標準則阻擋。
工作項目查詢檢查：確保在發行前，必要的任務、錯誤或變更請求處於正確的狀態 (例如，所有「必須修復」的缺陷都已解決)。使用範圍限定在該次發行或 commit 範圍內的查詢。

在環形部署的邊界和 Canary 階段實施閘道，將主觀的晉級決策轉變為可量化的決策。

多環境管線、變數與相依性

設計具有明確相依性與環境範疇的多階段 YAML 管線。使用部署作業 (deployment jobs) 搭配策略區塊 (strategy blocks) (runOnce、rolling、canary) 來模擬漸進式部署 (progressive rollout)，並包含 preDeploy、routeTraffic、postRouteTraffic 與 on: failure 的掛鉤 (hooks) 以實現自動化回滾。階段 (Stages) 應宣告 dependsOn 與 conditions，以便後續的環境只有在前一個環境通過閘門 (gates) 與核准 (approvals) 之後才會執行。

透過以下方式管理特定於環境的組態：

依環境劃定範疇的變數群組 (Variable groups)，並連結至 Azure Key Vault 以存放密鑰。每個階段參考對應的群組，並將敏感值排除在原始碼控制之外。
使用 YAML 範本與執行階段參數，以標準化跨服務的部署，並傳遞特定於環境的值 (例如連線字串、功能旗標的預設值、Front Door 的權重)。
針對 appsettings 與 Kubernetes manifests 進行權杖化 (Tokenization) 或轉換任務，確保「組態即程式碼」(configuration as code) 不會發生漂移 (drift)。

對於多環境的部署，偏好採用具備晉升 (promotion) 機制的不可變成品 (immutable artifacts) (也就是「建置一次，部署多次」)。將工作項目 (work items) 與提交 (commits) 及建置 (builds) 綁定，以便在同一個成品從開發 (dev) 環境流向生產 (prod) 環境的過程中維持可追溯性，從而產出準確的發行說明與進行稽核。

回滾策略與資料庫考量

在交付產品前就規劃好回滾計畫：

自動回滾 (Automatic rollback) 使用健康狀態信號，在無人為介入的情況下進行還原。在 AKS 中，保守地設定 maxSurge/maxUnavailable，並在部署失敗時啟用自動回滾；使用 kubectl rollout undo 或依賴部署策略的失敗掛鉤 (failure hooks) 來觸發前一個 ReplicaSet。在 Azure App Service 中，交換回部署槽 (slot swap back) 是即時的；可搭配健康狀態檢查與部署閘門 (deployment gates) 來自動做出決策。
手動回滾 (Manual rollback) 適用於需要操作員判斷才能進行恢復的情況 (例如有資料風險、部分失敗)。提供一鍵式的管線任務，用以重新路由 Front Door/Traffic Manager 的權重、復原部署槽交換，或重新部署最後一個已知的良好建置。將前一個成品準備好以便隨時取用，並將決策過程文件化。
資料庫回滾需要格外小心。避免向後不相容的變更。使用擴展-收縮 (expand-contract) 模式：新增資料行/資料表並填入資料，同時保持讀寫相容；如有需要，部署可同時寫入新舊兩種結構 (schema) 的程式碼；最後才移除已棄用的元素。對於 Azure SQL Database，結合使用以下方法：
- DACPAC 或遷移框架 (如 EF Core)，搭配具備冪等性 (idempotent)、版本化的腳本，以及部署前/後驗證。
- 線上作業 (例如可續行的索引重建、資料分割切換)，以最小化鎖定競爭 (lock contention)。
- 時間點還原 (Point-in-time restore) 與作用中異地複寫 (active geo-replication) 作為最後手段，並認知到有資料遺失的風險。在進行任何結構降級之前，透過功能旗標關閉相關功能。根據 Azure Monitor 與 Query Store 中捕獲的資料庫健康狀態 (如 DTU/CPU、死結) 來決定是否晉升至下一階段。

使用 Azure App Configuration 的功能旗標與版本說明的自動化

Azure App Configuration 透過適用於 .NET、Java、Node.js 等語言的 SDK，集中管理功能。您可以使用標籤來界定每個環境或環的功能旗標範圍，並啟用動態重新整理，讓應用程式無需重新部署即可取得變更。

目標篩選條件允許根據使用者/群組、宣告、裝置或自訂屬性進行細緻的啟用。定義群體（例如，內部租用戶、VIP 客戶）以對應環形部署。
百分比推出會逐步將功能揭露給隨機的子集。從 1–5% 開始，驗證 KPI，然後逐步增加。與 Front Door 的加權設定協調，以在使用者和流量層級上進行分層控制。
Kill switch 能在事件發生時立即停用功能。使用一個無需部署即可執行的全域關閉開關，來保護高風險路徑（如支付、資料寫入）。記錄所有開關操作以供稽核，並與事件建立關聯。

自動化版本說明以提供可追溯性與溝通：

透過要求 commit 訊息和 PR 參照 ID 來強制連結工作項目。Azure DevOps 會自動將建置和發行與工作項目及 commit 建立關聯。
在管線中使用「產生版本說明」任務或呼叫 REST API，來列出自上次成功部署到目標環境以來的變更和工作項目，藉此產生變更日誌。輸出 Markdown 格式，並包含功能、修復、重大變更和資料庫遷移等章節。
將說明發佈到專案 Wiki，將其打包為建置產出物，並附加到發行中。包含部署中繼資料（建置編號、commit SHA、環境、核准者、通過的閘門）以符合法規。

實務問題情境

Adobe 需要為其託管在 Azure 上的行銷網站導入一個新的個人化引擎，同時不能在行銷活動高峰期冒轉換率下降的風險。團隊必須頻繁部署、逐步揭露功能、驗證 SLO，並在 KPI 下降時能立即回滾。

使用 Azure Deployment Environments 定義環境

在一個 Git 支援的目錄中，為應用程式、AKS、Azure SQL 和 Front Door 建立環境定義（Bicep）。開發人員可以安全地自助佈建開發/測試環境，確保與生產環境的一致性，並為實驗啟用暫時性的測試堆疊。ADE 會強制執行配額和 RBAC 來控制支出和存取。

使用多階段 YAML 實現「建置一次，部署多次」

單一產出物會依序晉升通過 ring-r0、ring-r1、ring-r2 和 prod 等階段。各階段相互依賴，並使用部署作業搭配策略：在適當之處使用 canary 和 rolling，以保證在各個環之間二進位檔的一致性。

對於舊有的 Web 層，使用 App Service 部署位置實現藍綠部署

部署到預備位置，進行暖機，然後為 ring-r0 的內部使用者進行交換。如果 Adobe 的 SLO 出現退步，反向的位置交換能提供最快的回滾，且幾乎無停機時間。

透過 Azure Front Door 加權路由導入 Canary 部署

註冊舊有和新的個人化後端。從 ring-r1 開始，將 1% 的流量導向新的後端。Front Door 的健康狀態探測和即時的權重更新，能夠根據流量模式進行安全、快速的調整。

使用客觀檢查作為晉升的閘門

新增 Azure Monitor 檢查，監控來自 Application Insights 的 p95 延遲、錯誤率和轉換率 KPI。新增一個 REST API 檢查，對 Adobe 的內部實驗服務進行確認，以驗證防護指標。設定一個工作項目查詢檢查，確保「必須修復」的錯誤在晉升到下一個環之前都已關閉。閘門會定期評估並設有逾時，以防止變更停滯不前。

在關鍵轉換點要求核准

對於 ring-r2 和 prod 的部署前核准，需要行銷和 SRE 團隊簽核，並設定 4 小時的逾時以避免懸置的發行。部署後核准則用來確認 UAT 和分析驗證已完成，然後才關閉該發行。

使用 Azure App Configuration 功能旗標控制揭露範圍

實作黑暗啟動，讓新引擎雖然已部署但初始為停用狀態。使用目標篩選條件為內部員工（ring-r0）和選定的客戶群體（ring-r1）啟用。應用百分比推出以擴大揭露範圍。如果出現異常，一個 Kill switch 可以在幾秒鐘內全域停用該引擎，無需重新部署。

透過擴展-收縮遷移保護資料

首先部署附加性的 SQL 變更，非同步地回填資料，並在需要時進行雙寫。只有在穩定性得到證實後，才移除已棄用的結構描述。閘門會監控 DTU、死結和長時間執行的查詢，以防止不安全的晉升。

自動化回滾路徑

部署作業上的失敗掛鉤會觸發回滾：Front Door 將新後端的權重調回 0%；App Service 執行反向位置交換；AKS 執行

undefined

。對於複雜情境，操作人員仍然可以使用手動的一鍵回滾。

自動化發行文件

管線會從關聯的工作項目和 commit 產生 Markdown 格式的版本說明，其中會突顯已開啟的功能、資料庫變更以及通過的閘門。這些說明會發佈到 Azure DevOps Wiki 並附加到發行中，以滿足稽核和利害關係人的可見度需求。

這種方法善用每種工具的長處：使用 ADE 建立安全、可重現的環境；使用 YAML 策略和核准來管理流程；使用 Front Door 和 App Configuration 進行分層的漸進式交付；使用 Azure Monitor 和閘門進行客觀的品質控制；並透過自動化回滾和版本說明來確保韌性與可追溯性。

← 容器化與 Kubernetes · 所有領域 · 安全性、合規性與 DevSecOps →

練習這些題目 → · 在 ExamRoll.io 上限時練習 →