FinOps 團隊的核心職責在於建立雲端支出的透明度和責任制，而非僅僅控制成本。他們提供專業知識，協助工程師和業務團隊理解複雜的雲端計費模型，並將成本指標整合到日常決策中。FinOps 團隊制定成本分配規則和統一的業務指標，確保各團隊在相同的標準下運作，並透過提供資料和工具賦能團隊進行成本最佳化。隨著組織雲端成熟度的提升，FinOps 團隊將更專注於自動化日常任務和處理複雜的雲端效率專案，例如最佳化儲存層級和服務層級選擇，最終提升整體雲端資源使用效率。
為何需要FinOps團隊？
FinOps的核心不在於集中支出審核，而是在於建立支出的可視性，使各相關部門能夠承擔相應的責任。FinOps團隊的雲端專業知識使其他團隊能夠理解如何將每項可計費專案分配到不同的成本中心，並透過「chargeback」與「showback」的方式來呈現與處理成本。這些術語將在第11章中探討。
為什麼需要集中式團隊？
本文中多次提到FinOps團隊及其所扮演的集中式角色。值得注意的是，雖然我們將持續提到集中式的FinOps團隊，但實際上有多種不同的FinOps團隊模式可供選擇。你的FinOps團隊結構將取決於你的組織型別以及如何支援跨部門協調。
雖然我們仍會提到FinOps團隊，但可以將其理解為推動FinOps最佳實踐的協調機構。無論採用何種組織設計，FinOps團隊都應在整個組織內推動變革，以確保成功轉型。
FinOps團隊的角色與功能
無偏見的最佳實踐分享：集中式FinOps團隊與業務長官、工程團隊和財務團隊緊密合作，分享客觀的最佳實踐和建議。由於該團隊不受特定部門利益影響，因此更容易贏得信任。
成本分配規則的制定：由集中式團隊制定成本分配規則，並清晰地向各團隊溝通其績效評估標準。這樣可以確保所有團隊按照相同的標準進行管理和衡量，避免因獨立分配成本而導致的重疊或遺漏，從而提高資料的可信度。
統一業務指標定義：FinOps團隊定義組織使用的業務指標。這是一個關鍵的早期任務。雲端支出中的一美元不僅僅是一美元，它可以根據不同的計算方式（如攤銷或未攤銷的成本）以及是否應用自定義費率而有所不同。當業務指標在各團隊間明確定義後，所有人都能使用相同的語言進行溝通。
FinOps團隊並非獨自執行FinOps
FinOps並非僅由集中式FinOps團隊執行；相反，該團隊主要扮演支援角色，為其他部門提供雲端計費資料、定價模型、集中資料與報告、承諾管理等方面的專業知識，並幫助分散的工程團隊獲得做出日常決策所需的資料。
FinOps團隊的主要任務
- 提供專業知識以幫助其他團隊理解複雜的雲端計費和定價模型。
- 加速在整個組織內推廣可重複的FinOps實踐模式。
- 協助工程團隊最佳化其基礎設施並實作業務目標。
隨著組織雲端成熟度的提高，FinOps團隊的工作重心會從日常任務轉移到更複雜的雲端效率專案上。例如，AWS S3儲存服務至少有6種不同的收費動作和8種不同的儲存型別，總共會有48種定價組合。FinOps團隊的專業知識可以幫助導航這種複雜性。
FinOps團隊的未來發展
隨著FinOps團隊的成熟，他們可能會承擔更多自動化日常任務的責任，例如修復因遷移到雲端而引入的技術債，如將儲存置於比實際需求更昂貴的層級，或購買高於所需的服務層級。
總之，FinOps團隊在推動組織雲端財務管理的透明度、效率和最佳實踐方面發揮著至關重要的作用。他們透過提供專業知識、制定統一的成本分配規則和業務指標，幫助組織實作更好的雲端成本管理。
FinOps 團隊的文化轉變與角色定位
在雲端運算的時代，企業需要建立一個有效的 FinOps 團隊，以確保雲端資源的使用效率和成本控制。FinOps 團隊的角色是提供資源和指導，讓工程師和業務團隊能夠更好地理解和最佳化雲端成本。
FinOps 團隊的定位
FinOps 團隊不是單獨負責最佳化所有雲端資源，而是提供資源和工具，讓工程師和業務團隊能夠自行最佳化雲端成本。這種模式與雲端安全類別似，是一種分享責任模型。FinOps 團隊的工作是加速和賦能組織更有效地使用雲端，而不是取代其他工程團隊和業務長官者的日常職責。
各團隊在 FinOps 中的角色
圖 3-1 展示了組織在 FinOps 模型下的運作方式。一個跨功能的團隊，如雲端卓越中心（CCoE），負責管理雲端戰略、治理和最佳實踐，然後與其他業務部門合作，轉變雲端的使用方式。
高階主管和長官者
高階主管（如基礎設施副執行長、雲端卓越中心負責人、CTO 或 CIO）專注於推動責任制和建立透明度，確保團隊高效運作，不超出預算。他們也是推動文化轉變的關鍵，讓工程師開始將成本視為效率指標。
工程師和開發人員
工程師和維運團隊成員（如首席軟體工程師、首席系統工程師、雲端架構師、服務交付經理、工程經理或平台工程總監）專注於為組織建立和支援服務。成本被引入作為一種指標，與其他效能指標一起被追蹤和監控。團隊考慮透過諸如調整大小（調整雲端資源大小以更好地匹配工作負載需求）、分配容器成本、查詢未使用的儲存和計算資源以及識別支出異常是否符合預期等活動來高效設計和使用資源。
財務部門
財務團隊成員使用 FinOps 團隊提供的報告進行會計和預測。他們與 FinOps 從業者密切合作，以瞭解歷史帳單資料，從而建立更準確的成本模型。他們利用預測和來自 FinOps 團隊的專業知識與雲端服務提供商進行費率談判。
採購和供應鏈
採購和供應鏈人員管理企業與供應商（包括雲端服務提供商）的關係。這種關係可能與公司過去管理的其他 IT 服務關係非常不同，並且可能更複雜和多樣化。他們的目標是為公司對每個供應商的承諾獲得最佳價格，並確保組織隨著時間推移獲得其惠顧和承諾的所有利益。
產品或業務團隊
產品團隊成員，包括產品經理、產品負責人、產品組合負責人、服務負責人、應用程式負責人等，負責一個服務或產品或產品線。他們將與 FinOps 團隊密切合作，以瞭解（通常以資料中心無法做到的方式）執行其產品或應用程式功能的總成本。產品負責人對解決客戶需求的新功能感興趣，並將能夠使用 FinOps 提供的資料來瞭解產品盈利能力、指導成本效率努力，並更準確地預測根據新功能發布的成本。
FinOps 從業者
FinOps 從業者是 FinOps 實踐的核心。他們瞭解不同的觀點，具備跨功能的意識和專業知識。他們是中央團隊（或個人），將最佳實踐推入組織，在所有需要的層級提供雲端支出報告，並充當業務各個領域之間的介面。他們可以是具有雲端經驗的財務長官者或具有成本意識的工程師。
新的協作方式
上述每個職能都需要以前所未有的方式整合。有人說工程師需要更多地像財務人員一樣思考，而財務人員需要開始像工程師一樣思考。這是一個好的開始，但整個組織需要從集中式成本控制模型轉變為分享責任制的模式。只有這樣，中央 FinOps 團隊才能賦予組織更快地移動和創新。
這種文化轉變也使長官層能夠以當前無法做到的方式參與決策。根據長官層的意見，團隊可以就他們是否專注於創新、交付速度或服務成本做出明智的選擇。有些團隊會全力以赴於某一個領域，採取「以任何代價實作增長」的思維方式。最終，當雲端賬單變得過高時，他們就不得不開始同時考慮增長和成本。例如，「快速行動，但保持我們的每客戶交易成本低於 0.45 美元」。
FinOps 團隊的匯報物件
大多數情況下，FinOps 團隊向技術長官者匯報，但也可以向財務部門或其他職能部門匯報。《FinOps 現狀調查》詢問了 FinOps 團隊的匯報物件，如圖 3-2 所示，結果表明 FinOps 團隊在不同組織中向多個不同的部門匯報。最常見的是，FinOps 團隊與技術團隊保持一致或平行。
FinOps 團隊的匯報物件與組織架構
根據 2022 年 FinOps 狀態報告（Figure 3-2），大多數的 FinOps 團隊直接向技術長官（如 CTO 或技術負責人）匯報。這意味著 FinOps 通常被視為技術組織的一部分。雖然有些公司將 FinOps 置於 CIO 的職權範圍內，但這種情況正逐漸減少。由技術長官監督技術支出可能存在利益衝突，因為同一團隊既花錢又監督支出。然而，將 FinOps 置於技術組織內也有其優勢。首先，工程和技術營運團隊更傾向於接受來自內部提出的建議和最佳化方案。更重要的是，技術團隊最瞭解雲端運算的複雜性，能夠快速建立管理高變動性雲端支出的實踐。
財務驅動的 FinOps 通常嘗試將現有的財務報告和預測系統應用於雲端帳單，但這些系統並未針對雲端環境設計，後者每月有數百萬條變動的費用記錄。因此，我們越來越多地看到混合職能模式的出現，例如在 CTO 下設立 COO 或 CFO 職位負責技術事務。
FinOps 團隊的組織架構與合作模式
無論 FinOps 團隊隸屬於哪個部門，其核心任務是與財務和工程部門緊密合作。在小型公司中，可能沒有專門的 FinOps 團隊，通常會指定一人或將部分人員的時間分配給推動和實踐 FinOps。在大型、複雜的組織中，中心 FinOps 團隊可能有多達 10 人或更多。
理解不同角色的動機
當來自不同背景的聰明人聚集在一起時，摩擦是不可避免的，因為他們有不同的目標和指標。財務部門關注成本效率和預算控制，而營運團隊則專注於提供高品質的服務並減少故障。
工程師的動機
- 希望解決有意義且具挑戰性的問題
- 希望快速、可靠地交付軟體
- 厭惡低效率，希望資源利用更高效
- 希望跟上最新的技術發展
- 以效能、正常執行時間和韌性作為衡量指標
- 希望交付新功能、修復錯誤並提升效能
工程師通常更關注將新功能或錯誤修復交付給客戶，而不是財務方面的問題。FinOps 團隊需要與工程師合作，幫助他們瞭解成本、檢視環境中的最佳化機會，並評估成本效益。
工程師與 FinOps 的合作案例
Jason Fuller（HERE Technologies 的雲端負責人）與他的工程師合作，採取了以下策略：
「讓我的團隊和 FinOps 組織來處理這些事，讓我為你們設定儲存生命週期策略。你們知道應該要有這樣的策略，但它在你們的待辦事項清單中排第 100 位。所以，我會處理這件事。對工程師最有效的策略是『讓我來幫你們，我會處理好所有這些事情，讓我來標準化和編寫你們的儲存生命週期策略，以減少你們的工作量。』」
在某些情況下，FinOps 從業者會與工程師合作執行這些重複性任務，並透過資料分析找出潛在的最佳化機會。然後，他們會幫助工程師簡化和標準化流程，有時甚至會主動承擔一些自動化的技術債清理工作。
財務人員的動機
- 希望準確預測支出
- 希望能夠完全分配和追蹤所有支出
- 希望將成本適當攤銷到相關團隊
- 希望區分分享成本（如支援和分享服務）
- 希望控制和降低成本，同時保持服務品質和速度
- 希望協助高層制定雲端戰略
- 希望提前發現預算風險
當企業首次採用雲端運算時，財務人員可能會因為支出的不可預測性而感到震驚。從資本支出轉向營運支出，加上大量變動的成本和用量資訊，可能讓他們感到無所適從。因此，向財務團隊解釋雲端運算其實是一種消費型服務（如水電費），只是 SKU 更多、變化更快，這有助於他們理解雲端支出的模式。
財務人員面臨的挑戰
雲端運算對財務人員來說可能是一種挑戰，尤其是當他們不熟悉雲端計費模式時。他們可能難以跟上變化的速度，並且對雲端供應商提供的帳單資料缺乏信任。因此，需要提醒他們雲端運算其實遵循著他們熟悉的財務模型，只是在採購流程和資料粒度上有所不同。
組織中的FinOps實踐與文化變革
在當今數位轉型的時代，企業對於雲端運算的依賴日益加深。為了有效管理雲端支出並實作數位業務轉型，企業需要推動FinOps文化的變革。本章將探討FinOps在組織中的實踐，以及如何推動文化變革以實作雲端成本的最佳管理。
高階主管與長官層的角色
高階主管和長官層在推動FinOps文化變革中扮演著至關重要的角色。他們的主要目標包括：
- 推動團隊間的共同責任制
- 實作數位業務轉型
- 縮短新服務上市時間
- 取得競爭優勢
- 制定成功的雲端戰略
- 定義和管理關鍵績效指標（KPIs）
- 證明技術投資的價值
長官層需要支援FinOps從業人員在組織內推動的文化變革，並提供指導，平衡「好、快、便宜」之間的優先順序。為了使FinOps有效運作，長官者和高階主管必須在跨領域和不同層級之間保持一致，共同推動雲端目標和控管措施。
採購與外包團隊的角色
採購和外包團隊傳統上以談判折扣為績效指標，但隨著雲端運算的普及，他們的角色正在發生變化。現在，他們需要：
- 確保支出符合供應商協定
- 與戰略供應商建立關係
- 談判和續簽供應商合約
隨著工程師直接設定雲端資源，採購團隊需要保持對雲端支出的可視性，並產生準確的預測，以推動供應商關係和合約談判。採購團隊應該幫助推動責任制，同時使團隊能夠獲得創新所需的資源。
FinOps在組織中的實踐
在現代組織中，各個團隊需要考慮整體優先順序，而不僅僅是自己的優先事項。如果技術營運團隊不考慮其雲端支出的影響，財務部門將難以預測和預算組織的雲端支出。相反，如果財務部門完全控制雲端支出並要求對每個資源進行審批，組織將難以利用可變支出資源和按需基礎設施的優勢。
來自雲端的故事——Rob Martin
Rob Martin，FinOps基金會的學習總監，分享了一個來自最近FinOps認證培訓課程的匿名故事，講述了FinOps不同角色如何協同工作：
隨著FinOps責任制文化的建立，各個部門開始更密切地合作。當產品經理確定一個新功能時，他們可以快速確定提供該功能的收入或客戶影響，以及他們需要產生的利潤。負責損益表的長官可以批准投資，並靈活調整預算，以便開發團隊進行開發。他們制定了成功引數、預期成本和銷售預期。這為工程長官提供了明確的方向，以制定計劃，將工作安排到sprint中，以建立最小可行產品（MVP），並估計建設期間的成本曲線，財務部門可以清楚地看到這一過程。隨著計劃的完善，預算進行調整，資源被請求，並附上適當的標籤。在過去，這個過程需要數月時間來簡報、協調和獲得批准；現在，我們可以在幾天或幾週內完成。
FinOps人才招募與培訓
要推動FinOps文化的變革，不能僅僅依靠僱傭從業者或引入承包商。每個人在組織中都有自己的角色。要在所有徵才中新增FinOps要求，從高階主管到財務到營運團隊，都需要在職位描述中列出FinOps，或提供FinOps培訓作為新員工入職培訓的一部分。詢問工程師成本指標如何影響良好的服務設計，並詢問財務部門雲端的可變支出如何改變正常的財務慣例。如果不僱傭具有FinOps理解的新人才或對新加入團隊的成員進行持續培訓，所建立的文化將慢慢被缺乏正確思維方式的新員工所侵蝕。
FinOps 文化的實踐與團隊角色演變
隨著 FinOps 的發展，企業需要具備更多元技能的員工，這些員工不僅要有商業頭腦、財務思維，還要具備技術能力。財務人員需要學習雲端技術，就像 IT 人員需要學習財務知識一樣。
全面商務人才的崛起
回想當初「全端工程師」的概念剛出現時，如今是時候開始思考「全商務人才」了。這類別人才需要具備多種技能，以滿足 FinOps 實踐的需求。
建構 FinOps 團隊所需的關鍵技能
在建立 FinOps 實踐時，您需要填補以下常見的技能缺口：
策略治理
制定政策檔案、標準、關鍵績效指標（KPIs）和目標與關鍵成果（OKRs），以及治理框架，以指導組織的成本分配和雲端使用。
技術寫作
建立有關 FinOps 流程的檔案，幫助推廣標準（標籤），並傳送預算警示。
分析
深入研究成本異常現象，瞭解雲端成本模型，並向工程師和財務人員解釋這些模型，同時為高階主管建立和交付報告。
工程
考慮架構決策的成本，並協助自動化帳單資料、最佳化、預算和預測報告，以及治理。
自動化工程
專注於自動化雲端工具，例如自動化雲端帳單機制（如預算警示和承諾）或自動化最佳化建議。
資料工程
建立系統以收集、管理並將原始資料標準化為可用的資訊，供資料科學家和業務分析師進行分析和報告。資料工程師實施方法以提高資料的可靠性和品質。
培訓
讓團隊瞭解 FinOps 對他們的意義，需要提供培訓材料，並管理自定進度或面對面的課程。
福音傳播/行銷
在組織內建立 FinOps 的形象，需要努力建立推廣者基礎，並透過幫助反對者瞭解 FinOps 提供的價值來贏得他們的支援。
FinOps 文化的實踐
讓我們來看一個例子，瞭解 FinOps 文化和語言如何使企業受益。容器化的引入對成本可視性產生了影響。隨著容器化的引入，維運團隊能夠在相同的計算資源上封裝更多的服務。像 Kubernetes 這樣的服務為維運團隊提供了前所未有的控制和自動化能力。
容器化對成本可視性的影響
容器化使維運團隊能夠更有效地利用資源，但也可能導致成本可視性的損失。雲端帳單資料中包含底層計算例項的成本，但可能沒有詳細資訊來幫助財務人員瞭解哪些容器在哪些例項上執行。
無 FinOps 文化的情況
在沒有 FinOps 文化的情況下，財務團隊可能會要求工程師幫助將底層計算資源的成本分攤到正確的業務部門。這種請求意味著工程師必須停止手頭的工作，將重點轉移到成本和財務資料上。這種轉移最終會導致生產力的下降，財務團隊可能會得出結論，認為容器化對業務營運不利。
有 FinOps 文化的情況
當引入 FinOps 從業者時，情況會有所不同。從業者對雲端服務提供商的帳單檔案中有關可用或不可用的資料有深入的瞭解。財務人員會學習並瞭解容器化的基礎知識及其對業務的益處。同時，維運團隊會瞭解回扣和展示的重要性。
圖表翻譯：容器化對成本可視性的影響
此圖示說明瞭容器化如何影響成本可視性，以及 FinOps 文化如何幫助企業更好地瞭解和管理成本。
困難：激勵他人
在過去兩年的 FinOps 狀態調查中，FinOps 從業者面臨的最大挑戰是激勵工程師採取行動，如圖 3-3 所示。
Mike 的故事
曾經，我與一家大型科技公司內的 FinOps 團隊交談。當談話轉到激勵工程師採取行動時，其中一名團隊成員分享了一個故事。他的父親在矽谷從事科技行業數十年，他向父親講述了他在工作中遇到的挑戰，試圖讓工程師更改其雲端組態。在這次對話中，他的父親笑了，並說：「你沒有新的雲端問題。你有一個古老的問題，即激勵其他人做你想做的事情。」
內容解密：
這段故事說明瞭激勵他人是一個長久存在的問題，而 FinOps 從業者需要具備良好的溝通和激勵能力，以推動團隊成員採取行動。
激勵工程師採取行動：FinOps 文化的關鍵
在雲端運算的世界中，FinOps 從業人員經常面臨一個挑戰：如何激勵工程師根據建議進行變更並將新的做法納入他們的工作流程中？這個問題看似與雲端運算息息相關，但實際上，它是一個普遍的人類挑戰。
瞭解行動的天平
如圖 3-4 所示，「行動的天平」形象化地展示了工程師是否願意實施建議的平衡狀態。這個天平受到多種因素的影響，這些因素要麼促進行動，要麼阻礙行動。
促進行動的因素
在天平的正面，有幾個關鍵因素能夠促進工程師採取行動：
- 興趣：工程師對建議的興趣程度直接影響他們的參與意願。透過改變溝通方式，例如從「您需要審查此建議」變為「您知道是什麼原因導致了這個建議嗎？」，可以提高工程師的興趣。
- 動力：當工程師的績效與成本相關的結果掛鉤時，他們更有可能投入時間來審查和實施建議。
- 理解：工程師需要清楚地瞭解建議的內容、如何審查建議以及實施變更所需的步驟。
阻礙行動的因素
然而，也有幾個因素會阻礙工程師採取行動：
- 努力和時間：實施建議所需的時間和努力會降低工程師採取行動的意願。
- 流程：複雜的手動步驟和審批流程會降低工程師的動力。
- 風險：變更雲端資源組態可能會帶來風險，過去的失敗經驗會降低工程師對建議的信任度。
讓天平傾向行動
要促進工程師採取行動，需要同時提高促進因素和減少阻礙因素。
增加動力
與工程師溝通，瞭解他們需要什麼來參與這個過程。引導他們完成任務，但也要給予他們一定的自由度，讓他們決定如何完成工作。當團隊開始參與並取得成功時，分享他們的成就，以激勵其他團隊。同時，表達對他們努力的讚賞和獎勵。
教育團隊
清晰地解釋需要工程師做什麼，以及為什麼需要他們完成這項任務。提供培訓、相關檔案，並讓自己隨時可供回答問題。
減少努力
驗證建議的品質，以減少工程師審查所需的時間。與工程師合作，確定可以提供哪些資訊來幫助他們。自動化可以減少實施任務所需的時間和努力。
避免失去信任
當發生失敗時，瞭解失敗的原因，並移除高風險的建議。與工程師分享如何更好地評估建議，以避免重蹈覆轍。
