雲端成本管理已成為企業的重要挑戰，FinOps 的出現讓工程師和財務部門能有效合作，在兼顧系統效能和可用性的同時控制成本。本文除了介紹 FinOps 的核心原則，也以保時捷和豐田的例子說明如何在不同的約束條件下進行成本與價值的權衡，並提供 Atlassian 的實際案例，說明 FinOps 團隊如何與工程師合作，推動成本最佳化。此外，文章也強調了長官層支援的重要性，以及如何在產品開發早期引入財務約束，避免後期昂貴的重新架構。最後，文章也探討了 FinOps 與其他 IT 框架的整合，例如 ITSM、ITIL 和 ITFM，以及如何有效地管理雲端成本，實作技術支出最大價值。
在雲端運算中實作成本效益工程的原則
在雲端運算的世界中，成本管理已成為一項重要的挑戰。傳統上，工程師們關注的是如何最大限度地提高系統的效能和可用性，而財務部門則關注如何控制成本。然而，這兩者並不一定是相互衝突的。事實上，透過有效的FinOps實踐，工程師和財務部門可以攜手合作，實作成本效益和工程創新。
是開發雲端的保時捷還是豐田？
創新可以在高價格和高品質的情況下發生，也可以在低價格和低品質的情況下發生。在您的團隊中，請考慮您是在開發雲端的保時捷還是一輛豐田。兩種方法都是有效的。保時捷工程師和豐田工程師都接受了類別似的培訓，但面臨著不同的約束條件。他們都必須不斷地進行成本與價值的權衡，但要在不同的約束條件下進行。
當一個團隊（或團隊成員）認為他們正在遵循保時捷模式，而實際上其他人正在遵循豐田模式時，就會產生摩擦。最佳雲端與使用每個功能都可能帶來巨大費用的雲端之間存在著梯度。
許多人認為需要開發雲端的保時捷才能讓工程師做出最好的工作。他們將其設計為最具可用性、最具容錯性和最具效能的。然而，開發豐田雲端的工程師則是在緊密的約束條件下建立高效的服務，在某些情況下，實際上解決了一個比那些可以使用任何可用服務的保時捷工程師更困難的工程問題。每當預算受到擠壓時，就會帶來機會，以創新的方式進行最佳化，例如使用spot、無伺服器或新的系統設計來適應這些約束。這仍然是創新工程，只是根據鐵三角的不同平衡。
實作成本效益工程的原則
在介紹了美元作為約束的概念和豐田與保時捷的類別比之後，Gabe Hege分享了一套原則，供企業和技術人員在進行FinOps轉型時參考。
#1：最大化價值而非降低成本
最佳化一切並不總是答案：您可能有區域性最佳化機會，但不一定能對業務產生全域性影響。工程師的觀點是，財務部門過度關注支出。如果財務部門能夠重新定位自己，關注業務價值，那麼工程師就能更密切地與之相關聯，並更願意進行與FinOps原則相符的交易談判。
Gabe認為：“您希望使他們能夠最大限度地創造價值。這不僅僅是減少支出，而是花在正確的事情上。”
#2：記住我們在同一團隊
團隊需要密切合作才能使FinOps蓬勃發展。Gabe將這種夥伴關係比喻為保齡球：“財務是護欄，工程是保齡球。一起，我們旨在用最少的回合擊倒最多的球瓶。”
#3：優先改善溝通
Gabe說：“很多財務術語對工程師來說並不熟悉。同樣，工程術語對財務人員來說也不太好理解。站在工程師的角度非常重要，而不是與他們對立。我認為FinOps工作是一種合作夥伴關係，我們還必須幫助非工程師，例如財務人員，瞭解與工程合作是什麼樣的。”
他建議組織考慮將一些工程人才調到財務部門，或者讓財務部門參與一些工程活動，以便他們能夠更直接地瞭解工程在交易談判過程中需要考慮的約束條件。
與工程師合作實作 FinOps 的六大原則
在現代企業中，財務營運（FinOps）已成為管理和最佳化雲端成本的關鍵方法。要成功實施 FinOps，與工程師的有效合作至關重要。以下是實作這一目標的六大原則。
#4：在產品開發早期引入財務約束
在開發週期的最後階段引入嚴格的財務約束，很難在下一次發布中實作。快速的勝利可能會朝正確的方向邁出一步，但不太可能實作長期目標。財務約束需要時間來實施，特別是在開發後期才引入時，因為它們可能與早期做出的基本選擇不相容，需要重新架構。重新架構的成本可能最終不值得雲端成本文省，尤其是與所需的工程時間及其對其他發布交付時間表的影響相比。
如同 Gabe 在他的 FinOps X 演講中所說：「如果財務部門只在發布到測試或生產階段才出現，那麼就太晚了。你需要在一開始就將成本約束納入其中，否則你通常是在要求工程師重新開發一個新產品。」
內容解密：
這段文字強調了在產品開發的早期階段就引入財務約束的重要性。這樣可以避免在開發後期需要進行昂貴且耗時的重新架構。
#5：啟用而非控制
工程師的主要任務是根據需求確定需要構建什麼，然後檢查約束條件以確定如何構建。如果約束過於僵化，就會產生 Gabe 所謂的「技術人員」：那些只被告知「把閥門轉到某個位置」而不進行創新的人。另一方面，也有 Gabe 所謂的「藝術家」，他們過度精心製作昂貴的解決方案。在《辛普森一家》的一集中，Homer 被賦予了無限制的預算來設計完美的汽車。結果卻是一個昂貴的怪物。如果沒有找到合適的成本防護欄和其他約束，創新實際上會受到影響。
在中間立場上，有足夠的約束來發揮創造力，但又不至於僵化到無法找到優雅的解決方案。簡單的防護欄，如總成本或批准的雲端服務 SKU 清單或批准的區域，可以促進創新。但如果你這樣做，你需要提供其他引數，讓工程師有靈活性。例如，如果你保持在這個預算內，並避免使用這些服務或區域，那麼你可以做你想做的任何事情。
內容解密：
本段落說明瞭在給予工程師足夠創作空間的同時，也需要設定適當的財務約束。這樣既可以促進創新，又可以控制成本。
#6：長官層支援不是有幫助，而是至關重要
長官層的支援是 FinOps 轉型（或任何組織轉型）成功的單一最重要因素。如果你的工程和財務長官者不同意其重要性和預期結果，那麼文化變革註定會失敗。同樣，重要的不是長官層下達命令，而是長官者不斷發出訊號，表明成本——及其最終帶來的業務價值——在開發的所有階段都很重要。這個資訊不應該是「將成本降低 10%」這樣的命令，而是「成本效率始終很重要，是你工作的重要組成部分」這樣的不斷鼓吹。
Gabe 以他以前作為安全工程師的工作為例說：「你不能只是偶爾進行安全衝刺；你需要在開發生命週期的每個部分都將安全性融入其中。如果新功能破壞了你的成本約束，那麼這就是一個錯誤，就像安全問題一樣。你必須應用這種程度的紀律。」
內容解密：
本段強調了長官層支援對於 FinOps 轉型成功的關鍵作用。長官者需要不斷強調成本效率的重要性，並將其融入開發流程的每個階段。
與工程師合作推動 FinOps
Atlassian 的中央 FinOps 團隊經過多年的發展，已經與數百個工程合作夥伴建立了緊密的合作關係。我們現在會明確地提出具體請求，例如：「我們希望承諾某些 Savings Plans 或 Reserved Instances，以實作特定的目標。以下是我們正在考慮的承諾內容、預期的回報價值，以及對業務的影響。你們是否認為有任何阻礙我們推進的因素？」
隨著時間的推移，我們越來越受到重視，因為我們更擅長進行價值導向的對話，而 FinOps 團隊也變得更加成熟。在初期，我們主要關注最佳實踐。我花了很多時間試圖說服大家更多地關注成本。
一旦我們鞏固了自己作為一個專門團隊的地位，並獲得了高層長官的支援，就使得整個組織更加清楚地認識到 FinOps 並非 Atlassian 的附帶想法。正如早期的情況一樣，他們看到我們的團隊得到了長官層的關鍵投資，這有助於推動他們需要與我們合作的訊息。
與此同時，我們在提出請求時保持謹慎。我們確保他們瞭解請求的內容、需要做什麼，以及這項工作的影響。當某個團隊做出了預算承諾，但現在卻沒有達到預期時，就會發生更具挑戰性的對話。在這種情況下，我們會提出諸如以下的疑問：
- 為什麼我們沒有達成我們承諾的目標？
- 這是一次性的情況嗎？
- 這是一個新的趨勢嗎？
我們試圖與他們一起找出解決方案，提出諸如以下的疑問：
- 你能否改變其他一些事情，以達到承諾的目標？
- 我們看到越來越多的浪費建議；能否安排一些時間來清理它們？
- 我們可以做些什麼改變，以減少資源變成浪費的可能性？
內容解密：
上述段落描述了 Atlassian 的 FinOps 團隊如何與工程師合作，共同推動成本最佳化的目標。首先，團隊會明確提出具體請求，並解釋對業務的影響。在遇到挑戰時，團隊會與工程師一起分析原因，並尋找解決方案。這種合作方式有助於建立信任，並推動 FinOps 成為工程師日常工作的一部分。
資料在工程師工作流程中的重要性
工程師，尤其是開發人員，通常處於深度專注的工作週期中，通常被稱為「流程」。打斷這個流程可能會嚴重影響工程師的工作表現。因此，只有在需要立即回應或採取行動時，才應該使用即時通訊方式，如聊天、視訊通話或親自拜訪，來打斷工程師的工作。如果需要的行動可以等待，那麼就應該考慮如何以不打斷工程師工作流程的方式通知他們。
回到第8章介紹的「資料在工程師工作流程中」的概念，讓 FinOps 資料存在於工程團隊已經工作的場所，是減少工程師參與 FinOps 所需努力的關鍵因素。將 FinOps 與工程師現有的流程整合，避免了他們開啟新的報告和執行額外的 FinOps 相關儀式的努力。然而，未經宣佈就將 FinOps 注入工程團隊報告和流程中應該避免，因為這可能會真正打斷工程團隊儀式的流程。理想情況下，工程師應該幫助指導在哪裡插入 FinOps 資料，以最大程度地幫助他們在現有的工作流程中。
內容解密：
本段強調了讓 FinOps 資料融入工程師工作流程的重要性，以減少對他們的幹擾。將 FinOps 與現有的流程整合，可以避免額外的努力，並使工程師更容易接受 FinOps。同時，也強調了與工程師合作，找出最合適的整合方式。
建立成本效益文化
如果長官層要求工程師立即清理雲端浪費並削減10%的成本，他們很可能會看到快速的結果。命令是讓工程師採取行動的快速方式。但它們往往不可持續，並且可能創造出負面的文化衝擊。一旦命令過時，不再被長官層強化，它就會從工程團隊的腦海中淡去，他們會重新關注交付和其他關鍵指標的最佳化。
然而，對 FinOps 的負面感受卻是持久的。成本命令是點狀的短期影響，但隨著時間的推移，你會再次遇到相同的浪費問題。更廣泛的訊息，即成本指標對業務很重要，應該不斷被重申，成為工程運作方式的一部分。
當你開始在文化層面建立成本效益是核心價值觀時，它就成為服務工作流程的一部分。目標是建立習慣和肌肉記憶，讓 FinOps 成為整個故事的一部分。文化不會消失——它只是成為日常工作的一部分。
內容解密：
本段討論了建立成本效益文化的必要性。單純依靠命令式的方法來削減成本可能是短期的，但不可持續。透過將成本效益納入文化層面，可以使其成為工程師日常工作的一部分，從而達到長期的效果。
與工程團隊合作推動FinOps實踐
要成功實施FinOps，與工程團隊的合作是至關重要的。FinOps團隊需要與工程團隊密切合作，瞭解他們現有的流程和報告，並獲得他們的反饋，瞭解FinOps資料將在哪裡帶來最大的效益。當工程師能夠參與FinOps的實施方式時，他們更有可能幫助推動所需的變更。
與工程團隊合作的模式
每個FinOps團隊都會根據團隊成員的知識和技能組合，以不同的方式與公司的工程師合作。
直接貢獻
具備工程技能的FinOps團隊通常會採取更積極主動的方法，直接幫助工程師設計更高效的雲端服務，並開發工具以避免從一開始就產生浪費。這是一種在工程師和FinOps團隊之間建立協作環境的有力方法，可以更有效地將使用率最佳化的數量降至最低。對於非常大的公司來說，這種型別的合作夥伴關係可能有其侷限性，因為積極參與雲工作的工程團隊數量可能會超出FinOps團隊的能力範圍。
間接協作
並非所有的FinOps團隊都有工程師，但這並不意味著他們在與周圍的工程團隊合作時會無效。這種型別的合作夥伴關係通常會看到FinOps團隊與組織內的雲卓越中心（CCoE）或技術架構組（TAG）之間有著強大的協作。依靠TAG和/或CCoE團隊來幫助推動所有工程團隊更高效地設計，並利用他們深厚的雲知識幫助FinOps瞭解目前的雲支出，預測未來的成本，並清楚地識別最佳化機會。
具有針對性貢獻的間接協作
作為與工程團隊合作的混合方法，採用間接協作模式，但利用FinOps團隊成員的工程技能來針對業務的特定領域。FinOps成員可以直接與支出最大的工程團隊合作，或專注於組織內雲成熟度最低的工程團隊，以提升他們。執行這種直接協作的FinOps團隊成員可能會隨著需求變化在組織內浮動，或專門負責特定的工程領域。在Atlassian，有成本工程師嵌入其他團隊來執行此功能。
選擇合適的合作模式
選擇建立合作夥伴關係的模式應該首先評估FinOps團隊中的技能、CCoE/TAG團隊在工程領域內的成熟度，以及所有工程團隊在雲採用方面的成熟度。選擇一種模式並不會將您鎖定在那種合作方式上，隨著您的雲足跡擴大，混合模式變得越來越可能。
與其他IT框架的連線
除非您的公司是在雲端誕生的，並且大部分技術預算都花在雲端，否則FinOps很可能不會在真空中存在，並且它可能不是貴組織實踐的唯一IT管理規範。大多數大型組織使用各種不同的IT管理規範來定義如何交付技術服務，瞭解相關支出的價值，加速採用或交付曲線，並使組織免受各種風險。
常見的IT相關框架
我們列出了一些常見的與FinOps並存的框架。它們通常以以下方式與FinOps互動：
這些框架涵蓋了廣泛的IT管理領域，如資產、許可證、財務管理、安全、開發實踐、架構流程等。與這些框架和規範成功合作，可以使它們互相補充，而不是重疊或競爭。
IT相關框架與FinOps的互動
@startuml
skinparam backgroundColor #FEFEFE
skinparam componentStyle rectangle
title 雲端成本效益工程實踐原則
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與其他IT相關框架之間的互動關係。FinOps與資產管理、許可證管理、財務管理、安全規範、開發實踐和架構流程等領域都有聯絡，這些領域共同促進了成本最佳化、風險管理、敏捷開發和技術標準，最終實作高效營運。
重點摘要
本章節主要闡述了FinOps與其他IT框架之間的關係和互動方式，強調了不同IT管理規範之間的協作對於實作高效營運的重要性。
與其他框架的連線
FinOps 能夠與多個 IT 管理和財務學科相互協作，從而更有效地管理雲端資源和成本。這些學科包括：
IT 管理學科
- IT 服務管理 (ITSM)
- IT 基礎架構函式庫 (ITIL)
- 組態管理 (CM)
FinOps 可以提供雲端環境中執行的資源詳細資訊、資源組態方式以及它們所在的地理位置或區域。第 12 章中涵蓋的內容，如成本分配、帳戶層級結構和標籤等，在這裡非常重要。
IT 財務學科
- IT 財務管理 (ITFM)
- 技術業務管理 (TBM)
- 軟體資產管理 (SAM)
- IT 資產管理 (ITAM)
FinOps 有助於對雲端帳單中不同型別和類別的雲端使用情況進行分類別。所需的分類別可能會推動您的標籤策略。跨雲端環境跟蹤許可證使用情況和資產生命週期是重要的概念。它們專注於將雲端計費的詳細資料與其他財務框架提供的現有 IT 成本類別相匹配。
資訊安全 / 網路安全
FinOps 通常會分享異常檢測資料，這可能有助於提醒安全團隊關注潛在問題。標籤標準可以幫助安全團隊快速識別被安全流程標記為審查的雲端資源的所有權和預期用途。
GreenOps
這部分在第 19 章中有詳細介紹。
與其他框架的協作
在採用公有雲之前，您的組織可能已經使用了多種方法論、學科和實踐來管理 IT 交付的特定方面。一個常見的頓悟時刻是，這些其他學科實際上並不具備處理雲端的自助服務、按需和大量變化的特性，也無法處理它輸出的大量計費資料。FinOps 的目的不是取代這些學科，而是幫助實作相同的總體結果：為每筆技術支出帶來最大價值，但具有對雲端的深度領域關注。
您的組織可能正在採用或使用敏捷或 DevOps 框架的其中一種實作，以幫助加速和協調您的 IT 價值交付。您的組織可能已經有企業架構團隊，利用其中一種架構框架來推動您開發和實施 IT 解決方案。您可能已經有一個雲端卓越中心 (CCoE) 或雲端平台團隊，使用您所使用的雲端服務提供商的其中一個雲端採用框架或良好架構框架。而且，您一定有一個資訊安全團隊，專注於確保每個產品和工程團隊都保持對網路安全要求和風險的高度關注。
總擁有成本
由於 FinOps 特別關注雲端，因此您需要與組織中的其他團隊合作，以取得部分在雲端、部分在本地佈署的應用程式或產品組合的總擁有成本 (TCO)。所有那些您不透過雲端帳單購買的成本——租金、勞動力、合約和一些許可證——因此通常不會出現在您的 FinOps 報告中，都是您的 TCO 的一部分。瞭解 TCO 對於確定您的技術採購價值至關重要，並能夠實作我們在第 26 章中討論的資料驅動決策的理想狀態。
與其他方法論和框架合作
在開發 FinOps 時，您應該採取多個步驟，以避免與已建立的其他方法論或框架發生衝突。
發現誰在負責其他框架
FinOps 團隊開始工作後，有時會發現有其他團隊正在營運其他 IT 框架。這可能會導致團隊之間的誤解，認為彼此的工作存在衝突或重複。理想情況下，您應該在實施 FinOps 的過程中盡早識別誰在負責哪些框架和職能。首先要了解每個團隊的作用以及他們為業務帶來的價值。與他們溝通，瞭解他們正在嘗試實作什麼，以及誰是他們的執行發起人，並且最重要的是，開始建立工作關係。
成功合作案例
在 Pearson 公司，FinOps 長官者 Ashley Hromatko 分享了一個故事，講述了她的團隊如何與現有的 SAM (軟體資產管理) 實踐合作，建立了一種協作實踐：
在我們數位轉型之旅的高峰期，將數百個工作負載遷移到雲端時，我們開始簡化我們對第三方軟體和服務的採購，將其轉移到 AWS Marketplace。我們的組織有集中的採購和 SAM 團隊，但業務部門希望透過更快的雲端採購來釋放創新。這種敏捷性帶來了風險，即業務部門在沒有審批或談判的情況下存取資金，購買許可證時沒有公司範圍內的協定洞察，以及對供應商合約的適當審查。
我們的團隊體現了 FinOps 的原則，即「團隊需要協作」，開始瞭解現有的採購和 SAM 流程，並開始代表工程業務部門倡導提高效率、承諾優勢和可存取的粒度跟蹤的好處。
建立新的雲端治理
透過共同努力，這些團隊能夠建立一些基本規則，並共同制定新的雲端第三方治理。這包括鎖定對 AWS Marketplace 的存取許可權給授權負責人，制定需要 SAM 和財務參與的入門，記錄合格供應商清單，建立在購買前收集詳細資訊的工作流程，定期審核購買行為，以及新的攤銷成本分配輸出。我們繼續每年合作進行預測，並就下一年度採購哪些型別的第三方軟體和預算門檻做出商業決策。
