💡 先搞懂問題
虛構公司「晴空食品」經營一個便當線上訂購網站，一開始只在 Compute Engine 開了一台 VM，放在 asia-east1-a 可用區，網站直接用這台 VM 的外部 IP。平常沒問題，但有三件事反覆發生：每天 11:30 到 12:30 午餐尖峰，CPU 衝到 100%，訂單頁面轉圈圈；有一次網站程式記憶體外洩卡死，VM 在控制台上明明顯示「執行中」，使用者卻只看到錯誤頁，值班工程師半夜被叫起來重開；還有一次那個可用區出狀況，整個網站停了一個多小時。
這三件事對應三個不同的問題：容量（尖峰時機器不夠）、故障偵測與修復（誰發現程式卡死、誰去重開）、故障範圍（所有東西都在同一個可用區）。Compute Engine 的 VM 本身是可用區資源（zonal），一台 VM 只活在一個可用區；要解決這三件事，得把好幾個元件組起來：
執行個體範本（instance template）記下一台 VM 的完整設定：機器類型、開機映像、網路標記、啟動指令碼。代管執行個體群組（managed instance group，MIG）依照這份範本維持一群一模一樣的 VM，並提供自動調整（autoscaling），依負載增減 VM；自動修復（autohealing），用健康檢查發現程式沒回應就重建 VM。區域型 MIG（regional MIG）預設把 VM 平均分散到同一個區域的三個可用區。最前面再放一個應用程式負載平衡器（Application Load Balancer），對外只有一個 IP，把請求分給健康的 VM。新手最常卡的地方有三個：以為 MIG 只要開了就會修好卡死的程式（其實沒有設定健康檢查的自動修復，MIG 只會重建「不在執行中」的 VM）；以為負載平衡器的健康檢查會重建 VM（它只會停止轉送）；以為自動調整一按就有新機器（其實新 VM 要開機、跑啟動指令碼，還有初始化期間）。
生活比喻：同一個城市裡的連鎖便當店
晴空食品後來把網站想成一家在同一個城市開了好幾間分店的連鎖便當店。總部寫了一本開店標準手冊：店面多大、用哪台電鍋、菜單是什麼，每間新分店都照手冊開，所以每間長得一模一樣。分店刻意開在城市的不同行政區，一區停水停電，其他區照常營業。
客人不用記每間分店的地址，只要打總機訂餐專線，總機會把訂單轉給目前有空的分店；總機每隔幾秒打電話問各分店「還能接單嗎」，連續幾次沒人接，就先不轉單給那間。區經理負責兩件事：午餐尖峰排隊太長，就照手冊加開臨時櫃位，下午人少再收掉；有店員生病或整間店的出餐系統當掉，就換一組人重新開張。
這個比喻有幾個地方和實際不同。第一，換一組人重新開張的分店不會記得前一組人留下的東西：MIG 重建 VM 時是依範本重新開一台，開機磁碟上的本機資料不會保留，所以網站本身要設計成無狀態，訂單資料放 Cloud SQL 之類的外部資料庫；真的需要保留磁碟與名稱，要用有狀態 MIG（stateful MIG）。第二，總機發現某間分店不接電話，只會先不轉單，不會派人去修：負載平衡器的健康檢查只決定轉送，重建 VM 是 MIG 自動修復的工作，兩邊可以用同一個健康檢查，但要分別設定。第三，臨時櫃位不是一叫就開：新 VM 要開機、跑啟動指令碼，自動調整器也會在初始化期間（initialization period，舊稱冷卻期 cool down period）內不採計新 VM 的數字，所以突然的尖峰會有一段來不及的空窗。第四，晴空食品用的是全域外部應用程式負載平衡器，它的「總機」其實分散在 Google 全球的網路邊緣，客人就近接入，不是只有一支電話。
🎮 互動實驗室一：故障與自動修復模擬器
先選部署方式，再決定 MIG 有沒有設定「自動修復（應用程式健康檢查）」，然後觸發一種故障。畫面會依序顯示：負載平衡器的健康檢查什麼時候發現問題、停止把請求送給誰；MIG 會不會重建 VM；最後服務是正常、降級還是中斷。三種部署方式前面都放同一個負載平衡器，健康檢查每 5 秒一次、連續 2 次失敗判定不健康（官方預設值）；其餘時間都是示意。下方的結果表會記下你試過的組合。
🎮 互動實驗室二：自動調整模擬器
左邊調整自動調整政策，右邊是 30 分鐘的負載（示意，單位是「幾台 VM 跑滿的工作量」）。按「播放」或「下一分鐘」逐步看 MIG 的 VM 數怎麼變：深藍色是正在服務的 VM、淺藍色是開機中的 VM，橘線是負載，負載超過服務中 VM 數的分鐘會標紅，代表那一分鐘有人在排隊。模型刻意簡化：每分鐘依「平均 CPU ÷ 目標使用率」算建議台數，新 VM 開機要 2 分鐘，開機時 CPU 會因為安裝套件衝到 100%；初始化期間內的 VM 不採計，縮減時看最近 5 分鐘的最高建議值。數字都是示意，不代表真實的開機時間與調整速度。
🛠️ 操作教學：建立執行個體範本、區域型 MIG 與應用程式負載平衡器
跟著 8 個步驟，在左邊的示意控制台替晴空食品建立執行個體範本、健康檢查、跨三個可用區的區域型 MIG（含自動調整與自動修復），以及全域外部應用程式負載平衡器。網路沿用 qingsong-vpc 與 asia-east1 的子網路 web-tw（假設已設好 Cloud NAT，讓沒有外部 IP 的 VM 能安裝套件）。你填的名稱、區域、機器類型與自動調整數字會即時反映到右邊的 gcloud CLI 與 Terraform；目前步驟對應的那幾行以黃色底標示。填錯時畫面會說明原因，修正後才能進到下一步。
自己動手時要注意
權限：練習用的個人專案裡，專案擁有者（Owner）就夠了；在公司專案裡請找管理員依職責授權。建立執行個體範本與 MIG 通常需要 Compute Instance Admin (v1)（roles/compute.instanceAdmin.v1），範本若指定服務帳戶，還要對那個服務帳戶有 Service Account User（roles/iam.serviceAccountUser）；建立健康檢查、後端服務、網址對應、目標代理與轉送規則需要 Compute Load Balancer Admin（roles/compute.loadBalancerAdmin）；允許健康檢查探測的防火牆規則需要 Compute Security Admin（roles/compute.securityAdmin）。專案要先啟用 Compute Engine API（gcloud services enable compute.googleapis.com）。
費用：VM 依秒計費（最少 1 分鐘），停止後 vCPU 與記憶體不計費，但磁碟仍計費；MIG 開著就會維持至少「執行個體數下限」那麼多台 VM。負載平衡器依轉送規則與處理的資料量計費，跨區域或流出網際網路的流量另計。Free Tier 每月有 1 台 e2-micro（限 us-west1、us-central1、us-east1），新帳戶的 Free Trial 有 300 美元抵用金、期限 90 天（查證日期 2026-10-08），但本練習的區域型 MIG 會開好幾台 VM，加上負載平衡器，會超出免費範圍，練習完請馬上刪除。
收尾：用 Terraform 建立的，在同一個資料夾執行 terraform destroy 就會刪除它建立的所有資源。用 gcloud 建立的，要從最前面往後刪：先刪轉送規則、目標代理、網址對應、後端服務，再刪 MIG（MIG 會一起刪掉它管理的 VM），最後刪健康檢查、執行個體範本與防火牆規則；還被引用的資源刪不掉。最乾淨的做法是整個練習都開一個專用專案，結束後刪除專案。
# 方法一：Terraform 建立的，在範本所在資料夾執行（會列出要刪的資源，確認後輸入 yes）
terraform destroy
# 方法二：gcloud 建立的，依序刪除（名稱、區域換成自己的值）
gcloud compute forwarding-rules delete web-frontend --global
gcloud compute target-http-proxies delete web-proxy --global
gcloud compute url-maps delete web-lb --global
gcloud compute backend-services delete web-backend --global
gcloud compute instance-groups managed delete web-mig --region=asia-east1
gcloud compute health-checks delete web-hc --global
gcloud compute instance-templates delete web-template
gcloud compute firewall-rules delete fw-allow-health-check
# 方法三：整個練習專案一起刪除（專案裡所有資源都會停止並排入刪除）
gcloud projects delete my-project-id範例裡沒有任何服務帳戶金鑰、密碼或真實的專案 ID，my-project-id 請換成自己的專案 ID。在自己的電腦上用 gcloud，先執行 gcloud auth login 以使用者帳戶登入；Terraform 則用 gcloud auth application-default login 取得應用程式預設憑證（ADC）。在 CI／CD 管線裡執行時，改用 Workload Identity Federation 以短期憑證扮演服務帳戶，不要下載服務帳戶金鑰檔。VM 不給外部 IP，管理連線請用 IAP TCP 轉送（見 VPC 網路、子網路與防火牆規則互動教學）。
📘 原理補完
Compute Engine VM：可用區資源、機器類型與映像
Compute Engine 的 VM 屬於一個可用區，例如 asia-east1-a；可用區出問題，裡面的 VM 就受影響。依 Compute Engine SLA，部署在多個可用區的執行個體承諾可用性高於單一執行個體（一般區域、Premium 級別：多個可用區 ≥ 99.99%、單一執行個體 ≥ 99.9%，查證日期 2026-10-08），這就是要用區域型 MIG 的根本原因。建立 VM 要選機器類型（machine type），名稱由機器系列加規格組成，例如 e2-medium、n4-standard-2：一般網站先從一般用途的 E2 或 N4 開始，e2-micro、e2-small、e2-medium 是共用核心（shared-core），適合輕量服務，不適合持續高負載。開機磁碟從映像（image）建立，範本裡建議指定映像系列（image family），例如 debian-cloud 專案的 debian-12，它永遠指向這個系列最新、沒有被淘汰的映像，每次 MIG 建立新 VM 都會拿到修補過的版本；寫死某個映像版本，日後就得自己記得換。
想省錢時，MIG 也可以用 Spot VM：用閒置容量、最高約 91% 折扣（查證日期 2026-10-08），但隨時可能被收回，而且不在 SLA 範圍內。適合可中斷的批次工作或有足夠一般 VM 撐底的無狀態服務；面對使用者的關鍵網站，不要整群都用 Spot VM。舊名「搶占式 VM（preemptible VM）」最長只能跑 24 小時，官方建議改用 Spot VM。
執行個體範本與 MIG：一份模子，一群一樣的 VM
執行個體範本記下機器類型、開機映像、網路與網路標記、中繼資料（例如啟動指令碼）、服務帳戶等設定。範本建立後不能修改，要改設定就建立新範本，再讓 MIG 以滾動更新（rolling update）一批一批換掉舊 VM，也可以同時保留兩個範本版本做金絲雀測試。範本有全域與區域兩種；區域範本只能在所在區域使用。
代管執行個體群組依範本維持「目標大小（target size）」那麼多台 VM。它有兩種範圍：單一可用區 MIG 的 VM 全在一個可用區；區域型 MIG 預設把 VM 平均分散到同一區域的三個可用區，可管理的 VM 上限是 2,000 台（可申請到 4,000），是單一可用區 MIG 的兩倍。官方文件寫到，某個可用區故障時，區域型 MIG 其他可用區的 VM 會繼續服務；沒有設定自動調整時，MIG 不會在其他可用區補新的 VM，也不會重新分配；故障的可用區恢復後，MIG 會從那個可用區重新開始服務。所以規劃大小時要想好「少一個可用區時，剩下的 VM 撐不撐得住」。另一種是非代管執行個體群組（unmanaged instance group），只是把幾台各自管理、規格不一定相同的 VM 綁在一起給負載平衡器用，沒有自動調整、自動修復與滾動更新。
健康檢查：負載平衡器停止轉送，自動修復負責重建
健康檢查（health check）定時對 VM 發出探測，例如 HTTP GET /，回應 200 才算成功。官方預設每 5 秒檢查一次、逾時 5 秒、連續 2 次成功算健康、連續 2 次失敗算不健康（查證時間 2026 年 10 月）。同一種健康檢查資源用在兩個地方，效果不同：
掛在負載平衡器的後端服務上時，不健康的 VM 不會再收到新請求，但負載平衡器不會重建它。掛在 MIG 的自動修復政策上時，MIG 發現 VM 不健康，會刪除並依範本重建；這需要設定初始延遲（initial delay），讓新 VM 有時間開機、跑完啟動指令碼，否則還沒準備好就被判定不健康、一直被重建。另外，就算沒有設定自動修復，MIG 也會自動重建那些停止、當機、被搶占或被 MIG 以外的動作刪掉的 VM；它做不到的，是發現「VM 在執行，但程式卡死」，這種情況只有應用程式健康檢查看得出來。實務上常把自動修復的健康檢查設得比負載平衡器保守一些（例如允許更多次失敗），避免短暫抖動就把 VM 砍掉重練。最後別忘了防火牆：健康檢查的探測來自 Google 的範圍（IPv4 為 35.191.0.0/16，以官方健康檢查文件當下列出的範圍為準），要有輸入允許規則，否則探測被隱含拒絕規則擋下，所有 VM 都會被判定不健康。
自動調整：依訊號算出建議台數，再套用限制
自動調整器（autoscaler）可以依 CPU 使用率、負載平衡的服務容量、Cloud Monitoring 指標或排程調整；用多個訊號時，取各訊號建議台數中最大的那個。開啟自動調整時，預設會加上 CPU 使用率訊號。以 CPU 為例，你設定目標使用率（gcloud 的 --target-cpu-utilization 是 0～1 的小數，例如 0.6），自動調整器把它當成「所有 vCPU 的平均使用率」來維持：平均高於目標就加開，低於目標就考慮縮減。粗略的算法是「建議台數 ≈ 目前台數 × 平均使用率 ÷ 目標使用率，無條件進位」，例如 4 台平均 90%、目標 60%，建議 6 台（實驗室二就是用這個簡化模型）。建議台數一定落在執行個體數下限與上限之間。
幾個控制項各有用途。初始化期間（舊稱冷卻期，gcloud 旗標仍叫 --cool-down-period，預設 60 秒）代表應用程式開機需要的時間，自動調整器會忽略這段期間內 VM 的數字；設得太短，開機時的 CPU 尖峰會被當成負載而多開；設得遠比實際開機時間長，又會忽略掉真正的負載資料。縮減時，自動調整器看穩定期（stabilization period）內的最高負載來決定，避免負載稍降就馬上砍 VM、又馬上加回來。縮減控制（scale-in controls）再進一步限制一段時間內最多移除幾台（固定台數或百分比）。自動調整模式可以是開啟、只增加（only scale out）或關閉，關閉時保留設定但不動作。另外還有預測型自動調整（predictive autoscaling），依過去的 CPU 歷史提前加開，適合開機很慢、負載有規律週期的服務。
應用程式負載平衡器：一個 IP 背後的四層元件
全域外部應用程式負載平衡器在 gcloud 與 Terraform 裡不是一個資源，而是一串：轉送規則（forwarding rule）擁有對外 IP 與連接埠；它指向目標 HTTP(S) 代理（target proxy），代理在 Google 的前端終止連線，HTTPS 時憑證也掛在這裡；代理參照網址對應（URL map），依主機名稱與路徑決定送到哪個後端；最後是後端服務（backend service），裡面放 MIG 之類的後端、健康檢查、通訊協定與具名通訊埠（named port，例如 http:80），以及平衡模式（例如依使用率 UTILIZATION）。在控制台建立時，這幾個元件被包成「前端設定、後端設定、轉送規則」三個區塊，一次建好。
新建的全域外部應用程式負載平衡器使用 EXTERNAL_MANAGED 負載平衡配置，支援進階流量管理（例如依權重分流、標頭改寫）；舊的「傳統版（classic）」使用 EXTERNAL，官方建議遷移到新版。全域外部負載平衡器需要 Premium 網路服務級別，用單一 anycast IP 服務全球使用者；要指定流量只在某個區域處理（例如資料落地）或想用 Standard 級別，改用區域外部應用程式負載平衡器。負載平衡器是代理式的，後端 VM 看到的來源 IP 是代理的位址，原始用戶端 IP 要從 X-Forwarded-For 標頭讀。
相似功能怎麼分
| 部署方式 | VM 當機 | 程式卡死 | 可用區故障 | 依負載增減 | 適合 |
|---|---|---|---|---|---|
| 單一 VM | 中斷，要人工處理 | 中斷，沒人發現 | 中斷 | 不行 | 開發測試、不怕停機的工具 |
| 非代管執行個體群組 | 剩下的 VM 撐著，不會重建 | 負載平衡器避開，不會重建 | 看 VM 放在哪 | 不行 | 既有、規格不一的 VM 要放在負載平衡器後面 |
| 單一可用區 MIG | MIG 重建 | 有自動修復才重建 | 整組中斷 | 可以 | 需要低延遲叢集、可接受可用區風險 |
| 區域型 MIG | MIG 重建 | 有自動修復才重建 | 其他可用區繼續服務 | 可以 | 正式環境的無狀態網站與 API（官方建議） |
| 項目 | Google Cloud | AWS | Azure |
|---|---|---|---|
| VM 設定的模子 | 執行個體範本（建立後不能改） | 啟動範本（可建新版本） | 擴展集模型 |
| 一群相同的 VM | 代管執行個體群組（單一可用區／區域型） | EC2 Auto Scaling 群組（跨多個 AZ 子網路） | 虛擬機器擴展集（可指定多個可用性區域） |
| 程式卡死的處理 | MIG 自動修復＋應用程式健康檢查 | 群組改用 ELB 健康檢查 | 應用程式健康情況＋自動修復執行個體 |
| 新 VM 的暖機 | 初始化期間（舊稱冷卻期） | 執行個體暖機時間 | 自動調整規則的冷卻時間 |
| HTTP 負載平衡 | 應用程式負載平衡器（全域外部可用單一 anycast IP） | Application Load Balancer（區域服務） | Application Gateway（區域）、Front Door（全球） |
判斷步驟
- 先問服務需不需要完整掌控作業系統。不需要的無狀態網站或 API，先考慮 Cloud Run；需要 VM 才往下走。
- VM 是可用區資源：正式環境用區域型 MIG 把 VM 分散到多個可用區，再用負載平衡器對外；把網站做成無狀態，資料放外部資料庫或 Cloud Storage。
- 寫好執行個體範本：映像用映像系列、不要寫死版本；VM 不給外部 IP；網路標記配合防火牆規則（健康檢查探測、IAP 管理連線）。
- 設定兩種健康檢查用途：後端服務的健康檢查決定轉送，MIG 的自動修復負責重建；自動修復要設足夠的初始延遲。
- 設定自動調整：先選訊號（CPU、負載平衡用量、指標或排程），目標使用率留餘裕，執行個體數下限要能在少一個可用區時撐住基本流量，上限要考慮配額與成本；初始化期間設成實測的啟動時間。
- 依流量選負載平衡器：HTTP／HTTPS 用應用程式負載平衡器；全球使用者、單一 IP、要接 Cloud CDN 或 Cloud Armor 用全域外部；資料落地或 Standard 級別用區域外部。
- 換版本時建立新範本，用滾動更新或金絲雀更新逐批替換，不要直接改 VM。
容易考錯的地方
VM 卡死但沒當機。情境寫「VM 狀態是執行中，但網站沒有回應」，答案是替 MIG 設定應用程式健康檢查與自動修復。只加自動調整、只靠負載平衡器的健康檢查，或寫一個 cron 定時重開，都不是最合適的答案。
要撐過可用區故障。情境要求「單一可用區故障時服務不中斷」，答案是區域型 MIG（多個可用區）加負載平衡器；單一可用區 MIG 就算開很多台也沒用。反過來，「Region 等級的災難」要靠多區域部署，區域型 MIG 只涵蓋同一個區域。
範本不能修改。要改機器類型或映像，正確做法是建立新範本，再用 MIG 的滾動更新替換；「直接編輯現有範本」不是可行選項。
目標使用率的寫法。gcloud 的 --target-cpu-utilization 是 0 到 1 的小數（0.6 代表 60%），寫成 60 是錯的；--max-num-replicas 一定要有。固定台數用 resize，那不是自動調整。
新 VM 一直被重建或一直多開。自動修復的初始延遲太短，新 VM 還沒啟動完就被判定不健康而重建；初始化期間太短，開機時的 CPU 尖峰被採計而多開。兩者都要依實測的啟動時間設定。
健康檢查全部失敗。剛建好的負載平衡器所有後端都顯示不健康，先檢查有沒有允許健康檢查探測範圍的防火牆規則，以及具名通訊埠是否對得上後端服務的 port name。相關考試：ACE 的 MIG 自動擴展與網路設定、PCA 的高可用架構設計、PCNE 的負載平衡與後端服務自動調整都會考到這些判斷。
✅ 自我檢測
以下 6 題都是原創題，選完會立即顯示對錯與解析，全部作答後會出現總分。目前得分：0 / 6