FinOps-管理大量預購的能力
- 什麼是大量預購的折扣及其運作方式
- 不同CSP的不同類型的大量預購的折扣
- 量化大量預購的有效折扣管理的影響
- 用於管理大量預購的折扣的協議
- 描述不同成熟度等級的大量預購的折扣管理
定義
大量預購是使用雲端資源可以獲得的折扣，以換取在特定時間範圍（通常為 1 或 3 年）內承諾一定程度的資源使用。 每個CSP都有自己的一套大量預購的折扣選項，因此我們承諾的具體內容和我們收到的折扣將根據CSP和我們所做的大量預購類型而有所不同。
有效管理大量預購的折扣以最大限度地優化成本可能是一個耗時且複雜的過程。 它涉及分析我們的歷史和預測使用資料、了解大量預購的折扣機制以及追蹤我們先前的大量預購。 我們使用該資料來確定是否做出額外預購或修改現有預購。
為何是重要的
- 在相同的雲端服務上花費更少
- 能夠展現FinOps團隊的價值
- 需要深入了解雲端資源使用情況和預測
- 影響力大，可以省很多錢，但也可以浪費很多錢
參與人員
此能力的參與人員根據RACI模型如下:
- R — FinOps成員
- A — FinOps團隊或財務單位
- C — 財務、產品、採購、所有技術等團隊、高階管理者、CSP
- I — 所有人，對於資料品質與即時性有關的人
成功衡量的標準
- 所有可優化的支出都包含在大量預購中
- 所有大量預購已超過收支平衡點
- 透過最大限度地提高折扣的大量預購涵蓋每種類型的可優化雲端支出
- 透過多樣化大量預購類型將風險降至最低
- 能夠報告所有大量預購的使用率/節省情況
- 計算混合費率
根據FinOps社群的調查，大量預購的覆蓋率在Crawl — 60%、Walk-75%、Run-80%。
Crawl階段
該階段工作通常涉及做出不頻繁、不規則的人工作業的大量預購
- 分析和採購以臨時單次方式橫跨多個業務部門進行
- 採購方式可能無法為企業提供最大的整體折扣
- 當支出過高或有人因未達預測/預算會被動地進行採購或管理。
- 技術團隊自主地做出大量預購，而不考慮 WACC/NPV(淨現值) 或其他以財務為中心的考量。
- 財務人員在沒有正確了解計劃的基礎設施變更的情況下進行購買
Walk階段
- 集中分析和採購以半定期的節奏進行，並得到了技術+財務的投入
- 當大量預購的使用率下降、停止使用或因偏離既定規範而需要注意時發出告警
- 定期評估長期業務技術計劃
- 不斷評估CSP的新版本/更新
- 關於 KPI 的一次性報告
Run階段
該階段會經常與定期的進行預購，並定期報告結果。另外也要不斷評估CSP的大量預購新版本/更新，如果發現使用率不夠好則修改未充分利用的大量預購。
- 根據業務需求自動分配折扣，從而產生頻繁的購買週期
- 從基於時間的節奏轉變為基於需求的節奏
- 指標驅動管理何時進行更改以及資源調整規模/使用率/重構與適當的預購類型和術語之間的雙向連接
- 定期報告 KPI
- 更加關注折扣與覆蓋範圍和使用率的優化
大量預購的基本概念
- 哪些服務可以預購
- 一般預購的選項
- 預購越具體，折扣越大
- 預購的單位通常是小時
三大雲的可預購產品
AWS:
EC2, Lambda, Fargate, RDS, Elasticache, Redshift, Sagemaker, Opensearch
Azure:
VMs, SQL Database, Synapse Analytics, Cosmos DB, Blob Storage, Dedicated host, Azure Database for MySQL/PostgreSQL/MariaDB, Managed Disks, Databricks, Cache for Redis, Data Explorer, SUSE Linux, Red Hat Linux, Azure VMWare solutions, Red Hat OpenShift, App Services, Azure Files, Data Factory, Azure SQL Edge, Arc-enabled SQL Managed Instance
GCP:
Compute Engine
一般預購選項
期間:
AWS、Azure 和 GCP 均提供 1 年或 3 年期限
3 年期的折扣比 1 年期的折扣大得多
支付方式:
AWS 提供三種付款方式； 全部預付、部分預付或無預付。預付金額越多，折扣越大。從無預付到部分預付費用的折扣通常比從部分預付到全部預付的折扣幅度更大。。Azure 提供預付款或按月付款選項，但折扣不變。GCP 僅提供按月付款。
以AWS為例，說明為甚麼預購的內容越具體，折扣越高:
最佳實踐
- 集中採購
- 頻繁的預購
- 達到收支平衡
- 追蹤預購的使用情況
- 分散風險 —
與金融投資一樣，多元化的雲預購組合可以降低風險。 預購也不是憑空產生的，需要協調。 - 取得購買策略/範本批准
- 衡量合規性並持續改進
集中採購
集中採購費率優化被認為是基於大量預購的折扣的最佳實踐，因為：
- 一個中心化團隊對所有使用情況擁有最廣泛的可見性，不針對個別情況作出承諾。我們希望平衡跨時區、白天/夜間、大量和線上的使用
- 大量預購需要持續管理
- 中心化流程可提高覆蓋範圍
- 中心化流程可以降低風險
- 工程師不需要了解預購如何運作的機制
以下我們舉例，一間企業有三個使用相同instance type資源，並且是各自採購的情況。以下是三個團隊針每天運作該資源的情況。目標是預購能節費30%，並且損益平衡是70%的預購使用率。
對A團隊來說預購一個類型的資源，他們的On Demand Cost是32USD，每天總體費用是26USD，所以節省了6USD。
而B團隊也是預購一個類型的資源，但他們的資源使用時間太集中，所以這樣的預購是錯誤的。On Demand Cost是20 USD，整體費用是26 USD。這樣反而還多付6 USD
C團隊因為使用時間分散，所以沒有預購資源。On Demand cost與整體費用 都是 18 USD，沒有節費。所以個別採購無法讓節費30%，並且損益平衡是70%的預購使用率。
但是如果我們將三個團隊集中採購，就會變成以下狀況。
三個團隊的On — Demand Cost是 70 USD，也由於每個團隊的預購都可以分享給其他團隊使用(一共有三個資源預購)。所以整體費用是 58 USD，整個企業節省了 12 USD。
所以針對每個團隊的個別節費，我們使用每個團隊在每天的時間區間的使用量(也就是上圖的全部35個資源使用區間) / 每個團隊個別使用量。
頻繁的預購
為什麼要頻繁的採購呢?有使用過雲端服務的人都知道，雲端是非常動態的，所以資源量的使用也是非常動態的。大區間的採購無法符合動態的雲端服務。
預購的資源應不斷監控和修改，以實現利益最大化並提高財務靈活性。
損益平衡
損益平衡是當預購使用量等於 1 減去節費時。例如節費率是30%，損益平衡就是70%。當預購使用量處於損益平衡點時，On-Demand成本等於預購成本。任何高於損益平衡點的使用都會帶來節費， 如果預購使用低於損益平衡，則預購成本高於On-Demand成本。以下是一個節費率要達30%的預購資源使用場景。
追蹤預購的使用情況
我們需要工具來顯示預購使用率/實現的節費。AWS的 CUR 檔案可用於計算預購使用率/節費。如果預購的使用率不足以產生節費，我們應該在做出新預購之前考慮修改這些預購的選項。
為什麼做出預購後使用情況可能會改變？
- 技術漂移(Tech drift)
- 現代化資源進入市場
- 重構/重新架構
- 將系統搬進/搬出雲端
- 公司生意變差了
- 最佳化（資源擴展、資源調整規模、資源管理）
功能性活動
- 與財務目標/政策保持一致 —
在向公司要錢之前，我們需要確保我們了解組織的財務政策並將在其範圍內採取行動 - 分析歷史和預測的資源使用資料 —
按資源類型劃分的每小時支出、對特定實例類型未來使用的預期 - 了解預購的折扣機制 —
預購內容、每個選項的風險與回報、修改/取消選項 - 追蹤先前的預購
- 修改未充分利用的預購資源
- 做出新的預購
- 處理成本分配/攤銷
-如何處理預付款？
-攤銷(amortization)將如何運作?
-哪些成本/折扣會轉嫁給團隊?
預購決策的進行
- 什麼是有意義的回顧期？
- 我們需要與誰討論以驗證未來的資源使用預期？
-廣義範圍：如果提供給多個團隊使用的預購資源，過去的資料可能就足夠了
-狹義範圍：如果預購一個或幾個團隊使用的資源，我們需要與這些團隊討論以了解未來的期望 - 考量未來使用變化的影響
- 根據預購類型權衡業務風險
- 了解公司的 WACC(加權平均資成本) 或要求的回報率如何影響付款選項
- 風險、回報和時間承諾之間的正確平衡是什麼？
當預購使用不如預期時該怎麼做?
預購的風險是該預購資源不會被使用。 如果發生這種情況，有以下三種選擇：
- 承受損失(但有人要負責)
通常不會發生，因為有其他選擇 - 更多地使用你最初承諾的資源
激勵團隊使用已預購的資源，而不是使用其他實例類型（如果有意義的話） - 修改/取消/出售預購資源
— AWS：
標準 Rls 可以在市場上以折扣價出售。 可以修改可轉換 RI。 儲蓄計劃無法修改、取消或出售
— Azure：
Azure 允許我們隨時交換 Rls。 新的 RI 必須具有相同或更大的值，並且生命週期從新的預留開始。 也可以支付 12% 的費用取消，但每年的取消限額為 5 萬美元
