業務流程分析與成本優化

最低帳單不等於最好架構

把 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。

flowchart TB
  B["Cloud Billing exports<br/>Standard／Detailed／<br/>FOCUS／Pricing"] --> Q["BigQuery raw tables<br/>Late data、Credits、<br/>Corrections"]
  Q --> V["Stable curated views<br/>固定欄位與 invoice logic"]
  M["Project／Folder／<br/>Label／Tag<br/>Owner mapping"] --> A["Allocation rules"]
  V --> A
  S["Business metrics<br/>Orders／Users／<br/>Requests／TB"] --> U["Unit cost calculation"]
  A --> U
  U --> D["Owner dashboard＋Showback"]
  D --> G{"Total cost 或 Unit cost<br/>出現異常？"}
  G -->|"是"| I["追查 Usage、Price、Credit、<br/>Deployment 與 Business volume"]
  G -->|"否"| D

歸屬：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，不能拿來承擔最低可用容量。

flowchart TB
  H["數月 Usage history"] --> B["找出不含尖峰的<br/>穩定 baseline"]
  B --> R["扣除 Rightsizing、<br/>Migration、Shutdown<br/>與 Roadmap 變動"]
  R --> E["確認 Region／SKU／<br/>Service eligibility<br/>與 Sharing behavior"]
  E --> S["模擬 Growth／<br/>Flat／Decline 情境"]
  S --> G{"Utilization、<br/>Break-even、<br/>Stranded risk<br/>可接受？"}
  G -->|"否"| O["保留 On-demand／<br/>縮小 commitment"]
  G -->|"是"| C["只承諾 baseline<br/>的一部分"]
  C --> M["持續監控 Coverage 與 Utilization"]
  M --> R
  CAP["需要 Capacity<br/>guarantee"] -.-> RES["另外評估<br/>Reservation"]

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。

flowchart TB
  B["Budget／Forecast／Anomaly notification"] --> P["Pub/Sub<br/>At-least-once、可能亂序"]
  P --> I["Idempotent consumer<br/>依 event ID 去重"]
  I --> C["補充 Service／SKU／Project／Owner<br/>與最近變更 context"]
  C --> S{"風險與環境等級？"}
  S -->|"低風險"| N["通知 Owner＋<br/>建立 Investigation"]
  S -->|"預先標記的<br/>Ephemeral Non-prod"| A["經 policy 限流／<br/>Scale down／Stop"]
  S -->|"Production／<br/>High risk"| H["建立 Ticket＋<br/>Human approval<br/>附 rollback steps"]
  N --> V["驗證成本與服務狀態"]
  A --> V
  H --> V
  V --> L["Audit decision、<br/>action 與結果"]

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

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

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

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

flowchart TB
  R["Recommendation／Insight"] --> F["重新讀取 Resource 現況<br/>與 Recommendation<br/>freshness"]
  F --> C["加入 Seasonality、<br/>Failover、DR、<br/>Roadmap、Quota<br/>與 Owner context"]
  C --> G{"仍是有效且低風險<br/>的候選？"}
  G -->|"否"| X["Dismiss／Postpone<br/>記錄原因與 review date"]
  G -->|"是"| P["先在小範圍 Plan／<br/>Experiment"]
  P --> M["量測 SLO、<br/>Performance、<br/>Operational load 與 Cost"]
  M --> D{"符合 savings 與<br/>rollback<br/>condition？"}
  D -->|"否"| B["Rollback／<br/>調整方案"]
  D -->|"是"| E["逐步擴大<br/>並持續觀察"]
  B --> C
  E --> F

常見優化要先寫出副作用

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。

flowchart TB
  T["Optimization ticket"] --> E["估算 Savings、Engineering cost、<br/>SLO risk 與 blast radius"]
  E --> B["建立 Cost＋Performance＋Reliability baseline"]
  B --> P["在一個 Pool／Query／Bucket<br/>執行小規模變更"]
  P --> O["觀察至少一個<br/>代表尖峰的期間"]
  O --> G{"Unit cost 改善且 SLO、<br/>DR、Compliance 未退化？"}
  G -->|"否"| R["Rollback，記錄副作用"]
  G -->|"是"| A["逐步擴大範圍"]
  A --> M["持續監控 Unit cost 與 Error budget"]
  M --> G
  R --> T

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 或簡化需求。

離線演練：便宜的帳單，為什麼可能是更貴的訂單？

預留 20 分鐘，不需要計費帳戶。以下使用虛構的「成本單位」，不是產品價格、折扣報價或節省預測。三個候選方案都重播相同的 1,000,000 筆有效業務要求，使用相同資料與負載分布；觀察到尾端工作完成或確定失敗後，才結算結果。

為了公平比較，雲端成本都包含相同範圍的運算、資料庫、網路、日誌與備份；營運成本以同一估價方式計入這個窗口的排查、重試處理及值班工時。這是本次實驗的可比成本，尚不代表完整的多年 TCO。

表格超出欄寬時，可左右捲動；鍵盤可聚焦表格後用左右方向鍵查看。

本次發布門檻是：至少 99.5% 的有效要求在 800 ms 內成功完成。分母是同一批 1,000,000 筆要求，逾時、失敗、拒絕與未完成都不能從品質統計中消失。

先計算並提出決策：

1. 用 (雲端成本 + 營運成本) ÷ 不重複成功訂單 × 1,000，算出每千筆成功訂單成本。
2. B 的雲端帳單下降多少？這是否代表每筆成功訂單更便宜？
3. 三個方案各有多少比例在 800 ms 內成功？你會批准哪個候選方案取代 A？

檢查分母：哪些東西不算新增成果？

同一張訂單重試三次、Cloud Tasks 派送兩次、API 回覆一次「已受理」，都不能變成六筆成功訂單。成功成果要依業務識別碼核對最終提交狀態；HTTP 202 只代表受理，不代表已完成。期末仍在排隊的工作必須列出數量與年齡，不能一邊把後續處理費用留到下期、一邊在本期宣稱節省。

也不要只統計成功回應的 latency，讓失敗請求從 SLO 分母消失。這裡的成本分母是最終成功訂單，品質分母則是所有有效要求；兩者用途不同，都應在報表上明寫。

遷移題：什麼證據會改變決策？

C 調整啟動與預熱流程後，再次重播相同的要求。本次可比總成本仍為 13,000，最終成功 1,000,000 筆，其中 998,000 筆在 800 ms 內完成。它現在能取代 A 嗎？另列兩項正式採用前仍需補的證據。

這個方法對應官方框架的以業務價值衡量雲端支出。若省錢方案依賴擴縮，回到第九課的連線預算；若依賴排隊，把第十八課的 backlog 與重試容量一起列入證據。各課的虛構窗口不同，不能直接把秒流量乘上本表成本。

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

假設一家 SaaS 這一期的雲端帳單比上一期多了一倍，團隊還說不出原因。

寫下你的調查順序：先確認什麼、拿哪些資料比對、什麼時候才動手優化，再展開對照。

課後檢查

往下看重點之前，先試著回答這幾題；答不出來，括號裡是該回去重讀的那一節。

• 帳單變高時，為什麼要連 unit cost 一起看，不能只看總金額？（回〈最低帳單不等於最好架構〉）
• 花費超過 budget 時，Cloud Billing 會做什麼、不會做什麼？（回〈Budgets 會通知，不會自動封頂〉）
• Recommender 建議縮小一台低 CPU 的 VM，照做之前要先確認什麼？（回〈Recommender 是候選清單，不是自動待辦〉）
• 重試與期末 backlog 會如何扭曲「每筆成功交易成本」？品質統計應用哪個分母？（回〈檢查分母：哪些東西不算新增成果？〉）

本課重點

• 同時看總成本、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 和容量驗證方法。