FinOps 不僅僅是降低雲端成本，更是一種文化轉型，旨在將財務責任分散到工程團隊，使他們能夠根據資料做出最佳決策。這需要與現有的 IT 管理和財務學科（如 ITSM、ITIL、ITFM 和 TBM）緊密合作，打破部門壁壘，建立共同目標和流程。透過分享影響力、術語和流程，例如將 FinOps 標籤策略與現有的 ITAM 資源分配規則整合，可以提升整體 IT 管理效率。FinOps 與其他框架最大的區別在於其專注於公有雲和 SaaS 的可變支出，並需要處理龐大且快速變化的資料集。
圖表翻譯：此圖示顯示了 FinOps 與其他 IT 管理和財務學科之間的協作關係。
內容解密：
此圖表展示了 FinOps 如何與其他多個 IT 管理和財務學科相互連線。其中包括 IT 管理學科（如 ITSM、ITIL 和 CM）、IT 財務學科（如 ITFM、TBM、SAM 和 ITAM）、資訊安全 / 網路安全以及 GreenOps。這些學科之間的協作有助於更好地管理雲端資源和成本。
與其他框架和方法論的協同運作
在匯入FinOps的過程中，與其他已存在的框架和方法論建立良好的合作關係至關重要。這不僅能避免資源的浪費和重複勞動，還能透過分享目標、影響力、術語和流程來提升整體的IT管理效率。
建立共同目標
要消除「我們對他們」的對立心態，因為這種態度只會降低團隊間的協作意願。相反，應該明確定義各團隊之間的共同目標，以確保大家朝著同一個方向努力。例如：
- 誰負責提供及時決策所需的資料，以及這些資料如何幫助企業衡量各種取捨以最大化業務價值？
- 各團隊如何共同管理IT支出和資源使用率？
- 如何控制和治理IT支出，並由誰來定義相關規則？
透過識別各框架的優勢和劣勢，可以制定出互補的策略，以更好地實作組織的整體目標。
FinOps與其他框架的差異
FinOps主要關注於公有雲和SaaS供應商的可變支出成本，而其他框架則往往涵蓋更廣泛的IT相關支出，如人員成本、諮詢契約、許可證管理和資料中心營運等。此外，FinOps需要處理極為龐大和複雜的資料集，並且需要在盡可能短的時間週期內（例如每小時或每天）執行，以應對雲端使用情況的快速變化。
分享影響力、術語和流程
現有的框架團隊可能已經對某些人員具有一定的影響力，而FinOps的引入可以為這些團隊提供擴大影響力的機會。透過統一術語和訊息傳遞，可以形成一種共同的聲音，向組織內部強調各框架的重要性和互補性。
在實施FinOps或其他框架時，應盡量重用現有的政策、標準和術語，以避免不必要的混淆和重複工作。例如，如果已經有ITFM或TBM團隊定義了資源分配規則，那麼在制定FinOps的標籤計劃時，可以直接借鑒這些現有的規則。
分享基礎設施和知識
現有的框架團隊可能已經建立了報告和儀錶板，供工程師、財務人員和管理階層使用。與其重新建立新的報告，不如與這些團隊合作，將FinOps的訊息整合到現有的報告中。這樣不僅可以減少建立FinOps報告的工作量，還能避免對相關人員造成額外的負擔。
FinOps是一門整合性的學科，它將組織內多個其他學科的工作聯絡在一起。因此，FinOps從業人員應與其他相關學科的從業人員分享知識和教育計劃，以建立對彼此框架的共同理解。
與其他框架的協同運作
在組織內部與管理其他框架的團隊進行協調與互補是一個重要的步驟。各個團隊之間可以互相學習，並找到可以互相支援的領域。透過合作，可以避免重複工作並促進彼此目標的實作。具體來說，需要決定哪個團隊負責重疊責任中的每個組成部分，並在組織內部建立一致的訊息傳遞，圍繞著雲端支出和業務價值決策。
FinOps 極樂世界：資料驅動的決策
FinOps 的極樂世界是指支出責任完全分散到工程團隊，他們每天都能做出有效的選擇，而不僅僅是在有強制要求時才這樣做。在這種狀態下，長官層的支援使成本成為與其他關鍵軟體效能指標一樣重要的因素。
目標是讓組織能夠根據業務價值持續、資料驅動地做出雲端支出的決定。這些決策涉及多個角色，包括：
- 架構師在設計基礎設施時
- 工程師在編寫程式碼和佈署服務時
- 財務和採購團隊在對雲端供應商做出承諾時
- 長官層在推動技術戰略時
這是一個持續的協作過程，只有在 FinOps 文化轉型發生後才能完全實作。
單元經濟學與指標
單元經濟學指標的一個簡單定義是與特定商業模式相關的直接收入或成本，以每單位為基礎進行表達。對於導向客戶的應用程式來說，這個單位可能是使用者或客戶訂閱；對於電子商務平台來說，可能是交易；對於航空公司來說，可能是座位里程。
根據 FinOps 基金會單元經濟學工作小組的工作，更長的定義正在發展中：
內容解密：
單元經濟學指標是用於衡量業務運作效率的重要工具。它們幫助工程師、財務團隊和管理階層瞭解雲端支出的價值，並根據資料做出明智的決策。透過將雲端成本與業務產出掛鉤，組織可以最佳化成本效率，並確保技術投資帶來預期的業務價值。
FinOps 流程圖
圖表翻譯： 此圖示展示了 FinOps 流程中的不同角色之間的協作關係。架構師設計基礎設施，工程師編寫程式碼和佈署服務，財務和採購團隊根據雲端供應商的承諾做出決策，而長官層則推動技術戰略。這種迴圈表示了各個角色之間的持續協作和反饋。
雲端單位經濟學：實作利潤最大化的關鍵
雲端單位經濟學（Cloud Unit Economics）是一種根據客觀衡量組織績效的利潤最大化系統，不僅針對FinOps目標，還涵蓋市場上的業務表現。雲端單位經濟學透過衡量與雲端軟體開發和交付相關的邊際成本（即單位成本指標）以及邊際收益（即單位收益指標）來實作其崇高目標。
多層次的單位經濟學
沒有單一的指標能夠適用於整個組織。您需要在組織內的多個層面，以不同的輸入和粒度來進行單位經濟學分析。您可以進行高層次的單位經濟學分析，例如每個客戶的雲端成本，但也可以在應用程式層面進行單位經濟學分析，例如每筆交易的成本，甚至可以在個別服務層面進行單位經濟學分析，例如每個微服務執行的計算成本。
單位經濟學不必與收益掛鉤
許多組織無法將雲端支出與頂線收益指標直接掛鉤，無論是由於業務型別還是成熟度。單位經濟指標應該像巢狀娃娃一樣，在多個層面發揮作用。如果您是投資組合經理，您可能會為每個應用程式進行根據營運活動的單位經濟學分析，或者為整個業務部門進行分析。作為應用程式負責人，您可能會有一套衡量指標，告訴您應用程式執行某項操作所需的成本，而這項操作無法與收益直接掛鉤。每個指標可能非常不同，沒有一個能夠完全反映雲端價值，但它們共同提供了方向，可以幫助您（和您的高管）開始朝著最大化雲端價值的方向邁進。
計算單位經濟指標
在每個雲端單位經濟學計算中，都有一個分子和分母。您將某個指標（通常是活動或產出指標）除以另一個指標（通常是雲端支出的某個部分），以得出單位指標值。
- 分子：是雲端支出的衡量指標，量化了架構和工程團隊所做的選擇。
- 分母：則是工程價值衡量指標、財務價值衡量指標或業務價值衡量指標，為該支出提供了重要的背景。
尋找盟友與現有的單位經濟分析
在組織的某個地方，某種形式的單位經濟學已經在進行。Anthony “TJ” Johnson，Box, Inc.的雲端業務經理建議，首先要尋找已經在使用單位經濟指標的管理者。通常是財務部門的人員可能已經向業務部門負責人提供了相關資料，以衡量他們對技術投資的利用效率。這成為了一個潛在的衡量指標，可以將雲端資訊基礎設施納入其中，尤其是如果您是雲端優先或雲端原生組織，並且將其作為未來的發展路徑。
找到正確的衡量單位是一門藝術
找到正確的衡量單位來評估您的業務是一門藝術，並且可能會隨著時間的推移而改變或更新。具有複雜結構和多種產品供應的組織通常會有許多不同的單位經濟指標，每一個都與特定的產品、應用程式或服務相關。
花費不是問題，浪費才是問題
回想FinOps生命週期中的資訊階段。該階段專注於揭示雲端成本，以建立對支出的認識和問責制。透過對雲端支出的可見性，您能夠確定趨勢並為未來成本建立預測。當雲端成本超過您的預算時，下一步就是開始調查增加的原因並解釋正在發生的事情。
內容解密：
計算單位經濟指標時，分子代表雲端支出，分母則代表某種形式的價值衡量。透過這兩個值的計算，可以得出用於管理業務某個部分或提供洞察以考慮變更的雲端單位經濟價值衡量指標。尋找組織內已經進行單位經濟分析的人員，並嘗試將雲端資訊基礎設施納入他們的衡量指標中，是推動雲端單位經濟學成熟的重要步驟。
圖表翻譯： 此圖示展示了進行雲端單位經濟分析的基本步驟，從確定分子和分母，到計算單位經濟指標，最後根據結果調整策略並持續最佳化。圖中清晰地展示了整個過程的流程和邏輯關係，有助於理解如何有效地實施雲端單位經濟學分析。
雲端成本最佳化中的單位經濟指標
在進行雲端成本最佳化時，除了使用成本指標外，其他相關指標也能提供重要的商業背景。單位經濟指標（unit economics）能讓我們瞭解雲端支出變化背後的商業意義。有時，SaaS 產品會以業務產生的收入作為簡單的起始點，透過將總雲端成本除以產生的收入，可以判斷雲端支出的增長是否帶來利潤增長。
單位經濟指標的選取
理想的單位經濟指標應該具有低波動性，即業務某一部分的決策不會影響其他部分的指標。讓我們來看一個例子。
圖表 1：公司收入與雲端成本的關係
當公司引入免費方案時，雲端支出增加但收入沒有直接影響，這使得單位經濟指標受到影響。如果工程團隊使用這個指標來評估基礎設施成本與業務價值的匹配程度，這將產生負面影響。
圖表 2：引入免費方案後的公司收入與雲端成本
為瞭解決這個問題，可以改用月活躍使用者數（MAU）作為單位經濟指標。當活躍使用者增加時，雲端支出也會增加，這樣單位經濟指標保持一致。
圖表 3：月活躍使用者數與公司雲端成本的關係
更換為 MAU、服務頁面數或 API 呼叫次數等單位指標，可以提供更好的背景。當客戶付費價格變化時，這些單位指標的值不會改變。這些指標能夠衡量雲端平台創造的業務吞吐量，特別是在與雲端支出相關的情況下，成為做出雲端成本效率決策的關鍵因素。
活動導向成本法
對於業務模型或結構複雜的公司，可以使用活動導向成本法（Activity-Based Costing）來衡量雲端支出所創造的非貨幣性產出單位。這種方法關注特定應用或服務執行的任務，例如處理 API 呼叫、傳回一定單位的資料或行動資料等。
圖表 4：檔案渲染數量與雲端成本的關係
在這個例子中，追蹤服務渲染的檔案數量和相關的雲端成本，可以發現渲染任務增加時，雲端成本也會增加。
圖表 5：檔案渲染成本的變化
如果雲端成本在月中增加，但渲染任務數量沒有變化，則表明某些東西已經改變，例如使用的資源增加或預留資源不再適用。
程式碼範例：計算檔案渲染成本
def calculate_rendering_cost(num_files, cost_per_file):
"""
計算檔案渲染的總成本。
:param num_files: 渲染的檔案數量
:param cost_per_file: 每個檔案的渲染成本
:return: 總渲染成本
"""
total_cost = num_files * cost_per_file
return total_cost
# 範例用法
num_files_rendered = 1000
cost_per_file_rendered = 0.05 # 每個檔案的渲染成本為 0.05 美元
total_rendering_cost = calculate_rendering_cost(num_files_rendered, cost_per_file_rendered)
print(f"總渲染成本：${total_rendering_cost:.2f}")
內容解密：
此程式碼定義了一個函式 calculate_rendering_cost，用於計算檔案渲染的總成本。函式接受兩個引數：num_files（渲染的檔案數量）和 cost_per_file（每個檔案的渲染成本）。函式內部將這兩個引數相乘，得到總渲染成本，並傳回該值。在範例用法中，我們計算了 1000 個檔案的渲染成本，每個檔案的成本為 0.05 美元，最終輸出總渲染成本。
雲端成本最佳化流程
@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：資料驅動的決策
迴歸鐵三角原則
要在組織中實作有效的決策，最佳方法之一是運用鐵三角原則（即在「好」、「快」和「便宜」之間取得平衡），正如第14章所討論的那樣。這種方法有助於架構決策過程。
單位指標為團隊提供了必要的資料，以便衡量基礎設施變化對成本的影響。技術營運團隊和財務部門之間的對話不再侷限於技術細節，而是轉向討論這些變化將帶來的影響。這使工程師能夠專注於在單位指標支援的財務約束條件下工作，如第26章所述。這樣一來，企業能夠根據變更的預期影響進行權衡取捨，例如將每活躍使用者的成本提高2%是否會使應用程式效能提升10%，並帶來正面的商業成果，從而使額外投資變得值得。
有些FinOps實踐者選擇不實施單位指標，或因其複雜性而延遲實施。最終，FinOps的理想狀態是讓組織能夠根據雲端支出的價值進行決策，無論採用何種方法來衡量價值並與成本進行比較：決定何時增加支出以對雲端環境的價值產生正面影響，以及何時降低成本更為合適。
當你將單位指標應用於FinOps生命週期的最佳化階段時，你的目標設定將從僅使用營運指標（如達到90%的承諾基礎折扣覆寫率）轉變為使用對收入產生影響的目標，如將每訂閱者的成本降低25%。前者可能對企業有所幫助，但也可能分散對真正重要事項的注意力。
方程式中缺失的部分
到目前為止，你一直在使用雲端支出作為分子；然而，你可能需要將其他多項成本納入總體擁有成本（TCO）。畢竟，基礎設施成本往往相對於勞動成本而言微不足道。
單位指標在你擁有所有相關成本資料（包括勞動成本等）時最為有用。到目前為止，我們分享的成功FinOps案例都僅關注雲端成本。僅將雲端支出除以單位提供的有限背景對於瞭解真正的單位成本至關重要。實際上，企業還有許多其他成本會影響產生收入的總成本。
程式碼範例：計算單位成本
def calculate_unit_cost(total_cloud_spend, total_labor_cost, total_units):
"""
計算包含雲端支出和勞動成本的單位成本。
:param total_cloud_spend: 總雲端支出
:param total_labor_cost: 總勞動成本
:param total_units: 總單位數
:return: 單位成本
"""
total_cost = total_cloud_spend + total_labor_cost # 合計總成本
unit_cost = total_cost / total_units # 計算單位成本
return unit_cost
# 範例用法
cloud_spend = 10000 # 雲端支出
labor_cost = 50000 # 勞動成本
units = 1000 # 單位數
unit_cost = calculate_unit_cost(cloud_spend, labor_cost, units)
print(f"單位成本：{unit_cost}")
內容解密：
- 函式定義：
calculate_unit_cost函式接受三個引數：total_cloud_spend（總雲端支出）、total_labor_cost（總勞動成本）和total_units（總單位數）。 - 總成本計算：將
total_cloud_spend和total_labor_cost相加，得到total_cost，代表總成本。 - 單位成本計算：將
total_cost除以total_units，得到每個單位的成本，即unit_cost。 - 傳回結果：函式傳回計算出的
unit_cost。 - 範例用法：透過提供具體的雲端支出、勞動成本和單位數值，展示如何呼叫函式並列印預出計算結果。
在第15章中，我們討論了將服務重構為無伺服器架構模型。在決定是否重新架構服務時，應權衡基礎設施費用和潛在節省與重構的勞動成本。此外，一旦服務執行在無伺服器架構中，服務的成本就不再僅僅是雲端資源的收費，更與勞動力的營運成本有關。
當然，你可以擴充套件FinOps本身以追蹤雲端賬單以外的成本，如仍在資料中心執行的裝置成本或軟體授權的額外費用。然而，在我們看來，FinOps與現有的財務模型（如第25章所述）共同工作會更有意義。與這些其他框架合作，你可以豐富用於決策的單位指標，使其包含總體成本，而不僅僅是雲端支出。
使用FinOps成熟度模型作為指導，以下是將非雲端成本納入單位經濟學分母的典型階段，如最近的FinOps Foundation工作組的《雲端單位經濟學介紹》檔案中所述：
將非雲端成本納入考量的階段
階段1：僅考慮雲端成本
根據應用的複雜性，這也可以分多個階段進行，其中一些雲端成本最初被視為「直接」成本，而其他則被視為「分享」成本。
階段2：雲端 + SaaS + 授權成本
這可能包括Datadog、ServiceNow或PagerDuty等SaaS工具，或是在雲端基礎設施上執行的BYOL（自帶授權）軟體，如Windows或SQL Server。一旦開始納入SaaS工具或授權費用，你可能需要與負責該產品的團隊合作，以瞭解他們關心的KPI以及他們如何量化時間花費，例如SAM或ITAM團隊。
階段3：雲端 + SaaS + 人力資本 + 混合成本
這涉及到納入勞動力等成本，甚至是支援特定產品或服務的本地佈署成本。執行階段通常是公司開始為複雜系統的不同部分收集多個指標，並隨著時間推移變得更加細化的時候。
當你開始在FinOps單位經濟學中納入非雲端成本（如勞動力和非雲端技術投資）時，你管理的就不再只是雲端成本，而是更大的業務。當FinOps文化允許組織內的所有團隊協作地檢視所有的成本資料，並與組織從中獲得的價值進行比較，然後做出明智的決策時，這就是單位經濟資料驅動的雲端價值決策的理想狀態。這不是單靠FinOps就能實作的。隨著雲端越來越成為未來每個組織數位價值的驅動力，這是無法在沒有FinOps參與下完成的。
何時算是贏得了FinOps？
我們想強調的是，FinOps沒有終點線。我們無法告訴你一個界限，超過這個界限你就再也沒有東西可學，也沒有事情可做了。實踐會不斷演變，雲端服務提供商不斷釋出更新其產品和相關帳單資料。簡而言之，只要雲端在進化和變化，FinOps就會持續演進。
目前實施FinOps的公司——尤其是那些處於雲端旅程早期的公司——將透過避免賬單衝擊時刻和相關創新放緩，從他們的雲端投資中獲得最大的價值。在這些組織中，FinOps不會被視為由單一角色或小型團隊負責；相反，組織內的所有相關人員（從工程到財務到採購和業務）都會明白他們在整個公司實踐FinOps中的角色。