💡 先搞懂問題
虛構公司「晴空食品」的線上訂購 API 跑在一台 Azure 虛擬機器（VM）上。第一個月很順利，第二個月出了兩次狀況：一次是 Azure 平台做主機維護，VM 重新開機了幾分鐘；另一次是中午訂餐尖峰，CPU 長時間滿載，客人一直看到逾時。工程師的直覺是「再開一台」，於是手動建了第二台，卻沒注意到它和第一台可能在同一個機櫃上，如果那個機櫃斷電，兩台會一起倒；而尖峰過後，兩台都閒著繼續計費。
這裡有兩個不同的問題。第一個是故障隔離：多台機器要分散到「不會一起壞」的地方，Azure 提供的工具是可用性設定組（availability set）與可用性區域（availability zones）。第二個是容量跟著負載走：機器數量要能依 CPU 等計量自動增減，Azure 的工具是虛擬機器擴展集（Virtual Machine Scale Sets，VMSS）搭配 Azure Monitor 的自動調整（autoscale）。新手最常卡在兩件事：把「多開幾台」當成高可用（其實要看它們分散在哪裡），以及以為擴展集會自動處理一切（其實門檻、上下限與冷卻時間都要自己訂，訂錯會來回加減機器）。
生活比喻：連鎖便當店
想像晴空食品同時經營實體便當店。最早只有一家店、一個櫃位：店員請假或冰箱壞了，整家店就停賣。後來在同一棟商業大樓開了三個櫃位，分別接在不同的電箱上，大樓輪流做消防檢查時也一次只封一個樓層，所以單一電箱跳電或某層停業時，其他櫃位照常營業。但如果整棟大樓停電，三個櫃位還是一起關門，於是公司在不同行政區開了分店，各自有獨立的電力和聯外道路。最後，午餐尖峰排隊的人太多，店長訂了一條規則：「排隊超過 15 人就加開一個櫃位，少於 3 人就收掉一個，而且每次調整後至少觀察 10 分鐘再決定下一步」。
這個比喻有幾個地方和實際不同。第一，加開櫃位只要叫一個店員過來，新的 VM 卻要配置、開機、跑完初始化才能接流量，通常要幾分鐘，所以放大門檻不能等到 100% 才觸發。第二，行政區分店仍在同一個城市，可用性區域也都在同一個區域內；區域級的大型災難（例如整個區域的服務中斷）要靠第二個區域，例如搭配 Azure Site Recovery 或在另一個區域再部署一套，這已經超出本頁的範圍。第三，櫃位多開幾個只是多付薪水，VM 多開幾台就是多付運算、磁碟與網路費用；擴展集本身不收費，但裡面每一台 VM 都照常計費，所以縮小規則和最大執行個體數同樣重要。
🎮 互動實驗室一：故障模擬器
先選一種部署方式，畫面會把執行個體放到區域、可用性區域與機架裡。接著按一種故障，系統會先請你預測服務是「存活」還是「中斷」，再顯示哪些執行個體掛掉、服務還剩幾台，以及這種部署方式對應的官方 SLA。4 種部署 × 4 種故障共 16 種組合，下方小方塊會記錄你預測過哪些。示意的前提：單一 VM 與可用性設定組都位在可用性區域 1 的資料中心裡。
🎮 互動實驗室二：自動調整模擬器
晴空食品的訂購 API 在早上 8 點到 11 點會經歷一波訂餐尖峰。下面的需求曲線是示意數字，單位是「相當於幾台 VM 滿載」，例如 4.5 代表要 4.5 台的 CPU 全速運轉才吃得下。左邊調整自動調整規則，右邊按「下一步」每次前進 5 分鐘，或按「播放」自動跑完。模擬的規則：每 5 分鐘看一次平均 CPU，超過放大門檻就加 1 台、低於縮小門檻就減 1 台，任何一次調整後要等冷卻時間過了才會再動作，新加的 VM 從下一個 5 分鐘開始分擔負載。
自動調整規則
播放
🛠️ 操作教學：建立跨可用性區域的擴展集與自動調整
晴空食品決定把訂購 API 改成擴展集：分散在三個可用性區域，前面放負載平衡器，再依 CPU 自動增減。下面用簡化重繪的入口網站走一次建立流程，右邊（手機版在下方）同步顯示等效的 Azure CLI 與 Bicep。你改名稱、區域、可用性區域、大小、執行個體數與自動調整規則，指令會跟著變，目前步驟對應的幾行以黃底標示。不需要登入 Azure，也不會建立任何資源。
示意畫面：簡化重繪，只保留和本主題有關的欄位；實際畫面以 Azure 入口網站為準。
同一件事的三種做法
入口網站、Azure CLI 與 Bicep 最後都把請求送到 Azure Resource Manager（ARM），由它驗證身分與權限後交給運算、網路與監視服務。差別在於「替你做了多少決定」：az vmss create 很省事，沒指定的部分會自動補上：沒給虛擬網路時會自動選用或新建一個，負載平衡器預設新建一個 Standard SKU 的（連同它的公用 IP），預設大小是 Standard_D2s_v5、預設協調流程模式是 Flexible；Bicep 則要把虛擬網路、網路安全性群組、負載平衡器、擴展集與自動調整設定一個一個寫清楚，篇幅較長，但每一個設定都看得見、可以放進版本控制與審查，也能在多個環境重複部署。第一次學習或臨時驗證用入口網站，寫腳本或排除問題用 CLI，要長期維護的正式環境用 Bicep。
自己動手時要注意
- 權限：需要在資源群組上有參與者（Contributor）以上的角色；如果還要指派受控識別或角色，則需要擁有者或使用者存取管理員。只要管 VM 的人可以考慮虛擬機器參與者（Virtual Machine Contributor）。
- 費用：每台 VM 依大小與執行時間計費，加上受控磁碟、公用 IP、負載平衡器與輸出流量。自動調整的最大執行個體數就是費用上限，練習時請設小一點。
- 連外：範本裡的子網路設為 private subnet（
defaultOutboundAccess: false），VM 要連網際網路下載更新時，需要另外加上 NAT Gateway 或負載平衡器的輸出規則。 - 練習完清理：擴展集、負載平衡器、虛擬網路都在同一個資源群組裡，整組刪除最乾淨：
az group delete --name <名稱> --yes --no-wait。 - 不要放真實資料：指令與範本裡不要寫密碼、私密金鑰、連接字串或訂用帳戶 ID；SSH 只上傳公開金鑰，部署時以參數傳入。
📘 原理補完
可用性設定組：同一個資料中心內的兩種分散
可用性設定組（availability set）是一個邏輯分組，放進去的 VM 會由平台分散到不同的容錯網域與更新網域。容錯網域對應實體故障：同一個容錯網域的主機共用電源與網路交換器，一個區域內的可用性設定組最多 3 個容錯網域。更新網域對應計畫性維護：平台需要重新開機的維護一次只處理一個更新網域，最多 20 個、預設 5 個。可用性設定組本身不收費，但 VM 只能在建立時放進去，事後不能直接加入；它也只在單一資料中心內分散，整個資料中心停擺時保護不了。官方建議兩台以上 VM 放在同一個可用性設定組，才能符合 99.95% 的 SLA（Learn「Availability options for Azure Virtual Machines」，2025-12-05 更新，2026 年 10 月查證）。
可用性區域：區域性、區域備援與非區域部署
支援可用性區域的區域至少有 3 個可用性區域，各有獨立的電力、冷卻與網路。資源與區域的關係有三種：區域性（zonal）是你指定放在某一個區域，例如 VM 放在區域 1，要扛區域故障就得自己在多個區域各放一份；區域備援（zone-redundant）是服務自動跨區域分散或複寫，例如跨區域的擴展集、ZRS 儲存體、區域備援的 Standard 負載平衡器；非區域（regional／nonzonal）則不保證放在哪個區域。另一個細節是區域編號是邏輯的：兩個訂用帳戶都選「區域 1」，不代表在同一個實體資料中心。VM 或擴展集有 2 台以上執行個體、分散在 2 個以上可用性區域時，SLA 是 99.99%（Learn「Use availability zones with Virtual Machine Scale Sets」，2026-09-09 更新，2026 年 10 月查證）。代價是區域之間有一點延遲（官方目標是往返約 2 毫秒內），對延遲極度敏感、需要彼此頻繁溝通的叢集，有時會選擇放在單一區域。
各種部署方式比較
| 部署方式 | 擋得住 | 擋不住 | 月可用率 SLA | 自動增減 |
|---|---|---|---|---|
| 單一 VM | （無備援） | 主機維護重新開機、機架與資料中心故障 | 99.9%（所有作業系統與資料磁碟都是 Premium SSD、Premium SSD v2 或 Ultra Disk 時）＊ | 無 |
| 可用性設定組（2 台以上） | 單一主機維護、單一機架故障 | 整個資料中心或可用性區域故障 | 99.95% | 無，台數要手動調整 |
| 跨可用性區域的 VM（2 台以上） | 上面兩種，加上單一可用性區域故障 | 整個區域故障 | 99.99% | 無，台數要手動調整 |
| 擴展集跨可用性區域（Flexible） | 同上 | 整個區域故障 | 99.99% | 有，搭配自動調整規則 |
| 多區域部署 | 整個區域故障 | 設計錯誤、資料複寫落差 | 沒有單一 SLA，要自己用複合 SLA 估算 | 依各區域設定 |
＊單一執行個體 VM 的 99.9% 與磁碟條件，引自 Microsoft 員工在 Microsoft Q&A 對 SLA 條文的轉述（2023 年），Learn 文件本身沒有列出這個數字；實際條件請以 Microsoft 的 SLA 文件為準。其餘數字為 2026 年 10 月查證的 Learn 文件。
擴展集：協調流程模式與分散方式
虛擬機器擴展集用同一份設定建立與管理一群 VM，本身不另收費。建立時要選協調流程模式（orchestration mode），之後不能變更：Flexible（彈性）是官方建議的模式，成員就是一般的 Azure VM，可以混用不同大小、混用 Spot 與一般 VM，最多 1,000 台；Uniform（統一）的執行個體完全相同，用擴展集專用的 API 管理，適合大量、無狀態、完全一樣的工作節點。跨區域部署時，執行個體預設「盡量平均」分散到所選的區域（best-effort）；設定嚴格平衡（zoneBalance）則要求各區域台數一致。Flexible 搭配可用性區域時，官方建議容錯網域數設為 1（最大分散，max spreading），讓平台盡量把執行個體分散到不同的硬體上。
自動調整：規則怎麼被評估
擴展集的自動調整由 Azure Monitor autoscale 負責：它定期讀取計量（例如 Percentage CPU），依規則決定加減執行個體，評估頻率依資源類型約每 30～60 秒一次。幾個規則要記住：設定裡的最小、最大是台數的上下限，手動調整到範圍外也會被自動調整拉回；預設是讀不到計量時使用的台數；多條規則時，放大只要任一條成立，縮小要所有縮小規則都成立；每次調整後要過了冷卻時間才會再動作，CLI 的預設是 5 分鐘。最容易出事的是門檻設得太近：放大後平均 CPU 掉到縮小門檻以下，馬上又縮小，縮小後 CPU 又衝過放大門檻，這叫震盪（flapping）。Azure 在縮小前會先估算「減掉之後的平均值」，若會觸發放大就略過或少減幾台，但這只是保險，正確做法仍是把兩個門檻拉開，並一律成對設定放大與縮小規則。
判斷步驟：選哪一種部署方式
- 先問需不需要完整控制作業系統。只是跑網站、API 或容器，App Service、Container Apps 這類 PaaS 的擴縮與修補更省事。
- 確定要用 VM 後，問要防的是哪一種故障：主機維護與機架故障用可用性設定組就夠；要扛資料中心或可用性區域故障，就跨可用性區域部署。
- 台數需要依負載自動增減，或想用同一份設定管理一群 VM，就用擴展集（新部署選 Flexible），再搭配可用性區域與負載平衡器。
- 訂自動調整規則：成對設定放大與縮小規則，兩個門檻拉開，最大執行個體數就是費用上限，冷卻時間至少涵蓋新 VM 開機到能服務的時間。
- 要扛整個區域故障，或業務要求高於 99.99%，再考慮第二個區域與流量切換，並用複合 SLA 估算整體。
容易答錯的地方
容錯網域與更新網域顛倒：容錯網域對應「硬體壞掉」（電源、網路交換器），更新網域對應「平台計畫性維護重新開機」。題目寫機架斷電選容錯網域，寫主機更新選更新網域。
可用性設定組能扛資料中心故障：不能。可用性設定組只在單一資料中心內分散，要扛資料中心或可用性區域故障，要跨可用性區域部署；要扛整個區域，要跨區域。
一台 VM 也有 99.95%：99.95% 與 99.99% 的前提都是 2 台以上執行個體且確實分散。只有一台時，SLA 依磁碟類型另有條件。
擴展集會自動高可用：擴展集只是管理一群 VM 的方式，要不要跨可用性區域、要不要自動調整都要自己設定。沒選可用性區域的擴展集，仍可能被單一區域故障整組帶走。
協調流程模式可以事後改：不行，Flexible 與 Uniform 建立後不能互換。新部署官方建議 Flexible。
只設放大規則：沒有縮小規則，尖峰過後台數不會降回來，費用一路累積；放大與縮小門檻太近又會震盪。另外，Basic SKU 的負載平衡器已於 2025-09-30 退役，CLI 的 --lb-sku 雖然仍列出 Basic，新部署請用 Standard。
✅ 自我檢測
以下 6 題都是原創題，選完會立即顯示對錯與解析，全部作答後會出現總分。目前得分：0 / 6