雲端成本管理日益重要，承諾型折扣已成為企業降低成本的重要手段。本文將探討如何有效利用承諾型折扣，並結合財務模型與實際案例，分析不同支付方案的優劣，以及如何選擇最佳購買時機。同時也將探討如何與團隊協作，制定合理的承諾策略，避免過度承諾或資源閒置，並分享一些程式碼範例和圖表說明，以幫助讀者更好地理解和應用這些策略。此外，文章也將探討永續發展的概念，以及 FinOps 和 GreenOps 如何協同合作，降低雲端碳足跡，實作企業的永續發展目標。最後，文章將分析雲端碳足跡測量的現狀和挑戰，並提供一些解決方案和最佳實踐，幫助企業更好地管理和降低其數位碳足跡。
管理承諾型折扣策略的最佳實踐
在雲端運算的成本管理中，承諾型折扣（Commitment-Based Discounts）是一種常見的成本文省方式。企業可以透過承諾使用一定的資源量來獲得折扣，從而降低整體的雲端成本。然而，如何有效地管理承諾型折扣策略，是一個需要仔細考量的問題。
承諾型折扣的財務考量
在決定是否採用承諾型折扣時，企業需要考慮其加權平均資本成本（WACC）和承諾的淨現值（NPV）。透過計算不同支付方案的NPV，企業可以判斷是否應該選擇全額預付或其他支付方式。
隱含利率的概念
AWS提供的不同支付選項（如無預付和部分預付）可以視為供應商對未預付部分的貸款，並帶有隱含的利率。企業需要比較其WACC與AWS提供的隱含利率，以決定最合適的支付方案。
- 當企業的WACC低於隱含利率時，選擇全額預付可能更划算。
- 當企業的WACC高於隱含利率時，選擇無預付或部分預付可能更有利。
管理承諾策略
為了避免各團隊自行管理承諾，導致過度承諾的風險，FinOps團隊需要提供透明的折扣資訊和整體節省情況。這樣可以確保在集中式的承諾型折扣模式下，各團隊不會自行購買承諾。
與團隊協作
雖然採用集中式的管理模式，但FinOps團隊仍應與各業務團隊合作，瞭解他們的未來計畫和資源使用預測。這樣可以在需要時調整或轉換承諾。
適時購買承諾
企業需要仔細規劃承諾的購買時間，以避免過早或過晚購買的風險。
過早購買的風險
如果過早購買承諾，企業可能會在一段時間內支付承諾費用卻無法獲得折扣，從而浪費一部分成本。
過晚購買的風險
如果過晚購買承諾，企業將以隨用隨付（on-demand）的價格支付資源費用，錯失獲得折扣的機會。
圖表說明：資源使用與承諾購買時機
圖表翻譯： 此圖示說明瞭在不同時間點購買承諾對資源使用成本的影響。如果在一月購買一年期承諾，將在前三個月支付無折扣的費用，直到四月開始使用資源後才獲得折扣。相反，若未購買承諾，將以隨用隨付的價格支付費用，錯失獲得折扣的機會。
建立承諾型折扣策略的實踐與挑戰
在雲端運算的成本管理中，承諾型折扣（Commitment-Based Discounts）是一種常見的成本最佳化策略。企業透過承諾在一定期間內使用特定的資源，從而獲得相應的折扣。然而，如何有效地實施承諾型折扣策略，卻是許多企業面臨的挑戰。
承諾型折扣的基本原理
承諾型折扣的核心思想是企業透過預先承諾使用雲端資源，從而獲得成本上的節省。以AWS的Reserved Instances（RI）或Azure的Reserved Virtual Machine Instances為例，企業可以透過預付一定費用，獲得未來一段時間內特定資源的使用權，並享受相應的折扣。
承諾時機的選擇
選擇合適的承諾時機對於實作成本最佳化至關重要。如果企業過早地進行承諾，可能會面臨資源利用率不足的問題，從而導致實際成本文省不如預期。反之，如果企業過晚進行承諾，則可能會錯失獲得更大折扣的機會。
例如，如果企業在4月就進行了為期9個月的承諾，那麼從4月到12月的資源使用將能夠享受到折扣。相反，如果企業等到9月才進行承諾，那麼將需要以全價支付5個月的資源使用費用，從而錯失了原本可以實作的成本文省。
頻繁承諾的優勢
提高承諾的頻率可以減少企業以全價支付資源使用費用的時間，同時也能減少過度承諾的誘惑。然而，這也需要企業具備快速分析當前資源使用情況和未來需求的能力。
許多企業最初會按照固定的時間表（如每年、每季或每月）進行承諾。在這種情況下，企業可能會傾向於過度承諾，以在每個週期中實作最大的成本文省。然而，這種做法可能會導致在年初時企業為未使用的承諾支付額外的費用。
正確調整與承諾的平衡
在進行成本最佳化時，企業需要在資源調整（Rightsizing）和承諾型折扣之間找到平衡。有些人認為應該先進行資源調整，然後再進行承諾。然而，這種做法可能會導致企業錯失透過承諾型折扣實作成本文省的機會。
資源調整是一個需要工程團隊參與並對成本有深入瞭解的過程，通常需要較長時間才能完成。因此，在資源調整尚未完成之前，企業如果不進行任何承諾，將會以高昂的按需費率支付資源使用費用。
同步進行資源調整與承諾
正確的做法是同時進行資源調整和承諾型折扣。這兩者看似相互對立，但實際上是相輔相成的。透過逐步進行資源調整和適當的承諾購買，企業可以實作持續的成本最佳化。
程式碼範例：計算合適的承諾比例
def calculate_commitment_coverage(current_usage, growth_rate, months_ahead):
"""
計算合適的承諾比例
:param current_usage: 目前的使用量
:param growth_rate: 未來的使用量增長率
:param months_ahead: 未來預測的使用月份
:return: 合適的承諾比例
"""
future_usage = current_usage * (1 + growth_rate) ** months_ahead
commitment_coverage = current_usage / future_usage
return commitment_coverage
# 使用範例
current_usage = 1000 # 目前的使用量
growth_rate = 0.05 # 每月5%的增長率
months_ahead = 6 # 預測未來6個月的使用量
optimal_coverage = calculate_commitment_coverage(current_usage, growth_rate, months_ahead)
print(f"合適的承諾比例為：{optimal_coverage:.2%}")
內容解密：
此程式碼用於計算合適的承諾比例。首先，根據目前的使用量、未來的增長率和預測的使用月份，計算出未來的預期使用量。然後，透過比較目前的使用量和未來的預期使用量，計算出合適的承諾比例。這樣的計算能夠幫助企業在考慮未來增長的情況下，做出更合理的承諾決策。
分割槽管理策略
由於承諾型折扣通常僅適用於特定區域和具有相同屬性的資源，因此在低使用區域或較舊的例項型別上進行承諾可能會存在風險。為了更好地管理這些風險，企業可以採取分割槽管理策略，即根據不同的區域和使用情況，分別制定合適的承諾計劃。
建構承諾型折扣策略的核心要素
在雲端運算成本管理的實踐中，承諾型折扣（Commitment-Based Discounts）是一種有效的成本最佳化策略。企業需要清楚瞭解如何有效地實施和管理這類別折扣，以達到最大化的成本效益。
分割槽管理策略
分割槽管理是實作承諾型折扣策略的重要方法。這種方法將雲端資源的使用分為允許區（Allowed Zone）、限制區（Restricted Zone）和封鎖區（Blocked Zone）。
允許區
允許區是工程師最容易操作的區域。在這個區域內，工程師可以使用最新的、常見的例項型別，並且佈署在企業廣泛採用的區域。這種做法使得工程師在日常工作中無需考慮承諾型折扣計畫，從而簡化了工作流程。
限制區
在限制區內，工程師需要自行管理承諾或與財務營運（FinOps）團隊密切合作來購買特定的承諾。這種做法需要額外的努力，因此對工程團隊的吸引力較低。
封鎖區
封鎖區明確規定了哪些位置和型別的承諾不被企業批准購買。這可以用來劃定工程師不應該建立基礎設施的區域。
靈活運用不同型別的承諾
使用更靈活的承諾選項，如SPs（Savings Plans）或Flexible CUDs，可以涵蓋較少使用的區域，從而減少因團隊轉移而導致的承諾覆寫風險。這種混合使用不同承諾型別的做法類別似於投資多樣化以對沖風險。
誰該承擔承諾的費用？
批准財務營運團隊購買承諾型折扣並不一定意味著他們將承擔全部費用。承諾的成本包括前期費用和小時費用。正確的做法是將這些成本攤銷到實際受益的雲端資源上。
未使用承諾的成本分攤
對於未使用的承諾成本，需要制定合理的分攤策略。常見的方法包括：
帳戶基礎歸屬：根據購買承諾的帳戶，將未使用的承諾成本分配給相關團隊。
混合攤銷：將未使用的承諾成本新增到攤銷率中，有效地將未使用的成本混合到所有相關資源的費率中。
資源混合費率：建立一個新的費率，將所有相關資源的成本、攤銷和未使用的承諾成本混合在一起。
節省池：建立一個流程，將所有節省集中管理，使用隨需應變的費率進行預算和預測，避免工程團隊需要考慮複雜的承諾費率。
建構承諾型折扣策略的最佳實踐
在雲端成本管理中，承諾型折扣（Commitment-Based Discounts）是一種常見的成本最佳化策略。企業透過購買承諾使用量（Commitment）來獲得折扣，從而降低雲端服務的成本。然而，如何有效地實施承諾型折扣策略需要仔細的規劃和執行。
成本分配的重要性
當企業購買承諾使用量時，需要將這些承諾的成本分配給相關的團隊或部門。這種分配可以透過多種方式進行，例如按照實際使用量或預算比例分配。正確的成本分配方式可以幫助企業更好地理解其雲端成本結構，並鼓勵團隊最佳化其資源使用。
### 成本分配策略範例
1. **集中式管理**：將所有承諾成本集中管理，由FinOps團隊負責分配。
2. **分散式管理**：將承諾成本分配給各個團隊或部門，根據實際使用量進行核算。
內容解密：
- 集中式管理：這種方式可以簡化成本分配的流程，但可能需要FinOps團隊具備足夠的專業知識來進行正確的分配。
- 分散式管理：這種方式可以鼓勵團隊最佳化其資源使用，但可能需要更複雜的成本核算系統。
策略提示
在建構承諾型折扣策略時，以下幾點值得注意：
- 建立可視性：在購買承諾之前，瞭解雲端成本結構和資源使用情況是非常重要的。
- 瞭解承諾機制：承諾型折扣的機制相對複雜，瞭解不同型別的承諾和使用場景可以幫助企業避免錯誤的購買決策。
- 尋求幫助：FinOps從業者可以透過參加培訓課程、獲得認證和與雲端服務提供商的支援通路互動來獲得幫助。
圖表翻譯： 此圖示呈現了建構承諾型折扣策略的步驟順序，從建立可視性開始，瞭解承諾機制，然後尋求幫助，最終避免錯誤的購買決策。
避免從零到英雄
在實踐中，建議企業從小規模開始，逐步擴大承諾型折扣的範圍。這種漸進式的方法可以幫助企業建立信心，並根據實際情況調整其策略。
永續發展：FinOps 與 GreenOps 的合作
近年來，隨著雲端運算的普及，企業對於雲端服務的碳足跡關注度大幅提升。雲端供應商和雲端團隊開始重視衡量和減少其雲端碳足跡。永續發展作為一門學科，有三大主要支柱：環境、社會和經濟。本章節將重點討論環境支柱，特別是與雲端資料中心排放相關的議題。
為何企業應關心永續發展
組織對其數位服務的碳足跡日益關注，主要是由於來自內外部重要利害關係人的壓力所致：
- 投資者和股東敦促 CEO 和董事會成員對其整體排放量負責，這是由 ESG（環境、社會和治理）倡議以及公開報告的永續性衡量指標所驅動的。
- 政府正在收緊環境報告要求和法規，因此企業較難進行漂綠（虛假聲稱或宣傳公司比實際上更環保），並更注重實際行動。
- 客戶越來越多地根據道德考量（包括他們所考慮的公司的永續性實踐）來做出購買決定。
- 員工要求自己的公司更加永續。在選擇下一份工作時，員工非常重視潛在僱主如何應對永續性。
利害關係人對永續發展的影響
圖表翻譯： 此圖示呈現了不同利害關係人如何影響企業的永續發展。投資者與股東透過推動ESG倡議來促進企業的永續發展；政府透過收緊環境法規來約束企業行為；客戶透過根據永續性實踐做出購買決定來影響企業；員工則透過要求企業更加永續來推動變革。
為何永續發展在雲端運算領域中很重要
雲端服務產生的碳足跡規模龐大，因此永續發展在雲端運算領域中變得尤為重要。直到最近，IT 服務的碳足跡一直被 ESG 專業人士忽略，他們將重點放在了企業的其他領域，認為 IT 和雲端消費相對其他更直接汙染的業務領域來說無關緊要。
隨著雲端服務的發展，產業和媒體越來越關注資料中心的碳足跡，特別是它們消耗了多少電力以及水資源來滿足看似無窮無盡的資料儲存和計算需求。這種轉變現在正在發生，因為越來越多的公司正在關閉自己的小型資料中心並整合到雲端。將許多小型設施的工作負載集中到由雲端供應商營運的大型綜合體中，可以使雲端供應商實施的整體效率提升產生更大的影響。
據報導，構成雲端的資料中心消耗了全球總能耗的 1%–4%，預計這一數字在未來十年內將增長到 10%，遠遠超過航空等其他行銷部門。此外，它們還是大量耗水者，這會以水蒸氣的形式產生排放。「典型的資料中心每天使用大約 300 萬至 500 萬加侖的水，與一個擁有 3 萬至 5 萬人口的城市用水量相當，」德克薩斯理工大學水資源中心主任 Venkatesh Uddameri 教授在 2021 年接受 NBC 新聞採訪時表示。
根據《時代》雜誌 2022 年的一篇文章，「谷歌將其用水量視為專有商業秘密，甚至禁止公職人員披露該公司的用水量。但相關資訊有時會透過與當地公用事業公司和保護團體的法律訴訟洩露。僅在 2019 年，谷歌就申請或獲準使用超過 23 億加侖的水。」
FinOps 與 GreenOps 的合作
FinOps 和 GreenOps 的合作對於實作雲端運算的可持續性至關重要。透過結合成本最佳化和環境可持續性，這兩種實踐可以幫助企業減少其雲端足跡，降低成本，並提高整體營運效率。
程式碼：計算碳足跡
def calculate_carbon_footprint(energy_consumption, water_usage):
# 將能耗和水資源使用量轉換為碳足跡
carbon_footprint = energy_consumption * 0.5 + water_usage * 0.2
return carbon_footprint
# 範例用法：
energy_consumption = 1000 # 千瓦時
water_usage = 5000 # 加侖
carbon_footprint = calculate_carbon_footprint(energy_consumption, water_usage)
print(f"碳足跡：{carbon_footprint} 公噸 CO2e")
內容解密：
此程式碼範例用於計算給定能耗和水資源使用量的碳足跡。其中 calculate_carbon_footprint 函式接受兩個引數：energy_consumption（能耗）和 water_usage（水資源使用量），並傳回計算出的碳足跡。函式內部將能耗和水資源使用量根據相應的係數轉換為碳足跡。在範例用法中，我們計算了特定能耗和水資源使用量下的碳足跡，並將結果列印出來。
雲端碳排放的真相：瞭解與管理數字足跡的重要性
隨著企業逐漸擺脫自建資料中心，轉而依賴雲端服務，雲端使用量的爆炸性成長使得永續發展措施成為不可忽視的課題。要有效管理和降低數位碳足跡，所有相關人員必須對碳排放有共同的理解。
什麼是雲端碳排放？
要管理並降低數位碳足跡，首先需要了解溫室氣體及其計量單位。溫室氣體包括二氧化碳（CO₂）、水蒸氣、甲烷（CH₄）、一氧化二氮（N₂O）等，這些氣體會在大氣中吸收並重新發射熱量，導致地球溫度上升。
關鍵概念：
- CO₂e（碳二氧化當量）：用於衡量所有溫室氣體對環境的影響，將不同氣體的全球暖化潛勢轉換為等效的二氧化碳排放量。
- 淨零排放：指企業透過減排措施抵消其活動所產生的總排放量，達到碳中和的狀態。
範圍1、2、3排放
企業的碳排放被分為三個範圍，分別代表不同的排放來源：
- 範圍1排放：企業直接擁有或控制的排放源，如自有資料中心的柴油發電機。
- 範圍2排放：企業間接產生的排放，如購買電力所導致的排放。
- 範圍3排放：企業價值鏈上下游的間接排放，包括供應商和客戶相關的活動，如雲端服務供應商的全部排放。
重點解析：
雲端服務供應商的範圍1、2、3排放最終都會計入客戶的範圍3排放。瞭解這一點有助於企業更全面地掌握其整體碳足跡。
雲端供應商是否「環保」？
評估雲端供應商的「綠色程度」需要多角度分析：
- 一方面，雲端供應商出於效率和利潤的驅動力，通常具備比本地資料中心更高的能源效率，並盡可能使用可再生能源。
- 另一方面，大部分雲端供應商僅關注範圍1和2的排放，而範圍3的排放往往遠超前兩者之和。例如，微軟2021年的報告顯示，其總排放量中有超過75%屬於範圍3。
在雲端供應商提供更透明、全面的碳排放報告之前，很難準確評估其「綠色程度」。目前，各大雲端供應商在永續發展報告上的做法各異，逐漸朝向更細緻、頻繁更新的資料集發展。
圖表解析：
圖表翻譯： 此圖示展示了不同範圍的碳排放如何層層累積，最終納入客戶的範圍3排放中，呈現出完整的價值鏈碳足跡。
雲端碳足跡測量現狀與挑戰
目前主要雲端服務提供商對其碳排放的報告內容混雜不清，缺乏一致的方法論和完整性。例如，在本文撰寫時，AWS 和 Google 的報告僅涵蓋其範圍 1 和 2 的排放，忽略了範圍 3 的排放。這使得 Azure 成為唯一報告涵蓋所有三個範圍的碳排放的提供商，但所有報告都大量使用平均值和不同年份的碳資料。
資料取得的困難
雖然頂級雲端服務提供商已發布可持續性工具和/或碳使用報告，但許多其他雲端提供商要麼無法提供可持續性資料，要麼要求其雲端使用者支付額外的費用來進行一次性稽核。可持續性資料的更新頻率從手動（按需）到每月不等。資料本身以 PDF 報告、自定義儀錶板（可透過雲端平台網頁介面存取）或有限的 API 資料（用於自有的分析報告）形式提供。
由於缺乏對可用資料和存取方法的標準化，第三方供應商平台所提供的可持續性功能受到限制。開源空間中的一個選擇是名為 Cloud Carbon Footprint 的應用程式。Cloud Carbon Footprint 使用您的雲端服務提供商帳單資料和可持續性資料來估算您的雲端使用碳足跡。這是一種創新的解決方案，但它依賴於資料和計算方法的有效性和成熟度，包括雲端提供商提供的資料。
資料完整性的挑戰
在嘗試瞭解雲端服務提供商提供的可持續性資料的完整性時，您將面臨困難。大多數理解資料的困難是由雲端服務提供商用於計算碳足跡的方法所驅動。前面提到缺少範圍 3，但並非雲端服務提供商提供的所有服務都包含在其報告中，並且在計算中應用了大量的平均值。平均值的挑戰在於，它可能為不同地區、資料中心或個別產品提供誤導性的碳足跡。例如，一個低碳例項可能與相對低效、老舊的替代例項具有相同的碳足跡。一些雲端服務提供商目前建議將雲端支出作為碳影響的直接代理，這是不準確的——更昂貴的服務並不總是意味著更多的排放。
要建立對所提供資料的信任，雲端服務提供商需要納入所有雲端服務，更公開地說明其計算方法和涵蓋的氣體，並減少平均值的使用。
資料粒度不足
大多數由雲端提供商提供的資料都匯總到國家或地理區域，使得根據可持續性在不同的雲端區域之間佈署雲端服務的決策變得不可能。目前沒有一家雲端提供商能夠在雲端資源層級上提供真正準確的碳資料，而是將資料匯總為每個雲端提供商服務的總碳排放量。沒有資源層級的資料，您就無法確定哪些資源型別更有效率。例如，您無法識別特定位置是否更具可持續性或碳效率，也無法在不同區域或位置之間以任何準確度比較例項或服務。
目前，雲端服務提供商不提供像雲端成本計算器那樣的排放計算器。如果沒有主動計算工作負載預期排放量的方法，您的組織要了解其影響的唯一方法是佈署服務，然後等待更新的碳報告。
與工程師合作推動可持續性
一個正在興起的趨勢是與 GreenOps 相關但不同的實踐。GreenOps 的目標是建立一種實踐，讓工程師參與到他們的雲端可持續性中。GreenOps 用於描述組織推動其雲端佈署和其他 IT 領域（如資料中心、基礎設施平台和軟體開發）的可持續性的實踐。
AWS 最近對其 Well-Architected Framework 進行了擴充套件，引入了一個可持續性支柱，概述了可持續性的共同責任模型。受此啟發，圖 19-2 被建立用來幫助解釋兩個關鍵領域之間的劃分：雲端的可持續性與在雲端的可持續性。
前進的方向
雖然目前雲端服務提供商提供的可持續性資料仍有很大的改進空間，但等待所有正確的資料只會阻止您的組織發展出最佳化所需的文化和技能，並根據您的雲端佈署的可持續性做出決策。
圖表翻譯：
此圖示展示了「在」雲端的可持續性與「雲端的」可持續性之間的劃分。這兩個概念分別代表了不同的重點領域，前者關注的是如何在使用雲端的同時保持可持續性，而後者則著重於雲端本身的可持續性發展。
@startuml
skinparam backgroundColor #FEFEFE
skinparam componentStyle rectangle
title 雲端成本最佳化與承諾型折扣策略
package "系統架構" {
package "前端層" {
component [使用者介面] as ui
component [API 客戶端] as client
}
package "後端層" {
component [API 服務] as api
component [業務邏輯] as logic
component [資料存取] as dao
}
package "資料層" {
database [主資料庫] as db
database [快取] as cache
}
}
ui --> client : 使用者操作
client --> api : HTTP 請求
api --> logic : 處理邏輯
logic --> dao : 資料操作
dao --> db : 持久化
dao --> cache : 快取
note right of api
RESTful API
或 GraphQL
end note
@enduml圖表翻譯： 此圖示展示了「在」雲端的可持續性與「雲端的」可持續性之間的關係。「在」雲端的可持續性涵蓋了資源最佳化和節能措施，而「雲端的」可持續性則關注綠色能源的使用和基礎設施效率。這兩大方向共同構成了推動整體 IT 可持續性的關鍵要素。
