FinOps架構核心領域與能力解析

– 16 分鐘閱讀

FinOps 的核心在於將財務管理和雲端營運整合，透過理解雲端使用情況和成本、追蹤效能並進行基準測試、即時決策、雲端使用最佳化、雲端費率最佳化以及組織對齊等領域，來幫助企業更好地管理和最佳化雲端資源的使用。每個領域都包含一系列能力，例如成本分配、預測變異數等，並透過衡量這些能力的成功指標來評估 FinOps 實踐的有效性。此外，企業需要根據自身情況調整 FinOps 框架，參考外部資料來源和最佳實務，並與其他財務模型整合，才能最大化 FinOps 的效益。構建高品質的 FinOps 報告和儀錶板，並持續監控資料品質，也是 FinOps 實踐成功的關鍵。選擇合適的工具和平台，無論是原生工具、SaaS 平台還是自建方案，都需要根據企業的資源、文化和技能進行評估。

FinOps架構的核心領域與能力解析

核心領域及其主要成果

在FinOps（財務營運）框架中，定義了多個核心領域，每個領域都對應著特定的主要成果，以幫助企業更好地管理和最佳化雲端資源的使用。這些領域包括：

  1. 理解雲端使用情況和成本：推動責任制和透明度。
  2. 效能追蹤和基準測試：定義什麼是良好的表現。
  3. 即時決策：實作快速的反饋迴圈，以便進行資料驅動的支出決策。
  4. 雲端使用最佳化：確保雲端資源的高效利用，同時減少浪費的支出。
  5. 雲端費率最佳化：利用各種承諾型折扣計劃來降低所消耗資源的成本。
  6. 組織對齊：使雲端使用與組織目標和結構保持一致。

這些成果如何幫助企業

透過這些核心領域及其主要成果，企業能夠回答諸如：

  • 某個應用程式的主要成本驅動因素是什麼？（理解雲端使用情況和成本）
  • 如何減少特定服務的支出？（使用最佳化和費率最佳化）
  • 某一類別資源的使用情況如何隨時間變化？（效能追蹤）

領域的結構

每個領域遵循一個標準化的結構，包括：

  1. 定義：闡述為了實作預期成果所需進行的高階活動，以及該領域旨在解決的主要問題。
  2. 能力：列出實作該領域成果所需的能力。
  3. 供應商和服務提供者：提供解決方案以幫助企業在該領域內進行管理和最佳化的工具和服務提供者列表。
  4. 培訓和課程：由FinOps Foundation提供的培訓以及認證培訓合作夥伴所提供的課程，以幫助企業和員工提升在該領域的能力。

能力的結構

每個能力代表支援其對應FinOps領域的功能活動區域。每個能力的核心部分遵循一個標準化的結構：

  1. 定義：闡述該能力的範圍，以幫助理解哪個能力與特定的目標或成果相符。
  2. 成熟度評估：提供不同成熟度階段的能力示例，用於評估當前狀態並確定下一步的工作重點。
  3. 評估視角：透過不同的視角來評估FinOps實踐的強項，包括知識、流程、指標、採用和自動化五個方面。
  4. 功能活動：描述允許不同角色在FinOps生命週期中迭代滿足FinOps實踐需求的任務或流程。
  5. 成功衡量指標：至少需要一個指標來監控該能力的績效，並允許FinOps從業者設定目標。

衡量成功的指標範例

  • 成本分配：能夠被分配給其所有者的雲端支出百分比。
  • 預測變異數：預測支出與實際支出之間的變異百分比。

這些指標和相關目標能夠衡量企業在特定能力上的成功程度，並隨著實踐的成熟而提高目標值，實作短期目標的設定和客觀衡量。

FinOps 框架的實踐與客製化調整

在匯入 FinOps 框架的過程中，組織需要根據自身的營運需求對框架進行調整，以確保其能夠有效地提升雲端財務管理的效率。本章節將探討 FinOps 框架的客製化調整、相關資源的利用以及與其他財務模型的整合。

資源利用與最佳化

在實踐 FinOps 的過程中，資源利用的最佳化至關重要。其中一個關鍵指標是閒置或低效率資源所佔用的每月雲端支出比例。透過監控這一指標，組織可以有效地識別和最佳化雲端資源的使用，從而降低成本。

輸入與參考資料

為了成功實踐 FinOps，組織需要參考多種外部資料來源、報告、白皮書和培訓資料。例如：

  • 雲端採用框架
  • 供應商針對最佳化的建議
  • 業務政策和標準

這些資源能夠幫助組織更好地理解 FinOps 的核心原則，並根據自身需求進行調整。

客製化 FinOps 框架以符合組織需求

由於不同組織的營運需求各不相同，FinOps 框架被設計為具有方向性的，透過一系列的 KPI 指標和成熟度特徵來描述所需的活動和各個 FinOps 角色的責任。例如，公共部門或政府機構的預算和預測流程與私營公司大不相同。因此，組織需要根據自身的營運需求對 FinOps 框架進行調整和更新。

調整與實施

  1. 選擇合適的雲端服務提供商和供應商工具：不同的雲端服務提供商和工具會影響團隊在 FinOps 實踐中的具體活動。
  2. 修改功能活動：根據組織或行業的特定需求，調整 FinOps 框架中的功能活動，例如變更管理流程或採購審批流程。
  3. 分配角色和責任：為每個活動分配具體的角色，並對員工進行相關培訓。

實施與社群資源

FinOps 社群提供了多種實施，這些是由社群成員、工作組和合作夥伴貢獻的，旨在提供行業或供應商特定的實施方案。例如，2022 年，一組美國政府機構聯合推出了第一個政府 FinOps 實務，該根據 FinOps 框架，針對政府採購流程和規則的特殊性進行了調整。

貢獻與分享

組織在開發自己的 FinOps 解決方案時，可以將其貢獻回社群，作為實施幫助其他面臨類別似挑戰的組織。

與其他框架/模型的整合

FinOps 需要與其他財務模型和框架（如 IT 財務管理、技術業務管理、IT 資產管理和 IT 服務管理）進行整合。透過識別 FinOps 和其他模型之間的職責範圍和資訊分享機制，可以實作各個系統之間的協同工作，避免重複建設並提升整體效率。

FinOps 的使用者介面

您的報告和儀錶板為組織提供了 FinOps 的使用者介面（UI）。將您的報告視為 UI，您就可以應用數十年來對有效 UI 設計的研究成果。您應該仔細檢視這些報告，將其視為 FinOps 實踐的成果。因此，它是使用者與資料互動的介面。您在報告中呈現 FinOps 資料的方式會影響組織中 FinOps 實施的成功程度。FinOps 產品應被視為生產工作負載：品質、清晰度和使用者經驗（UX）非常重要。這些因素能夠建立對資料的信任，從而促進團隊的決策，並避免浪費時間辯護資料的品質。

製作包含漂亮圖表和資料表格的報告很容易，但要根據使用者的需求講述一個故事，並使他們能夠對需要採取的行動做出決定，卻很困難。本章將介紹一些重要的概念，以幫助您建立高品質的 FinOps 報告。在本章的其餘部分，我們將使用「報告」一詞，但這些概念和建議同樣適用於用於向使用者交付 FinOps 資料的儀錶板和商業智慧系統。

自建、購買還是使用原生工具

在思考您將作為 FinOps 實踐的一部分建立的報告時，首先要考慮的是您需要用來完成這項工作的工具和平台。正如您在第 5 章中所學到的，為了建立 FinOps 報告，您必須持續處理大量資料，因此您可能需要一整套工具。問題在於您將使用什麼型別的工具。本章中的概念並不是說您應該建立自己的 FinOps 報告平台，也不是說您不應該這樣做。我們經常看到多種工具路徑可以成功地進行 FinOps 資料管理：

  • 原生工具，如 AWS Cost Explorer、Google Cloud Cost Management 或 Azure Cost Management，始終是開始 FinOps 之旅的第一步。
  • SaaS（軟體即服務）平台，如 FinOps.org 上指定的認證 FinOps 平台，通常被用來超越原生工具，加快實作價值的速度。它們還充當了您與不斷變化的多雲計費資料之間的關鍵抽象層。
  • 「購買然後增強」是一種越來越常見的做法，大型雲花費者會利用原生工具或平台的 API，在其周圍新增自定義功能，並將資料整合進出這些工具。
  • 自製工具是 2022 年 FinOps 現狀資料中增長最快的領域；有時從頭開始構建，但通常建立在現有的商業智慧（BI）工具（如 Tableau 或 Looker）之上，或使用雲端特定的解決方案（如 AWS Cost Intelligence Dashboards 或 Google 的 BigQuery Export）。

與許多事情一樣，您採取哪種方法的答案取決於公司的資源、文化和技能。我們知道一些成功的大型 FinOps 實踐完全依賴於某個平台，也有一些完全依賴於自製工具。大多陣列織（如果不是全部的話）將依賴於多種工具和方法的組合，這些工具和方法可能會隨著其成熟度和雲使用情況的變化而改變。沒有正確的答案。

何時使用原生工具

每個雲端提供商都提供自己的成本管理工具集。我們建議您始終從原生工具開始。它通常提供您在早期成熟階段所需的基本功能。隨著您的雲花費和複雜性增加，您很可能需要超出原生工具所能提供的功能。那時，問題就變成了是自建還是購買。無論您採取哪條路徑，原生工具仍然可以作為您平台輸出資料的健全性檢查，而且它通常是您與雲端服務提供商的支援團隊溝通的方式。請及時瞭解原生工具的發展，並確保組織中的正確人員能夠存取它們。

通常，原生工具分為兩類別。首先是專門為成本管理而設計的工具，如 AWS Cost Explorer、Google Cloud Cost Management 和 Azure Cost Management。其次，隨著您的成熟，還有一些 BI 工具——如 Google 的 Looker 和 AWS 的 QuickSight——它們由雲端服務提供商提供報告範本，使您能夠透過這些工具更深入地自定義您的報告。

何時自建

在 FinOpsPod 播客中，Target 的效率工程總監 Kim Wier 講述了她的 CIO 將 Target 視為一家產品公司，因此大多數開發工作都在內部進行的故事：

「我們需要在 Target 內部具備相關知識。我們的 CIO 不想將技術知識外包給其他公司。Target 的開發工作基本上都在內部進行。我們已經建立了軟體工程文化，因此我們所有的開發工作都是內部完成的。」

因此，Target 投資了一個強大的 FinOps 工程團隊來管理資料管道、攝取，以及前端開發團隊負責為不同的角色（如工程師和長官層）開發自定義儀錶板。

人們選擇自建自己的報告層的一些常見原因包括：

  • 對自己資料的控制權
  • 能夠輕鬆地與內部資料（單位經濟資料、分類別資料、績效資料等）整合
  • 根據公司特定需求自定義功能
  • SaaS 模式往往不符合所需的合規性要求（例如 FedRAMP、SOC 2）
  • 費用結構並不總是與價值成比例
  • 報告的靈活性
  • 能夠快速進行更改
  • 能夠在公司內部執行複雜的軟體開發和資料分析
  • 組織內部對持續投資於學習雲端資料細節達成了共識，因為這些資料不斷演變和擴充套件

自建案例解析：

Target 公司因應自身需求，開發了客製化的 FinOps 系統，不僅加強了內部知識的掌握，也提升了系統的可擴充套件性和彈性。

圖表翻譯：

本圖示展示了不同的FinOps實施路徑，包括原生工具、SaaS平台和自建方案，以及它們各自的特點和適用場景。此圖示清晰地呈現了不同實施路徑之間的關係和區別，有助於讀者更好地理解FinOps的實施選擇。

圖表翻譯： 本圖表展示了FinOps的不同實作路徑，包括原生工具、SaaS平台和自建方案。每個路徑都有其特點和適用場景，有助於企業根據自身需求選擇最合適的FinOps實施方案。。

為何選擇購買FinOps平台

在實施FinOps實踐時，選擇自建或購買平台是一個重要的決策。作為國際級的技術研究者與工作者，我曾協助至少四家公司啟動FinOps實踐。進入一個組織後，我首先執行的步驟是生成使用報告，以回答以下問題：

  • 過去三個月內有多少人存取了該平台？
  • 哪些報告被頻繁使用？
  • 哪些功能正在被使用？

如果使用率低，我會探討低使用率背後的原因，評估平台的投資回報率（ROI）。我經常發現，利益相關者：

  • 偏好原生工具（例如：Cost Explorer）
  • 請求修改標準報告，但這些修改超出了平台的能力範圍
  • 只使用了平台10%的功能（大多與報告相關）
  • 想要了解平台自動化的程式碼，以便不允許自動修復，尤其是在生產例項中
  • 試圖根據組織的特定需求定製平台，但這通常需要定製或變通方法，從而增加工具的成本

要使自建或購買的平台成功，必須得到以成本意識為核心的文化支援，因為工具如果沒有底層的FinOps文化重點，就會失敗。

為何選擇購買

Equifax全球技術財務長RJ Hazra選擇購買平台，以更快地朝著FinOps的文化方面邁進，同時也專注於自動化工作：

我們使用採購的FinOps平台來產生可見性。但這還不夠——我們需要能夠快速對可見性採取行動。財務和工程需要比以往任何時候都更密切地合作。CTO優先考慮了FinOps文化轉型，並授權SRE（網站可靠性工程師）在組織中幫助啟用和說服其他工程師。我們需要一名工程師與另一名工程師討論使用最佳化，而不是構建工具。我們需要弄清楚如何構建雲端供應商的承諾，因此我們也將採購/招標納入我們的團隊。

Couchbase高階雲端FinOps經理Michael Barba對購買FinOps平台的原因提供了他的觀點：

許多公司可能沒有內部的工程資源來構建自有的工具，或者即使有，這些人員在其他地方更有價值。對於Couchbase來說，這意味著專注於構建我們銷售的服務，而不是構建內部報告，我們可以透過軟體外包。

以下是人們選擇購買SaaS平台的一些常見原因：

  • 快速實作價值：通常只需很少的IAM和雲端控制檯工作即可設定
  • 簡單的工具來建立自定義的分組，以對映支出
  • 複雜的數學運算，如攤銷RI對映已經計算好了
  • 比原生工具更詳細的最佳化功能
  • 可以存取平台公司的主題專家
  • 平台提供商減輕了雲端資料和資料品質的變化風險

FinOps社群的故事

這是來自FinOps基金會成員Slack論壇的故事，由法國跨國製造公司Saint-Gobain的Angel Alves分享：

當我加入我之前的公司時，他們已經在使用第三方工具。我試圖還原到自建的解決方案，但挑戰是缺乏資源。我可以替換類別似的報告（單一供應商，沒有Kubernetes），但我們的路線圖上有採用另一家雲端供應商和Kubernetes。當努力構建支援該路線圖的解決方案時，決定將工程資源用於其他優先事項，因此我們選擇繼續支付第三方平台費用，並專注於促進新雲端供應商和Kubernetes技術的採用。

另一個人在Slack上分享了他們對平台的看法：

對我們來說，簡單來說就是我們沒有資源/時間來自己構建。使用第三方平台為我們節省了很多時間，並允許我們自動保持最新狀態（新的AWS服務、Kubernetes支援等）。雖然正在改進，但原生工具還不夠好，至少現在還不夠。我們經常看到人們問「我如何做XYZ」這樣的問題，而第三方工具通常已經提供了這個功能。

營運報告

您的報告和儀錶板必須一致地呈現資訊，具有高資料品質和高度的審查和控制。您應該像工程團隊對待生產服務一樣對待您的FinOps報告，具備控制、品品檢查和嚴格的審查。如果您的報告中斷或開始呈現錯誤或不一致的資訊，那麼組織內的FinOps就會受到不利影響。

資料品質

Atlassian的雲端FinOps高階業務分析師Diana Mileva在FinOps X 2022上發表了關於FinOps報告中的資料品質的演講。Diana解釋了資料品質的重要性以及FinOps團隊處理資料問題的不同方法。Diana演講中的關鍵內容包括資料延遲、資料問題、品品檢查以及FinOps從業者面臨的報告挑戰。

當有人質疑我們的FinOps資料時，我們將其視為生產錯誤並開啟Jira票據進行調查。我們在整個資料集上執行自動資料品品檢查，以及及時性和準確性的SLO（服務水平目標）。我們的目標是在使用者之前檢測到任何問題，並主動向他們告知，以便他們不會根據錯誤資訊做出決策。 — Diana Mileva，Atlassian高階業務分析師

在撰寫本文時，在大多數雲端中，使用雲端資源和接收其使用的帳單資料之間存在延遲。延遲通常為24-48小時。不幸的是，延遲並不一致，尤其是在月初和月末，可能會更長。您可能會收到最近一段時間的帳單資料的部分資訊。其影響是，FinOps報告可能會錯誤地顯示最近幾小時的成本下降，並且可能會丟失最近一兩天的資料。

圖表翻譯： 此圖示呈現了雲端資源使用、帳單資料接收以及FinOps報告之間的關係。由於帳單資料接收存在延遲，可能導致FinOps報告錯誤地顯示成本下降或丟失最近一兩天的資料。

內容解密：

圖表說明瞭雲端成本管理中常見的問題，即由於資料延遲導致報告不準確。這種情況在使用即時資料做出決策時尤其重要，因為延遲可能導致成本分析出現誤差。因此，FinOps團隊需要考慮這些延遲並實施相應的檢查機制，以確保報告的準確性和可靠性。

雲端成本報告的資料品質監控與報告分級

在 FinOps 的實踐中，雲端成本報告的資料品質是至關重要的。資料品質不僅影響到企業的決策制定，也關係到 FinOps 團隊的評價和效率。本文將探討如何監控雲端成本報告的資料品質，以及如何對報告進行分級管理。

監控資料品質

雲端服務供應商的計費資料可能存在問題，例如資料不完整或不準確。這些問題可能會導致 FinOps 報告出現錯誤，從而影響到企業的決策制定。因此，監控資料品質是非常重要的。

為了監控資料品質，FinOps 團隊可以採取以下措施：

  • 移除最近幾天的資料，以避免成本下降的影響。
  • 在報告中顯示兩個日期：一個是報告最後更新的日期，另一個是建立報告時可用的資料的日期。
  • 監控計費資料的品質，並在發現問題時提醒相關人員。

程式碼範例：資料品質監控

import pandas as pd

# 載入計費資料
billing_data = pd.read_csv('billing_data.csv')

# 檢查資料是否完整
def check_data_completeness(data):
    # 檢查是否有缺失值
    if data.isnull().values.any():
        print("資料存在缺失值")
    else:
        print("資料完整")

check_data_completeness(billing_data)

#### 內容解密：
此段程式碼首先載入計費資料，然後定義了一個函式 `check_data_completeness` 來檢查資料是否完整。該函式使用 `isnull()` 方法檢查資料中是否存在缺失值。如果存在缺失值，則輸出「資料存在缺失值」；否則，輸出「資料完整」。

驗證查詢邏輯

FinOps 報告是根據查詢建立的，而查詢邏輯可能會出現錯誤。這些錯誤可能會導致報告出現錯誤，從而影響到企業的決策制定。因此，驗證查詢邏輯是非常重要的。

為了驗證查詢邏輯，FinOps 團隊可以採取以下措施：

  • 在建立報告時驗證查詢邏輯。
  • 在報告上線後持續驗證查詢邏輯。
  • 瞭解查詢的限制，避免誤解或錯誤。

查詢邏輯驗證流程

@startuml
skinparam backgroundColor #FEFEFE
skinparam componentStyle rectangle

title FinOps架構核心領域與能力解析

package "系統架構" {
    package "前端層" {
        component [使用者介面] as ui
        component [API 客戶端] as client
    }

    package "後端層" {
        component [API 服務] as api
        component [業務邏輯] as logic
        component [資料存取] as dao
    }

    package "資料層" {
        database [主資料庫] as db
        database [快取] as cache
    }
}

ui --> client : 使用者操作
client --> api : HTTP 請求
api --> logic : 處理邏輯
logic --> dao : 資料操作
dao --> db : 持久化
dao --> cache : 快取

note right of api
  RESTful API
  或 GraphQL
end note

@enduml

報告分級

在 FinOps 的實踐中，不同的報告具有不同的用途和重要性。因此，對報告進行分級管理是非常重要的。

為了對報告進行分級管理，FinOps 團隊可以採取以下措施：

  • 將報告分為受管報告和非受管報告。
  • 對受管報告進行定期維護和更新。
  • 明確標示受管報告和非受管報告。

資料品質的重要性

Diana Mileva 在 2022 FinOps X 談話中提到：「個別的資料品質報告被視為生產事件，需要快速調查，包括向報告者發出一致的溝通，並對任何實際問題進行事後分析。透過這個過程，我們不斷提高資料品質，並與我們的利益相關者建立信任，使他們相信我們認真對待資料品質問題。」

Perfect Is the Enemy of Good（完美是好的敵人）。資料品質並不意味著 100% 的即時準確性，而是意味著足夠好的資料，以便做出明智的決策。FinOps 團隊的工作是採取商業上合理的努力，以確保所呈現的資料是一致的、最新的，並且具有足夠的準確性，以便為組織做出正確的決策。

總之，監控雲端成本報告的資料品質和對報告進行分級管理是非常重要的。FinOps 團隊需要採取多種措施，以確保資料品質和報告的可信度。只有這樣，才能夠為企業提供可靠的決策支援。

玄貓 BlackCat

玄貓 BlackCat

技術愛好者，專注於分享程式開發、雲端技術與 AI 應用的心得體會。