💡 先搞懂問題
假設虛構公司「晴空食品」的網購網站跑在 Azure App Service 上。過去每次上線，工程師都把新版程式直接部署到正式網站：部署的那段時間網站會重新啟動，第一批進來的顧客要等程式載入；新舊檔案交替的瞬間偶爾出現奇怪的錯誤；最麻煩的是新版有問題時，只能把舊版再部署一次，又要再等一輪。新手通常卡在兩個地方：以為「先測試再上線」一定要另外開一個網站、自己切換網域；或者測試環境開了，上線時卻把測試用的資料庫連線一起帶到正式站。
App Service 的部署位置（deployment slot）就是為這件事設計的。一個 Web 應用程式除了正式的 production 位置，還可以再開 staging 等其他位置；每個位置都是獨立運作、有自己網址的應用程式，跑在同一個 App Service 方案（App Service plan）的執行個體上。新版先部署到 staging，暖機、測試，確認沒問題再執行交換（swap），讓正式網址改由已經準備好的新版回應；出問題時，再交換一次就回到舊版。
生活比喻：餐廳換新菜單，對調兩個廚房的出餐窗口
一家餐廳要換季推出新菜單。笨方法是營業中直接把廚房的食材和器具全部換掉，換到一半時客人點的菜可能做不出來；新菜不受歡迎，又得把舊食材全部搬回來。這家餐廳的做法不同：它有兩個廚房，前場只有一個出餐窗口。新菜單先在備用廚房試做、讓店員試吃，爐火也先開好；確認沒問題，店長把出餐窗口對到備用廚房，從下一張單開始，客人拿到的就是新菜。新菜出了狀況，再把窗口對調回來，舊廚房的鍋還熱著，馬上就能接手。
還有一個細節：有些東西「屬於廚房」，例如這間廚房接的是哪一條瓦斯管、送貨單寫哪一個倉庫；有些東西則「跟著菜單走」，例如食譜與調味比例。窗口對調時，食譜跟著新菜單一起面對客人，瓦斯管和倉庫則留在原本的廚房。
這個比喻有三個地方和實際不同。第一，真實餐廳的兩個廚房是兩套設備，部署位置卻共用同一個 App Service 方案的執行個體；staging 跑壓力測試時，production 也會被拖慢，正式的效能測試最好另外開方案。第二，瓦斯管天生就屬於某個廚房，但 App Service 的應用程式設定與連接字串預設是跟著程式碼交換的，要你自己勾「部署位置設定」才會固定在位置上；忘了勾，正式站可能在交換後連到測試資料庫。第三，對調窗口是一瞬間的事，交換卻是一連串步驟，包含重新啟動與暖機，花多久取決於應用程式的啟動速度；它減少的是使用者感受到的中斷，不保證任何變更都能無痛回復，例如新版已經改了資料庫結構而舊版讀不懂，交換回去也救不了。
🎮 互動實驗室一：部署位置交換模擬器
晴空食品的 production 位置跑 v1.4，staging 位置剛部署好 v1.5。下面每一列是一項設定，左右兩格分別是兩個位置目前的值。應用程式設定與連接字串可以勾選「部署位置設定」，讓它固定在位置上；有鎖頭的項目由平台決定，不能勾。工程師已經替部分設定打勾，請先檢查有沒有漏掉，再在每一列勾選「我猜 production 這格會變」，然後按「交換」。交換完會逐列告訴你猜得對不對、為什麼，再按「回復交換」看看舊版怎麼回來。
production 位置 勾選「我猜會變」
staging 位置 勾選「部署位置設定」
- 把 production 的「部署位置設定」套用到 staging 的執行個體
- staging 的執行個體重新啟動，全部完成才繼續；任何一台失敗就中止交換
- 暖機：對每個執行個體送出 HTTP 要求，等它回應
- 切換路由：正式網址改連到剛暖好的執行個體
- 原本 production 的執行個體套用 staging 的設定並重新啟動
🎮 互動實驗室二：方案層級分診台
每張卡是一個虛構公司的需求，請替它選一個 App Service 方案層級，或判斷它其實該改用 Static Web Apps、Azure Functions、Container Apps。原則是「選能滿足需求的最低層級」：多付錢買用不到的功能也算選錯。答完會說明理由，選錯時會告訴你你選的那一項缺了什麼或多了什麼；右邊的對照卡會亮起這題用得到的事實。
數字查證：2026 年 10 月，依 Microsoft Learn「Azure 訂用帳戶與服務限制」的 App Service 限制表、App Service 可靠性文件與自動調整文件。價格不在比較範圍內，實際費用請用 Azure 定價計算機估算。
🛠️ 操作教學：建立 Web 應用程式、新增 staging 位置並交換
不用登入 Azure，也能先把流程走一遍。左邊是簡化的入口網站，照步驟填表、按按鈕；右邊同步顯示等效的 Azure CLI 與 Bicep，黃色底的那幾行就是目前這一步對應的指令。你可以故意填錯看看驗證訊息，也可以改名稱、區域或定價方案，看指令怎麼跟著變。
slotConfigNames，交換仍要另外執行。
自己動手時要注意
權限方面，在資源群組上至少要有「參與者」（Contributor）角色，或是包含 Web 應用程式與 App Service 方案寫入權限的角色；只執行交換的部署身分，可以只給該 Web 應用程式範圍的權限。費用方面，Free 以外的方案只要存在就按執行個體持續計費，練習用的 Standard 或 Premium 方案即使沒有流量也會產生費用；部署位置本身不另外收費，但它們跑在同一個方案的執行個體上。練習完請把整個資源群組刪掉，裡面的方案、Web 應用程式與位置會一起刪除：
# 練習完刪除整個資源群組（--no-wait 讓指令不必等刪除完成）
az group delete --name rg-shop-demo --yes --no-wait範例裡的名稱都是示意。不要把真實的密碼、金鑰、連接字串或訂用帳戶 ID 寫進指令、範本或截圖；需要時用 <your-subscription-id> 這類佔位字，正式環境的祕密放在 Key Vault，再用 Key Vault 參考或受控識別讓 App Service 讀取。
📘 原理補完
方案、Web 應用程式、部署位置是三層不同的東西
Azure App Service 是 PaaS 的網站與 API 代管平台：你部署程式碼或容器，作業系統修補、負載平衡、執行階段更新由平台處理。所有 Web 應用程式都跑在一個 App Service 方案上，方案決定區域、作業系統、定價層，以及執行個體的大小與數量；計費也以方案的執行個體為單位，同一個方案裡放幾個 App 都不會多收，但它們共用 CPU 與記憶體。部署位置則掛在單一 Web 應用程式底下，每個位置有自己的網址（預設格式是 應用程式名稱-位置名稱.azurewebsites.net），和 production 一樣跑在同一個方案的執行個體上。官方文件明確說明使用部署位置不會額外收費，代價是共用資源。
交換到底做了哪些事
交換的目的，是讓正式網址換手的那一刻，接手的執行個體已經套用正式環境的設定、而且已經啟動完成。官方文件描述的順序如下，其中只要有任何一個執行個體重新啟動失敗，交換就會中止並還原，production 不受影響：
- 把目標位置（通常是 production）的部署位置設定，例如勾了「部署位置設定」的應用程式設定與連接字串，套用到來源位置的所有執行個體；這會觸發來源位置重新啟動。使用預覽交換就停在這一步之後，讓你用來源位置的網址確認新版在正式設定下是否正常。
- 等來源位置的每個執行個體都重新啟動完成。
- 暖機：對每個執行個體送出 HTTP 要求，收到回應才算暖好。預設路徑是根目錄
/，可以用應用程式設定WEBSITE_SWAP_WARMUP_PING_PATH改成健康檢查路徑，也可以用WEBSITE_SWAP_WARMUP_PING_STATUSES限定哪些狀態碼才算成功；有啟用本機快取或自訂暖機時，這一步會多做對應的初始化。 - 切換路由：目標位置的網址改連到剛暖好的執行個體。
- 原本在目標位置的執行個體（舊版）現在屬於來源位置，套用來源位置的設定並重新啟動。
哪些設定會跟著程式碼走
判斷原則是：和「這一版程式怎麼執行」有關的設定跟著程式碼交換；和「這個位置的身分、網址、規模、網路」有關的設定留在原位置。應用程式設定、連接字串與掛接的儲存體預設會交換，但你可以把個別設定標成部署位置設定，讓它固定在位置上。部署位置設定其實記錄在 Web 應用程式的 slotConfigNames 清單裡，對所有位置一體適用：名稱列在清單中的設定，每個位置各自保留自己的值。以下依官方文件整理（查證時間 2026 年 10 月）：
| 類別 | 項目 | 說明 |
|---|---|---|
| 會交換 | 語言框架設定（.NET、Java、PHP、Python、Node.js 版本）、32／64 位元平台、WebSocket、處理常式對應、路徑對應、公開憑證、WebJobs 內容、混合式連線、服務端點、Azure CDN | 這些描述程式怎麼跑，跟著新版一起上線才合理。 |
| 預設會交換，可改成留下 | 應用程式設定、連接字串、掛接的儲存體帳戶 | 勾選「部署位置設定」後固定在位置上。正式資料庫連線、付款模式、環境名稱這類「屬於環境」的值要勾；新功能旗標這類「屬於版本」的值通常不勾。 |
| 不會交換 | 自訂網域名稱、非公開憑證與 TLS／SSL 設定、擴縮設定、發佈端點、WebJobs 排程器、受控識別、虛擬網路整合、名稱以 _EXTENSION_VERSION 結尾的設定、Service Connector 建立的設定 | 這些屬於位置本身。例如受控識別不交換，所以 production 與 staging 可以各自有不同的 Key Vault 存取權。 |
| 不會交換，可改成會交換 | 協定設定（僅限 HTTPS、TLS 版本、用戶端憑證）、IP 限制、Always On、診斷記錄設定、CORS | 在每個位置加上應用程式設定 WEBSITE_OVERRIDE_PRESERVE_DEFAULT_STICKY_SLOT_SETTINGS，值設為 0 或 false，這幾項就會改成跟著交換。 |
WEBSITE_OVERRIDE_PRESERVE_DEFAULT_STICKY_SLOT_SETTINGS 改成跟著交換。使用預覽交換、自動交換與流量百分比
使用預覽交換（swap with preview）把交換拆成兩個階段：第一階段把 production 的位置設定套到 staging 並重新啟動後就暫停，這時 staging 網址上跑的是「新版程式＋正式設定」，正好可以檢查新版會不會因為正式環境的連接字串或金鑰而出錯；確認後按「完成交換」才切換路由，按「取消交換」則讓 staging 回到原本的設定。CLI 對應的是 az webapp deployment slot swap 的 --action preview、swap、reset。
自動交換（auto swap）讓程式部署到來源位置後自動暖機並交換到目標位置，適合持續部署；官方文件註明 Linux 上的 Web 應用程式與 Web App for Containers 不支援自動交換，這時改用部署管線在部署完成後執行交換指令。流量百分比（Traffic %）可以把一部分正式流量導到其他位置做線上測試，被分到的使用者會由 x-ms-routing-name cookie 固定在同一個位置，官方說明的固定時間是一小時或直到 cookie 被刪除。
方案層級怎麼選
選層級時先列出硬需求，再找能滿足的最低層級。下表依 Microsoft Learn「Azure 訂用帳戶與服務限制」、App Service 自動調整與可靠性文件整理（查證時間 2026 年 10 月）。部署位置數是「每個 App」的上限；規則式自動調整（autoscale）是 Azure Monitor 依 CPU、記憶體等計量或排程增減執行個體，自動擴縮（automatic scaling）則是平台依 HTTP 流量自己決定，可設定常備與預先暖機的執行個體。
| 層級 | SLA | 執行個體上限 | 部署位置 | 規則式自動調整 | 依流量自動擴縮 | 可用性區域備援 |
|---|---|---|---|---|---|---|
| Free／Shared | 無 | 1（共用） | 無 | 無 | 無 | 無 |
| Basic | 99.95% | 3（手動） | 無 | 無 | 無 | 無 |
| Standard | 99.95% | 10 | 5 | 有 | 無 | 無 |
| Premium v2／v3／v4 | 99.95% | 30（Premium v1 為 20） | 20 | 有 | 有 | 有，至少 2 個執行個體 |
| Isolated v2 | 99.95% | 100（可申請更多） | 20 | 有 | 無 | 在 App Service Environment 規劃 |
「垂直擴充」（scale up）是換到更高層級或更大的執行個體，「水平擴充」（scale out）是增加執行個體數。Basic 也能 scale out，只是要手動調整，上限 3 個。
什麼時候不該選 App Service
App Service 適合常駐執行的網站與 API，方案存在就持續計費。如果需求的形狀不同，別的服務會更合適：只有預先建置好的靜態前端加少量 API，Static Web Apps 從 Git 推送自動建置部署，每個 Pull Request 還有預覽環境，它的「預備環境」和部署位置是不同的機制；由事件觸發、執行時間短、閒置時不想付費的工作，選 Azure Functions（新的 serverless 應用程式建議用 Flex Consumption 方案）；已經容器化的微服務，需要依佇列長度等事件擴縮、閒置時縮到零，選 Container Apps，它用修訂版本（revision）的流量分割做藍綠部署，概念上類似部署位置，但機制不同。
判斷步驟
- 先確認工作負載的形狀：常駐網站或 API 用 App Service；純靜態前端、事件觸發的短工作、需要縮到零的容器微服務，先看 Static Web Apps、Functions、Container Apps。
- 要零停機上線或快速回復，就需要部署位置，至少 Standard；需要超過 5 個位置，至少 Premium。
- 要依計量或排程自動加減執行個體，至少 Standard；要平台依 HTTP 流量自動擴縮、保留預先暖機的執行個體，選 Premium v2 以上。
- 要扛單一可用性區域故障，選 Premium v2 以上並啟用區域備援，執行個體至少 2 個，而且區域本身要支援可用性區域。
- 要完全隔離的專用環境或超過 30 個執行個體，選 Isolated v2（App Service Environment）。
- 設定部署位置時，把屬於環境的應用程式設定與連接字串勾成部署位置設定；交換前用 staging 網址或使用預覽交換驗證，並在 Application Insights 觀察錯誤率。
容易考錯的地方
以為 Basic 有部署位置：Basic 有 SLA、也能手動擴充到 3 個執行個體，但沒有部署位置與自動調整。情境同時出現「最低成本」與「零停機上線」，答案通常是 Standard。
以為所有設定都會交換：連接字串預設會交換，所以「交換後正式站連到測試資料庫」的題目，解法是把連接字串標成部署位置設定，不是交換前手動改值。反過來，自訂網域、受控識別、擴縮設定本來就不交換，不需要也不能勾。
把部署位置當成獨立的伺服器：位置共用方案的執行個體，staging 的壓力測試會影響 production；需要獨立資源的效能測試要另開方案。位置也不能各自放在不同的區域或可用性區域。
回復就是重新部署：交換後舊版還在另一個位置執行，最快的回復是再交換一次。前提是資料庫結構等外部變更和舊版相容。
自動交換到處可用：Linux 上的 Web 應用程式與 Web App for Containers 不支援自動交換，要用部署管線在部署後執行交換。
autoscale 和 automatic scaling 混為一談：前者是 Standard 以上依規則或排程，後者是 Premium v2 以上依 HTTP 流量，兩者是不同的擴縮選項。考試會用「不想自己維護規則」「依流量」這類字眼區分。
相關考試：AZ-900 會考 App Service 在運算服務中的定位；AZ-104 大綱點名 App Service 方案與擴縮、部署位置；AZ-400 的建置與發行管線領域點名部署位置。
✅ 自我檢測
6 題原創題，選完立即顯示對錯與解析，全部作答後會出現總分。目前得分：0 / 6