FinOps 的實踐不應等到雲端成本失控才開始，而應從一開始就納入規劃。早期匯入 FinOps 有助於建立成本意識，並隨著業務規模擴大逐步完善流程。這與過去在成本達到臨界點時才被迫實施的模式截然不同，那種亡羊補牢的方式會拖慢創新和遷移速度。現在，越來越多的企業意識到 FinOps 的重要性，並開始在早期階段就引入 FinOps 基礎建設，例如設定帳戶、標籤和標記層次結構。隨著企業雲端使用成熟度的提升，FinOps 實踐也會逐步擴充套件，最終形成一套完整的成本管理體系。
為何及早匯入FinOps：文化轉變與即時決策的重要性
如同DevOps一樣，FinOps代表著一種文化上的轉變，而越早開始實踐FinOps的組織，將越早享受到其帶來的益處。我們的經驗告訴我們，FinOps應該從第一天就開始實施，但隨著規模的擴大，會有更多的流程被納入進來。多年的觀察顯示，公司通常在兩個典型的時間點開始採用FinOps：
早期匯入與危機驅動的FinOps
過去，最常見的做法是在情況失控時才開始實施FinOps。在這種情況下，當支出達到某一臨界點時，高層管理者會強制要求實施新的管理模式。然而，這並不是理想的匯入方式，因為在這種「高層火警演習」期間，創新和遷移的速度會減慢，甚至暫時停止。
較明智的做法是，那些曾經經歷過雲端旅程並且認同FinOps.org上FinOps成熟度模型的企業高層所採取的方法。FinOps實踐需要以與公司在FinOps成熟度週期中的位置以及公司對雲端使用的成熟度相匹配的速度發展。最初，可能會指派單個人員來管理對雲端供應商的承諾。他們會著手實施初始的帳戶、標籤和標記層次結構。隨著實踐的擴大，流程的每個部分都可以擴大規模。現在，我們看到大多數新的從業者都是以這種方式加入FinOps基金會。
啟動FinOps的關鍵步驟
無論公司如何決定實施FinOps，第一個關鍵步驟是開始向相關團隊及時提供雲端支出的可視性，以便每個人都能開始瞭解正在發生的事情，並在成本超支變得過大之前確定如何解決。在成熟的實踐中，透過周到的架構設計，在成本超支甚至開始之前就能夠預防它們。在實作這種可視性的同時，FinOps團隊開始教育更廣泛的業務利益相關者。當跨功能團隊一起工作時，財務人員將學習更多關於雲端的語言，而工程師則開始掌握相關的財務概念，業務人員則能夠就資源投資做出更好的決定。
從終點出發：資料驅動的決策
FinOps中最重要的概念之一是使用單位經濟指標來實作工程團隊的資料驅動決策。其理念是根據業務產出或價值指標來衡量雲端支出，然後根據這些指標提供的洞察採取行動。這就是我們之前討論過的「Prius效應」的即時反饋迴圈。
選擇合適的業務指標
為基礎設施的每個部分選擇合適的業務指標是一個複雜的過程，這個過程將在第26章中詳細介紹。目前，主要要記住的是，提供單位經濟指標以實作資料驅動決策依賴於FinOps的幾乎所有方面，包括標籤、成本分配、成本最佳化、與其他財務框架的連線以及FinOps營運。
業務指標之所以重要，是因為它可以將討論從僅僅關於支出的金額轉變為關於效率和雲端支出價值的討論。能夠說「為客戶提供服務的成本是X美元，而這些客戶帶來了Y美元的收入」，這為評估X美元和Y美元是否是合理的投資提供了背景。然後，隨著產品的發展或完全改變，新功能出現，公司能夠透過這些業務指標來衡量這些變化的影響。
FinOps實踐的價值
最終目標是能夠區分好的雲端支出和壞的雲端支出，並隨著時間推移跟蹤這些決策。你應該在閱讀本文以及在組織內實施FinOps的過程中牢記這些業務價值指標。我們正在努力實作的理想狀態是，你的組織能夠持續地根據從雲端支出中獲得的價值做出資料驅動的業務決策。
來自雲端的故事——Jason Fuller
Jason Fuller負責HERE Technologies（一家提供全球地圖服務的多國企業）的雲端業務，他在一次FinOps基金會會議上分享了一個故事，很好地說明瞭這一點：
「我們有一個團隊的預算嚴重超支，每月使用了90億個lambda函式。我無法直接影響這一點。但我能做的是與團隊坐下來，瞭解你在lambda中編寫的演算法品質，並判斷它是否可以更加精簡。
我們需要你提供的毫秒級精確度嗎？是的。好的。現在，業務部門明白了這是有價值的。
現在，我們可以根據我們認為這個產品的價值以及我們認為可以在市場上為它獲得多少價格來做出商業決策。
結果是，我們不再為基礎設施爭吵——我們現在討論的是它的商業價值。」
為何需要FinOps？
當我們審視企業使用雲端運算的原因及其所帶來的利益時，FinOps的重要性與必要性便顯而易見。成功的FinOps實踐擴充套件並加速了雲端運算所帶來的商業利益。雲端運算不應僅被視為一種重新託管的替代方案，而應被視為商業加速器。同樣地，FinOps也不僅僅是關於成本最佳化，更是關於最大化價值。
正確使用雲端的理由
成本文省常被吹捧為雲端運算的主要好處，但最成功的雲端優先企業已經向世界展示，擴充套件性和創新才是真正的優勢。以Spotify為例，它利用雲端的規模直接向全球客戶串流內容。Flickr則將大量的客戶資料安全地儲存在雲端，以實作安全、快速的存取。由於雲端運算的存在，這些企業能夠以過去使用自有資料中心無法做到的方式進行競爭。價格始終是一個因素，但它遠遠落後於規模和全球可用性。
使用雲端運算也使企業能夠更快地行動並增加收入。即使是金融服務、航空公司和零售公司等「非科技」領域的企業，也正在轉向軟體和資料來區分自己與競爭對手。事實上，2022年FinOps資料中排名第一的行業是金融服務和銀行業。
軟體幫助企業與客戶建立聯絡，最佳化實體資產，並監控工廠。它能夠傳遞最新的流行歌曲、零售包裹，甚至將人員運送到全球各地。
我們不再是一家航空公司。我們是一家擁有翅膀的軟體公司。 —Veresh Sita，Alaska Airlines首席資訊官
截至2023年初，大多數《財富》500強企業都是公有雲的大量消費者，而三大雲端供應商本身也躋身或接近該榜單前15名最有價值的公司之列。微軟、亞馬遜、阿里巴巴和騰訊等科技巨頭與摩根大通、滙豐和美國銀行等銀行業巨頭並駕齊驅，都將雲端運算作為與客戶建立聯絡的主要方式。
即使是傳統上非科技類別的公司，如埃克森美孚和強生，也正在加快數位轉型的步伐，以區分自己與競爭對手。
成功的關鍵組成部分現在是商業敏捷性和創新速度。隨著企業逐漸擺脫將雲端視為成本避免策略的思維，它們越來越將雲端視為其主要創新驅動力。XaaS（任何事物即服務）使企業能夠更快地嘗試更多技術，而IaaS（基礎設施即服務）則以前所未有的速度和規模提供運算資源。
在資料中心架設伺服器並從頭開始構建已經「解決的問題」已不再是企業區分自己的方式。雲端運算已使最新的技術——可擴充套件基礎設施、機器學習或物聯網（IoT）——按需提供給各種規模的企業。在執行內部佈署資料中心時，傳統企業很難與Google、AWS和微軟在執行基礎設施和吸引人才方面的技術規模競爭。
贏得勝利的企業圍繞著授權工程師編寫更好、更快的程式碼，以向客戶交付價值而團結起來。而這些工程師可以越來越多地獲得他們想要的任何東西，無論何時他們需要它。雲端運算從根本上改變了他們交付更具競爭力產品的能力。
雲端價值主張
來自FinOps Foundation的FinOps Certified Professional課程的圖2-1闡述了推動組織業務成果的飛輪效應。這對高管來說很有吸引力，他們可能會覺得自己的IT職能有潛力推動組織的數位未來，而採用公有雲是實作這一願景的關鍵工具。
圖2-1：FinOps Certified Professional課程中的雲端價值主張
雲端服務供應商真正成為任何組織內創新的倍增器——具有幾乎無限的可能性。
雲端支出持續加速
當我們撰寫本文的第一版時，雲端支出已經開始達到一個臨界點。2019年，Gartner曾預測2022年的雲端支出將達到約3600億美元，但實際上2022年的支出接近5000億美元。最新的Gartner預測顯示，到2025年，將有超過一半的企業IT支出轉移到雲端。這意味著可能有多達1.8兆美元被轉移到雲端。根據我們的經驗，企業長期以來一直低估了他們的雲端支出，行業預測經常被向上修正。雲端正在成為企業IT預算的重要組成部分，對企業損益表（P&L）的收入和支出兩端都產生了影響。大型企業通常每年在雲端的支出達到數億美元，我們知道有許多個別企業的年度公有雲賬單超過了10億美元。
隨著這種增長，技術、財務、採購和業務團隊之間長期存在的部門壁壘已經成為一個問題。要了解為什麼，讓我們來看看我們最喜歡的Dave Nielsen在2011年的“Cloud Computing Is OSSM”演講中對雲端的定義。要被稱為「雲端」，Dave表示基礎設施供應商必須具備「OSSM」的特徵：
- 隨需應變
- 可擴充套件
- 自助服務
- 可衡量
這些特徵使企業能夠以過去無法想像的方式使用雲端運算。然而，這種快速增長也帶來了新的挑戰，需要企業重新思考如何管理和最佳化其雲端支出。
為何需要FinOps？
在公有雲環境中，OSSM中的「OSS」推動了令人矚目的創新，同時也創造了對FinOps的需求。由於雲端服務具有自助服務、可擴充套件性和按需使用的特性，使得工程師只需點選按鈕或執行一行程式碼，就能花費公司的資金，而無需經過傳統的財務或採購審批流程。因此，每個人的角色都發生了變化。
過去預先購買大量裝置的時代已經結束，取而代之的是在雲端以極低的成本購買非常小的資源單位，這使得傳統的採購和財務流程變得無效。工程師不再需要為每個雲端資源向中央採購團隊申請審批，而試圖實施微審批流程可能會威脅到創新，這是雲端的一大優勢。
傳統資料中心與雲端的對比
讓我們回顧一下傳統資料中心的流程：
- 裝置被故意設計得過大，並具有內建的備用容量，以確保在折舊期內能夠應對意外的增長。
- 如果某個服務使用的容量超過了合理範圍，只要容量尚未耗盡，這通常不是問題。
- 減少資源使用量不太可能帶來任何節省，而消耗備用容量的服務通常也不會產生額外成本。
- 容量管理是裝置生命週期內的主要成本控制手段。當容量接近耗盡時，會對服務的資源分配進行審查和調整。
- 裝置的成本是預先支付的，可能還伴隨著一些每月固定的費用，如資料中心費用、軟體授權費等。
- 成本報告和審查通常是每月或每季度進行一次。由於資料中心的日常營運成本相對穩定，因此不頻繁的報告是可以接受的。
現在，讓我們來看看雲端的情況：
- 無需預先購買裝置，並且總是能夠獲得備用容量。預先購買容量通常不是必需的，公司可以透過不為不需要的容量付費來節省成本。
- 當服務使用超出所需的資源時，會導致更高的營運成本。減少分配給服務的資源規模可以實作成本降低。
- 由於雲端服務提供商提供了可用的容量，因此容量管理不再是主要問題。移除這一流程意味著服務不再被人工限制在資源可用性上。
- 資源可以在繁忙時期被使用，然後在較慢的時期被移除。這種可變的消費模式降低了營運成本，但也使得成本預測變得困難。
- 由於資源以微小的單位被單獨收費，因此計費不再簡單易懂。
每季度或每月一次的成本審查往往會導致人們在看到意外或被遺忘的資源使用量累積成巨額賬單時感到震驚。從固定支出到可變支出的巨大轉變改變了你報告成本的方式。一系列的限制被移除，從根本上改變了公司構建和交付軟體的方式，無論是好的還是壞的。管理這種可變支出的工作與過去IT根據可靠的固定成本運作業務時的工作大不相同。
不採用FinOps的影響
在傳統資料中心中，工程團隊能夠快速存取的可用容量存在人工限制。成本的增加受到商業流程的嚴格控制，這些流程用於審查和批准任何額外的支出。這限制了成本變化的速度以及團隊進行實驗和創新的速度。
雲端消除了對可用儲存和計算的人工限制，使工程團隊能夠快速獲得所需的資源。在資料中心中，工程團隊無法透過呼叫API來組態數百台新的伺服器，然後為此付費。但在雲端，工程師可以輕鬆做到這一點。
當你專注於速度和創新時，雲端賬單很容易飆升。作為回應，公司往往會過度限制雲端的使用，導致創新放緩，並有可能使他們在過程中變得不那麼具有競爭力。
麥肯錫公司在2020年9月發表的一項研究《CIO和CTO如何透過雲端平台加速數位轉型》得出結論，能夠從雲端平台中獲益的公司將其採用視為一項商業技術轉型，透過以下三點實作：
- 將投資重點放在雲端能夠提高收入和利潤率的業務領域。
- 選擇符合業務戰略和風險約束的技術和採購模式。
- 開發並實施圍繞雲端構建的營運模式。
然而，他們也發現，所需的雲端經濟、技能、流程和組織變革過於複雜，跨越了業務的多個不同部分，無法由基礎設施負責人單獨管理。這導致絕大多數大型機構經歷以下失敗模式之一：
試點停滯
初始雲端工作負載或遷移的價值證明未能達到預期，從而無法成功建立擴大雲端使用的商業案例。
雲端網格鎖死
由於IT無法建立自動化或參考架構，以安全、彈性和合規的方式使用公有雲平台服務，雲端計劃陷入停滯。
“提升和轉移”缺乏價值
在未利用雲端最佳化槓桿或原生技術的遷移後，對雲端的支援當機，導致價值回報不足。
雲端混亂
缺乏長官層指導，讓工程師自行組態雲端服務，導致成本、安全性和合規性問題。
麥肯錫公司得出結論，儘管支出正在快速增長，但只有10%至15%的企業工作負載成功從資料中心轉移到雲端。
投資FinOps能夠發展FinOps能力，從而實作對雲端服務的更好財務管理。這確保了雲端計劃能夠提供可衡量的業務價值，而每一個由價值驅動的計劃都會給雲端價值飛輪帶來推動力。
透過在圖2-1的基礎上新增FinOps，可以得到圖2-2所示的擴充套件雲端價值主張。為了維持對FinOps的投資，必須展示出雲端價值的可衡量改進。在組織對FinOps和雲端的業務價值建立信心之前，需要取得快速勝利。每當FinOps計劃帶來業務價值的改進時，它都會進一步推動雲端價值飛輪和FinOps價值飛輪，但前提是必須將這些改進傳達給投資於雲端和FinOps的利益相關者。如果這些改進沒有被傳達出去，它們就等於不存在，而公司範圍內的雲端採用可能會停滯不前。
為何企業需要FinOps？
在現代企業中，雲端運算已成為推動創新與加速交付的重要技術。然而，在享受雲端運算帶來的好處的同時，企業也必須面對其所帶來的成本挑戰。雲端成本的管理不僅需要技術上的支援，更需要組織文化的轉變與跨部門的協作。本章將探討企業在雲端運算中採用FinOps（雲端財務營運）的重要性，以及不採用FinOps可能帶來的影響。
忽略FinOps的風險
許多企業在進行雲端遷移時，往往將成本視為次要考慮因素。他們可能會認為，只要能夠順利完成遷移或釋出新功能，成本問題可以稍後再處理。這種「忽略」FinOps的做法，可能會在未來帶來嚴重的後果。
簡單忽略 vs. 明智忽略
簡單忽略是指企業完全忽視雲端成本，不進行任何測量或監控。這種做法可能導致企業在未來的某個時刻遭遇突如其來的成本衝擊，從而被迫採取緊急措施，這可能會影響到雲端運算的採用乃至更廣泛的業務目標。
與此相對，明智忽略是指企業雖然暫時不採取行動來降低雲端成本，但仍會持續監控成本、預測未來支出，並分析潛在的節省機會。這種做法使企業能夠在保持工程師對速度的關注的同時，為未來的FinOps實踐做好準備。
FinOps的核心價值
FinOps的核心價值在於提供對雲端成本的可視性，並幫助企業做出明智的決策。透過實施FinOps，企業可以：
- 確保雲端支出與業務預期保持一致。
- 及早發現潛在的成本風險，並採取相應措施。
- 培養工程師在佈署基礎設施時考慮成本的習慣。
- 提升財務部門對新複雜性的處理能力。
圖表說明：Lift-and-Shift遷移的價值變化
此圖示（Figure 2-3）由Forrest Brazeal繪製，形象地展示了Lift-and-Shift雲端遷移的價值如何隨著時間推移而遞減。如果企業僅停留在Lift-and-Shift階段，而不進一步向雲原生架構邁進，那麼最初由遷移帶來的正面價值將逐漸被其負面影響所抵消。
關鍵決策：永遠不要忽視的基礎設施
在FinOps實踐中，有些決策是絕不能忽視的。例如，建立一個全面的標籤/標記/帳戶方法論是至關重要的。一旦錯過了這個基礎步驟，日後想要回頭修正將會非常困難。2022年的FinOps狀態報告顯示，成本分配被認為是FinOps框架中最重要的能力之一。
第三章：文化轉變與FinOps團隊
FinOps 不僅僅是一種技術解決方案或是一份清單式的任務交給某個團隊。它是一種生動且實際的方式，用於最大化雲端的價值。技術確實能解決諸如監控最佳化建議和檢測異常支出等問題，但它無法就這些行動的商業價值進行深入的對話。
在本章中，我們將探討誰在推動 FinOps，以及他們在組織中的位置。同時，我們也會檢視 FinOps 的角色和職責，因為最終還是由人來推動 FinOps 的運作。
公司文化與支出管理的演變
公司圍繞支出的文化必須與工具和流程同步演變。在實施成功的 FinOps 實踐過程中，存在著許多障礙和挑戰。它們要麼是由人員和團隊引起的，要麼是由他們解決的。最終，這取決於你。你的團隊是否會開發並採用正確的原則和實踐來實作成功的 FinOps？
Deming 的業務轉型理念
在為第二版書籍進行研究時，我們遇到了由著名的工程和商業教授 W. Edwards Deming 在 1982 年發表的關於管理業務轉型的關鍵原則。FinOps 的許多關鍵點都與 Deming 的原則相呼應，因此值得我們去探討 Deming 的幾項關鍵原則。
Deming 強調了目的恆定的重要性。他的觀點是，推動公司長期成功的最佳方式是培養長期思維，並不斷實施持續改進。
他還強調，所有參與轉型的團隊需要作為一個單元共同工作，打破部門之間的壁壘，使整個組織能夠及早發現問題，並協同合作尋找解決方案。同樣，成功的雲端和 FinOps 轉型需要每個參與雲端管理的團隊都明白，這種轉型是每個人的責任。
FinOps 團隊的角色與技能
從財務到營運，再到開發人員、架構師和執行官，組織中的每個人都有自己的角色。看看本文中參照的各種職稱，你就會明白我們的觀點。
“每個人的工作都是幫助公司發展得更快。在敏捷的世界裡，我們都是服務型長官者，幫助工程師交付他們的工作。其他人應該在旁邊解除交付的阻塞。”
—— David Andrews，Just Eat 的高階技術經理
無論是隻有幾名員工佈署雲端資源的小企業，還是擁有數千名員工的大型企業，FinOps 實踐都可以並且應該在整個組織中實施，儘管所需的工具和流程的程度以及實施的頻率會根據每個地方交付的價值而有所不同。
那麼，FinOps 團隊需要具備哪些技能和角色呢？在後面的章節中，當我們探討最佳化階段時，我們將討論 FinOps 團隊如何產生需要被更廣泛的組織考慮的建議，例如更改資源組態或向雲端服務提供商做出承諾。雖然這些無疑會為組織節省資金，但需要在產品、財務和工程之間建立信任，以實作這些目標。
為了盡快建立這種信任，FinOps 團隊必須具備雲端專業知識。否則，建議可能會完全錯誤，或者工程團隊可能會浪費寶貴的開發時間來解釋為什麼不需要進行必要的效能修改。具備雲端領域專業知識的 FinOps 團隊能夠建立信任和可信度。
FinOps 實踐的推行與挑戰
FinOps 需要有執行層的支援，能夠分享最佳實踐，並使用共同的語言將不同的專業領域聯絡起來。正如我們將在下一章中討論的那樣，這不僅有助於傳播 FinOps 對公司很重要的訊息，還能確保員工有時間分配給所需的任務。
當 FinOps 做得好時，它並不會增加技術和業務團隊之間的衝突。相反，這種衝突被消除。這是在團隊使用共同語言時實作的，這種語言有助於圍繞業務目標創造一致性，從而確保每個人都理解並支援這些目標。
一個中央 FinOps 啟用團隊是推動整個組織 FinOps 思維方式的驅動力，它宣揚將成本考慮納入開發計劃的最佳實踐。FinOps 從業者執行一些集中任務，如管理和報告根據承諾的折扣給雲端提供商，或集中報告以確保每個人都在看相同的數字。這可以防止其他團隊重複造輪子，同時利用與承諾相關的規模經濟。
然而，許多 FinOps 最佳實踐的實際實施必須分散到公司內各個產品和應用程式團隊中的工程師手中。一個很好的例子是許可權調整和閒置使用率降低。雖然中央 FinOps 團隊可以幫助提供資料和目標設定，但各業務線的工程師必須根據業務價值和工作量做出資料驅動的決策，決定何時對基礎設施進行更改。
“當你能夠在24小時內向財務部門發出有關支出激增的警示，而不是一個季度後，這會贏得很多可信度。如果需要多個月才能弄清楚是什麼原因導致了超支，這不會讓財務部門對技術團隊的能力有信心。”
—— Joe Daly，前任 Nationwide 雲端最佳化總監
中央 FinOps 團隊的另一個重要角色是促進團隊之間的對話並培養信任。財務團隊必須與工程師合作，使用分享資料和報告，使每個人都能快速找到並解決需要處理的問題。
憑藉 FinOps 團隊提供的報告和帳單知識，工程師將能夠展示在哪裡、何時以及為什麼某個計劃或成本超出了預算。這種分享知識建立了信心、信任和效率。
圖表翻譯：
此圖示展示了 FinOps 團隊在組織中的角色和職責。它闡述了中央 FinOps 團隊如何與其他部門協作，以及如何推動整個組織的 FinOps 思維方式。
@startuml
skinparam backgroundColor #FEFEFE
skinparam defaultTextAlignment center
skinparam rectangleBackgroundColor #F5F5F5
skinparam rectangleBorderColor #333333
skinparam arrowColor #333333
title 圖表翻譯：
rectangle "推動FinOps思維方式" as node1
rectangle "提供資料和報告" as node2
rectangle "協助最佳實踐" as node3
rectangle "協同工作" as node4
rectangle "分享資料" as node5
rectangle "資料驅動決策" as node6
node1 --> node2
node2 --> node3
node3 --> node4
node4 --> node5
node5 --> node6
@enduml
圖表翻譯： 此圖示呈現了中央 FinOps 團隊如何協助各部門達成業務目標，並透過分享資料來最佳化雲端資源。