雲端成本管理日益複雜，精準預測和有效最佳化至關重要。本文從成本管理四個層級出發，探討如何設定目標、最佳化成本及達成目標的最佳實踐。同時也涵蓋FinOps三大關鍵焦點：建立評價、可維護性與成本控制，並輔以程式碼範例及圖表說明，提供更全面的成本管理策略。從基本預測到單位經濟指標，逐步提升成本管理效率。透過滾動預測模型、驅動因素預測和季節性調整，提升預測準確性，並結合細粒度預測和跨團隊反饋，制定更有效的成本最佳化策略。
雲端成本管理：從預測到最佳化
在雲端運算的世界中，成本管理是一個持續的挑戰。從預測到最佳化，每一步都需要謹慎的規劃和執行。本篇文章將探討雲端成本管理的不同層級，以及如何有效地設定目標和最佳化成本。
成本管理的四個層級
成本管理可以分為四個層級，每個層級都有其特定的目標和方法。
Level 1-2: 基本預測
在最初的層級中，企業通常依賴簡單的預測方法，例如固定預測或歷史資料分析。然而，這些方法往往無法準確反映實際的雲端支出。
Level 3: 成本削減目標
在第三層級中，企業開始設定成本削減目標。這種方法可以激勵團隊減少支出，但往往缺乏與業務成果的直接聯絡。例如，一家線上雜貨店設定了20%的成本削減目標，初期取得了顯著的效果，但隨著時間的推移，這種方法開始顯現其侷限性。
Level 4: 單位經濟績效指標
在第四層級中，企業開始將雲端支出與實際的業務成果掛鉤。這種方法可以更準確地評估雲端投資的回報。例如，透過跟蹤服務每個客戶的成本，並持續降低該成本，企業可以更好地理解其雲端支出的價值。
預測的最佳實踐
要實作準確的預測，企業需要採用滾動預測模型，並結合驅動因素預測和季節性調整。此外，細粒度的預測和來自工程和FinOps團隊的反饋也是至關重要的。
設定目標的重要性
設定目標是雲端成本管理的關鍵步驟。透過設定目標，企業可以跟蹤業務決策，設定期望，並識別雲端支出中的問題。不同的團隊可能有不同的目標，例如快速佈署服務或維持預算。
如何設定有效的目標
要設定有效的目標，企業需要考慮不同的業務需求和優先事項。這包括清晰地溝通指導方針，設定貿易-offs的期望，並允許某些團隊有一定的預算不確定性。
調整以達成目標：最佳化階段的最佳實踐
在設定進一步的目標之前，您必須清楚瞭解目前的狀況。當您在雲端擴充套件資源時，實施明確的標籤和帳戶分離策略將使您更容易理解所面對的挑戰並最佳化資源。
清晰的成本分配策略
每個組織都應該按成本中心/業務部門來追蹤支出。這不僅能讓每個團隊瞭解他們對整體雲端支出的影響，還能讓企業判斷哪些團隊正在推動成本變化。
我們已經討論過如何實施清晰的成本分配策略，以幫助識別按成本中心劃分的支出。這些成本分配策略需要保持一致。如果不一致，團隊在嘗試確定其歷史雲端支出時，將無法區分其成本變化和分配策略之間的差異。
程式碼範例：成本分配策略實作
def allocate_cost(cost_center, total_cost):
# 將總成本根據成本中心進行分配
allocation_ratio = get_allocation_ratio(cost_center)
allocated_cost = total_cost * allocation_ratio
return allocated_cost
def get_allocation_ratio(cost_center):
# 根據成本中心取得分配比例
# 假設這裡有一個資料函式庫或組態檔案儲存了各成本中心的分配比例
allocation_ratios = {
'center1': 0.3,
'center2': 0.7
}
return allocation_ratios.get(cost_center, 0)
# 使用範例
cost_center = 'center1'
total_cost = 1000
allocated_cost = allocate_cost(cost_center, total_cost)
print(f"Allocated cost for {cost_center}: {allocated_cost}")
內容解密：
allocate_cost函式根據提供的成本中心和總成本計算出分配後的成本。get_allocation_ratio函式根據成本中心取得對應的分配比例。- 分配比例儲存在一個字典中，模擬從資料函式庫或組態檔案中取得資料。
- 使用範例展示瞭如何呼叫
allocate_cost函式並列印預出結果。
節省是目標嗎？
正如我們多次提到的，節省成本並不總是目標。許多 FinOps 從業者最初專注於減少雲端賬單，但必須記住，FinOps 的目標是促進問責制、擁有支出投資決策以及最終的創新。
在設定目標時，您應該問自己：如何花費適當的金額以為企業帶來最大的利益？您所追求的利益包括哪些？它們是否包括增加收入、加快專案交付、在其他領域提高成本效率，或者只是讓客戶更滿意？在某些情況下，增加支出可能會減少其他方面的成本，例如勞動力成本。
鐵三角：好、快、便宜
鐵三角（或稱「專案三角」）是專案管理中一個約束條件的模型：速度、成本和品質。常見的表述是：「好、快、便宜，選兩個。」它認為專案經理可以在確定專案完成方式時，在這些約束條件之間進行權衡。一個約束條件的變化必然會導致其他約束條件的變化，以進行補償。
鐵三角模型
圖表翻譯： 此圖示呈現了鐵三角模型的三個主要方面：好（品質）、快（速度）和便宜（成本）。它們之間相互影響，表明在專案管理中需要在這三個維度之間進行權衡。
使用 OKRs 達成目標
OKRs（目標與關鍵結果）是一種定義和跟蹤目標及其結果的框架。對於每個 OKR，有一個要實作的目標，以及一組衡量該目標實作程度的指標，稱為關鍵結果。OKRs 通常有一個季度的有效期。
在 FinOps 基金會的一次演講中，Nationwide 的前雲端服務總監 Joe Daly 表示：「我們用 OKRs 來設定目標，並專注於結果，以提供清晰度、問責制和可衡量的成果。」他還強調，OKRs 最重要的是專注於結果。
實踐FinOps的三大關鍵焦點：建立評價、可維護性與成本控制
在匯入FinOps的過程中，設定正確的目標至關重要。來自Nationwide的Daly在其FinOps團隊初成立時提出了三個主要的關注領域，分別是評價（Credibility）、可維護性（Maintainable）與控制（Control）。
OKR焦點領域 #1：建立評價
Daly認為，在建立FinOps實踐時，評價是最重要的領域。評價等同於信任，如果缺乏信任，就需要不斷地為提供的服務進行辯護。他透過提供從終端使用者到程式碼層級的透明度來支援評價目標。這包括定期更新支出情況（每日、每週、每月），並根據每個利益相關者的需求提供相應的粒度。這些更新必須簡單易懂，並且與會計人員在月底報告的數字相符。
內容解密：
- 定期支出更新：根據不同利益相關者的需求，提供每日、每週或每月的支出更新。
- 透明度：確保更新內容簡單易懂，並且與會計報告一致。
OKR焦點領域 #2：確保可維護性
許多新的FinOps團隊在工作中採用了不可持續的方式，例如不強制執行自動化標籤。Daly指出，有意義的資料需要由對其有意義的人進行管理。他們建立了一個由應用產品經理和麵向業務人員維護的標籤儲存函式庫，這樣就可以將應用資料和業務資料與資源繫結，而無需依賴工程師。
程式碼範例：標籤管理系統
class TagRepository:
def __init__(self):
self.tags = {}
def add_tag(self, resource_id, tag):
if resource_id not in self.tags:
self.tags[resource_id] = []
self.tags[resource_id].append(tag)
def get_tags(self, resource_id):
return self.tags.get(resource_id, [])
# 使用範例
tag_repo = TagRepository()
tag_repo.add_tag("resource_1", "application_name:MyApp")
tag_repo.add_tag("resource_1", "application_owner:JohnDoe")
print(tag_repo.get_tags("resource_1"))
內容解密：
TagRepository類別：用於管理資源的標籤，提供新增和取得標籤的功能。add_tag方法：為指定的資源新增標籤。get_tags方法：取得指定資源的所有標籤。
OKR焦點領域 #3：成本控制
此目標旨在建立控制的同時促進速度。Daly提到，他們透過建立直接的收費模式、分享知識和鼓勵使用者採用，同時實施政策以防止自動擴充套件帶來的問題，從而將使用控制的責任推給應用/產品團隊。
Plantuml成本控制流程
圖表翻譯： 此圖示展示了成本控制的流程，從建立收費模式開始，接著分享知識和鼓勵使用者採用，最後實施控制政策並持續監控與調整。
跨團隊協作的重要性
不同的團隊有不同的目標和激勵因素。工程師關注效能、可用性和新功能的佈署速度；財務團隊關注支出、節省和效率；業務長官者則關注整體業務表現。在設定FinOps目標時，不能讓這些團隊單獨設定目標，否則不僅無法實作正確的業務成果，還會增加團隊間的摩擦。
透過讓工程和財務團隊共同合作，可以找到對雙方都適用的解決方案。同樣，與其他組織的FinOps從業人員討論目標，可以幫助你建立正確的目標，並與整個FinOps社群保持一致。
最佳化階段：調整以達成目標
在前面的章節中，我們討論了資訊階段如何幫助我們瞭解目前的狀況。當我們進入最佳化階段時，我們會設定目標，以確定我們希望達到的狀態。利用這些目標，企業能夠專注於需要關注的專案。
雲端成本最佳化指標
為了有效地進行雲端成本最佳化，我們需要建立並追蹤相關的指標。以下是一些關鍵的指標：
- 預留例項使用率：我們的目標是達到95%的預留例項使用率，並按預算分段進行追蹤。
- 標籤使用率：標籤對於我們的最佳化工作至關重要，尤其是應用程式擁有者的標籤，有助於我們進行資源調整（rightsizing）。
- 資源調整選擇離開率：我們追蹤選擇離開我們提供的資源調整建議的比例，目標是將選擇離開的比例降低到25%。
- 雲端服務提供商預算：我們追蹤兩個方面的預算：對雲端服務提供商的承諾以及每個預算分段內的預算進度。
- 節省機會：我們追蹤透過資源調整和預留例項覆寫所產生的總節省機會，並設定年度目標以降低總節省機會。
目標作為參考線
目標不僅僅是一個單一的數值，而是一個隨著時間變化的趨勢。如果將目標設定為每月的固定金額，那麼就必須等到月底才能評估是否達標。將目標分解為每日數值，可以在雲端支出圖表中繪製參考線，以便進行近乎實時的分析。
圖表示例
圖表翻譯： 此圖示呈現了每日支出的趨勢，以及如何根據每日支出累計計算月底總支出，並與預設目標進行比較。如果超出目標，則需要調整支出；如果未超出，則繼續監控。
預算差異
當我們的指標與目標之間存在顯著差異時，通常意味著存在問題。為了維持預算，團隊應該認真對待超出目標的情況，並盡早對指標表現的變化做出反應。
預算差異型別
- 預期異常：當團隊為了實作特定的業務目標而主動超出預算時，例如為了加快專案進度而佈署更大的資源。
- 非預期異常：當團隊在佈署資源時預期維持預算，但實際上卻超出了預算。這通常需要對佈署的資源或預算目標進行調整。
減少支出的方法
當我們知道實際支出與預期之間的差異時，下一個問題就是如何處理超出預期的情況。有兩種主要方法可以減少雲端支出：
- 減少使用量：透過縮減資源規模或關閉不需要的資源來減少使用量。
示例程式碼：縮減虛擬機器的規模
def resize_vm(vm, new_size): # 縮減虛擬機器的規模 vm.resize(new_size) print(f"虛擬機器已縮減至 {new_size}")
使用範例
vm_instance = get_vm_instance(“instance_id”) resize_vm(vm_instance, “small”)
#### 內容解密：
* 此程式碼範例展示瞭如何縮減虛擬機器的規模。
* `resize_vm` 函式接受虛擬機器例項和新的規模作為引數，並呼叫虛擬機器例項的 `resize` 方法來縮減規模。
* 在實際應用中，需要根據具體的雲端服務提供商的 API 來實作此功能。
2. **降低費率**：透過向雲端服務提供商承諾一定的使用量來獲得費率折扣。
```python
# 示例程式碼：承諾使用量以獲得費率折扣
def commit_usage(cloud_provider, commitment_term, usage_amount):
# 向雲端服務提供商承諾使用量
cloud_provider.commit_usage(commitment_term, usage_amount)
print(f"已承諾 {usage_amount} 的使用量，期限為 {commitment_term}")
# 使用範例
cloud_provider_instance = get_cloud_provider("provider_name")
commit_usage(cloud_provider_instance, "1_year", "100_GB")
#### 內容解密：
* 此程式碼範例展示瞭如何向雲端服務提供商承諾使用量以獲得費率折扣。
* `commit_usage` 函式接受雲端服務提供商例項、承諾期限和使用量作為引數，並呼叫雲端服務提供商例項的 `commit_usage` 方法來承諾使用量。
* 在實際應用中，需要根據具體的雲端服務提供商的 API 來實作此功能。
使用最佳化：實踐更有效的資源利用
在FinOps生命週期中，減少使用量是最具挑戰性的環節之一。要在文化上實施使用量最佳化需要耗費大量的努力和時間。如果你的目標是快速節省成本，那麼購買承諾型折扣（我們將在第17章中介紹）是實作成本降低的更快途徑。與購買預留例項不同，後者可以在無需工程行動的情況下帶來顯著的成本文省，而使用量最佳化則需要工程師將最佳化工作納入他們的迭代開發中。
雲端消費的殘酷現實
當你開始關注使用量最佳化時，如果聽到類別似以下的對話，請不要感到驚訝：
FinOps從業者：「嘿，看起來你們沒有使用這些資源。你們需要它們嗎？」
團隊成員：「哦，那些還在那裡？我忘了！我現在就刪除它們。」
此時，你可能會情不自禁地拍額頭感到沮喪。你很快就會意識到，如果你早些進行這次對話，也許就能節省數月的資源費用。
然而，事情並沒有那麼簡單。當你在雲端大規模營運時，幾乎可以肯定會有某些未充分利用或被遺忘的資源。當面對雲端看似無限的資源選擇時，許多工程師會傾向於選擇更大的資源選項。這種選擇可以讓他們避免在半夜被叫醒處理問題。
然而，要知道哪些資源需要審查並不容易。如前所述，這需要團隊擁有正確的指標來瞭解其應用程式的需求。團隊還必須瞭解資源規模和營運方式背後的業務原因。FinOps在各組織中非常有效，因為它要求組織內的所有團隊遵循一致的工作流程，並共同將建議付諸行動。
浪費從何而來？
我們所謂的浪費是指任何已付費的使用量，或是透過調整或減少資源數量以更好地滿足應用程式需求而可以避免的已付費使用量部分。
當雲端資源首次佈署時，其容量需求往往不完全清楚或不被充分理解。在佈署的早期階段，幾乎每個人都面臨這種情況。
這種不確定性導致團隊過度組態容量，以確保不會出現效能問題。初始佈署時過度組態資源並不是壞事。雲端的美妙之處在於，它允許你快速佈署，然後在過程中進行調整。你要避免的是佈署資源後不根據利用率指標進行監控。這樣你就會發現自己在長期內為資源支付了超出應有的費用。
內容解密：
本段落主要闡述了雲端資源浪費的來源。由於初始佈署時對容量需求的不確定性，團隊往往會過度組態資源。然而，如果不持續監控這些資源的利用率，就會導致長期的資源浪費。持續監控和調整是避免這種情況的關鍵。
隨著團隊忽視根據利用率指標維護其資源，浪費會不斷增長。持續監控資源是否過度組態至關重要。這是因為今天正確使用其資源的服務可能會在明天因更高效的服務程式碼佈署而變得過度分配。甚至客戶行為的變化也可能導致容量需求的減少。
如何減少使用量
減少使用量需要在文化上進行轉變。這不是一次性的修復，而是一個持續的迴圈，不斷選擇合適大小的資源並消除過度組態。減少使用量要求工程師像思考記憶體或頻寬一樣思考成本，將其視為另一個佈署KPI。他們很快就會發現，將成本視為效率指標是值得付出的努力。
將資源大小減半通常可以節省50%的成本，或者在未使用的資源（如未掛載的區塊儲存卷或閒置例項）的情況下，節省100%的成本。雲端按需、變動性質的一個好處是，你可以隨時調整任何資源的大小，或者完全停止使用它。
對於正確調整大小且持續使用的資源，可以透過費率降低選項進一步節省成本，我們將在第17章中介紹。
Plantuml圖表示例
@startuml
skinparam backgroundColor #FEFEFE
skinparam componentStyle rectangle
title 雲端成本管理預測與最佳化實踐
package "時間序列分析" {
package "資料準備" {
component [時間索引] as time_idx
component [重採樣 Resample] as resample
component [缺失值處理] as missing
}
package "特徵分析" {
component [趨勢 Trend] as trend
component [季節性 Seasonality] as season
component [殘差 Residual] as residual
}
package "預測模型" {
component [ARIMA] as arima
component [指數平滑] as ets
component [Prophet] as prophet
component [LSTM] as lstm
}
}
time_idx --> resample : 時間聚合
resample --> trend : 分解
trend --> season : STL分解
season --> residual : 殘差分析
trend --> arima : 自迴歸
season --> ets : 季節調整
residual --> prophet : 預測
residual --> lstm : 深度學習
note right of arima
p: 自迴歸階數
d: 差分階數
q: 移動平均階數
end note
@enduml
圖表翻譯： 此圖示展示了從初始佈署到成本最佳化的流程。首先，在初始佈署階段，由於對需求的不確定性，往往會進行過度組態。接著，透過持續監控來發現未充分利用的資源。最後，根據監控結果調整資源大小，從而實作成本最佳化。