雲端費用的成本分配
本文講述我們在將雲端費用的成本分配給每一個BU或成本中心之前應該有的戰略決策。因為如果沒有此類的決策，我們很容易將錯誤的將雲端費用成本歸類到錯誤的單位/業務/專案。而企業本身也能透過這個成本分配報告得到許多的效益。
為什麼成本分配是重要的
在雲端中，如果我們知道公司所花的每一塊錢是花到哪裡的的話(這也是每一個老闆想知道的)，哪我們優勢就比其他正在懵懵懂懂使用雲端的同業還要大。首先，我們知道"誰在花錢"。我們去除了典型的雲端技術討論會議，這種討論都是 — — 哪個正在使用的資源不是我的，然後就結束。最有價值的是 — 我們可以開始針對每個團隊進行”趨勢的預測增長”（相對於整個公司的支出），並為團隊”設定預算”，以便他們知道他們是”如何實現目標”。
一旦我們確定了這一點，我們就會開始知道異常(預期外的花費，也是老闆最不想看到的)來自哪裡，以及哪個業務範圍和哪一個團隊的產品或服務觸發了這些異常。了解資源在做什麼(錢燒在哪裡)有助於我們通過考慮環境特徵並開始有智慧的優化它們。是生產環境還是開發環境？每個環境所需要的資源會是多少？依此類推。同時，使用雲端平台的團隊會收到真實的每日費用支出圖表，這與財務單位要在月底對這個單位的費用計算有關。而所謂使用雲端平台的團隊指的不只有技術團隊，而是整雲端平台個相關的利害關係人，可能有業務/行銷團隊等。
我們應該走向單位經濟，將控制預算的責任交給使用雲端的團隊。FinOps中心化團隊仍做成本分配的工作，但我們用chargeback和showback將責任歸於使用雲端的團隊，使其成為他們的責任。FinOps中心化團隊則定義如何使用雲端的政策或框架。
事實上，成本分配是業務價值和雲端支出之間的重要紐帶。當員工意識到他們的行為以及這些行為所產生的影響時，這種意識就會推動一種精實文化。產生問責制的是chargeback和showback。當然，如果也把成本費用當作員工的KPI之一就更好。
我們希望知情階段是優化階段的必要先決條件變得越來越明顯。即便如此，我們還是經常看到使用雲端運算的企業會一開始就一頭栽進嘗試優化其雲端環境的成本，同時忽略了解雲端中成本分配驅動因素的重要性和複雜性。即使是可靠的雲端帳號的關聯策略或是一個像樣的標記策略也不足以解決成本分配問題。部分原因是成本分配可能是一個會移動的目標。要考量沒有下標記或無法下標記的資源、共同成本以及非常見的可能性，意即：組織重組或需要報告事物的方式的變動可能會破壞我們的成本分配策略。
企業的員工也增加了複雜性。不同的人會以不同的方式看待或取得事情。財務人員想知道雲端支出的去向以及如何以用有意義的方式將其與 SKU 和產品關聯起來。工程師關心可變的雲端資源消耗以及他們的日常行為如何影響帳單。CTO關心將多種視角匯總到一個全局視角。而事情的脈絡就是一切，因為我們每天都可能在不同的情境下作業。因此，當我們制定策略時，我們要牢記所有不同的需求和觀點，以便我們可以建立每個人都認為有意義的成本分配結構。
當然，我們不要忘記業務指標。我們的策略必須讓團隊將業務指標與他們的雲端支出關聯起來，從而實現單位經濟和關於雲端支出對業務價值的討論。
Chargeback VS. Showback
哪麼我們需要何時進行chargeback或showback呢？ 有時候，這個選擇通常取決於企業的雲端成熟度。 越不成熟的組織做showback，越成熟的組織做chargeback。 這兩種方法都推動了問責制，但我們需要觀看它們之間的核心區別。 當實際發生的成本被分配回個別單位的預算或損益表時，就會發生chargeback。 當我們對團隊展示他們的雲端支出時，就是 showback，但資金是從中央預算(也就是公司的整體預算)內部分配的。
所以簡單的來說：
Showback 留下一張待分析的帳單； Chargeback 會有一張相同的帳單，但使用的團隊需要付錢。
實際上，兩者之間的選擇更多地取決於組織的結構，而不是其成熟度。 看企業是偏好或是部門損益表，企業通常會選擇其中一個。 例如，財務主管或 CFO 可能在企業的各個部門反對部門損益表的概念，或者對業務的某些部分可能沒有意義。 在這些情況下，組織將傾向於showback而不是chargeback。
適合業務目的的模型組合
某些企業會使用chargeback和showback的組合。當它是面向客戶的 SaaS 系統時，公司會在集中管理預算的同時進行showback。然後，對於某些研發工作，他們會對開發團隊的損益表進行chargeback。
在團隊之間分配支出是複雜且持續的。將每個團隊的數十個不同的雲端帳號的關聯與業務需要報告的相關產品和成本中心進行對照。但是，可能在一次企業大改組之後，使用雲端的團隊可能很少移除雲端資源並在不同的雲端帳戶中重建它們以匹配新的組織結構。這樣會讓組織的雲端的問責制產生問題，而我們必須將現有的雲端資源使用情況重新分配給相應的團隊。
這是許多 企業都遇到的共同挑戰。工程師對資源下標記的方式不一定與企業報告雲端支出的方式一致。並且雲端支出通常需要重新對照以匹配成本中心或產品，這些成本中心或產品是雲端支出的合法“所有者”。
如何確保成本分配作業的日益成熟的方法，以下是一些企業中可能的作法：
帳號命名
每次要開新帳戶時，都必須為其將支援的產品命名。 如果它是特定於某個環境的，則必須在名稱中顯示環境。 我們需要確保遵循此流程的中心檢查點。 所有開新帳戶請求都必須經過中心化管理團隊。 在 AWS 中，這將採用Linked account的形式。 在 GCP 中，這將以project或folder的形式出現，在Azure可能以account或subscription的方式出現。
資源標記
有時候我們接手舊帳號的名稱不是依照新規則，有時還會大量下標記，尤其是在舊的多租戶帳號中，也就是一個帳號有不同的部門使用。 他們的主要tag的 key稱為“部門”，它可以幫助他們在這些帳號中分辨部門的支出。 舊版多租戶帳號要求使用所有人對所有使用的資源下標籤。 但是，我們應該知道，並非所有雲端資源都是可以下標記的，並且並非所有最終用戶都能合規。 因此，通常仍有大量未有下標記的支出報告給管理高層。
跨帳號的共享公司成本
其他企業如何在雲端世界中分配中心成本的常見問題。 我們可能將批發折扣、原廠技術支援和RI預付款攤銷等成本分攤。
在早期，有些企業使用多租戶帳號方式時，標記的覆蓋率不是很好，大部分支出都沒有下標記。因此，企業專注於隨著時間的推移降低支出與沒有標記支出的比率。以雲端帳號為單位的基礎上，負責特定產品的團隊負責人已詳細了解構成這些產品的服務。進而提供近乎即時的成本報告，從而提高了當月和季度雲端支出的可見性。這有助於縮小成本分配差距。
按照 FinOps 的典型成熟度曲線，企業首先將批發折扣、原廠技術支援和 RI 攤銷等預付款排除在最終團隊收到的報告之外。我們可以將越來越多的這些成本納入支出報告中。最終，團隊可以看到了經過適當調整的價格。我們能夠查看完全調整後的支出，將攤銷和準確的雲端資源量納入數字中，從而更準確地了解實際成本。
運作中的showback模型
Showback 的關鍵顯然是成本控制，以便團隊知道他們花了多少錢。 我們可以向每個團隊展示他們的實際支出與預測支出的對比，包括兩者之間的差異以及與預算的比較。我們可以按月和按季度這樣做，並定期提供有關成本驅動因素和異常情況的更詳細的報告。
企業的CIO或CTO 每月與每個技術團隊的負責人進行一次維運審查，來顯示團隊的支出。如果沒有任何明顯的差異，這些會議可以很快結束。我們在實施即時的 FinOps 流程可以提醒每個團隊的負責人他們將超出預算。
當發現差異時，我們可以快速顯示導致差異的問題和成本驅動因素，然後團隊負責人可以與中心化團隊團隊合作進行修正，而無需等待每月的維運審查。這是打破穀倉效應和即時決策的一個很好的例子。
Chargeback與Showback的考量
我們有多種方法可以實現chargeback/showback，例如直接轉嫁成本、收回額外收入以及支付管理成本：
收回實際成本
這是最常用的方法，推薦用於Cloud-first 的組織。 沒有第二套帳本需要維護，每個人都有著相同的數字和目標。 Chargeback是按完全攤銷，經過與雲端平台商協調後的費率調整和未混合的費率以顯示團隊在此期間產生的實際成本。 最成熟的組織也會分攤共同成本，例如原廠的技術支援費用。
集中RI的購買與存下節省後的費用
這種方法允許中心化團隊為自己提供資金，並與使用雲端的團隊分享節省後的費用的效益。 但是，可能會有一些來自團隊的反對，他們被要求放棄對 RI 購買的控制權，因此無法獲得所有可能的省下來的錢。
集中協商折扣與存下節省後的費用
與雲端平台商談判折扣通常會隨著我們承諾的支出增加而增加。 中心化團隊可以獲得的規模經濟可以實現最佳的費率，達到單一業務部門無法達到的水準。 有時這些費率也是高度機密的，並且不希望在公司內到處傳播這種資訊，甚至外傳給雲端平台商的其他客戶。 由於所有這些原因，一些公司選擇保留一部分（或全部）談判後費率省下來的錢來為中心化團隊的管理提供資金。 雖然並不少見，但這種方式缺乏了資訊透明度。
在企業中分攤共同成本
每個企業都有共同的 IT 成本，這些成本跨多個業務部門。隨著組織越來越多的使用公有雲，將共同的雲端資源分配給特定業務部門、了解如何正確和公平地分配成本以及實際預測未來業務部門預算變得越來越困難。
原廠的技術支援費用是這一挑戰的一個常見例子。雲端平台商的技術支援費用通常在最高一層的帳戶收費。一些組織選擇用中央管理式的IT/雲端團隊的預算來支付這筆費用，但這種方法並不常用。更常見的是，中央管理式的IT/雲端團隊被視為支援組織（就是成本中心），因此需要將其成本分配給內部客戶：就是業務部門或應用程式的擁有者。
隨著服務共享平台的興起，現代架構也引入了更多的共同成本。這些平台有多個團隊使用相同的核心資源，例如在AWS S3 bucket中建立的資料湖或在共享cluster上運行的 Kubernetes 。猛然一看，這些平台的chargeback和showback似乎是不可能的，但訣竅是正確下標記和正確分配共同成本。
通常有以下三種方法分配共同服務成本：
- 比例式的
基於直接成本的相對百分比 - 平均分配
在目標之間平均分配總金額 - 固定的
自己定義的係數（係數之和需為100%）
雲端成熟度較高的組織傾向於根據直接費用在業務部門之間按比例分配共同成本。 以下是一個範例。 下表 顯示了一個企業的每個業務部門在特定月份的雲端資源消耗量，以及該組織如何收取 100K美元的enterprise support charge(原廠技術支援)。
在表一中我們可以看到，如果沒有分配 Enterprise support charge，費用收取就會是上表一樣，這100K的Enterprise support charge就會歸到一個中央預算。
但如果我們是按比例來分配這一項費用，就會長得像下表二
攤銷(Amortization): 這是個應計的世界
我們在雲端費用帳單的解析中介紹了匹配原則：它指出費用應該記錄在企業在使用雲端時所收到的價值的時期，而不一定是在雲端平台商開發票時。白話一點就是使用雲端時，企業開始有利潤了。
這裡要考慮的會計原則是按“現金(cash)”的基礎還是“應計(accrual)”的基礎的報告。前者意味著我們報告"發生期間的費用支出"，而後者表示我們報告"實現收益期間的費用支出"。這適用於某些 RI(批發)等計費結構，其中一部分初始費用需要期末結轉到使用 RI 時。期末結轉是一種會計用語，有興趣的讀者可以參考本文的解釋。
這種“期末結轉”或攤銷相當於地端機房中許多人熟悉的硬體折舊概念。但在這裡它特別適用於無形資產。如果不將前期成本攤銷到使用時間和地點，即時的費用支出的資料就會引起混亂和懷疑。維運團隊會誤以為他們的支出比實際少，而且當他們從會計部門收到費用更大張的發票時，通常會出現的不爽的意外，會計部門在收取費用之前已經套用了攤銷。
在下圖中，圖下部的"收付實現制(Cash Basis)"報告圖表顯示了在未套用攤銷的情況下費用支出如何看起來很不穩定。圖上半部的"權責發生制"圖表顯示了成本攤銷後支出趨勢如何變得更加清晰。收付實現制與權責發生制均屬會計用語，有興趣的讀者可以參考本文。
以下是一個簡單範例中如何計算攤銷和由此產生的費用節省：
- 資源的On-Demand費率為每小時 0.2 美元。
- RI費用為 300 美元，使用時每小時 0.05美元。
- 攤銷費率為 300 美元，除以 365 天，每天 24 小時，再加上每小時 0.2 美元的費率。
300 / (365 × 24) + (0.005) = 0.039 美元 - 節省的費用是On-Demand per hour費率減去攤銷費率。
0.2–0.039 = 每小時 0.16 美元（節省 20%）
一家公司可能在任何特定時間點擁有數百甚至數千個 RI。 這使得追踪所有預購資源的活動變得非常具有挑戰性。 每個預購事件通常都有一個獨特的時間表，具有特定的開始和結束日期。 此外，RI 可以修改為一組新的 RI，要求在所有新的目標 RI 之間適當分配原始固定價格。
我們建議將攤銷納入所有費用支出報告數據中，包括預測(forecasting)、chargeback、異常情況，以及基本上提交給團隊的任何其他資料。 如果成本報告和分析與預測還有異常等進階功能不匹配，則可能會出現資料混亂。 正如我們多次說過的，資料的混亂越少越好。
使用會計創造信譽和可審計性
良好的標記策略的額外效益超出了全部的成本分配和可審計性的責任。 在我們推進成本分配策略時，使用可審計性作為標記的額外效益可以讓財務單位支持我們的成本分配行動。而會計工作的很大一部分是確保所有花費的資金都可以被審計和追踪。 正確標記的資源越多，我們的雲端支出就越能進行審計。
如果這還不夠，可靠的標記策略可以讓我們建立更準確的預測模型，這僅是因為我們使用的資料更豐富、更準確、更精細。 由於會計的另一個關鍵作用是預測未來費用，因此標記對於在維運和財務之間建立信任和信譽是有幫助的。 所有這一切都將減少我們成本分配作業的阻力，更願意轉移成本，總體來說，團隊更有能力實現公司的目標。
使用 TBM 分類
我們可以通過將費用支出與本身的財務結構（如成本中心和目標代碼）進行對照。但我們還應該考慮將其與一致的分類關聯起來，我們可以使用該分類法對費用支出資料進行效能測試(benchmarking)並將其整合到對業務部門有意義的視角中。財務單位並不是永遠需要有關業務如何使用哪種雲端服務的詳細資訊，但他們通常需要根據正確的成本池(cost pools)和 IT towers來分配支出，以便在不同團隊之間提供一致的視角，並與同產業的企業進行效能測試。CIO通常希望讓內部雲端使用團隊對他們的雲端費用支出負責，如果沒有適當的對照，這是很難做到的。基礎設施的管理者需要用apple-to-apple的方式將地端機房與公有雲服務進行比較，如果我們沒有普遍理解的術語和定義，這個過程會令整個組織與所有團隊無法溝通與理解。
許多規模較大的企業（多達 50% 的財星100大企業）使用TBM分類法在其更廣泛的 IT 費用支出中實現這一目標。 TBM 和 FinOps 之間有許多相似之處，但它們也為我們提供了不同的資料視角。
TBM 分類法在廣泛的標準化層次結構中對來自不同來源的 IT 成本進行分類與組織它們。 它提供了一組通用術語來描述成本驅動因素和雲端的消耗量 — — 並將所有 IT 支出（無論採購模型如何）與業務價值關聯起來。 TBM 分類的一致結構不僅僅是一種對費用支出進行分類的方法，還可以對技術支出進行內部和外部比較。 它通過規範報告方式來幫助使資料中心支出與公有/私有雲端支出保持一致。 這種一致性還使得這些通常分離的技術之間以及與類似產業的其他公司之間的基準比較更容易。
下圖為TBM分類法所提供針對報告成本與相關業務指標標準層次結構．
上圖分類的四層（costs pools、IT Towers、Applications&Service以及Business Units or Capabilities）支援對業務不同部分的資料的三種不同視角(上圖右邊的箭頭)。正如我們之前所討論的，企業歷來希望通過不同的角度和脈絡來查看費用支出資料。
對於財務(Finance View)，這個模型包含來自整個公司的總帳 (GL) 資料和其他成本來源。它還有助於區分CapEx和OpEx — — 如同固定支出對比可變支出 — — 並將所有 IT 支出集中到九個標準成本池（硬體、軟體、內部勞動力、外部勞動力等）中，如上圖二，這有助於財務單位進行成本分配，並更容易比較內部團隊、專案和其他成本驅動因素。
對於 IT(IT View)，這個模型將成本池中的支出對映到稱為 IT Tower的通用功能（例如，server computing, storage, application developement, application support, IT management）。由於這些IT Tower在企業中高度一致，因此它們使 IT 能夠評估和進行效能測試其所有 IT 支出之間的效率，無論是雲端還是內部。IT Tower還使他們能夠隨著時間的推移監控單位成本，設定改進目標，並在很大程度上從支援方的角度管理他們的效率。
對於業務(Business View)，該模型將 IT Tower的支出對映到標準化產品/服務，這些產品/服務反過來支援不同的業務能力或由特定業務部門使用。例如，IT 可能會提供基於基礎架構的服務，例如應用程式託管、資料倉儲或網路存儲。此外，可能還會有基於應用程序的服務，例如CRM、財務管理或產品工程。 TBM 分類為我們提供了一種統一的方式來對映到這些類型的產品和服務。在 TBM 分類的這一層，這些術語對業務部門來說非常有意義，無論他們是業務應用程序擁有者還是業務部門主管。
最重要的是，該分類在標準模型中提供了一組預先定義的指標和KPI，以便企業可以就雲端支出（實際上是所有類型的 IT 支出）如何與業務關聯起來進行有意義的討論。此外，它可以幫助加快不同團隊和支出類型的效能測試。
花錢恐慌症的臨界點
正常情況下，不同團隊在使用雲端時幾乎沒有人監督，直到收到帳單時讓老闆嚇一跳。 雖然這些使用雲端的團隊經常會反對使用chargeback — 甚至也不喜歡showback— 在沒有 showback/chargeback 的情況下使用雲端運算並不能回答有關誰在花錢的問題。 下圖顯示了一個雲端費用計算範例，在雲端支出引起老闆注意之前，成本管理並不在老闆的關心的清單上。
典型的雲端運算成熟度曲線顯示了組織開始關注其雲端費用支出的點。 上圖說明了在一個非常具體的點達到老闆的注意：當支出超過一個無形的門檻並且管理高層開始真正關心它的那一刻。 對於某些組織，這可能是每月 100 萬美元，而對於其他組織，可能是每月 1000 萬美元。 每個組織的數量不同，但產出是相同的。 然後老闆被驚嚇到了，開始關心並尋求優化雲端費用支出。
有一個企業的故事類似是這樣的。
他們曾經有過三個不同的時期，出現了“花錢恐慌症”，從而推動了對雲端費用的問責制。
第一個驅動因素是需要回答問題。 這讓財務部門有了向團隊顯示使用雲端的團隊的費用支出的想法。 之後支出再次增加，並讓這個團隊在組織中很難看，團隊試圖減少支出。 直到第三次花錢恐慌症發生後才沒有再繼續發生：如果組織的業務正在成長，帳單上漲不一定是壞事。
那時，組織開始將問題重新定義為：“我們是否盡可能有效地支出？” 正如我們所解釋的那樣，“討論轉移到了‘我們如何優化雲端？’ 而不是強制要求降低成本的目標”
花錢恐慌症即將發生。 如果我們有一個自動化系統來查看我們的支出模式，並且我們知道支出會增加太多的大致日期，那麼 CCoEs(雲端卓越中心) 可以積極主動地為隨後不可避免的高階管理層審查做好準備。 如果沒有 CCM 或合理的成本分配，我們免不了就每天都會被老闆盯。 我們可以通過一個可擴展的、易於變更的成本分配策略來保護我們自己。
結論
成本分配策略因公司而異，但它是 FinOps 生命週期中的重要組成部分。 它使我們能夠專注於正確的領域能夠最終回答在這一篇文章FinOps的生命週期 — 告知階段所提出的問題。
總結：
- FinOp 實踐中的雲端支出通常以權責發生制為基礎，將攤銷預付款、折扣率和共享成本納入團隊看到的資料中。
- 將模型的共享成本考慮在內，例如支援、攤提和未分配費用。
- Chargeback和Showback都是問責制。
- Chargeback或Showback模型還可以幫助提高標記和可稽核性。
- Chargeback是更好的模式，但由於會計實務的原因，它並不適合所有企業。 通常最好從展示Showback開始，然後試著在公司內往Chargeback方向前進。
- 在達到「花錢恐慌」臨界點之前建立一個模型將有助於回答高階主管關於推動支出的因素的問題。
