FinOps — 成本分配的能力

學習目標:

• 描述資源層次結構及其與成本分配的關係
• 定義使用”資源和層次結構metadata”進行分配成本的策略
• 描述分配雲端成本的多種方法
• 預測不同成熟度水準下成本分配成功的衡量標準
• 了解哪些工具可用於執行成本分配活動

FinOps框架

"成本分配"是了解"雲端資源使用和成本領域"中最重要的功能。 然而，資料和分配規則對於整個框架中的任何地方的運用都非常重要，因為各個團隊希望優化其各自的雲端資產，對於組織來說，組織會考量如何在設定KPI 的情況下將雲端使用責任在損益表中委派給各個團隊，以及當我們即時地運作和處理異常支出時。

框架解決了什麼問題？

• 團隊/組織收到有幾百萬行資源使用細項的雲端帳單

框架回答了什麼問題？

• 如何確定誰該負責雲端成本的每個品項
• 組織如何將雲端成本公平地分配給擁有該成本的每個團隊

取自FinOps Foundation官網

定義成本分配

透過結合以下方式，辨識雲端成本並在負責使用雲端的人員之間分攤：

• Account、projects、subscriptions、resource groups和其他資源邏輯分組的層次結構（以及這些層次結構分組的命名）
• Metadata— tag或lable — 在 CSP 內應用，或由第三方 FinOps 平台應用到雲端資源或層次結構分組
• 成本分配策略

為什麼成本分配很重要?

1. 成本的可見性與可控性
2. 總體成本的視圖
3. 對所有在FinOps角色的影響
   -業務結構長成怎麼樣
   -如何對資源進行分組和tag/label
   -如何呈現和劃分成本
   -成本資料和責任的分佈範圍如何
4. 提供給其他FinOps能力基礎資訊

此能力所參與角色(Personas)的RACI

• R- FinOps Lead
• A- C-Level們
• C- 財務、產品、採購、技術(平台、架構、開發等團隊)、C-Level們
• 所有人

成功的衡量標準

• 成本分配可以分配到應該要負責的人身上
• 資源以可預測的分組且具一致性地被建立，並適當命名
• 資源或分組具有一致性且是可預測的metadata
• 未分配成本是可以清楚識別的，並且有一個辨識它們的流程
• 所有人都清楚了解metadata合規性並有一致性的報告
• 組織能夠有效地將成本映射到其
  -組織本身
  -損益表/財務分類
  -功能上的使用(應用程式、服務組合、服務等)
• 根據絕大多數的運用FinOps的組織，在Crawl階段有80%雲端成本可以被分配，在Run階段可以達到90%

成功的衡量標準-Crawl階段

• 在成熟度較低的情況下，分配成本的機制的細緻度不足但是更通用，並且處理共享成本或未標記成本的能力將不太有效，成本分配的細緻度可能是在業務部門或投資組合級別
• 此階段成本分配可能包括簡單地將總帳單除以帳號、專案或訂閱，其中已知這些清單屬於特定成本中心或業務部門
• 隨著雲端使用的成長，未知的帳號、專案或訂閱將會到處都是，FinOps 或財務團隊可能需要在幾個月內調查這些內容以確定所有者
• Tags或Labels可用於某些成本分配，但使用不一致，或不用於大部分支出
• Metadata strategy（包括資源和層次結構命名標準）可能存在，但可能無發有一致性的去遵守
• 使用CSP工具

成功的衡量標準-Walk階段

• 在該階段，成本分配的機制將會很完善，並且會有多種機制，但可能不會有一致性或普遍使用，並且一些共享成本或未分配的成本可能仍然存在，成本分配的細緻度將通常位於應用程序或服務等級
• 此階段成本分配通常包括多種因素的組合，例如透過metadata或命名標準識別為屬於特定成本中心的帳號、專案或訂閱，可以識別為屬於特定成本中心的共享成本池內的資源，以及一些共享成本的機制
• 雲端基礎設施中可能仍然存在舊有或不太關鍵的部分，這些部分沒有一致地使用成本分配標準，這可能仍然需要一些手動或評估工作
• 可能存在一些共享成本基礎設施，如果沒有成本和使用資料中未提供的某些資訊，則無法直接分配這些基礎設施，但可以直接將其作為共享成本進行預算，也可以除以可用的商定因素（例如，應用程式支付的直接歸屬其他成本的百分比與共享成本項目支付的百分比相同）
• 結合使用CSP工具和各種類型的第三方工具
• 成本分配的關鍵績效指標已被理解，但不太可能自動化

成功的衡量標準-Run階段

• 在此階段上，成本應該可以根據組織的需要分配到盡可能細緻化程度，透過直接分配或一致性的機制來分配共享成本項目，並且metadata、層次結構和命名標準的策略得到一致且有效的普遍使用。
• 多個資料來源被匯集在一起，以便在對組織至關重要的水準上有效地分配共享成本
• 在極少數情況下，所有成本都未在最細緻度層級進行分配或未識別，基本上不需要研究或報告產生時間
• 使用CSP工具、第三方工具、自行開發和維護的工具以及自動化
• KPI 易於理解且自動化

最佳實踐

1.雲端費用對映於業務

• 建立有意義的成本分類法
• 組織架構（依部門、業務單位、管理層級）
• 功能細分（按應用程式）
• 依成本中心、專案 ID 或其他識別碼（對應到可用分類法）

2.評估/定義我們的層次群組

• 這可能因不同的CSP而異
• 隨著時間的推移可能會使用不同的模型
• 與技術/營運團隊的緊密聯繫

3.評估/定義我們的Metadata strategy

• 我們將在雲端應用哪些metadata？ 我們將應用或連結到雲端外部的哪些metadata？
• 如何處理無法在雲端標記的支出
• 如何處理tag/label的合規性

4.定義組織如何在團隊之間分配內部成本

• 對於每月使用的雲端服務的直接成本
• 預付費用（例如所有預付款）
• 用於分攤成本（通用功能、企業支援等）

將雲端支出數據對應到我們的組織架構

Top Down(Hierarchical)

• 組織結構層次
• 業務單位損益表責任
• 組織責任分配
• 辨識成本分配給目前的最低等級

功能性

• 考量影響產品定價或獲利能力的成本分組
• 考量將單獨支付的共享成本項目
• 考量non-hierarchical matrixed responsibilities、特殊專案或策略性舉措

財務性

• 考慮總帳科目表
• 考慮不同財務處裡的成本
  -開發
  - 不同的稅務管轄區

以上這些都可以作為成本的共存疊加視圖，並且幾乎總是如此。

Hierarchy Groups(Accounts/Projects/Resource Groups)

下圖是三大公有雲的成本分配結構，其中綠色區塊是必須設置的。而這也是一開始最簡單與最好的成本分配方法。因為它可以:

• 減少需要應用的Metadata(tags/labels)
• 非常明確的邊界

Metadata策略

• 名稱、建立者、負責人、環境、應用程式、成本中心
• 自動標記資源與建立資源的項目要一樣多或者更多
• 下標記是團隊在建立資源時的責任
• 尋找組織現有的分配名稱並且拿來用(例如從TBM/CMDB/CCoE等團隊)
• 問自己這個問題 ＂這個tag/label可以回答甚麼問題？＂
• 支援多種模型並完整記錄它們
• Crawl/Walk/Run： 完美是下tag/label的敵。先求能對資源下標記
• 選擇適用於我們（認為可能的）使用的 CSP 的標準
• 與盡可能多的人一起驗證我們的策略

Metadata策略-Resource

• Metadata直接應用在資源上（VM instance/storage結構等）
• 大部分的資源可以標記，但有些沒辦法（各家CSP狀況不一）
• 在雲端帳單檔案中有些東西不能被標記，需要另案處理

Metadata策略-Hierarchy Group

• Metadata直接應用在整個資源上（account/resource-group/project等）
• 簡化Metadata application，因為這些值可以「向下流動」到群組中的所有資源

這個功能會因為不同的CSP而有所不同

Metadata策略-綜合規則或業務規則

• IF-THEN-ELSE的邏輯可以協助我們制定更多複雜規則的成本分配決策
• 有利於共享分組中更動態的成本分配、特定成本中心的識別
• 當採用多層次metadata策略時，它會非常強大
• 通常在帳單資料產生後由第三方/內部工具套用
• 可用於透過自動化將metadata重新套用到 CSP 環境中的資源（這很少見）

成本分配策略

詢問自己以下這些問題以達成良好的成本分配：

1. 我可以存取所有的資料嗎？（資料擷取與正規化）
2. 我有理解整個Hierarchy group是怎麼被建立的嗎？
3. 我有足夠的Metadata應用到resource上嗎？
4. 可以標記單一資源嗎？
5. 我能理解共享的資源是甚麼並且是否充分標記這些共享資源（管理共享成本）
6. 我是否將這些metadata對應到重要的業務結構中？
7. 我是否有任何需要解析資料的疊加方法？
8. 我擁有的metadata是否支援所需的報告？(資料分析與showback)
9. 未來我還需要在哪些方面做更多的工作？
10. 是否清楚地記錄下來並且我是否有效地傳達了它？

持續優化與持續合規

隨著時間的推移，我們需要改變我們的策略。這需要：

• 更高的細緻度
• 重疊分配(overlay allocation)
• 導入新的雲端服務、新的應用程式、新的業務單位、新的管理方法
• 自動化能標準化並且也改變了某些事

而修復這個區域的技術債是有成本的。

而合規的挑戰在於：

• 透過metadata清楚地識別什麼是“不可標記的”
• 以前從未見過的新雲端服務可能會出現
• 衡量成本與資源的合規性
• 如何內化協調/報告

所以我們需要經常考慮優化我們的metadata 策略，這一個考量的步驟不是只有自己在哪邊想，而是需要有一個流程。而這一個流程重要的就是與相關人員持續性的溝通，並且是及早的將這些人帶入此流程。

成本分配的產出

我們在進行完整個成本分配的活動之後，通常會產生以下的可交付物:

• Hierarchy/Group Strategy
• 針對Hierarchy Groups與resource訂立命名規則
• Metadata Strategy
• 針對Metadata的使用建立使用指南
• 成本分配的策略
• 合規指南

工具

三大公有雲其實都有針對FinOps提供一些工具、方案與服務。

AWS

• Cost Categories
• Organizations/ Control Tower
• Tag Editor

Azure

• 將tag貼在Resource Group這一個層級，而不是直接貼在resource

GCP

• 可以將labels貼在 resources/folders/projects
• GCP貼在resource上的稱為labels，tag是用在network security中。(別搞混了)

第三方工具、方案與服務

大多數第三方平台為各種 CSP 提供開箱即用的Metadata(Tag/Label)合規性。

• CloudHealth 允許我們將成本分為稱為「Perspectives」的分組，從而提供產生帳單後文件加料功能
• Cloudability 透過標記某些層次結構群組或應用業務線對應（ynthetic metadata）來對帳單檔案加料
• Iris3 是最初由 DOIT 創建的 GCP 開源標籤管理器
• Cloud Custodian 可以檢查合規性並自動修復合規性

總結

基於成本分配資源和分層分組標籤聚合資料的能力使組織能夠對成本報告進行切片和切塊(slice and dice)，以便與不同角色的利害關係人進行溝通，與各種商業論證保持一致，例如與應用程式契合、財務所有權、營運所有權，以及以下各種。

• 大部分雲端成本可以分類並分配給所有者
• 資源以可預測的分組創建，並適當命名
• 資源或分組具有一致性且可預測的附加metadata
• 未分配成本是可以清楚識別的，並且有一個辨識它們的流程
• 透明地向整個組織明確共同成本
• 所有人都清楚了解metadata合規性並有一致性報告
• 組織能夠有效地將成本映射到其
  -組織本身
  -損益表/財務類別
  -功能運用(如應用程式)

最後下表示呈現傳統的IT財務管理與雲端財務管理的不同之處比較表

參考資源

• 從零開始 — Riley Jenkins 發表在 FinOps.org 上的《鼓勵工程師採取行動》白皮書
• Google Cloud 文件很好地概述了他們的專案和元資料策略
• Azure 同樣提供了一個概述頁面，其中包含有關管理成本的豐富內
• AWS 白皮書提供特定主題的指導，例如組織環境
• Azure 中的哪些服務支援標記
• Cloud Custodian Tagging 的合規性
• 關於 Google Labeling