雲端運算的單位經濟學
如果我們已經經歷過了 FinOps 生命週期的三個階段,那麼我們應該已經到達了考慮雲端費用的最具挑戰性的轉變。 FinOps 的終極階段是進入單位經濟費用管理(我們的每 單位成本(例如是X)是多少,其中 X = 客戶、服務、用戶等)。達到這種可見性非常重要,這樣我們就可以就何時在雲端中增加或減少支出做出明智的決定。要做到這一點,我們需要發揮我們所有的 FinOps 肌肉,並從其他一些紀律中獲得幫助。
我們在FinOps中所做的一切都是能夠到達這個境界。我們已經分配了支出、設定了優化目標並實施了SOP,讓我們的團隊能夠實現這些目標。我們可能已經經歷了幾次 FinOps 生命週期,每一的週期過後都優化我們的成本分配策略、指標threshold和對雲端使用情況的可見性。
但我們仍有一些差距,因為每次我們的雲端費用增加時,關於這個費用的成長是好是壞的辯論就會重新開始。費用是否因組織的業務成長而增加?是因為雲端的加速遷移嗎?還是因為低效的使用模式重新回到團隊的習慣中?要給出一個明確的答案是非常棘手的,尤其是一個讓高階管理層有信心的答案。
在本文中,我們將開始使用單位經濟(Unit economic)將我們的雲端費用與業務價值關聯起來。指標可幫助我們確定允許一定金額的支出以獲取額外收入的價值,並為業務績效設定KPI。
在本文中,我們將討論我們如何仍然缺少一些關鍵業務要素來達到單位經濟的終極階段。為了填補這些眾多要素的差距,我們需要超越 FinOps 可以為技術業務管理模型提供的內容。
哪麼甚麼是雲端單位經濟學呢:
雲端單位經濟學是一個利潤極大化系統,基於客觀指標衡量組織不僅實現其 FinOps 目標,而且作為市場上的企業的表現。 雲端單位經濟學透過利用特定於基於雲端的軟體的開發和交付的邊際成本(又稱單位成本指標)和邊際收入(又稱單位收入指標)的衡量來實現這些野望。
指標是單位經濟學的基礎
單位經濟學的一個常見定義是與特定商業模式相關的直接收入和成本,具體以單位為基礎表示。 指標使我們能夠確定我們將從單一個業務單位獲得的收入以及與服務相關的成本,最終揭示雲端費用的業務價值。 對於面向客戶的應用程式,基本單元可能是用戶數或客戶訂閱數; 對於電商平台,可能是交易量; 對於運輸業來說,它可能是一個座位或一個貨櫃。
衡量服務核心價值的單一指標不是一種新的概念。 我們可以把它視為組織的指南針。 將其視為幫助組織專注於長期業務成長而不是短期影響的指路明燈。
找到正確的單位來衡量組織的業務是一門藝術,隨著時間的推移我們可能會變動或更新。在雲端環境中提供單一產品的組織很可能只需要一個跟整體雲端支出相關的單一價值。而具有複雜結構和多種產品的組織通常會有多個單位,每個單位都與特定的產品線、應用程式或服務相關。
有雲端費用產生是好的,但浪費不是。在FinOps 生命週期的告知階段,這個階段強調浮現雲端成本以建立成本意識和該資源的所有權。通過了解雲端費用,我們能夠確定趨勢並預測未來成本。當雲端成本超出我們的預算時,下一個顯而易見的步驟是開始調查費用的成長並解釋正在發生的事情。與指標驅動(metric-driven)的成本優化提供整體脈絡的方式相同,單位指標(Unit metric)也為雲端支出的變化提供了整體脈絡。
回到指南針的概念,我們經常看到組織開始使用產品產生的業務收入(雲端中的運行)作為一個簡單的起點。將總體雲端成本除以產生的收入,我們可以確定雲端支出的成長是否增加了組織的利潤 — — 因此是“好的”費用支出。
通過計算總體收入的雲端費用支出,我們可以將雲端費用支出的成長與我們的整體業務成長關聯起來。當這些都符合時,雲端費用支出不會被浪費是有道理的。當雲端費用支出成長快於業務成長時,可能會引起高階主管層的擔憂。
理想情況下,我們用於單位經濟學的指標應該具有低熵(entropy),其中業務某一部分的決策不會影響其他業務使用的指標。 以下有一個例子,在下圖一中,公司正在追踪組織整體收入與雲端費用支出的關係。只要這些線或多或少保持一致,單位經濟似乎就正常了。
而在下圖二中,我們的公司在雲端環境上提供了付固定的月費但觀看影音是吃到飽。 我們期望這些客戶會不斷購買新的影片,從而增加整體收入。 但是,當公司推出這項產品時,我們的雲端費用支出會增加,但卻沒有增加收入。 我們的單位經濟受到衝擊。 如果我們的技術團隊使用這個指標來衡量其基礎架構成本與業務價值的匹配程度,則影響是負面的。 當然,我們可以告訴我們的技術團隊預期這種變化並繼續運作 — 也就是說,直到3個月後公司的行銷團隊進行廣告投放以提高我們的影片的購買率並且我們的單位指標受到影響。
在下圖三中,我們決定根據每月活躍用戶 (MAU) 衡量雲端費用支出。 隨著我們增加活躍用戶,我們的雲端費用支出也可能增加。 而隨著影片套餐的推出,活躍用戶和雲端費用一起增加,我們的指標總體上保持一致。 在這種情況下,如果未來的行銷活動吸引了更多客戶或客戶購買了更多影片,它會產生與下圖三類似的效果。 他們可以看到活躍用戶的成長增加了雲端費用支出。 在此指標中,業務價值(MAU)是根據雲端費用支出來衡量的。
從公司營收改為每月活躍用戶、飛機座位或追踪的運輸活動等單位將提供更好的脈絡。 當我們使用與組織收入不直接相關的單位時,向客戶收取的價錢變化不會改變單位指標值(unit metric value)。 當我們使用這些指標時,衡量雲端平台建立的業務吞吐量(尤其是與雲端費用支出相關的)會成為圍繞雲端成本效率而做出業務決策的關鍵要素。
FinOps的鐵三角
單位經濟學為團隊提供了他們需要衡量的數據 ,雲端基礎設施的變動將如何影響成本。 維運團隊和財務部門之間的對話“不再是關於變更的細節,而是更多地關注它將產生的影響”。 這使企業可以做出決策,權衡變更的好處與對單位成本的預期影響,例如將每位活躍用戶的成本提高 5% 是否會使應用程式效能提高 20%。
當我們將單位經濟學應用到 FinOps 生命週期的優化階段時,我們的目標設定就會是成熟的,從只有使用營運指標(例如達到 80% 的 預購覆蓋率)到使用影響收入的目標(例如將每位訂戶的成本降低 30%)。 前者可以幫助企業,但也可能分散對真正重要的事情的注意力。
這個挑戰在於採取有效行動,同時保持成長和速度。 當我們處於競爭激烈的產業時,目標通常不是節省成本,而是推動更多功能和更快的業務成長。 在雲端上花更多的錢可能會讓我們有更多的收入,可能是客戶群成長,或者可以讓我們更快地關閉地端機房。
勒緊腰帶
讓我們再看一下為我們的雲端產品提供影音吃到飽的範例。 在衡量雲端支出的成長以及吃到飽的套餐對長期收入的影響時,我們確定雲端支出的成長給組織帶來的成本高於預期的收入成長。 公司決定降低影音吃到飽的客戶的成本,可能讓這些使用效能較低的資源(如降低影音品質)。 吃到飽的效能降低可能是使吃到飽方案的長期利益重新回到公司所想要的(帶動更多的客戶成長或影片購買)。
決定投資更多
或者,我們可以確定吃到飽方案對企業來說效果很好,並且我們預測顯示,進一步提高應用程式效能或可用性將導致收入進一步增加。 企業決定增加雲端費用支出以提高應用程式效能。 這讓吃到飽產品的客戶感到滿意,這反過來又促使他們之中的更多人買更多的影片。
無論哪種情況,我們都可以根據跨職能對話做出有意義的選擇。 單位經濟學提供數據來幫助我們圍繞FinOps的鐵三角做出決策。
基於業務活動的成本
FinOps專家會查看執行與基礎設施底層功能相關的特定業務的成本。 他們在了解所涉及的機器時間(建立每個文件的成本、每次運作的成本等)的基礎上進行預算。 在下圖四中,我們正在追踪由我們的服務呈現的文件數量以及支援它所涉及的相關雲端費用成本。 隨著運行的工作增加,雲端費用也在增加。
在下圖五中,我們正在追踪運作文件的成本。 雲端費用成本在月中成長了,但運作的作業數量並未增加。 這突顯了一些事情發生了變化。 與月初相比,我們現在為運作文件支付的費用更多。 這可能是由於使用了更多資源或預購的費率不再套用於我們的雲端資源。
正如我們在雲端費用帳單的解析中討論的那樣,雲端帳單是由使用量乘以費率的數字產生的。 因此,當我們超出預算時,我們可以確定是因為我們的資源使用情況或是預購的產品組合的變化。 當我們進行基於業務活動的成本時,我們正在積極管理成本驅動因素。
在算式中還缺少了什麼?
到目前為止,我們一直使用雲端支出作為分子;但是,我們可以合併許多其他費用。我們已經達到了 FinOps 的終極階段,這讓我們深入了解了雲端費用支出的商業利益,但雲端成本只是整體情況的一部分。畢竟,與企業員工的成本相比,雲端基礎設施成本通常是大巫見小巫。當我們擁有所有相關成本資料(包括勞工成本等)時,單位經濟學會對我們有所幫助。
到目前為止,這一系列的 FinOps 故事完全集中在雲端成本上。將雲端費用除以一個單位成為每單位的實際成本只能提供了有限的脈絡。實際上,企業還有許多其他成本會影響公司營收的總成本。
在這篇雲端資源的優化 — 用得更少文章中,討論了將服務重構為serverless架構模型。在決定重新架構服務時,我們應該權衡基礎設施費用和潛在節省與重構的人力/時間成本。此外,一旦服務在無服務器架構中運行,我們的服務/產品成本可能會變得更少能夠跟收取的雲端資源成本相關聯,而更多地與雲端維運成本有關。
當然,我們可以擴展 FinOps 以包含雲端費用之外的成本。然而,在從FinOps的角度來看 ,與現有的、久經考驗的總成本管理模型一起工作更有意義。
多年來,Technology Business Management(TBM) 提供了一個將價值與 IT 支出關聯起來的框架。然而,TBM 並不能幫助組織在每秒、並且費用是變動的雲端世界中營運,尤其是在組織的每個團隊都可以自行決定購買決策的情況下。這就是為什麼 FinOps 是 TBM 的絕佳搭配。
那些維運基礎設施的人經常無法看到它對公司能產生的收入 — — 尤其是在科技領域。相反,負責營收的人對營收背後的成本驅動因素沒有足夠的了解。 TBM 將營收納入方程式,並將其與 FinOps 提供的成本驅動因素相結合,從而能夠就雲端的收入影響進行更完整的業務討論,這是任何一種組織中的紀律都無法提供的。
這是 FinOps 應該停下來的地方,然後將其融入現有的完善框架,以告知有關 IT 支出的決策。我們可以用 FinOps 讓TBM 能夠以更加雲原生的方式以及在雲端世界中運作,而 TBM 將允許 FinOps 在不整體框架打掉重來的情況下,對雲端帳單之外的更高業務成本進行推算。
總結
我們現在應該了解構建的 FinOps 流程如何使我們能夠開始根據其提供的業務價值衡量我們的雲端費用支出。 我們可以使用業務價值圍繞優化設定目標,並使用指標來追踪雲端成本的真正驅動因素。
總結一下:
- 我們的指南針指標衡量我們的雲端費用支出的業務價值。 每月活躍用戶 (MAU) 是一種常見的指南針,但它會因企業而異。
- 具有複雜結構和多種產品的組織通常會有多個單位指標,每個指標都與特定的產品線、應用程式或服務相關。
- 決策不再關注雲端的成本,而是基於效益.