雲端運算的批發折扣策略

在我們搞清楚雲端的批發折扣是甚麼之後(AWS/Azure稱RI/SP, GCP稱CUD/Flexible CUD)，接下來其實有一些棘手但也是重要的問題是:

• 我們要預購甚麼樣的雲端資源?
• 預購的時間是何時?
• 誰應該參與整個過程?
• 我們要怎麼知道我們的批發預購(RI/CUD)能得到很好的利用而沒有浪費?
• 我們要怎麼知道何時應該進行重新採購?
• 誰應該為雲端資源付費?
• 我們如何在預購的租約期間內分配成本和省錢?

不幸的是，以上這些問題沒有標準答案。每個公司都必需因時因地的制宜才會有上述問題的答案。隨著 FinOps 的成熟、CSP 不斷的會更新它們的預購模型以及我們公司的現金流發生變化，這些答案可能會發生很大變化。

常見的錯誤

以下是一些企業在進行預購(RI/CUD)時會常犯的錯誤，它們是:

• 對預購的採購推遲太久
• 採購過於保守
• 用基於insatnce的量(也就是地端機房買機器的思維)來採購，而不是用收支平衡的方式
• 對預購後的資源不進行管理
• 買錯了

不過沒關係，幾乎每個人都在早期的雲端策略的某些部分出錯。 這是FinOps的爬行階段。 我們可以把它想成學習騎腳踏車或編寫我們的第一段code — — 這是一個學習過程，可能需要幾次嘗試才能正確完成。

建立預購策略的步驟

以下是五個關鍵步驟讓我們建立我們第一個預購策略：

1. 學習雲端預購的基本知識
2. 建立一個可重複的採購流程
3. 定期與非定期性的採購
4. 測量與迭代(Measure and iterate)
5. 正確的分配預購的成本

以下是每一個步驟的詳細說明．

1.學習雲端的基本知識

如果組織的相關人員已經有的基本的雲端預購知識．哪麼基本我們已經可以加速這一個步驟了．不過，這裡我們仍有幾個概念需要再說明．第一個就是預購成本的收支平衡點．如果我們不想記得本節的其他內容，請永遠不要忘記這一點：

當我們進行預購承諾時，它(CSP)的一年不是我們的一年並且它的三年也不是我們的三年．

我們預購的租約期間是從跟CSP購買的哪一刻算起的，但是我們不需要真正使用 RI 這麼長時間來進行的採購是具有財務上的意義。即使對於雲端運算的狂熱者來說，三年的租約似乎也有點長。 在某些方面，它違背了我們對雲端的熱愛的優點：just-in-time, scalable, on-demand usage。 但是，對CSP來說，一到三年租約可以節省大量資金，並徹底改變雲端運算的經濟性，嚴格來說對我們(企業)是有利的。

1 年的租約可能會在短短 4–6 個月內的達到收支平衡，而 3 年的 租約可能會在短短 9–12 個月內收支平衡。 在我們的組織中共享這些收支平衡點的資料可以幫助減輕對我們選擇雲端預購租約的恐懼。 讓我們分解預購收支平衡點的各個組成部分。

預購收支平衡點的各部分
下圖顯示了雲端資源在一年內的累積成本，包括on-demand資源和預購資源。 在範例中，預購費用我們事先預付了 300 美元，這就是為什麼預購的這一條藍線開始超過 300 美元。 如果我們使用“無預付(No Upfront)”的預購，那麼它將在on-demand 這條綠線下方開始。 如果我們使用“一次付款(All Upfront)”的預購，它將以預付成本的值繪製為一條藍線。

預購的現金流

現金流收支平衡點(cash flow break-even point)是預購讓我們花費與使用on-demand費率相同的時間點。出於顯而易見的原因，有些人將現金流收支平衡點稱為交叉點(crossover point)。 我們不再為現金流收支平衡點的預購再付錢。 但是，我們將繼續支付預購的持續（每小時）費用。 如果我們在現金流收支平衡點時停止使用雲端資源，將導致我們損失等同於on-demand費率的金額。

總體預購成本收支平衡點(上圖的Total RI cost break-even)是我們使用雲端資源的on-demand成本高於預購的總成本。 這是真正的收支平衡點，因為我們可以停止運作與跟我們預購所匹配的任何雲端資源，並且我們不會比我們沒有進行預購會更糟。 我們將會支付的on-demand資源是與預購相同的費率。 在收支平衡點之後，我們從預購中實現了省錢。

On-Demand的這條線與總體預購成本收支平衡點之間的差異是預購所帶來的省錢。 重要的是要了解，使用上圖，無論我們是運行一整年(12 個月)的預購相匹配的資源，還是在此期間運行許多不同的匹配的雲端資源，都無關緊要。

如果我們將我們雲端資源使用量加總後套用我們預購的折扣批發費率，則我們可以將預購的總成本與on-demand費率為相同雲端資源使用量支付的總成本進行比較。 這種比較將告訴我們何時達到收支平衡點以及我們已實現的省錢。

要點如下：大多數情況下，有良好計畫的預購會比我們預期的更快達到收支平衡。 當談到預購策略時，真正的挑戰通常不是決定首先購買什麼，而更多的是讓我們的組織在如何購買預購批發方面保持一致。

批發折扣的平衡點

如我們已經知道的，我們不會為特定的insatnce購買預購，也無法確定預購折扣將用在哪裡。 預購折扣將是以非確定性地套用於與預購標準匹配的雲端資源。

如果我們是成功的利用了雲端的彈性，我們將在一天/一周/一個月內擁有不同數量的雲端資源使用量 — — 在離峰時間較少，而在高峰的時間則更多。

下圖顯示了在一段時間內的一些雲端資源使用情況。 如果我們購買了四個 預購量，則它們每個的使用率都為 100%； 第五個 預購將有 90% 的使用率； 第六個預購，80%； 等等。 如果預購為我們節省了 25%，那麼與On-demand成本相比，為了省錢，我們需要在超過 75% 的時間內使用預購的折扣。

購買七次的預購，我們將為第七次預購支付比on-demand費率更多的費用，因此任何超過六次預訂的雲端資源使用都省不到錢。

在第4–8的row中，可以將單個預購套用到不同的雲端資源。此外，這些資源可能來自我們的雲端資產中的不同帳號。正是這種資源共享 — — 以及隨之而來的規模經濟 — — 使得集中式的預購成為 FinOps 最佳實踐的核心原則。如果是每個團隊自行進行預購，組織最終可能會得到錯誤的預購數量。在 Google 中情況較少，CUD 不在專案之間共享。無論如何，我們已經看到最好將費率優化從技術團隊的日常工作中分離出來，以便他們可以專注於優化雲端資源使用率。

採購單位的新角色是成為一個戰略採購部門，確保我們的公司通過預購和協商定價獲得最佳的資源消耗率。

2.建立一個可重複的採購流程

建立預購折扣策略的第二步是構建一個可以定期重複運作的流程，以盡快做出正確的購買決策。 為什麼這很重要？ 因為雲端就是即時採購(沒有lead time)。 我們只在需要時啟用資源。 同樣，我們應該在需要的時候進行預購：不要太早也不要太晚。

為此，我們需要知道誰將參與這個過程，在採購提交之前需要考慮哪些決策標準，以及簽核過程是什麼樣的。考慮將此收編到公司政策中，概述誰負責，怎麼批准的，理想情況下，是預先批准的"用於固定數量的預購量"的流程。

我們在雲端中的基礎設施應該是流動的：快速變化的instance types，migrations，elasticity，usage spikes等等。我們應該通過快速調整預購來支援這些變動。我們可能需要每月都要預購以跟上變化的速度，而且我們幾乎肯定會更頻繁地更換、修改和調整我們的雲端投資組合。

因此，我們的 FinOps 團隊中應該有一個專職人員負責預購流程。我們有時稱此人為預購主管。他們需要深入了解 雲端預購的作業原理，並對運作雲端資源的團隊是熟悉並互動頻繁的。他們需要與財務、技術和高階管理團隊互動，以履行承諾。通常，此人是 FinOps 團隊中具有技術頭腦的業務分析師。

為什麼要有主管？簡單的答案是，他們可以為公司節省 10–40% 的雲端費用。更細緻入微的答案是，決定何時購買以及購買多少預購量的工作通常不是由專注於有效運行資源的技術或營運團隊完成的。請記住，我們希望建立職責分工，其中 FinOps 團隊針對降低費率進行優化，而產品或應用程式團隊針對減少使用雲端資源進行優化。

3.定期與非定期性的採購

雲端運算是專為即時採購而設計。 我們不應該以地端機房的方式運作基礎設施或購買機器(容量)。 多年前，AWS 在其官網上有類似於下圖中的圖表。 左邊的圖表顯示了我們必須在地端機房和硬體方面購買容量的方式，其中充滿了硬體的限制和較長的交付週期。 右側的圖表顯示了在雲端中運行基礎架構的理想方式：在需要時啟動它。 進行預購也是如此。

4.測量與迭代

有很多關於錯誤購買預購的公司的可怕故事。 為避免這種常見錯誤，請確保我們的初始預購量很小。 我們應該仔細設置帶有thresholds的指標。 這些可以從簡單的措施開始，例如保留應該保留的資源的百分比。 相反，我們應該追踪現有預購的浪費（或空置）量，以確保它們被最大限度地利用。 有關用於管理預購的指標的更多資訊，我們將在其他文章中介紹指標驅動(metric-driven)的成本優化。隨著我們對流程的信心增強，我們就可以增加購買的頻率和規模。

5.正確的分配預購的成本

我們有在其他文章中介紹了配比原則，即費用應在組織得到價值的期間入帳。 如果我們對預購先給錢，即使是部分支付，它會在很長一段時間（一或三年）內為我們的雲端資源提供折扣，並且我們需要在整個期限內分配預付款。 分配預付款稱為攤銷。 對於 AWS 等一些CSP，我們可以選擇對預購的資源一次全部付款、部分或不預先支付任何費用。 我們提前支付的費用越多，預購折扣就越高。

決定是否預先付款需要兩個主要考慮因素：

會計
第一個受影響的就是會計流程．我們在之前的文章中有強調，預購的折扣是隨機的分配到我們的雲端資源中．如果我們需要將部分預付款掛帳給一個團隊，另一部分分配給另一個團隊，我們將需要準確追踪預購套用的折扣的是在哪個資源，然後相應地進行攤銷。

細致度
我們不能只將預購分成每個月都是相等的。 並非所有預購都是在當月第一天的第一個小時去採購的，而且 2 月天數比 3 月短 10%，因此攤銷需要更精細的方法。

中心化控管式的預購模型

成功的 FinOps 團隊集中了預購的購買流程。預購很複雜，我們需要有控制專家（前面提到的預購主管）。讓一個團隊負責組織內所有預購的分析、批准、購買和管理將確保效率和準確性，進而實現最高水準的省錢。如果我們的團隊單獨分析他們自己對雲端的使用，他們經常會弄錯，或者他們可能會在購買的預購上加倍。

由單一團隊管理的預購只能考慮自己這個團隊的使用情況。單一團隊在預購時考慮的使用高峰和低谷將排除可能很好資源使用的覆蓋率。當我們的一個團隊減少雲端資源使用時，另一個團隊可能會同時增加使用量，從而導致整體使用量持平。就單一團隊而言，似乎沒有足夠的雲端使用量需要預購。但是組合所有團隊的使用量，預購可以為組織省錢。從組織的視角考量所有團隊的使用情況，將為組織帶來更高的整體省錢率。

現在很清楚的是，預購很複雜，而且隨著每個CSP不斷發展其產品，他們很可能會變得更加複雜。讓組織中的各個團隊考慮產品的變化並更新他們自己的雲端資源分析和採購流程是低效的。這將導致團隊錯誤地執行預購，並最終使組織付出更多代價。

為了減少單一團隊管理自己的預購的需求，FinOps 團隊必須提供對每個團隊資源適用的折扣以及所實現的總體省錢的可見性。如果沒有這種可見性，團隊將傾向於保留自己的雲端資源使用量以節省開支。當我們在集中式預購模型中運作時，讓分佈式團隊進行預購是危險的，因為我們最終可能會過度使用資源而享受不到預購的折扣。

集中式預購模型並不一定會阻饒單一團隊對預購發表意見。 FinOps 團隊應該要有營運團隊計劃實施的roadmap item，尤其是在這些變化將影響雲端資源使用的情況下。當預購可以轉換或交換時，需要單一團隊的較少意見，因為 FinOps 團隊可以在需要時轉換預訂。如果無法修改預購，則應讓擁有所涵蓋資源使用的各個團隊有機會對所做出的預購發表評論。讓負責的團隊了解預購以及這對他們的雲端資源使用意味著什麼，確保他們在計劃將來對資源使用進行任何變更時將預購考慮在內。

預購的時間點

關於時機點，我們需要了解過早買與晚買的影響是重要的。如果我們提前預購，我們將支付預購費用，而不會對我們的帳號套用任何折扣。如果我們預購的使用量超過最終需求，我們將支付整個租約期限（一年或三年）的預購費用，而根本沒有任何省錢。但是，如果我們等待的時間過長，我們將用on-demand的費率來付錢，並且會錯失如果我們早些進行預購本可以省到的錢。

為了更好地理解這一點，下圖顯示了雲端帳單中的一些資源使用情況。如果我們在 1 月份購買了為期一年的預購，我們最終將支付 3 個月的預購費用而沒有獲得折扣，浪費了 25% 的 預購（3 個月/12 個月）。 4 月開始使用時，我們將立即收到這個資源的的折扣率，直到年底。如果這次預購沒有為我們節省超過 25% 的費用，那麼我們在年底支付的費用將比您完全不進行預購時支付的費用更多。

相反，如果我們一直等到 9 月才進行預購，我們最終會以全額on-demand費率支付五個月的費用，從而錯過我們本可以實現的省錢。大多數公司開始時按固定時間表進行預購，例如每年、每季度或每月。當有一個固定的時間表時，公司很容易在每個週期內過度使用以實現最大的省錢。

例如，一家每年進行預購的公司可能會租下比他們需要的多 30% 的預購。這個想法是，隨著時間的推移，他們的支出會增加，備用的預購將立即開始套用折扣。然而，在今年上半年，該公司為這些未能套用折扣的額外預購多付了錢。如前面的範例所示，這些預購套用的折扣可能永遠不會超過未使用的預購成本金額。

通過提高我們執行預購的頻率，您可以減少full on-demand費率收費的時間，並且我們還消除了過度使用預購的誘惑。然而，以更快的速度執行預購有幾個障礙。我們分析我們現有和需求的預購量所花費的時間可能會減慢執行預購的頻率。如果我們的CSP具有內建的自動建議服務，可以就預購的內容提出建議，那麼這是一個很好的起點。隨著我們的 FinOps 團隊成熟，使用我們自己刻或第三方工具和分析這些將有助於提高建議的品質並加快分析過程。

何時調整資源大小與資源預購

我們在這篇雲端資源的優化 — 用得更少文章中看到了資源調整如何影響預購。因此，許多人認為最好的方法是先調整資源大小，然後再預購。儘管這種方法聽起來很正確，但它並不正確。它總是通過不必要的on-demand費用導致失去省錢的機會。

資源調整很困難，可能需要很長時間。它需要技術團隊參與進來，接受有關雲端成本的教育，並接受做出改變。它不會在一夜之間發生。通常，技術團隊專注於交付功能，不能直接跳進去做資源使用優化。通常需要六個月或更長時間才能將工程師轉變為將成本視為效率指標的文化。同時，如果我們不預購任何東西，那麼您將在很長一段時間內不必要用到on-demand費率。而且，當調整規模確實發生時，通常是一個漸進的過程，而不是一個大爆炸，因為工程師開始將優化納入他們正在進行的過程中。

當他們的 FinOps 實踐不成熟時，公司所犯的最大錯誤之一就是等到他們“完成”調整資源大小後才進行資源預購。請記住，我們多次完成整個 FinOps 生命週期，每次都進行最關鍵的優化。

減少使用的爬行階段可能是擺脫未掛上VM的storage volumes，或者關閉Dev/stage帳號中 100% 的閒置機器。費率降低的爬行階段可能是購買我們的前 10% 的預購覆蓋範圍（如果我們使用 AWS，甚至可能使用“No upfront”RI）。在每一個上走和跑都需要跨職能、跨團隊的協作和大量的教育。

最好的方法是為兩者設定保守一點的目標，並從一開始就開始平行執行流程。我們的整個雲端運算費用的很大一部分不太可能被浪費，因此可以調整資源大小。因此，我們可以通過預購安全地覆蓋 50% 的基礎架構，尤其是當我們的雲端資源使用量由於雲端遷移或新的應用程式而隨著時間的推移而增長時。

剛開始時，我們應該設定一個小的預購覆蓋率目標，可能是 25–30%，並預留一部分雲端資源，從而儘早實現省錢。隨著我們減少浪費，我們新購買的預購將適用於我們剩餘使用量的更大百分比。記住，insatnce大小靈活性 (ISF)、AWS 的可轉換 RI 和 Azure 取消 RI 的能力等方案為我們提供了優化基礎設施使用的空間，即使我們已經進行預購了。由於我們能夠衡量帳號中的浪費量，因此我們可以重新評估您的覆蓋目標並隨著時間的推移理想地增加它。在 走的階段，我們會定期預購，而技術團隊會定期清理未使用的資源並調整未充分使用的資源。當我們進行指標驅動的成本優化時，營運的階段就到來了。

建立我們的策略

無論我們用的是哪朵公有雲，預購的目標都是盡可能的省錢。 在制定預購策略之前，需要考慮一些事情。公司的profile將影響我們的預購策略。 我們還需要考慮我們對CSP的預購等級、我們可能需要考慮購買決策、支付流程、對成本分配的影響以及任何預付款的總體資金可用性的協商費率。

對CSP的預購等級

當我們在CSP的平台進行預購時，我們就是承諾會在他們那邊花費一定的金額。 這個承諾可能需要預付費用和按小時收費。 當我們將整個租約期限內的所有費用結合起來時，我們就得到了總預購成本，即我們承諾與我們在這朵雲所有的總費用。

三大CSP(AWS/Azure/GCP)都允許我們承諾一年或三年甚至五年的預購，更長的租約可以讓我們節省更多。 要在這兩個選項之間做出決定，我們需要考慮我們對CSP的承諾。 我們在此期間減少雲端資源使用的可能性有多大？ 假設我們預測我們不太可能在未來 24個月內搬到另一朵雲，但我們對未來三年的承諾缺乏信心。 在這種情況下，我們不應該承諾三年的預購。 如果我們在完整的三年任期之前停止，我們就無法有額外的省錢。

資本成本

雖然預購可以省錢，但它們確實需要可用的現金來支付預付費用。對於一些公司來說，這不是問題，而對於其他公司來說，這可能會讓公司的其他商業活動無法進行。一些公司需要在特定時間段內花錢，例如必須在財政年度結束之前消耗預算的時候。

在有資金的情況下，我們看到經驗豐富的 FinOps 專家會考慮加權平均資金成本 (WACC) 和現金的淨現值 (NPV)。這些計算確定了將業務資本用在於前期預購是否是一項良好的投資，而不是其他可能的投資。雖然不預先付款的折扣較低，但在業務的其他地方投資一些錢可能會產生更好的財務結果，這就是企業必須評估的機會成本。

將 AWS 對“No upfront”和“Partial upfront”購買選項中的每一個收取的溢價視為等同於對我們(企業)借出購買的非預付部分的利息費用，並將該利息費用視為持有年利率。我們將此稱為“No upfront”或“Partial upfront”購買期權的隱含利率。

雲端資源的終端用戶(也就是企業)是否應該選擇“All upfront”或替代支付選項，取決於企業的 WACC 是低於還是高於CSP為推遲支付預購而收取的隱含利率。企業的 WACC 是企業的金融資本成本，以公司債務利息成本和公司股本成本的形式出現。確定哪個成本更高的過程包括分別計算“All upfront”和“No upfront”場景的購買現金流的 NPV。

該過程首先確定企業的 WACC。大多數企業都會有一個標準的 WACC 供財務部門用於此類決策，通常我們可以將此數字視為特定的。如果使用 Goal Seek 計算的折扣率（即調整輸入以實現所需的輸出）超過企業的 WACC，則客戶應購買“All upfront”預購。如果該數字低於企業的 WACC，則“No upfront” 購買選項的隱含利率對企業而言將比“All upfront”選項便宜。

紅區與綠區法

在大多數情況下，預購並不適用於CSP全球的region，這意味著它們僅適用於同一region（在某些情況下，可能適用於同一AZ）。 此外，它們僅適用於匹配相同屬性的資源。考慮到這一點，預購通常不會在資源低度使用region購買。 在使用率低的region預購有預購覆蓋率低的風險，因此會多花錢而不是節省成本。 同樣，為老一代的insatnce type 進行預購也有類似的風險。

當團隊在這些Region構建基礎設施和(或)使用被認為風險太大而無法預購的instance type時，他們將不會獲得任何預購折扣。 HERE Technologies 的雲端首席業務分析師 Dave Van Hoven 有一種方法來構建這些預購盲點的可見性，這使工程師可以就如何構建它們做出明智的決策。

紅區/綠區法是向企業內部發布有關locations和insatnce type的資訊，這些資訊將由中心化 FinOps 團隊（綠區）自動計算到預購清單中，以及不會涵蓋的location和insatnce type無需詢問 FinOps 團隊（紅區）即可預購。

綠區
綠區是工程師最容易的區域。 選擇使用更新和常見的insatnce types進行構建，然後部署到整個公司最常使用到的CSP Regions，也就是公司離客戶最近的地方，使工程師能夠在日常作業中忽略預購這個因素。 這個綠區有助於將工程決策納入企業最需要支援的區域。

紅區
紅區要求工程師要嘛自己管理他們的預購，要嘛與 FinOps 密切合作來進行預購。 技術團隊的基礎設施的任何變更都將始終要求他們考慮他們對預購做出的額外的購買，因為預購不太可能被修改給其他團隊使用。 紅區需要工程師投入更多時間與精神，這導致技術團隊無法專注他們的功能交付。

禁止區
綠區/紅區的概念有一個延伸稱為禁止區，它清楚地說明了公司不會批准購買的Region和預購類型。 這可以用來描述工程師不應該在哪裡構建基礎設施。

紅區/綠區法清楚地說明了集中式預購實踐的工作原理。 它向技術團隊展示了預購不會自動套用於技術團隊，並定義了將預購應用於模糊運用的流程。 應提供報告以強調由集中式 FinOps 預購流程（在綠區）與紅區產生兩方的效率和省錢。

採購批准

業務批准流程也有助於在非經常性的預購。 如果業務流程需要數週時間才能獲得批准，那麼每月執行預購就會很麻煩。 這就是 FinOps 可以通過建立用於執行預購的新流程來使業務受益的地方，並在理解與改進流程下可以更多地加速整個組織的業務進行。

有許多成功的公司將季度預算分配給 FinOps 團隊進行預購，只有在總體預購超過此預算時才需要額外的批准。 在大多數情況下，減少批准過程中涉及的人數和文書工作量會加快預購頻率。 我們將在其他文章中詳細討論指標驅動(metric-driven)的成本優化，在那裡我們將看到預先批准的支出金額如何導致預購的流程會自動的發生。

誰為預購付費?

批准 FinOps 團隊進行預購並不一定意味著他們會為預購付錢。 預購費用有兩個主要組成部分：預付款和按小時付費。 一些預購包含兩種：“全部付(All upfront)”和“不先預付(No upfront)”預訂。

對於任何預付款，費用應該做攤銷，因為預購已套用在我們的雲端帳單中。 然後，任何未使用的預購容量將直接從我們的帳單中扣除，並且不會從初始預付費用中攤銷。

一旦成本在月底正確的攤銷，我們將最終得到：

• 將在未來幾個月攤銷的剩餘預付款的預付款應計
• 當月發生的攤銷雲端資源成本（通過tags、labels和帳號分配的成本）
• 在計費資料中集中收取未使用預購的未攤銷成本

當 FinOps 團隊獲准進行預購時，他們會將資金加到預付款應計項目中。 就每月成本而言，這不是業務費用。 在會計中，這是一項業務資產，當我們將成本攤銷到雲端成本中時，它就會變成費用。 因此，FinOps 團隊不會將預購的採購回報為業務費用。

當使用tages、labels和account將成本攤銷到我們的雲端資源時，我們可以將預購成本歸因於我們的showback/chargeback成本分配流程，並像處理所有其他雲端成本一樣處理它們。

但是，對於未使用的預購雲端資源，費用將集中計費（記入購買它們的帳號中），並且需要一個流程來適當地分配它們。 以下是我們已經看到用於處理這種未使用的預購成本的四種策略：

基於帳號的歸因

如果預購是在團隊帳號內購買的 — — 接近他們打算套用折扣的使用量 — — 則可以根據購買預購的帳號分配未使用的預購成本。 費用分配給擁有該帳戶的每個團隊。

混和攤銷

將未使用的預購成本加到攤銷率中，未使用的成本與每個人為該預購所涵蓋的資源支付的費率混合在一起。 "這會使預購未覆蓋到的資源的費用變得跟on-demand 費率是一樣的"。 預購適用於哪些確切資源的可變性意味著有時資源會獲得折扣，而在其他時候則不會。 折扣分配的這種差異會使追踪團隊成本變得困難。 建議在執行 showback/chargeback 時使用資源混合費率。

資源混合費率

在這裡，我們通過在帳單中混合資源費率的總成本來建立一個新的資源費率。 這裡不是指“混合費率(blended rate)”的 AWS 計費資料概念，我們在其他文章中討論過。相反，這個概念採用與預購（On-Demand和預購）匹配的所有使用量，套用到預付款的攤銷和未使用到的雲端資源的預購金額，然後在所有使用情況中建立一個新費率。 這意味著使用某種雲端資源類型的每個人都將獲得相同的費率，無論是否在計費資料中套用了預購。 這實質是建立了公司自己的平均費率 — — 在on-demand價格和預購價格之間 。對於隨著預購覆蓋率而變化的每種雲端資源類型。 它避免了在任何預購費率套用的地方都有“隨機的贏家和輸家”。

儲蓄池

與財務部門一起建立一個流程，集中省下來的錢，使用on-demand費率進行所有報告、預算和預測。 技術團隊不需要考慮其使用的正確預購率，並且不可預測的預購應用已不再是問題。 所有節省的費用都會集中報告給 FinOps 團隊，從中減去未使用的預購成本。 此節省金額用作儲備預算，FinOps 團隊預計將節省一定的資金，並根據他們與已實現正確剩下來的金額相比後來衡量績效。 然後，這個集中式的儲蓄池以更可控和適當的方式分配給組織的業務。

分配預購成本的方法將取決於組織的業務流程，並且可能會隨著我們的 FinOps 實踐的成熟度而改變。

策略小提示

在建立我們的預購策略時，以下提示是有用的:

首先建立可見度
我們經常會一次又一次聽到這樣的故事：“我購買了預購，但我的帳單費用剛剛上升了。” 通常進行預購是為了阻止雲端成本成長，它們首先在組織內的雲端成本成長階段實施。 最有可能的是，雲端成本的成長大於預購能夠節省的費用，而且是在無法了解預購能節省多少的情況下，我們得到的只是不斷增加的雲端費用支出。

了解與預購的工作原理
我們在這篇文章雲端費用的省錢-運用RI與CUD有提到預購的複雜程度。 人們在進行預購時最常犯的錯誤是沒有正確理解它們，然後購買了不正確的預購類型，或者在錯誤的Region購買了它們。 當預購與我們期望的雲端資源使用不匹配時，可能會導致非常大的成本增加。

尋求幫助
FinOps 團隊活成員並不能獨自完成所有事情來證明自己。 我們需要會使用某種形式的外部援助。 FinOps 基金會本身就是可以幫助我們的外部資源。通過向同行學習、參加培訓課程、獲得認證以及與CSP的支援管道互動，我們可以確保我們的預購計劃最有可能成功。如果預購對我們的組織來說是新的，我們應該考慮使用經驗豐富的廠商來開始。

讓一個人嘗試建立我們的所有帳單資料處理、預購建議和報告只會延遲預購地採購。最有可能的是，建立這些建議和報告的延遲將阻止比 使用FinOps 平台的成本有更多的省錢。此外，這些第三方平台創建的報告由具有多年經驗的團隊維護，並已在數十億美元的雲端支出中得到驗證。

不要一次就想飛
當我們第一次開始FinOps的爬行階段時，最好我們只購買一個預購。這使我們可以通過低風險採購來確認我們的知識。在進行更實質性的購買之前，我們可以驗證是否已避免所有常見錯誤。試圖“一次就想飛”往往會導致失敗。我們可以考慮之前討論的紅區/綠區法，確定可以從預購中受益的最低風險的雲端資源使用，然後增加購買量。這是建立對我們的預購策略信心的好方法。

我們不應該拖延。雖然應該是慢慢開始，但甚麼都不做是一個主要（也是常見的）錯誤。試圖通過不進行任何購買來避免錯誤會導致CSP繼續過度收費。再一次，我們找到並且購買了一些低風險的預購，然後隨著我們開始看到這些省錢，繼續學習和發展我們的報告流程。開始時，建議將預購目標設定的低一點。考慮綠區中 25–30% 的預購覆蓋率。隨著信心的增強，向上修改目標。我們看到組織渴望的一個常見覆蓋範圍是 80% 的預購覆蓋率。

考量所有的衝擊
預購將在某種程度上是隨機套用於雲端帳單中。 因此，如果我們有現有的成本報告並且團隊密切追蹤支出，那麼當一個地方的支出下降而不是另一個地方的支出下降時，預購可能會造成混亂。 溝通預購的購買情況，並迭代的使用組織的業務報告以準確反映它們產生的省錢影響，是避免混淆的關鍵。

這些技巧是是需要我們刻在自己的腦袋中的； 但是，對於最重要的支援，使用經驗豐富的廠商，並利用 FinOps 平台來指導我們進行預購的第一步。

結論

管理預購雲端資源的 Finops 策略因組織而異。 但是有一些常見的做法可以有高效和管理良好的預購艦隊。 FinOps 團隊的集中管理是最重要做法之一。

總結一下：

• 我們應該使用所有可用的協助來建立我們的策略，並避免自幹。
• 我們必須在進行預購之前了解預購的作業原理並花時間建立可見度．
• 我們不應該延遲進行預購。 購買低風險的預購，然後建立我們的流程來提高覆蓋率
• 溝通對我們整個組織都很重要，以避免混淆誰在做什麼