排程關機：非上班時間關掉

最直接的手段是排程關機——dev 跟 staging 在非上班時間自動關機、上班前自動開機。一個只有工作日白天有人用的環境，關掉晚上跟週末，運轉時間從一週 168 小時降到約 50 小時，成本直接省下七成。這對開發環境幾乎沒有副作用：沒人在用的時候關掉，早上開機幾分鐘就回來，換來的是大幅的成本下降。

排程關機的邊界是「哪些環境真的可以關」。跑著共用測試、或有人在跨時區使用的環境不能無腦關；但絕大多數團隊專用的 dev、staging，晚上關掉沒有任何人受影響。判斷的標準是這個環境有沒有「非上班時間必須在」的用途——沒有，就該排程關掉。

Ephemeral 環境：用完即拆

比排程關機更徹底的是 ephemeral 環境——按需建立、用完就拆，而不是常駐。典型做法是每個 PR 自動起一個獨立的預覽環境，PR 合併或關閉就自動銷毀。這種環境的存在時間只有它真的被用到的那幾小時或幾天，不用時根本不存在、自然不計費。

ephemeral 的好處不只省錢，還順帶解掉了環境漂移的問題——每次都從乾淨的 IaC 重建，不會累積手動改動。它的前提是環境要能完全用 IaC 重現、且建立夠快（不能每次等半小時）。做得到的話，ephemeral 是開發環境成本控制的理想形態：成本只在真的用的時候發生。

CI 與批次工作跑 spot

CI 跟批次工作是 spot instance 的理想場景。spot 便宜（單位成本遠低於 on-demand），代價是可能被中斷——而 CI 本來就能容忍中斷：一個 job 被收回，重跑就好，不像 production 服務中斷會影響用戶。把 CI runner、批次的資料處理、壓測這類「可中斷、失敗可重跑」的工作放到 spot，成本大幅下降而不影響正確性。

要讓 spot 的中斷不變成整批失敗，除了靠多機型、多可用區分散降低同時被收回的機率（這條在 模組五 成本模型 講過），還要讓工作本身能優雅承接中斷。雲商通常在收回前提前約兩分鐘發中斷通知，job 收到通知時該做的是把當前工作標記成待重跑、或 checkpoint 進度，讓它換一台接續而不是靜默地掉在半路。對無狀態、冪等的 CI job 這幾乎是免費的（重跑就好）；對有中間狀態的批次，checkpoint 讓被收回的那段能接續而非從頭。spot 省的錢，前提是中斷處理做對。

Per-team 成本上限

前面幾個手段是省，這一個是防失控。給每個團隊、每個非 production 環境設一個成本上限（budget），超過就告警甚至自動限制。它防的是開發環境特有的失控模式——有人開了一台大機器做實驗忘了關、某個測試腳本失控地建資源、自動擴縮在測試環境把上限設太高。這些在 production 有嚴格審查，在開發環境卻常常沒人盯，一個手滑就是一筆意外帳單。per-team 的上限讓每個團隊的實驗有一個成本天花板，配上 成本監控與告警 的歸因，超標時知道是誰、哪個環境。

下一步路由

• CI 用的 spot、spot 的中斷風險怎麼管 → 模組五 成本模型
• per-team 上限配的歸因與告警地基 → 成本監控與告警
• ephemeral 環境要能完全 IaC 重現的前提 → infra 治理好習慣