雲端費用的精準預測

16 min readJan 17, 2024

預測(Forecasting)是猜測未來雲端費用的做法，通常基於歷史費用趨勢和對未來計劃評估的組合。這樣做是為了了解未來的雲端基礎設施和應用程式生命週期變化可能如何影響預算並幫助評估雲端投資決策。這是 FinOps 中最難的難一部分。

預測很困難，因為它需要工程師、財務和採購之間的通力合作，其中財務有財務報告責任，採購有會計責任，並且都需要工程師和管理人員的幫助來履行這些義務並了解計劃的基礎設施變更。這些利害關係人團隊之間的協作對於建立商定的預測模型和 KPI 至關重要，並根據這些模型和 KPI 制定與業務目標一致的預算。當這些團隊建立模型來可靠地、準確地預測雲端支出時，雲端成本預測將為投資和營運決策提供資訊，以加速組織的發展。

在本文中，我們討論預測(Forecasting)，解釋預測為何如此困難，並回顧提高預測準確度所需的關鍵概念。

在雲端出現之前，傳統的 IT成本預測主要是年度預算的方式進行的。對於地端機房的設備，在執行系統強化或新系統建置時，會預先計算TCO的預測。由於技術團隊歷來沒有參與或關心建立資本支出商業論證之外的 IT 支出預測(因為哪通常不會是工程師的KPI)，因此他們不具備頻繁預測以及與財務和業務部門協作的歷史記憶。

在傳統的地端機房部署中，有很大一部分是已知的固定成本(CapEx)，因此預測不準確的影響可能有限。然而，當轉向雲端的可變動成本模型時，固定成本與可變成本的數量就會翻轉，其中較大的是可變成本，並且預測的不準確可能會很嚴重。

雲端中的頻繁預測比地端機房部署中的頻繁預測重要得多，並且需要團隊與個人之間更多的互動。

雲端費用預測的現況

即使對於資深的FinOps從業人員來說，雲端支出的預測也可能是一個具有挑戰性的領域。在最新的 FinOps 現狀調查中，這是第二大常見的 FinOps 挑戰，很大一部分受訪者（包括來自成熟實踐的受訪者）報告稱，他們的預測準確性存在超過 10% 的差異。當雲端帳單每月達到數百萬美元時，就算只有百分之十的差異，但金額會隨著支出迅速增加。

與預測的差異源於雲端成本的複雜性以及雲端資源的分散式消耗：當許多不同的人員和代碼根據需要運作在基礎設施上時，很難確定6–12 個月內所有這些費用加起來會是多少。這不僅是一個建模問題，也是一個人員和技術問題。準確的預測非常耗時，需要自動化並掌握其他 FinOps 實踐來提高效率。

重點在於費用預測由每年改成更短的週期，可能是每月甚至是每周的預測。週期越短，我們的FinOps成熟度與自動化就要越高。否則無法進行這麼頻繁且密集的重複性作業。

預測的方法

第一組需要契合的術語是如何產生預測本身的方法：

傳統地端機房法

使用的方式就是依照去年雲端的花費。去年是多少就依這樣的數字估計。

趨勢分析預估法

也稱單變量預測法，此方法仍然使用過去的雲端費用歷史記錄作為預測的基礎，但它還導入了某種形式的統計方式（例如線性回歸），以使用過去預測的趨勢來預測未來時期的支出。在下圖中，雲端費用的歷史趨勢用於預測未來時期。基於趨勢的預測只有考慮現有的歷史費用，沒有導入任何未來可能變化的其他情境或業務驅動因素。

基於業務驅動的預測

也稱多變量預測，此方法會考量其他業務指標來強化預測。連結雲端費用的業務驅動因素可以提高預測的準確性，特別是當其他業務指標已經以可接受的準確度進行預測時。這可以是手動調整預測或為自動預測演算法提供多個輸入資料來源的形式。在下圖(Forcast的黃色部分)中，與先前的單變量雲端費用的預測相比，我們會針對外部驅動因素造成的額外預期支出進行了調整。這方面的一些例子包括：

因為促銷活動而產生的費用
因為產品功能的變動或增加
在雲端進行實驗或創新的技術人員變多了
因產品/服務的增加而增加的資源使用

預測模型

現在讓我們考量一下可以用來產生預測的工具或模型。我們不會詳細介紹產生預測的不同演算法或機器學習模型。本文的目的是幫助思考雲端費用預測，並考量幫助我們在 FinOps 中處理雲端費用預測的技術。如果對預測這門技術有興趣的人，可以參閱這位大神有關預測的介紹。預測的模型包含：

機器學習

這個術語經常被過度用於描述預測技術。有些人認為只有深度學習模型才是真正的機器學習預測；其他包括此類別的統計模型和其他非深度學習模型。無論選擇使用哪種模型，最好貨比三家。不要害怕嘗試另一種模型。我們一開始使用的第一個不太可能是最好的。也可以考慮根據歷史評估多個模型，看看哪些模型最準確。

組合式

這是一種結合使用多個模型實現更準確預測的方法。一種簡單的組合方法是對多個模型給出的結果進行平均。

靜態式

此類預測在設定期間（例如 12 個月）開始時產生一次。直到該期間結束時才會更新，此時會為下一個期間產生新的預測。這種類型的預測對於非常固定的資源使用很有用。

滾動式

此類預測也會在設定期間（例如 12 個月）開始時產生。然而，與靜態預測不同的是，它在此期間會頻繁地重新預測（每週、每月、每季）。每次重新預測時，都會建立相同的時間長度，從而有效地將更多資料新增至預測範圍的末端。

雲端費用預測的挑戰

要產生更準確的預測，我們必須先解決一連串常見挑戰。我們可能已經在處理其中一些項目，因為解決預測所需的功能與我們在＂FinOps框架＂一文中的許多其他項目相關。根據我們的組織結構以及 FinOps 的完善程度，其中一些挑戰可能比其他挑戰更容易解決。

手動 Vs. 自動化的預估

預測通常會是企業內的財務或 FinOps 團隊的手工作業。這個作業可以使用一種簡單的方法，即使用先前的支出數字，然後根據技術團隊的回饋進行調整，或者將歷史數據轉移到電子表格中並使用公式產生一些基於趨勢的預測。隨著雲端支出規模擴大，這種手動方法會變得越來越困難，準確性通常會受到影響。低費用團隊的成本通常被分為一組並作為一個整體進行預測，從而降低了預測的細緻度。產生這些預測的努力意味著作業頻率非常短 — — 每季、每月或更短。

可以執行基於趨勢或基於驅動因素的預測的自動化工具可以經常產生預測。在 2022 年 FinOps 狀況調查中，最厲害的從業者每週甚至每天都會執行預測。成熟的 FinOps 文化將導致更多的技術團隊對其費用負責(有設定KPI)，從而使他們對預測更加聚焦。

不準的地方

尋找可以考慮雲端支出季節性的模式/工具。雲端費用不太可能整年都相同。進行能夠考慮雲端支費用上上下下情況的預測將帶來更高的準確性。有些模型受資料離群值的影響較大；異常現象造成的短暫、突然的高峰可能會導致預測不準確。有些模型可以很好地處理離群值，而有些模型則需要手動調整來修正它們。

細緻度

總體雲端費用水準的預測無法讓我們找出哪些單獨的雲端費用群(哪一類資源)導致了預測的不準確性。此外，財務部門可能需要更精細的預測來滿足其財務報告的要求。相反，產生非常詳細的預測可能需要付出比應有的更多的精力與時間，特別是當有使用大量的不同類別的雲端資源而雲端費用非常少時。

我們在雲端資源的標籤策略一文介紹了標記和標籤，沒有它們，幾乎不可能產生任何細緻度的預測。基於標籤和層次結構的方法可讓我們將雲端費用劃分為相關類別，例如成本中心、系統或環境。更精細的預測可以讓我們確定預測與實際情況不符的地方，並讓專注於這些領域進行改進。

產生精細預測時，預期預測與摘要(summary)預測一致。下圖中的費用層次結構，如果我們產生每個系統的預測，則預計將它們加在一起將等於我們的總體雲端費用預測。但是，如果除了細緻度度預測（例如在系統層級）之外，我們還為總體雲端費用產生摘要預測，由於預測演算法的統計屬性，所有精細度預測的總和可能不等於獨立產生的摘要預測的總合。預測之間的差異將由細緻度預測的系統層級的小誤差以及摘要預測中缺乏可用的詳細資訊而造成的。

我們可以透過將預測方法限制在一個細緻度層級來建立一致性的預測。以上圖的層次為例，大多數預測者使用三種主要的細緻度預測法：

由下往上法(Bottom-up)

由下往上法著重於細緻度最高的雲端費用；我們的範例使用系統層級的支出。這種方法為每個系統建立單獨的預測，然後將其加總為一個團隊的費用，然後是總體雲端費用。這種方法允許工程師和管理人員提供大量資料輸入，從而提高了細緻度等級的準確性，並可能導致最準確的總體費用預測。

由上往下法(Top-down)

由上往下法著重於使用歷史費用趨勢和未來專案資訊來產生總體雲端費用的預測。然後，使用與未來專案預期相符的歷史比例，將該預測分配給多個團隊和系統。當系統之間的費用分佈幾乎沒有變化時，這種方法最準，但在費用分佈波動較大的情況下，這種方法會變得非常不準。

中間散出法(Middle-out)

產生連貫預測的最後一種方法是中間散出。在上圖的範例中，這需要在團隊層級產生預測，然後匯總到總體雲端費用層級並按比例向下分配到系統層級。

預測的頻率

這裡的重點是要縮短預測的區間，不再是地端機房的年度預算法則。而是根據系統與雲端的變動調整成適合自己的預測區間，可能是每季、月或周。區間太長可能會導致預測失準。所以滾動式的預測模型通常比較適合雲端，所以公司的財務預算也可能不再是以年度為主。

下表中的資料顯示了五種系統的預測。該預測針對每個系統的每月支出，每週產生一次。透過比較之前和現行預測之間的差異，我們可以容易識別預測在哪裡發生變化。

成本預估

對於預測未來每個系統最後會長成怎麼樣並且對其雲端資源的使用進行預估，對技術團隊來說非常困難。因為影響的因素太多，特別是業務因素。而這些都不是技術團隊可以掌控的。就算進行了PoC或初步的估算(三大雲提供的費用計算機)，哪也只是依照當下的概念與資訊進行的。

將設計相似的現有雲端系統與將要導入的新系統進行比較或許可以幫助FinOps團隊估計新系統的未來成本。讓技術團隊對新舊系統進行比較，以確定我們是否有任何類似的系統。在可能的情況下，使用現有系統將有助於識別使用費用機算機時可能遺漏的成本項目。如果沒有現有系統，就要使用雲端的變動成本模型；讓技術團隊在測試環境中部署新系統並運行約一個小時。在此測試之後，我們可以確定與系統測試運行相關的成本。

不過就算如此，有一些雲端資源仍然很難進行費用預估，這包含了:

網路流量成本:

Region之間的流量
AZ之間的流量
個別資源(如LB)的總體流量

Event的數量

Function被執行的次數
Message在Queue中的收發
DB Query的次數

Data Storage的活動次數

有多少資料可以轉移到存取率較低的層級(也就是比較便宜的)
對單一Object的request次數

在要錢跟不要錢的領域中，我們開始看到像 Infracost 這樣的新工具，它使技術團隊能夠在將其部署到雲端平台之前了解其變更的成本影響的估計。這種左移(shifting left)使團隊能夠檢查他們的變更是否會對成本產生預期的影響。

成本優化對費用預測的影響

業務決策和新系統部署可以增加雲端費用一樣，未來的雲端成本優化也可以大幅減少支出，但同時也會使預測不準。就像有助於增加雲端支出的專案工作一樣，我們需要產生預測效率計算，該計算代表由 FinOps 活動驅動的雲端費用減少量，並從預測中減去它們。

在實施 FinOps 的早期階段，當導入"使用率和費率優化"時，雲端費用可能會大幅減少。如果預測中沒有預測到這些費用減少，最終的預測可能會高於實際情況。

當導入 FinOps 優化時，維運成本的降低可能會隱藏雲端支出的自然成長率。隨著這些優化趨於穩定，支出的正常成長率將恢復；在調整預測時對此進行建模很重要，這樣最初的費用減少就不會導致我們低估未來的情況。

費用的預測和預算

費用的預測和預算是齊頭並進的。用預測來制定預算是制定反映現實的預算的主要因素之一。

如果費用趨勢偏離了我們的預測，我們必須問自己：是否需要改變一些東西來回到預測軌道上，或者需要更改費用預測嗎？因此，應該每天追蹤實際支出與預測。雲端支出圖表應包含我們的預測，以確定是否需要採取任何行動（如下圖所示）。然後，將資訊分解到團隊層級，這樣就可以了解誰的行為使我們超出了預測範圍。可能存在業務因素（合規性、效能等），這意味著我們應該選擇簡單地調整預測。

預算不應意味著阻止雲端費用支出，而應提供一種工具來識別費用支出何時偏離計劃 — — 請記住，這可以促進各團隊之間的對話。

管理團隊對預算的重要性

人們很容易將預算是一種有嚴格的限制性控制。然而，預算不需要也不應該限制創新。再一次，FinOps 不是為了省錢，而是為了賺錢。在 FinOps 中，預算的目的是集中投資來推動創新，而不是阻礙創新。

技術團隊絕大多數都忙於技術問題，沒有空來注意於費用的管控(這也是FinOps的存在)。然而，如果技術團隊被指定了具體的成本目標，他們往往會實現這些目標。管理層(例如CTO)提出的節省成本的建議受到遵守。技術團隊會積極參與，尋求在保持速度和品質的同時削減成本的方法。資源規模調整的發生是因為團隊有明確的目標。領導力驅動的成本優化文化將讓技術團隊變成盟友，並讓他們了解他們如何幫助業務。技術團隊會開始明白，FinOps 不是要削減資源，而是要實現具有成本意識的速度和創新。

如果是新創公司，這可能是一種必要之惡，預算會分散人們在競爭激烈的成長市場中爭取盡可能多的市占率的注意力。他們沉浸在一場永無止境的軍備競賽中，以提供更強大更好的功能、引人入勝的內容或數據科學驅動的建議。 有一個毫無根據的前提：預算會減慢一切。

但對大多數企業來說，預算是啟動專案的必要步驟。在預算獲得批准之前不會開綠燈。雲端極大地改變了這樣的預算流程。透過採購訂單的力量來控制預算的日子已經一去不復返了，這樣就可以防止支付超出計劃的任何費用。但由於雲端支出的分散性和管理鬆散性，大多數企業（無論大小）都難以在公有雲中準確制定預算。

制定有效的預算是一個過程。以下是企業通常採用的四個層級的預算：

第一級:沒人做預算

在一間新創公司的會議上，團隊被問到如何定義雲端支出的預算。答案是：我們沒有預算。我們不想限制工程師。” 這家公司也意識到他們的支出遠遠超出了他們的意願。該公司已經制定了未來三年每年在雲端上花費多少的計劃，但由於該計劃沒有落實到負責消耗雲端資源的各個團隊，因此他們已經遠遠超過了原來的預估了。在這種情況下，他們完全忽視了預算，甚至視而不見。

第二級:用去年的歷史紀錄來做預算

一家企業的預算流程非常簡單，就是盡量控制在公司上一年的支出範圍內──進行靜態預測並用它來制定預算。儘管從表面上看，這似乎是一個很好的起點，但它並不是基於對企業的雲端費用支出是否花在刀口上。這跟政府預算非常相似，它鼓勵團隊花掉所有預算，這樣他們明年就不會失去預算，從而產生了錯誤的動機。

這種類型的預算（「第一步先止血」方法）實際上對於阻止失控的雲端支出相當有效。 但它不會帶來節省或任何與業務目標相關的有意義的雲端費用衡量標準。這類似於過去資本支出密集的地端機房採購中的預算制定方式。我們檢視了當時擁有的資源以及剩餘的容量，但無法深入了解所使用資源的實際效率。

第三級: 成本削減目標

成本削減目標根據滾動式預測檢視預測支出，然後將其減少金額。它們可以為團隊提供正確的激勵，但它們通常是隨便指定的(沒有經過分析)，並且與任何特定的業務成果無關。一家電商的目標是減少整個組公司的支出，並為其每個團隊設定了減少 30% 的成本支出目標。這個目標相當容易實現，因為這是團隊給出的第一個最佳化目標。畢竟，“被衡量的東西會得到改進。” 正在運行的機器可以完全終止，未使用的儲存閒置，並且有很多機會調整資源大小和購買 RI。隨著時間的推移，成本扣除方法開始出現問題，原因有二。

後期的節省通常不如一開始那麼顯著，這導致公司對 FinOps 本身的價值產生疑問
對總體支出的關注可以開始推動成本削減，從而影響系統效能或價值的其他面向

第四級: 單位經濟的效能指標

在這一級，公司開始將雲端支出與實際業務成果連結起來。如果業務正在成長並且正在雲端擴展，那麼花費更多的錢不一定是壞事。如果了解服務客戶的成本並持續降低成本，則尤其如此。正如我們現在所知，將支出指標與業務指標連結起來是 FinOps 旅程中要實現的關鍵一步，也是與基於驅動因素的預測的直接連結。任何人都可以看到單位成本是上升還是下降，但他們不知道為什麼，所以他們無法告訴你為什麼。為了真正使分散式團隊能夠影響他們的支出，基於活動的成本計算是最後一步。

最終，重要的是，每個負責支出的人都了解他們如何在期間內追蹤預算計劃。這可以讓他們儘早知道，如果情況出現問題，需要進行哪些修正才能達到目標。過度費用支出不只是問題:對財務團隊來說，支出不足可能同樣糟糕，因為這意味著預算本來可以用在有用的地方。

為了最好地駕馭這艘船，工程領導層需要在遵守計劃和競爭優先事項方面為組織做出盡可能最好的權衡。這意味著明確傳達有關權衡選項的策略優先順序以及它們預計將如何影響預期雲端支出資料的指導。

結論

即使對於最成熟的雲端財務運作實務來說，準確的預測也是一個挑戰。無論我們採用哪種方法，都應該預期時間線越接近，準確性/特異性就越高。下個季度的信心應該比兩年後高很多。我們可以對預測雲端費用支出的方式進行一些變更，以便產生更可靠預測的最佳機會。總結本文:

不要使用靜態預測；選擇滾動預測模型。
基於驅動因素的預測與可以處理季節性和異常的預測相結合，可以提供最佳的基線預測數據。
精細預測對於 FinOps 很重要，但需要保持摘要預測的一致性。
從傳統 IT 預測過渡到雲端費用支出的預測需要讓所有角色積極參與預測過程。
根據技術和 FinOps 團隊的回饋增強系統產生的預測。並非每個數據點都在歷史數據中可用。
預算應由預測驅動，並定期傳達給技術團隊，並就遵守預算和實現其他業務目標之間的預期進行權衡提供指導。