FinOps 並非單純的成本削減，而是將財務責任融入雲端運算的變動支出模式中，透過技術、財務和業務團隊的協作，達成資料驅動的支出決策。隨著雲端服務普及，企業需要適應新的成本管理模式，從傳統的專案導向轉向產品導向，並建立更敏捷的成本控制流程。FinOps 基金會定義 FinOps 為一種不斷演進的雲端財務管理學科和文化實踐，協助企業在雲端環境中實作最大商業價值。本文將探討 FinOps 的基本概念、團隊運作、專業術語、雲端服務計費方式，並提供實務案例與操作，引導企業有效管理雲端成本，並將其與業務價值連結。
雲端財務營運（FinOps）導論
在雲端運算時代，企業面臨著前所未有的挑戰與機遇。雲端財務營運（FinOps）作為一門新興的雲端財務管理學科，旨在幫助企業在雲端支出中實作最大化的商業價值。本文的第一部分將探討FinOps的基本概念、團隊運作模式、專業術語、雲端服務計費方式，以及如何根據FinOps基金會的框架開展企業的FinOps之旅。
何謂FinOps？
簡單來說，FinOps將財務責任引入了雲端運算的變動支出模式中。這一概念不僅僅是一種結果，更代表著企業在雲端運算環境下的文化變革。隨著雲端運算的普及，技術決策和財務決策的權責正在從傳統的採購部門轉移到工程、架構和產品團隊。這種轉變促使技術、財務和業務專業人士以更高效的方式共同合作。
全球各地的企業都在積極地向雲端遷移，無論他們是否已經準備就緒。就像過去從大型主機到客戶/伺服器架構、再到網際網路和行動裝置的轉變一樣，雲端運算的轉變（以及從專案導向到產品導向的轉變）帶來了對傳統業務功能在技術成本核算、請求和管理方面的巨大變革。
FinOps要求企業承認，傳統的基礎設施管理方法不僅效率低下，而且在雲端運算環境下可能導致失控的雲端成本，從而威脅到企業的經營。雖然傳統的方法在未來仍將適用於自有基礎設施的管理，但如果沒有引入FinOps，這些方法無法有效地管理雲端運算的變動消費模式。
FinOps的定義
截至2023年初，FinOps基金會對FinOps的定義如下：
FinOps是一種不斷演進的雲端財務管理學科和文化實踐，透過幫助工程、財務、技術和業務團隊共同進行資料驅動的支出決策，使企業獲得最大的商業價值。
本文架構
本文分為幾個部分，第一部分將介紹FinOps的基本概念，包括其定義、團隊運作、相關術語以及雲端服務的計費方式。第二部分將探討如何實施FinOps，包括成本最佳化、資源分配、財務報告等實際操作層面的內容。第三部分將分享一些成功的FinOps實踐案例，供讀者參考。
結語
隨著雲端運算技術的不斷發展，FinOps作為一種新的管理理念，將在企業的雲端戰略中扮演越來越重要的角色。透過引入FinOps，企業可以更好地控制雲端成本，提高資源利用效率，從而實作商業目標。本文旨在為讀者提供一個全面瞭解FinOps的機會，並希望能夠對讀者在實際工作中實施FinOps有所幫助。
雲端財務營運（FinOps）：企業雲端成本管理的文化實踐
雲端財務營運（FinOps）是一種文化實踐，旨在幫助企業有效管理雲端成本。它強調跨功能團隊之間的協作，包括工程、財務、產品和採購等部門，共同實作更快的產品交付，同時獲得更好的財務控制和可預測性。
FinOps 的由來與定義
FinOps 是由「財務（Finance）」和「DevOps」兩個片語合而成，強調業務和技術團隊之間的溝通與協作。除了「雲端財務營運」之外，FinOps 還有多種稱呼，如「雲端財務管理」、「雲端財務工程」、「雲端成本管理」或「雲端最佳化」。無論名稱如何，FinOps 的核心目標都是最大化企業的雲端投資回報。
FinOps 的核心原則與文化轉變
本章將探討 FinOps 的核心原則、相關文化轉變的起源，以及為什麼每個企業都需要採用這種方法來實作雲端成功。在此之前，讓我們先了解一個典型的 FinOps 從業者的成長故事。
FinOps 英雄的故事
如今的 FinOps 長官者通常來自傳統 IT 和虛擬化伺服器的管理、規劃和會計背景。以下是一個典型的故事，綜合了我們多年來聽到的許多經歷。你的情況可能與此相似，或者你已經在這條道路上前進。
故事的主人公名叫 Finn。在過去，Finn 的工作相當直接：每季度進行一次回顧性的財務報告，並透過推斷使用趨勢來猜測組織未來幾個季度的生產需求，以滿足不斷變化的產品需求。支出方面很少有意外。
直到 Finn 注意到越來越多的 AWS 或 Google Cloud 應付款項沒有相應的採購訂單。他的同事 Ana 向他解釋了雲端服務的高度可變性，以及它與本地資料中心的不同之處。同時，Ana 也介紹了一種全新的管理方法和正在興起的專業領域。
Finn 認真考慮了 Ana 的建議。這聽起來很有趣，也很有吸引力。但是，他隨後回想起自己為組織的 8,000 台本地伺服器制定的流程運作得非常好。雲端服務應該不會有太大差異，只要更嚴格地應用現有的流程，就應該能夠同樣有效地管理雲端成本。
然而，下個季度，雲端支出意外翻倍。Finn 不得不再次向 Ana 求助。他承諾嘗試一套新的流程，更頻繁地檢視支出，並增加與產生支出的工程團隊的溝通時間。
突然，之前對雲端支出漠不關心的財務主管開始催促 Finn 迴歸季度報告，認為他採用的即時方法不符合公司的其他流程。技術主管則反駁說，她無法同時考慮成本和滿足產品交付的截止日期。Finn 的執行團隊鼓勵採用自上而下的控制方法。Finn 再次向 Ana 求助，而 Ana 將他介紹給了 FinOps Foundation 的同行者。透過學習他們的經驗和教訓，Finn 開始規劃如何調整公司的流程，並推動更具野心的文化變革。
實施 FinOps 的關鍵步驟
Finn 推出了一項新的雲端支出分配策略、標籤、調整雲端資源規模的標準（即根據工作負載需求調整雲端資源大小），以及初步的費率最佳化承諾。這終於為他提供了一條前進的道路，既能核算支出，又能讓團隊無摩擦地獲得所需的技術。雲端遷移開始加速。
就在事情似乎進展順利時，一位新任 CFO 上任，表示雲端服務在大規模使用時過於昂貴，提倡大規模傳回資料中心。這是 Finn 面臨的最大考驗：與他的同事合作，證明雲端服務不僅僅是一個成本中心。他們需要展示雲端服務如何以本地資料中心無法做到的方式促進創新和加快發展速度，從而為公司帶來競爭優勢。CEO 看到了更大的圖景並表示支援，為公司鋪平了採用「雲端優先」策略的道路。
從單純成本控制到商業價值創造
新獲得信心後，Finn 繼續前進，打破部門之間的壁壘，推動組織內的真實變革。但他面臨最後一場戰役：雲端支出現在已達到相當規模，影響了公司的利潤。CFO 介入，要求不惜一切代價阻止支出的上升趨勢，以確保公司的利潤率不受影響。
Finn 超越了僅僅關注雲端支出的狹隘視角，轉而採用單位經濟模型，將支出與商業價值掛鉤。這讓他有了足夠的背景，能夠清晰地證明雲端支出正走在正確的道路上。
FinOps 的持續演進
最終，Finn 意識到這段旅程只是個開始。雲端技術在不斷演進，FinOps 也隨之發展。Finn 和 Ana 將透過幫助定義最佳實踐，在這個新領域發揮最大的影響力，他們認為這是回饋社群的重要方式。
FinOps的起源與發展
FinOps的概念最早出現在2012年的灣區，由Adobe和Intuit等早期雲端擴充套件的先驅公司提出。這些公司的實踐經驗為FinOps的發展奠定了基礎。隨著雲端運算的普及，越來越多的企業開始採用FinOps實踐，以應對雲端財務和責任挑戰。
FinOps的演變
在2010年代中期，像GE和Nike這樣的大型企業開始採用FinOps實踐。隨後，澳大利亞的企業如Atlassian、Qantas和Tabcorp也開始採用類別似的做法。在2017年至2019年期間，J.R.在倫敦見證了BP、HSBC和Sainsbury’s等企業發展出這種新的做法。FinOps逐漸在全球範圍內形成，成為一種新的專業領域。
FinOps的命名
“FinOps"這個術語出現得較晚。在早期，公司將這種做法稱為"雲端成本管理"或"雲端成本最佳化”。後來，AWS和其他雲端提供商開始使用"雲端財務管理"這個術語。然而，“FinOps"這個名稱最終被廣泛採用，因為它強調了跨功能和敏捷的重要性。
FinOps的成長
如今，FinOps已經成為一種獨立的專業領域。根據LinkedIn的資料，越來越多的人將FinOps列為自己的技能。2022年的FinOps狀態資料顯示，幾乎每個主要行業都正在執行FinOps實踐。
FinOps技能在LinkedIn上的增長
此圖示展示了在LinkedIn上將FinOps列為技能的人數增長趨勢。
圖表翻譯： 該圖表顯示了隨著時間的推移，在LinkedIn平台上將FinOps標記為技能的使用者數量持續增加，反映了FinOps作為一門專業技能的成長與認可度。
FinOps的職業發展
根據2021年的FinOps狀態資料，95%在該領域工作的人認為FinOps是他們可能的職業道路。許多財富500強企業正在徵才FinOps從業人員，這導致了對FinOps認證和相關技能的需求激增。
資料驅動的決策
FinOps使得每個營運團隊（工作負載、服務、產品負責人）能夠存取近乎實時的資料，以影響其支出並做出資料驅動的決策，從而在雲端成本效率與服務的速度/效能和品質/可用性之間取得平衡。
def calculate_cloud_cost(instance_type, usage_hours, cost_per_hour):
"""
計算雲端例項的總成本。
:param instance_type: 雲端例項型別
:param usage_hours: 使用時數
:param cost_per_hour: 每小時成本
:return: 總成本
"""
total_cost = usage_hours * cost_per_hour
return total_cost
# 示例用法
instance_type = "c5.xlarge"
usage_hours = 720 # 一個月的使用時數
cost_per_hour = 0.192 # 每小時成本
total_cost = calculate_cloud_cost(instance_type, usage_hours, cost_per_hour)
print(f"雲端例項 {instance_type} 一個月的總成本為：${total_cost:.2f}")
內容解密：
上述程式碼定義了一個名為calculate_cloud_cost的函式，用於計算雲端例項的總成本。該函式接受三個引數：instance_type（例項型別）、usage_hours（使用時數）和cost_per_hour（每小時成本）。函式內部將使用時數和每小時成本相乘，得出總成本，並傳回該值。在示例用法中，我們計算了一個特定例項型別一個月的總成本，並列印出結果。
FinOps 不只是省錢，更是創造價值
FinOps 的核心並非單純的成本削減，而是透過雲端資源的有效利用，推動業務增長、加速產品開發，甚至實作資料中心的關閉。FinOps 的目標是消除阻礙，讓工程團隊能夠更快速地交付更好的功能、應用和遷移方案，並促進跨部門對投資決策的討論。
即時反饋（又稱「Prius 效應」）
成功的 FinOps 實務包含三個關鍵要素：
- 即時報告
- 適時流程
- 團隊協作
即時報告的反饋迴圈對人類行為具有強大的影響力。我們發現，向工程師提供與其行為相關的即時反饋，能夠自動改善其行為模式。
「Prius 效應」的啟示
開過電動車的人可能都體驗過「Prius 效應」。當你踩下油門時，儀錶板會顯示能量從電池流向引擎；當你鬆開油門時，能量又會迴流到電池中。這種即時的反饋機制會立即影響駕駛行為，讓你開始駕駛得更為節能。
同樣的原理也適用於 FinOps。即時的可見性讓團隊能夠根據即時的資料做出明智的決策。在傳統的資料中心環境中，工程師的行為很難與公司的財務影響直接掛鉤，因為硬體採購和折舊排程通常需要很長的時間。
案例分享
曾經有個大型雲端使用者，每年雲端支出高達數億美元，卻從未將成本資訊與相關的工程師分享。直到他們開始實施 FinOps，將成本資訊即時反饋給工程師，結果帶來了戲劇性的改變。其中一個團隊發現，他們每月花費超過 20 萬美元在不必要的開發環境上。僅僅花費三個小時的工程時間，他們就關閉了這些資源，節省了足夠的資金來僱用一個新的工程團隊。
FinOps 的核心原則
在與成功匯入 FinOps 的實務者交流後，我們總結出以下核心價值：
- 團隊協作：財務和技術團隊需要近乎即時地合作，因為雲端服務是按資源、按秒計費的。
- 根據業務價值的決策：使用單位經濟效益和價值導向的指標來評估雲端投資的效益，而非僅僅關注總支出。
- 全面擁抱雲端成本責任：讓工程師從架構設計到營運都對成本負責，並賦予產品團隊自主管理雲端資源的權力。
透過遵循這些原則，企業能夠建立起一個自我管理的成本文化，在保持業務敏捷性的同時最佳化成本。
什麼是 FinOps？
FinOps 是一種管理雲端成本和價值的實踐，旨在幫助企業更好地理解和最佳化其雲端支出。隨著雲端運算的普及，企業面臨著日益增長的雲端成本，如何有效地管理和最佳化這些成本成為了一項重要的挑戰。
FinOps 的核心原則
即時且可存取的 FinOps 報告：FinOps 報告應該是即時且可存取的，這有助於企業更好地理解其雲端支出。
- 流程和分享成本資料應該在資料可用的情況下盡快進行。
- 即時的可視性有助於更好地利用雲端資源。
- 快速的反饋迴圈會導致更高效的行為。
- 為組織的所有層級提供一致的雲端支出可視性。
- 建立、監控和改進即時的財務預測和規劃。
- 趨勢和變異分析有助於解釋成本增加的原因。
- 內部團隊基準測試推動最佳實踐並慶祝成功。
- 行業同行基準測試評估公司的表現。
集中式團隊推動 FinOps：集中式團隊鼓勵、推廣和支援最佳實踐，在分享責任模型中，就像安全團隊一樣，雖然有集中式團隊，但每個人仍然對自己的部分負責。
- 需要高層的支援來推動 FinOps 及其實踐和流程。
- 費率、承諾和折扣最佳化是集中的，以利用規模經濟。
- 消除工程師和營運團隊對費率談判的需求，讓他們專注於最佳化自己的環境。
利用雲端的變動成本模型：雲端的變動成本模型應該被視為提供更多價值的機會，而不是風險。
- 接受即時預測、規劃和採購容量。
- 敏捷迭代規劃優於靜態長期計劃。
- 接受主動系統設計，持續調整雲端最佳化，而不是不頻繁的反應式清理。
何時開始 FinOps？
決定何時開始 FinOps 自本文第一版以來已經發生了很大變化。幾年前，這種做法通常在公司經歷了意外的大量雲端支出後才開始。現在，在雲端成熟度生命週期的早期階段，公司就開始採用這種做法。這在一定程度上是由於對雲端計費所帶來的挑戰有了更好的理解，也由於三大雲端提供商積極推動客戶提前解決成本問題。
三大雲端提供商也積極成熟了成本工具和資料，以便工程師和架構師在設計雲端解決方案時盡早考慮成本。
不幸的是，許多人仍然認為 FinOps 只關乎節省成本或減少消費；因此，這些人傾向於認為實施 FinOps 的時機應該由雲端支出的金額來衡量。可以肯定的是，這在某些層面上是有道理的。例如，大型雲端支出者可以立即找到很多潛在的節省機會。然而，為雲端支出創造問責制和完全分配成本的能力是高效 FinOps 實踐的重要組成部分，如果從事後節省成本的角度思考，往往不會實施這些。
此外，FinOps 對工程團隊和財務團隊所需的文化和技能變化可能需要數年時間才能實施。組織越大，環境越複雜，就越能從早期開始實踐中獲得複合效益。
成功的 FinOps 實踐不需要龐大的雲端佈署或數百萬美元的雲端帳單。早期開始 FinOps 將使組織更容易就雲端支出做出明智的決定，即使其營運剛剛開始擴充套件。因此，瞭解 FinOps 成熟度至關重要；建立 FinOps 實踐的正確方法是讓組織從小開始，並隨著業務價值的增長而擴大規模、範圍和複雜性。
正如您將在第 6 章中瞭解到的，無論您的過去經驗如何，都無法從零開始安裝一個完全成熟的 FinOps 實踐。它需要時間來改變工程師的工作方式，並教育財務人員瞭解雲端的工作原理，並讓高層管理人員支援使用雲端的正確理由。這是一種工作方式的文化變革，而資料驅動的問責制和決策的能力必須隨著時間的推移而建立。
沒有哪個團隊能夠單獨完成 FinOps；中央 FinOps 團隊致力於使組織內各個團隊能夠共同管理工作中的雲端業務價值。此外，在大型組織中，不同團隊可能在很長一段時間內處於 FinOps 之旅的不同階段，因為每個團隊都在達到採用 FinOps 的臨界點。
儘管本文可以指導組織成功地實踐 FinOps，並幫助團隊避免常見的陷阱，但沒有任何組織可以直接從零 FinOps 跳躍到高效 FinOps。每個組織和團隊都必須逐步實施 FinOps 流程，花時間在過程中相互學習。
程式碼範例：
def calculate_cloud_cost(instance_type, usage_hours, rate):
"""
計算雲端例項的成本。
:param instance_type: 例項型別
:param usage_hours: 使用小時數
:param rate: 每小時費率
:return: 總成本
"""
total_cost = usage_hours * rate
return total_cost
# 使用範例
instance_type = "t2.micro"
usage_hours = 720 # 一個月的使用小時數
rate = 0.025 # 每小時費率（美元）
cost = calculate_cloud_cost(instance_type, usage_hours, rate)
print(f"預估 {instance_type} 的月度成本為: ${cost:.2f}")
內容解密：
此 Python 程式碼範例展示瞭如何計算特定雲端例項型別的預估月度成本。它接受例項型別、使用小時數和每小時費率作為輸入，並傳回總成本。程式碼結構清晰，易於理解，並且提供了實際的使用範例。這種簡單而實用的方法展示瞭如何使用程式碼來支援 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圖表翻譯： 此圖表展示了計算雲端例項成本的基本流程。首先，定義要使用的例項型別；接著，取得該例項的使用小時數；然後，確定適用的每小時費率；隨後，利用這些資訊計算出總成本；最後，將結果輸出。這樣的流程圖清晰地呈現了計算過程中的每一步驟，有助於理解整個成本計算的邏輯。
