業務流程分析與成本優化

最低帳單不等於最好架構

把 database 縮到剛好不當機，帳單可能下降，使用者等待時間和 on-call 次數卻一起上升。FinOps 的工作不是單純砍費用，而是讓 engineering、finance 和 business 一起回答：

• 花費能否歸屬到 owner、產品和環境？
• 每一元成本換來多少交易、使用者、GB processed 或其他業務價值？
• 哪些費用是浪費，哪些是可靠性、成長或法規的必要投入？
• 要採取什麼動作，怎麼驗證沒有傷害 SLO？

因此要同時看總成本和 unit cost，例如每千筆訂單成本、每位活躍用戶成本、每 TB pipeline 成本。流量成長時帳單上升可能合理，但 unit cost 失控通常值得調查。

先建立成本可見性

Cloud Billing 可把 usage cost 匯出到 BigQuery：

• Standard export：服務、SKU、project、location、credit 等成本資料。
• Detailed export：再加入支援資源的 resource-level 明細。
• FOCUS export：依 FinOps Open Cost and Usage Specification 提供標準化資料，目前狀態與欄位應依文件確認。
• Pricing export：提供帳戶適用的 pricing metadata。

Export 不是即時串流，不同 services 回報週期不同，也沒有資料到達延遲保證。剛啟用時，region 與 multi-region dataset 的 backfill 行為也不同。成本告警和 dashboard 要容忍 late-arriving data、correction、credit 與 invoice month 差異。

建議在 export table 之上建立穩定的 BigQuery views，避免 schema 新增欄位時每張報表都壞掉。GKE 若要看到較細的 cluster／namespace 成本，還要啟用 GKE cost allocation。

歸屬：project、label 和 tag 各有用途

• Project／folder：穩定的組織與環境邊界，通常是第一層成本 owner。
• Label：服務支援時可標註 workload、team、environment 等資訊；不會追溯套用前的成本。
• Resource Manager tag：有集中 IAM、階層繼承和 policy 整合，Billing export 對支援 resources 也能輸出 tag 資料。

並非每個 service 都提供同等 resource-level labels／tags。先查 detailed export coverage，無法直接歸屬的 shared cost 再定義 allocation rule，例如依 request、storage、headcount 或固定比例分攤。

命名政策不能只靠文件。可以在 IaC module、CI policy、custom organization constraint（若資源與欄位支援）或部署平台驗證 metadata。對不能標註的資源，保留 project-level owner map。

Showback 先建立信任

Showback 讓團隊看到成本但不實際轉帳，適合先驗證資料品質和 shared cost allocation。Chargeback 會影響部門預算，必須有爭議處理、correction、credit 與未分配成本規則。報表不準時直接 chargeback，只會讓團隊花時間爭數字。

定價與折扣：先找穩定基線

Google Cloud 的定價因 service、region、billing model 與 SKU 不同。Compute 相關常見方式包括：

• On-demand／按使用量付費。
• Sustained use discounts（只適用符合條件的 Compute Engine usage）。
• Resource-based 或 spend-based committed use discounts（CUDs）。
• Spot capacity，適合可中斷 workload。

不要在架構課背一組最高折扣百分比。Discount、eligible SKU、sharing scope 和 consumption model 都會變。購買 commitment 前應：

1. 從數月 usage 找出不含尖峰的穩定 baseline。
2. 扣除可能被 rightsizing、migration 或關閉的需求。
3. 確認 region／resource／service eligibility 和 sharing behavior。
4. 用多個成長與下降情境計算 utilization、break-even 和 stranded commitment。
5. 先買 baseline 的一部分，再定期 review coverage 與 utilization。

CUD 是財務承諾，不是容量保留；需要 capacity guarantee 時還要另外評估 reservation。Spot 則不保證容量也沒有 SLA，不能拿來承擔最低可用容量。

Budgets 會通知，不會自動封頂

Cloud Billing budgets 以估算成本產生 threshold／forecast notifications。它不會自動阻止消費，資料也可能延遲或在 invoice 前調整。

可以把 budget 或 cost anomaly notification 發到 Pub/Sub，再觸發 workflow，但要把它視為 at-least-once、可能重複和亂序的事件。Consumer 應 idempotent，並監控 topic permission 和 delivery，因為設定錯誤時不一定另有告警。

安全的自動回應通常分級：

• 先通知 owner，附上增加最多的 service／SKU／project。
• 建立 incident 或 approval ticket。
• 對預先標記為 ephemeral 的 non-production resources 做限流、scale down 或停止。
• 高風險 production 動作需要人工核准和復原步驟。

不要一超過 budget 就停 production、拔 external IP 或 disable billing。Disable billing 可能停止服務並最終刪除資源，應只用在明確接受這種結果的隔離 project。

Recommender 是候選清單，不是自動待辦

Recommender 可針對支援服務提供 rightsizing、idle resource、IAM、commitment 等 insights／recommendations。每一項都要用業務 context 審核：

• 低 CPU 的 VM 是否在等待 failover？
• 未掛載 disk 是否是事故復原所需 snapshot source？
• 季末才執行的 permission 是否被短觀察期誤判為未使用？
• Commitment 建議是否知道產品即將下線？

Claimed recommendation 之後，resource 若變更，建議不一定跟著即時更新。執行前要重新確認現況，變更後用 SLO、性能和成本資料驗證。

常見優化要先寫出副作用

Compute

• Rightsize CPU／memory：可能降低 headroom，需重跑 load test。
• Autoscaling：節省離峰容量，但 startup time 和 downstream limits 可能造成尖峰失敗。
• Spot：降低可重試工作成本，但要支付 checkpoint、重試與等待的工程成本。

Storage

• Lifecycle／Autoclass：降低長期保存成本，但 retrieval、early deletion、operation 和 data access pattern 會影響結果。
• 刪除 idle disk／snapshot：先確認 retention、legal hold 和 DR dependency。

Network

• CDN：對可快取內容降低 origin load 與部分 data delivery cost，但增加 cache correctness 和 invalidation 工作。
• 減少跨 region／Internet egress：要和 latency、availability、data residency 一起看。
• Interconnect 可能改善大量穩定 hybrid traffic 的網路成本，但有 port、provider、circuit 和維運費，不是 Internet egress 的通用便宜替代。

Database／analytics

• Index、partition pruning、query rewrite 與 connection control 往往比直接加 machine 更有效。
• Read replica 增加讀取能力，也增加 instance、replication lag 和操作成本。
• BigQuery reservation／editions 與 on-demand 的選擇，要依 query baseline、concurrency 和可預測性試算。

每個優化 ticket 都應包含預估節省、engineering cost、SLO risk、owner、驗證期和 rollback condition。

TCO 和業務流程

比較 managed service、自管或 migration 方案時，TCO 至少包含：

• Infrastructure、license、network、backup 與 support。
• Platform engineering、on-call、patching 和 incident cost。
• Migration、parallel run、training 與 exit cost。
• Downtime、slow delivery 和 compliance delay 的業務影響。

有時最值得優化的不是 SKU，而是等待人工核准、重複搬資料、每天全量重跑或產品功能沒人使用。先畫 business process 和 data flow，再決定是否用 Workflows、event-driven pipeline 或簡化需求。

情境練習：SaaS 成本突然翻倍

1. 先確認是 usage、price、credit、currency 還是 late adjustment，不直接把帳單變化當成 resource 浪費。
2. 用 detailed export 依 project、service、SKU、region 和 resource 比較前後期間。
3. 把主要增幅映射到業務量，計算每千次請求／每位客戶成本。
4. 若 unit cost 上升，檢查 egress、query bytes、idle capacity、logging volume 和部署變更。
5. 對候選方案做小規模實驗，例如 rightsizing 一個 stateless pool、調整 query partition 或 CDN cache policy。
6. 觀察至少一個代表尖峰的週期，確認 SLO 不變後再擴大。
7. 只有在穩定 baseline 和產品 roadmap 清楚後，才購買部分 CUD coverage。
8. 建立 owner-level budget／anomaly notification，讓下一次變化更早被看見。

本課檢查清單

• 同時看總成本、unit cost、SLO 和業務價值。
• Billing export 有資料延遲與 service coverage 差異，不是即時帳本。
• Labels／tags 不追溯歷史成本，支援度也因 resource 而異。
• CUD 先找穩定 baseline；折扣、capacity reservation 和 Spot 是不同問題。
• Budget 不會自動封頂，programmatic notification 要容忍重複、亂序和延遲。
• Recommender 要加入 roadmap、季節性、HA 與 DR context 再執行。
• 每個成本優化都要寫副作用、驗證與 rollback condition。

延伸閱讀

• Cloud Billing export to BigQuery
• Budgets and programmatic notifications
• Compute Engine committed use discounts
• Recommender key concepts

下一步

下一課會把成本優化中反覆出現的「先量測、再調整」用在效能與擴展性，建立 latency budget、backpressure 和容量驗證方法。