雲端費用的財務指標

13 min readMar 14, 2024

企業在使用雲端時如如果沒有做好成本控管，哪麼在還沒有從雲端得到價值之前，成本就會失控了。我們要如何得知到使用雲端服務是否真的取得價值了呢?"指標(Metrics)"將是最清楚的資訊，因為指標告知我們目前的雲端財務狀況為何。

但是在有指標定義之前，我們必須要良好的指標策略。沒有良好的指標策略，哪麼指標資訊可能會變得"氾濫、重複、不具行動性、不夠直覺與不具通用性"。

指標策略治理是一項組織的整體策略，它定義要使用什麼指標、如何定義該指標以及誰負責該指標。這最終會產生一個為組織提供業務價值的指標。換句話說，如果指標不能帶來任何業務價值，那麼它很可能是不必要的。以下的問題可以讓我們能更確認組織的指標策略管理是否到位。

該指標由誰定義?
該指標的真實來源是甚麼?
該指標是怎麼產生的?
該指標的目的是甚麼?
如何衡量這個指標是否奏效?

記錄每個指標的這些答案可確保該指標確實的業務有用。這一類的記錄還可以幫助我們追蹤業務需求異動時的變化，以便我們可以看到指標隨時間的演變。我們將能夠追蹤指標的不同版本、更改時間、更改者以及更改原因。紀錄提供有關我們的成本和使用資料的metadata。 Metadata和cataloging對於任何希望成為資料驅動型組織的企業來說都是至關重要的。如果企業試圖透過為其營運、銷售和行銷數據建立健全的資料治理策略來從資料中發現見解。

指標治理框架的應用

組織通常有自己的指標治理的政策。而會有許多因素會影響指標治理的產生，例如組織規模、溝通方法、團隊組織以及雲端旅程的成熟度。然而，我們可以透過一個框架來概括指標治理的應用。

擁有成功指標治理的公司在該框架的範圍內運作，該框架由審核流程、標準化機制、"監控和報告"的間隔時間以及中央管理團隊組成。以下是每個組件：

審核流程

組織通常從審核流程開始，這要求審查所有指標以確保它們清晰且與業務功能相關。在這種情況下，業務功能正在透過消除不必要的支出或有效地使用所需資源來優化雲端資源的使用。

如果沒有既定的審核流程，我們就會面臨指標蔓延(metrics sprawl)的風險。當團隊可以建立、分享和報告其指標時，企業最終將遇到重複的指標、具有內容差不多但名稱不同的指標以及其他資料品質問題。

審核流程可確保指標指標剛剛好且夠。我們不希望出現這樣的情況：不僅無法了解自己在雲端環境中擁有哪些資源，而且還無法控制嘗試用於管理這些資源的指標。中心化FinOps 實踐可以定義企業將使用的指標並管理圍繞這些指標的metadata。

標準化

接下來，企業應該定義一種機制來控制或確定哪些指標可以而且應該標準化。 一種方法是建立一個指標的分層結構。應該標準化並在生產環境中使用的指標是第一層指標。這些是團隊在給C-Level的報告中呈現的指標，並在所有團隊之間共享。第二層指標在特定團隊內共享，因為它們僅適用於特定的敘事脈絡。一個簡單的例子是有效的rightsizing recommendation的數量。與技術和FinOps團隊相比，C-Level們不會關心這個指標。對於C-Level們來說，一個更有用的指標是由於rightsizing而節省的實際金額。第三層指標是尚未在生產環境中使用的指標，因為它們需要改進或因為它們在某個時間點不提供業務價值。

標準化指標在各層之間的移動方式或何時將其提升到生產環境有助於保持指標良好且足夠。透過良好的治理，我們可以使用報告中最有意義的指標與適當的利害關係人分享。如果沒有這種機制，團隊可能會建立重複的報告、更改現有報告，並且可能不會刪除不需要的報告。這有助於減少不必要的報告重複，這種報告困擾著許多組織，以至於大多數人最終因大量的噪音(無異議的資料)而忽略了這些報告。

監控與回報的間隔時間

最後，企業應定義監控和報告的間隔時間。這可確保定期檢視報告和指標的使用情況。如果不進行審核，隨著時間的推移，某些指標和報告可能會變得陳舊且毫無意義。 隨著業務需求的變化，定義滿足這些變化的需求是否成功所需的指標也會改變。 這還可以幫助團隊確定哪些指標應該棄用或升級到生產環境。

這些努力可協助企業定義、管理和批准用於為其 FinOps 實踐提供資訊的指標。 如果沒有清晰的流程，"成本和使用(cost & usage)"指標就沒有意義，也無法為團隊提供行動所需的資料(What’s up 之後是What’s Next)。定義和推廣企業內所有團隊遵循的指標治理架構是中央FinOps 團隊的一項職能。假設團隊是多元化的並且由技術、財務與FinOps的角色組成，那麼中央 FinOps 團隊中的角色將擁有成功完成此任務所需的業務、技術和財務專業知識。

指標策略角色的任務

會有以下三種角色來運作組織的指標策略:

財務:
驗證業務資料、提供來自雲端之外的資料、協助定義KPIs
FinOps:
定義指標治理、定義與回報指標、向所有利害關係人回報指標
技術:
驗證雲端資源的使用、堅守指標治理、承諾KPIs的使用

財務角色對於驗證 KPI 至關重要，因為它們不一定與雲端支出相關。企業將投資於雲端以外的其他專案，例如研發、行銷和人員發展。財務人員擁有為 IT 以外的其他領域定義 KPI 的經驗，可為中央FinOps團隊帶來寶貴的經驗和見解，以確保雲端支出的 KPI 對組織的業務有價值。

財務角色帶來了廣度，而技術角色則帶來了 IT 領域的深度。具體來說，技術角色驗證並提供來自雲端的使用資料。財務角色無法像技術人員一樣每天關注雲端使用情況並能解釋雲端帳單上的計費項目。技術角色可以定義 FinOps 領域脈絡中的指標。

前面兩種角色將為 FinOps 角色提供資料與意見。 FinOps 角色將領導使用所需指標定義儀表板、路線圖或報告框架的流程。 FinOps 角色最終負責將這些指標及時交付給所有利害關係人。

以上三個角色都參與指標審核流程。每個角色都運用自己的領域知識來決定哪些指標是有意義的，並為相關利害關係人帶來價值。一旦獲得批准，除了確定指標負責人和建立指標的過程之外，他們還可以標準化組織產生指標的方式。然後，根據利害關係人的需求，決定監控和報告的間隔時間，以及讀者何時以及如何收到報告。

這些角色擁有這些指標的治理權。他們本身可能並不負責所有指標，但他們充當定義如何使用指標、如何在整個企業中共享或呈現指標以及誰負責指標的看門人。

定義正確的指標

建立對我們自己公司有意義的雲端指標可能對其他公司毫無意義。與指標治理框架一樣，指標本身與每個組織的業務脈絡相關且範圍特定於該組織。因此，我們不會建議具體的指標，而是提供一個可用於定義業務指標的框架。透過這個框架，有五個問題來證明指標的存在和使用的合理性。我們可以將這些問題視為一種試金石。

指標發展的五個考量

第一個問題是這個指標是否具有實質意義。換句話說，該指標的雲端＂使用和報告＂是否會帶來行動(What’s up 之後是What’s Next)？這個問題本質上證明了該指標在帶來業務價值方面的重要性。指標應該要對組織產生影響。

許多組織在這方面使用的常見指標是總體支出與收入比率(overall spend-to-revenue ration)。這是衡量雲端總支出與系統/服務總收入的比率。

從表面上看，這個指標可能沒什麼意義，或者它提供的視圖可能過於籠統。但是，我們需要實施了強而有力的指標治理。在這個假設下，我們已經建立了良好的治理，並且可以定義該指標輸入的真實來源。透過這樣做，員工們可以依賴該指標並將其用作通用語言。此指標的通用適用性也意味著它考慮了組織中的所有雲端成本支出，並隨著時間的推移進行調整。

第二個問題是該指標是否是動態的。如果我們使用靜態指標來報告雲端的動態使用情況，就會出現很大的不匹配。儘管在某些情況下可以證明靜態使用（例如 RI 或 SP）的合理性，但大多數雲端使用都是動態的。事實上，靜態使用量量測是更廣泛的雲端資源動態運算使用的特定組成部分，通常，動態量測比靜態量測提供更多資訊。

永遠不會改的指標無法向組織傳達任何有用的資訊。處理指標的正確方法是增加動能，使它們更有用。一個例子是未標記資源的支出率指標，它呈現與無法進行成本分配資源與有成本分配的雲端支出百分比。只有當整個組織中擁有強大的標籤治理策略時，此指標才有意義。與高使用率高峰期相對應的未標記支出率可以提供非常豐富的資訊。

判斷指標是否動態的一個有用的衡量標準是，組織內的人員是否會忽略它的存在。這就像我們每天路過一個警告標誌，警告地板濕滑。大多數時候，地板上沒有水，但有人只是忘了把標誌拿掉。如果我們養成了看到該標誌並期望沒有水存在的習慣，那麼該標誌就失去了它的價值。同樣，如果一個指標只是存在並被掩蓋，那麼它也會失去其價值，應該被丟棄。我們需要能夠吸引讀者注意力的指標，因為這對他們和企業都有意義。

要問的第三個問題是該指標是否易於理解。這限定了指標的清晰度。換句話說，如果指標令人困惑或難以理解，它就不會為組織帶來任何價值，並且可能會導致更多麻煩。考慮該指標的一種方法是看看是否可以使用小學程度的數學來重現和計算它。如果沒有，請嘗試使用更簡單的方式來傳達訊息和指標的預期含義。有時，指標本身的術語可能無法概括指標的預期含義，但指標的相關描述應該能夠闡明其含義。

我們以系統/服務支出與交易比率為例。該指標本身可能會讓人疑惑，但我們可能擁有指向該指標的metadata，將其描述為特定於系統/服務的雲端支出與已識別需求驅動因素（例如同一時期內的交易量或API 呼叫數）的比率。該指標可能涉及特定的技術主題，但它並不太複雜，我們可以在看了之後 30 秒內對其進行解讀。

第四個問題有助於確定指標本身是否產生行動。這不會讓成本優化作業的指標是好玩有趣的，但會讓組織變革的指標有價值。如果我們看到的指標無產生行動，那麼我們應該質疑其使用。

一個範例指標可以是諸如運算資源調整建議之類的指標。如果調整建議中的指標顯示透過調整資源規模或終止閒置資源而預估每月節省的成本，那麼它就提供了團隊可以採取的具體行動來實現這些節費。並非所有指標都會如此簡單。在開始行動清單之前，某些指標可能會產生兩個或三個額外的指標，但所有指標都應產生可行動的見解，指導團隊進行最佳化。

最後問題是，如果我們要刪除該指標，會有人錯過它嗎？這證明了該指標的稀缺性。這種品質可以幫助我們減少對組織有用的指標數量。我們試圖避免的模式是讓組織淹沒在一堆指標中；避免出現過多的指標雜音，導致利害關係人對指標失去興趣和信任。

指標的數量應該與團隊或組織中的人數成反比。例如，對於少於 5 人的團隊或組織，我們希望最多保留 20 個指標。這適用於日常維運指標的人員。這也是為了阻止指標蔓延，但僅將其視為指導方針。相反，對於包含超過 30 人的團體或組織，我們希望將指標限制在 5 人左右。這尤其適用於在會議室中呈現指標。與呈現 20 個指標相比，呈現 5 個更重要的指標將有助於更集中的討論。主要想法是應用適當的指標治理，以確保您的企業保持指標感清且足夠，例如保持適當的雲端資源的正確使用。

雲端指標範例

以下是一些組織已經運用在雲端支出的指標清單範例，並且我們會定義與解釋，我們可以從組織的特定業務需求來對這些範例指標進行變形或也能直接使用(如果您的組織適合的話)。

帳單趨勢率

這是一個起始指標，顯示雲端隨著時間的推移的支出趨勢，也可以幫助我們識別意外的行為。每一個CSP都有提供其工具可以查看這一類的指標，例如 AWS Cost Explorer 可以查看一個區間內的雲端總支出。也可以使用它來查看每日、每週、每月和每年的支出，或之間的任何時間區段。

未標記的支出率

這是雲端支出的無法直接分類的比率，意思是沒有成本分配標籤的資源。這個比例越低，就能卻抱組織所花費的每一元都符合業務目的。我們的目標應該是透過成本分配標籤來最大化資源數量。設定目標（例如將未標記支出率保持在 1% 以下）可確保最大限度地減少浪費。例如在AWS中可以使用Tag Editor 和 Cost Explorer 分別套用和檢視已經有標籤的資源。與此類似的指標可以是未標記的資源，這些資源沒有成本分配標籤的雲端資源數量。

未分配支出率

這個指標是指該資源找不到家的。意思是還未將這個雲端成本指派給業務部門、產品線、負責人或任何其他所需標籤的 AWS 總支出的百分比。這為您提供了集體責任並管理雲端支出showback/chargeback。這也鼓勵團隊保持良好的財務紀律。

運算資源調整機會

這個指標顯示了透過調整未充分利用的資源規模和終止閒置資源而預期每月節省的費用。這個指標確保團隊只使用他們需要的東西。許多CSP都會免費提供這一類建議系統，因此不需要話太多時間即可開始使用。我們可以確保團隊在每月審核期間遵循調整規模建議，並由技術團隊進行評估。集中的 FinOps 職能將負責協調這些會議並促進討論。

承諾使用率與覆蓋率

這些是每個正在使用對CSP長租資源的使用百分比率(如AWS的 RI 和 SP )。我們一定希望最大化使用率，因為任何低於 100% 的使用率都意味著我們沒有使用雲端資源但還是需要付費。例如AWS Cost Explorer 的使用率報告可以幫助追蹤該指標。另一方面，100% 的覆蓋率可能並不理想，因為您不一定希望所有運算資源使用都會用到長租的資源，特別是在的工作負載尖峰或不可預測的情況下。

非生產環境費用

此指標顯示非生產環境的雲端資源與適用的 24/7 總支出的比率。換句話說，非關鍵雲端資源（例如測試、stage和開發環境中的資源）可以而且應該安排為只在上班時間運作。

現代化資源的運用率

這更多的是一種標籤策略，我們會需要隨時隨地來注意各家CSP所發布的新服務是否合適的用在我們的系統/服務中。例如CSP採用了新一代的硬體來運作資源。新一代的硬體往往具有更低的成本和更好的性能。因此，在其他條件相同的情況下，只需將我們的系統/服務升級到新一代硬體即可幫助我們實現成本節費。透過標記資源來幫助我們識別系統正在使用的是哪一世代的雲端資源，我們可以將這些資源與 CSP 提供的最新一代產品進行比較。了解 CSP最新一代雲端資源的公告是其中一個重要的部分，可以由中央 FinOps 職能部門來領導和溝通。

預測變異(forecast variance)

這個指標衡量當進行預算作業時與實際值與預測值之間變化的百分比。這可以在我們想要的時間範圍內（每月、每天等）完成。預測有助於團隊之間設定正確的期望。預測變異等指標有助於避免費用會讓老闆嚇一跳，或當實際成本超過預算金額時出現不必要的情況。

帳單讓老闆嚇一跳的頻率

如果我們正處於雲端的成本和使用量相對穩定的階段，我們可能需要計算實際值超過設定閾值的頻率。我們應該能夠相當程度地控制組織的雲端支出，並且最好避免任何意外。我們可以將此頻率設為指標，並根據觀察到的行為重新校準它。例如 AWS 有Cost Anomaly Detection來協助產生這些報告。

整體支出與收入率

這可以呈現組織在雲端中的成長是否與組織的利潤相關。該指標是一個很好的起點，但應該只是暫時的。該指標很容易受到外部因素的影響，例如免費試用、行銷活動和概念驗證(PoC)，因此請考慮將其用作初始估計，提供粗略的計算以了解成本 -收入。

系統/服務的支出與交易比率

這是組織在雲端運作中的總體支出與收入比率的改善版本。這個組織所在的行業息息相關。例如組織是電商，這可能是雲端資源的作業量與訂單成交筆數的比率。如果網頁廣告領域，這可能是系統支出與廣告點擊次數的比率。增加特異性(specificity)可確保組織擁有適合的業務性的最佳需求驅動因素。