💡 先搞懂問題
假設你在虛構公司「青松物流」負責把訂單網站搬上 Azure。業務主管只問一句話：「一個月最多會停多久？」你查了文件，網站用的 App Service 寫著 99.95%，資料庫 Azure SQL Database 寫著 99.99%，存放出貨單 PDF 的儲存體寫著 99.9%。很多人第一次看到這些數字，會挑最好看的 99.99% 回報，或者覺得「都在 99.9% 以上，應該差不多」。實際上，這三個服務只要有一個停擺，訂單網站就不能用，整體可用性一定比三個裡最差的那個還低。
這裡牽涉到兩個名詞。服務等級協定（SLA，service-level agreement）是 Microsoft 對每個服務以「每月可用時間百分比」做出的正式承諾，並寫明沒做到時的補償方式：退回一部分月費形式的服務抵用額度（service credits），而且要客戶自己申請。把多個元件組成一個系統後重新計算出來的整體數字，則常被稱為複合 SLA（composite SLA）。它不是 Microsoft 額外承諾的東西，而是你用各元件 SLA 自己推算出來、拿來檢查架構是否符合業務需求的估計值。另一方面，錢也是同一個架構決策的另一面：要更高的可用性，通常就要多付一份備援的費用，所以這一頁把 SLA 和成本放在一起看。
生活比喻：轉乘交通去開會
想像你明天早上九點要到客戶公司開會，路線是捷運轉公車，下車再走一段路。假設捷運準點的機率是 98%，公車是 95%，步行那段 99%（全部是示意數字）。三段都準時你才不會遲到，所以準時抵達的機率是三個數字相乘：0.98 × 0.95 × 0.99 ≈ 92.2%，比任何一段都低。轉乘越多段，遲到的機會就越大。
如果你很在意這場會，會怎麼做？常見做法是替最不可靠的那段準備第二條路：公車沒來，就改騎公共自行車（假設準時機率 90%）。公車和自行車只要有一個順利就好，兩者同時出狀況的機率是 5% × 10% = 0.5%，所以這一段變成 99.5%，整趟提高到約 96.5%。再進一步，有些客運公司會承諾「誤點超過 30 分鐘退一半車資」；這筆退款讓你心裡舒服一點，卻救不回錯過的會議。
這個比喻有三個地方和實際不同，讀後面的實驗室前先記住。第一，SLA 不是「保證不會壞」，而是「壞了之後依條款補償」的承諾；它只告訴你 Microsoft 願意為哪個水準負責，不代表服務不會停。第二，每個服務的 SLA 條件都不同：同樣叫虛擬機器，單一執行個體、可用性設定組、跨可用性區域的承諾數字不一樣；儲存體的讀取與寫入、不同存取層也不一樣；免費層與預覽功能通常沒有 SLA。比喻裡一段公車就是一個準點率，雲端服務則要先確認「你用的是哪一種部署方式與層級」。第三，交通延誤彼此多半無關，但雲端元件可能一起受影響，例如兩個區域共用同一個設定錯誤的部署管線，或兩邊都依賴同一個全域服務。複合 SLA 的公式假設各元件獨立故障，算出來的數字是理想上限，不是保證。
🎮 互動實驗室一：複合 SLA 計算器
左邊勾選系統用到的元件並選擇部署方式，這些元件是串聯關係（任何一個停擺，整個系統就停擺）；再決定要把整套系統部署在幾個區域（並聯備援），以及要不要加上負責把使用者導到健康區域的流量切換元件。右邊會即時列出每一步計算、整體可用性，以及換算成 30 天月份的可能停機分鐘數，並和業務要求比較。可以先按上方的情境按鈕載入預設組合。
一、單一區域內的元件（串聯）
二、整套系統部署幾個區域（並聯）
三、計算過程
🎮 互動實驗室二：計費方式分診台
每張卡是一家虛構公司的情境。請從八種做法中選出最適合的一種：隨用隨付、保留（Azure Reservations）、節省方案（savings plan for compute）、Spot、Azure Hybrid Benefit、Dev/Test 定價、自動關機，或是先依 Advisor 建議縮小規格。答完會說明為什麼，選錯時也會說明你選的那一種適合什麼情況。這裡不談實際金額，只看承諾長短、能不能被中斷、授權與環境用途。
🛠️ 操作教學：在成本管理建立預算與警示
青松物流的正式環境訂用帳戶上線後，財務希望「花到八成就通知、預測會超支也要通知」。下面用簡化重繪的入口網站走一次建立預算的流程，右邊（手機版在下方）同步顯示等效的 Azure CLI 與 Bicep。你在左邊改名稱、期間、金額、警示門檻與收件者，右邊的指令會跟著變，目前步驟對應的幾行會以黃底標示。不需要登入 Azure，也不會建立任何資源；金額都是示意數字。
示意畫面：簡化重繪，只保留和本主題有關的欄位；實際畫面以 Azure 入口網站為準。
同一件事的三種做法
入口網站、Azure CLI 與 Bicep 最後都把請求送到 Azure Resource Manager（ARM），由它驗證身分與權限後交給成本管理服務，所以建立出來的預算是同一種資源（Microsoft.Consumption/budgets）。入口網站適合第一次設定、想邊看邊理解欄位的時候；CLI 適合寫成腳本快速查詢或批次處理；Bicep 適合要在多個訂用帳戶套用同一套預算、需要版本控制與審查的團隊。這個主題有一個 CLI 的實際限制要知道：az consumption budget create 目前屬於預覽指令群組，參數只有名稱、類別、金額、期間與篩選，沒有設定警示門檻與收件者的參數。只用這個指令建立的預算不會寄出任何警示，所以要連同警示一起建立時，建議用 Bicep 搭配 az deployment sub create（資源群組範圍用 az deployment group create）部署。
自己動手時要注意
- 權限：建立訂用帳戶層級的預算需要擁有者、參與者或成本管理參與者（Cost Management Contributor）角色；成本管理讀者（Cost Management Reader）只能檢視。財務人員通常只給讀者角色，避免能改動資源。
- 費用：Cost Management 與預算本身不另外收費；但如果你為了練習而建立 VM 或其他資源，那些資源會照常計費。
- 練習完清理：刪除練習用的預算可以用
az consumption budget delete --budget-name <名稱>；如果同時建了練習用的資源群組，整組刪除：az group delete --name <名稱> --yes --no-wait。 - 不要放真實資料：指令與範本裡不要寫真實的訂用帳戶 ID、金鑰、密碼或連接字串；用
<your-subscription-id>這類佔位字，電子郵件用 example.com。 - 預算不是煞車：到了 100% 不會自動停機。真的需要自動處理，請在預算上接動作群組，並先在測試環境驗證自動化會關掉的是哪些資源。
📘 原理補完
SLA 是什麼、不是什麼
Microsoft 的 SLA 以「每月可用時間百分比（monthly uptime percentage）」表示，各服務的定義不同：虛擬機器看的是能不能連到至少一個執行個體，儲存體分開計算讀取與寫入請求的成功率。沒有達到承諾時，Microsoft 依落差大小退回一定比例的當月服務費，形式是服務抵用額度，而且要客戶在期限內提出申請，不會自動入帳。SLA 文件每月都可能更新，最新版本放在 Microsoft 授權網站的「Service Level Agreements (SLA) for Online Services」頁面；本頁查證時（2026 年 10 月）最新的是 2026 年 10 月版。
幾個常見的「沒有 SLA」情況要記得：免費層與預覽功能通常不在 SLA 範圍內，例如 App Service 的免費（Free）與共用（Shared）層；Spot VM 因為隨時可能被收回，也沒有 SLA；Dev/Test 定價的訂用帳戶限用於開發測試，官方條款寫明沒有可用時間保證（Azure DevOps 與 Azure Monitor 例外）。另一個容易混淆的名詞是 SLO（service-level objective，服務等級目標）：那是你自己替應用程式訂的內部目標，例如「訂單網站每月 99.9%」，要靠複合 SLA 與備援設計去支撐，不是 Microsoft 對你的承諾。
| 元件與條件 | 月可用率 | 查證來源（2026 年 10 月查證） |
|---|---|---|
| App Service（付費層） | 99.95% | Microsoft Learn 訓練單元「Understand service-level agreements」；免費與共用層沒有 SLA |
| Azure SQL Database | 99.99% | 同上訓練單元的複合 SLA 範例；部分層級搭配區域備援有更高承諾，以 SLA 文件為準 |
| 儲存體 LRS（經常性存取層） | 讀寫至少 99.9% | Learn「Azure Storage redundancy」（2026-08-11 更新）；非經常性、冷、封存層為 99% |
| 儲存體 RA-GRS（讀取） | 至少 99.99% | 同上；寫入仍是 99.9%，因為寫入只送到主要區域 |
| VM 可用性設定組（2 台以上） | 99.95% | Learn「Availability options for Azure Virtual Machines」（2025-12-05 更新） |
| VM／擴展集跨 2 個以上可用性區域（2 台以上） | 99.99% | Learn「Use availability zones with Virtual Machine Scale Sets」（2026-09-09 更新） |
| Azure Front Door | 99.99%（本頁當示意數字） | Microsoft 2019 年正式推出時的公告；現行條件請查 SLA 文件 |
串聯相乘、並聯互補
複合 SLA 的計算只需要兩條規則。串聯：系統要 A、B、C 同時都正常才能運作，整體可用性是 a × b × c。因為每個數字都小於 1，乘起來一定比最小的那個還小，所以串聯的元件越多，整體越差。並聯：只要 R 份當中有一份正常就能運作，整體不可用的機率是各份同時失敗，所以可用性是 1 − (1 − a)R（各份可用性不同時寫成 1 − ∏(1 − ai)）。Microsoft Learn 的例子是 App Service 99.95% 串聯 SQL Database 99.99%，得到 99.95% × 99.99% ≈ 99.94%；單區域 99.95% 的應用程式部署到兩個區域，則是 1 − (1 − 0.9995)² ≈ 99.999975%。
多區域不是免費的：切換元件也要算進去
兩個區域並聯的前提是「使用者能被導到健康的那一邊」。負責這件事的全域元件，例如 Azure Front Door 或 Traffic Manager，本身也有 SLA，而且它是串在兩個區域前面的。實驗室一的雙區域情境裡，兩區域並聯後約 99.9997%，再乘上 Front Door 的示意數字 99.99%，整體變成約 99.9897%，每月約 4.4 分鐘；也就是說，到了這個階段，瓶頸已經從區域轉移到切換元件。多區域還有另外三個代價：資料要跨區域複寫（非同步複寫可能遺失最後幾秒的資料），要定期演練容錯移轉，以及第二個區域的運算、儲存與跨區域傳輸都會計費。
判斷步驟：從業務需求倒推架構
- 先問業務：每月最多能停多久？換算成可用率（例如每月 22 分鐘大約是 99.95%）。
- 列出請求路徑上「任何一個停擺就整個停擺」的元件，查各自在你選的層級與部署方式下的 SLA。
- 串聯相乘，得到單區域的估計值；找出拖累最多的元件，先考慮換層級或換部署方式（例如 VM 從可用性設定組改成跨可用性區域）。
- 單區域還不夠，才考慮多區域並聯，並把流量切換元件、資料複寫與演練成本一起算進去。
- 最後回頭檢查成本：多出來的每一個 9 要付多少備援費用，業務是否願意付。
成本：先估價，再追蹤，最後用承諾換折扣
成本管理是一個循環。上線前用定價計算機（Pricing calculator）組合服務、選區域與規格估出月費；舊的總體擁有成本（TCO）計算機已退役，要比較地端與 Azure 可以改用 Azure Migrate 的商業案例。上線後用 Microsoft Cost Management 的成本分析依訂用帳戶、資源群組、標籤檢視花費，用預算與警示在花費超出預期時通知相關人員，用異常警示抓出每日用量的非預期變化。Azure Advisor 的成本建議會指出長期閒置或使用率低的 VM，以及適合購買保留或節省方案的用量。等工作負載穩定下來，再用 1 年或 3 年的承諾換取較低的單價。
計費方式怎麼選
| 做法 | 承諾或條件 | 省在哪裡 | 適合 | 不適合 |
|---|---|---|---|---|
| 隨用隨付 Pay-as-you-go | 無承諾，依用量計費 | 不用的時候不付 | 新專案、用量無法預測、短期活動 | 全年 24 小時穩定執行的正式環境 |
| 保留 Azure Reservations | 1 年或 3 年，綁定資源類型、規格（家族）與區域 | 運算單價，最高可達隨用隨付約 72% 的折扣 | 規格與區域都穩定的 VM、資料庫等 | 規格常變、即將搬遷或下線的工作負載 |
| 節省方案 Savings plan for compute | 1 年或 3 年，承諾每小時花費金額 | 自動套用到符合資格的運算服務，跨區域與規格 | 運算用量穩定但規格、區域、服務會變 | 想隨時取消（購買後不能取消或退款） |
| Spot VM | 使用閒置容量，隨時可能被收回，沒有 SLA | 價格大幅低於一般 VM（官方說最多約九成） | 批次、轉檔、CI 建置等可中斷的工作 | 正式網站、資料庫等不能中斷的服務 |
| Azure Hybrid Benefit | 已有附軟體保證的 Windows Server 或 SQL Server 授權 | 授權費（只付基礎運算費） | 搬上雲的 Windows Server、SQL Server 工作負載 | 沒有符合資格的授權 |
| Dev/Test 定價 | 需有效的 Visual Studio 訂閱，只能用於開發測試 | Windows VM 以 Linux 費率計費等開發測試優惠 | 開發、測試、展示環境 | 正式環境（沒有可用時間保證） |
| 自動關機 Auto-shutdown | VM 的「作業」設定，指定每天關機時間 | 非上班時間不付運算費 | 白天才用的開發機、教學環境 | 需要 24 小時服務的系統 |
這些做法大多可以疊加：Windows Server 正式機可以同時用 Azure Hybrid Benefit 省授權費、用保留省運算費；開發訂用帳戶可以用 Dev/Test 定價再加上自動關機。不能混為一談的是「承諾」與「可中斷」：保留和節省方案是你向 Microsoft 承諾用量換折扣，資源不會被收回；Spot 是 Microsoft 把閒置容量便宜賣你，需要時會收回。
容易答錯的地方
複合 SLA 取最高或最低：串聯的整體不是三個裡最好的，也不是最差的，而是比最差的還低。題目給兩個以上元件時，先判斷是串聯還是並聯再計算。
SLA 等於保證：SLA 是補償承諾，補的是一部分服務費，而且要申請。「Microsoft 保證服務不會中斷」「停機時 Microsoft 賠償營業損失」都是錯的。
預算會自動停機：預算只發通知。要自動處理，答案會是「在預算上設定動作群組，觸發 Automation Runbook、Logic Apps 或 Functions」，不是「把預算設成上限」。
保留與節省方案搞混：題目寫「規格與區域固定」選保留；寫「會換規格、換區域或換服務，但每小時花費穩定」選節省方案；寫「可以被中斷」才是 Spot。節省方案購買後不能取消或退款，保留可以在規則內交換或退款。
估價工具與追蹤工具：部署前估價是定價計算機，部署後看實際花費是 Cost Management，給省錢建議的是 Azure Advisor。題目若問「比較地端與 Azure 的長期成本」，TCO 計算機已退役，改看 Azure Migrate 的商業案例。
多區域忘了切換元件：只算兩區域並聯會得到很漂亮的數字，但流量切換元件與資料複寫也在路徑上；架構題會用這一點設計干擾選項。
✅ 自我檢測
以下 6 題都是原創題，選完會立即顯示對錯與解析，全部作答後會出現總分。目前得分：0 / 6