FinOps 生命週期是一個持續迭代的過程，旨在幫助企業有效管理和最佳化雲端成本。它涵蓋資訊、最佳化和營運三個階段，並透過持續監控、分析和調整，以確保雲端資源的最佳利用和成本效益。瞭解雲端成本的驅動因素，並將其與業務價值關聯，是 FinOps 的核心目標。透過跨團隊協作和實時支出能見度，企業可以更好地控制雲端成本，並將資源投入到更具戰略意義的業務發展中。全面負擔和分配成本是 FinOps 的基礎，可以幫助企業更精確地追蹤和分析支出，並識別潛在的最佳化機會。
FinOps 生命週期
在第一章中，我們討論了FinOps的核心原則。這些原則有助於指導行動，在第7章中，我們討論了建立在這些原則基礎上的FinOps框架。本章涵蓋了FinOps生命週期的持續、迭代階段，以及如何將它們應用於FinOps的能力。
FinOps的六大原則
再次列出這些原則如下：
- 團隊需要協作
- 決策由雲的業務價值驅動
- 每個人都對其雲使用負責
- FinOps報告應具有可存取性和及時性
- 集中團隊推動FinOps
- 利用雲的可變成本模型
#1：團隊需要協作
首先，FinOps是一種文化變革，專注於打破歷史上沒有密切合作的團隊之間的隔閡。當做得好時，財務團隊使用語言和報告，以雲的速度和粒度移動；產品經理微調他們的應用程式擴充套件預測，以適應新功能的預期收入；而工程團隊則將成本視為新的效率指標。
#2：決策由雲的業務價值驅動
首先考慮雲支出的業務價值，而不是成本。很容易把雲視為成本中心，尤其是當支出達到實質性水平時。雲是一個價值創造者，但你使用的越多，成本就會越高。FinOps的作用是幫助最大化由該支出創造的價值。不要關注每月的成本，而是關注每項業務指標的成本，並始終以業務價值為出發點做出決策。
#3：每個人都對其雲使用負責
雲成本根據雲使用，這是一個直接的相關性：如果你正在使用雲，你就會產生成本，因此你對雲支出負責。透過將雲支出責任推到組織邊緣，一直到個別工程師和他們的團隊，來接受這一事實。併為他們提供資訊和指導，使他們能夠為組織做好這項重要的工作。
#4：FinOps報告應具有可存取性和及時性
在每秒甚至微秒計算資源、雲端儲存無限制、分享Kubernetes叢集、自動化佈署和可能因外部控制觸發而產生成本的服務的世界中，每月或每季度的雲支出報告是不夠的。即時決策是關於快速將資料（如支出變化或異常警示）提供給佈署和管理雲資源的人員。
#5：集中團隊推動FinOps
文化變革在有旗手的情況下效果最佳。中央FinOps職能透過教育、標準化和傳播最佳實踐，將最佳實踐推入組織。這個集中團隊是您找到主題專家的地方，他們透過倡導和教育改變文化。FinOps團隊透過更好的工具改進可用資料，並修改業務流程，使您的組織能夠進行FinOps。
#6：利用雲的可變成本模型
在分散的雲世界中，容量規劃從前瞻性的“您需要什麼來滿足需求？”的角度轉變為即時的“我們如何在已經使用的基礎上保持預算？”的角度。根據實際使用資料，而不是根據可能的未來需求，進行權利調整、批次折扣和RI/SP/CUD購買。
程式碼處理及解說
import boto3
# 初始化AWS Cost Explorer客戶端
ce = boto3.client('ce')
# 取得當前月份的成本和使用量資料
response = ce.get_cost_and_usage(
TimePeriod={
'Start': '2023-03-01',
'End': '2023-03-31'
},
Granularity='DAILY',
Metrics=['UnblendedCost'],
GroupBy=[
{
'Type': 'DIMENSION',
'Key': 'SERVICE'
}
]
)
# 列印每天的成本和使用量資料
for result in response['ResultsByTime']:
print(f"日期：{result['TimePeriod']['Start']}")
for group in result['Groups']:
print(f"服務：{group['Keys'][0]}，成本：{group['Metrics']['UnblendedCost']['Amount']}")
內容解密：
此程式碼範例使用AWS SDK for Python（Boto3）來取得當前月份的成本和使用量資料。首先，我們初始化AWS Cost Explorer客戶端，然後呼叫get_cost_and_usage方法來取得資料。我們指定了時間範圍、粒度、要檢索的指標以及要分組的維度。最後，我們列印每天的成本和使用量資料。
- 初始化AWS Cost Explorer客戶端：使用
boto3.client('ce')初始化AWS Cost Explorer客戶端，這是與AWS Cost Explorer服務進行互動的介面。 - 取得成本和使用量資料：呼叫
get_cost_and_usage方法來取得指定時間範圍內的成本和使用量資料。我們指定了TimePeriod、Granularity、Metrics和GroupBy等引數來控制傳回的資料。 - 處理傳回的資料：遍歷傳回的結果，並列印每天的成本和使用量資料。對於每個結果，我們提取日期、服務名稱和成本金額，並將其列印預出來。
此程式碼範例演示瞭如何使用AWS SDK for Python來取得和分析AWS成本和使用量資料。您可以根據自己的需求修改此程式碼，以滿足特定的分析或報告要求。
FinOps 生命週期：雲端成本管理的三階段迴圈
隨著雲端實踐的成熟，企業開始關注如何充分利用現有的服務和資源，並盡可能延長其使用壽命。雲原生服務和諸如 Spot Instances 等模式的採用，可以幫助企業在需求出現時利用低成本資源。
FinOps 生命週期
FinOps 生命週期包含三個主要階段：資訊（Inform）、最佳化（Optimize）和營運（Operate）。這些階段並非線性進行，而是需要不斷迴圈的過程。
資訊階段（Inform）：提供成本分配的能見度，並透過顯示團隊的支出和原因，建立共同的責任感。這個階段使個人能夠看到他們的行為對帳單的影響。
最佳化階段（Optimize）：賦予團隊識別和衡量效率最佳化的能力，例如正確調整資源大小、儲存存取頻率或改善 RI（Reserved Instances）覆寫率。根據識別出的最佳化機會，設定與每個團隊關注領域相符的目標。
營運階段（Operate）：定義並實施能夠實作技術、財務和業務目標的流程。可以佈署自動化，以可靠和可重複的方式執行這些流程。
FinOps 生命週期
圖表翻譯： 此圖示展示了 FinOps 生命週期的三個主要階段及其迴圈關係。從「資訊」階段開始，企業獲得對成本的能見度；接著進入「最佳化」階段，團隊根據能見度進行成本最佳化；最後在「營運」階段實施最佳化措施。整個過程形成一個迴圈，不斷重複以實作持續改進。
資訊階段詳解
在資訊階段，企業開始瞭解其成本和背後的驅動因素。透過向團隊提供近乎即時的成本能見度，推動更好的行為。這個階段的主要活動包括：
將支出資料對映到業務：在實施準確的收費機制之前，必須根據成本中心、應用程式和業務單位，將支出資料正確對映到組織架構中。
建立 Showback（和其他）報告：透過 Showback 或類別似模型，向每個團隊展示其支出，推動支出責任制。這是驅動支出所有權和最終從中取得最大價值的基礎。
定義預算和預測：FinOps 團隊應提供必要的資料，讓團隊能夠對不同專案的雲端使用情況進行預測，並提出每個專案的預算。這些預算和預測應考慮雲端架構的所有方面，包括雲原生服務、容器和相關成本。
定義帳戶策略：組織如何分配和使用 AWS 帳戶、Google Cloud 專案、Azure 訂閱/資源群組或其他層級分組，將對成本分配產生重大影響。
設定標籤策略和合規性：後設資料策略（標籤和標記）既是一門藝術，也是一門科學。即使有強大的帳戶層級結構，仍需要早期協調一致的標籤策略，以實作更細粒度的成本分配。
識別未標記（和無法標記）的資源：將未標記的資源分配給團隊或工作負載，並對無法標記的資源應用元層分配，是實作正確收費、能見度和後續最佳化的關鍵。
公平分配分享成本：像支援和分享服務這樣的分享成本，應以適當的比例分配給相關方。可以根據使用指標（如支出或計算小時數）進行分配。
程式碼範例：成本分配邏輯
def allocate_cost(resources, teams):
# 將資源對映到團隊
resource_allocation = {}
for resource in resources:
team = resource['team']
if team not in resource_allocation:
resource_allocation[team] = []
resource_allocation[team].append(resource['cost'])
# 計算每個團隊的總成本
team_costs = {team: sum(costs) for team, costs in resource_allocation.items()}
return team_costs
# 範例資源列表
resources = [
{'team': 'TeamA', 'cost': 100},
{'team': 'TeamB', 'cost': 200},
{'team': 'TeamA', 'cost': 50},
]
#### 內容解密：
此程式碼範例展示瞭如何根據團隊分配成本。首先，它遍歷資源列表，將每個資源的成本對映到對應的團隊。然後，計算每個團隊的總成本。這樣的邏輯有助於在 FinOps 的資訊階段實作成本的可見化和責任制的建立。
雲端財務營運（FinOps）生命週期中的動態成本最佳化
雲端財務營運（FinOps）是一種強調企業在雲端運算環境中實作財務可視性、成本最佳化和資源有效利用的方法論。FinOps生命週期涵蓋了多個階段，包括成本分析、最佳化目標設定以及持續改進等。本文將探討FinOps生命週期的各個階段，並分析其在企業雲端成本管理中的重要性。
動態計算自訂費率和攤銷
企業需要考慮任何自訂的費率協定，並確保RI（Reserved Instances）、SP（Savings Plans）和CUD（Committed Use Discounts）所帶來的折扣能夠正確應用。同時，預付費用的攤銷也必須被正確計算，以確保團隊追蹤的支出資料準確無誤，避免與財務團隊的賬單出現差異。
def calculate_amortized_cost(prepayment, period):
# 計算攤銷成本
amortized_cost = prepayment / period
return amortized_cost
# 範例用法
prepayment = 12000 # 預付費用
period = 12 # 攤銷期數（月數）
amortized_cost = calculate_amortized_cost(prepayment, period)
print(f"每月攤銷成本：{amortized_cost}")
內容解密：
此程式碼範例展示瞭如何計算預付費用的攤銷成本。calculate_amortized_cost函式接受兩個引數：prepayment（預付費用）和period（攤銷期數）。函式內部簡單地將預付費用除以攤銷期數，得到每期的攤銷成本。在實際應用中，這有助於企業準確追蹤每月的雲端支出。
分析趨勢和變異
識別支出驅動因素通常需要對不同時間段進行臨時比較，並能夠在高層級（如成本中心）和資源層級（如容器、函式等）進行報告，以深入瞭解成本驅動因素。
SELECT
cost_center,
resource_type,
SUM(cost) AS total_cost
FROM
cloud_spend
GROUP BY
cost_center, resource_type
ORDER BY
total_cost DESC;
內容解密：
此SQL查詢範例用於分析不同成本中心和資源型別的總支出。查詢結果按照總支出降序排列，有助於企業快速識別主要的成本驅動因素。透過定期執行此類別查詢，企業可以及時發現支出趨勢的變化並做出相應調整。
建立評分卡和基準測試
評分卡使FinOps團隊能夠對不同專案團隊的成本最佳化、速度和品質進行基準測試。這是一種快速識別改進領域的方法，需要使用完全負載和正確分配的成本資料。
異常檢測和最佳化
異常檢測不僅涉及識別費用門檻，還需要監控使用量的異常波動。隨著雲端服務供應商提供的可變收費服務種類別日益增多，異常檢測有助於發現需要快速補救的問題。
最佳化階段
最佳化階段旨在找出對雲端環境的改進措施並設定未來營運階段的目標。在此階段，企業會設定成本避免和成本最佳化目標，並利用雲端服務供應商提供的優惠方案來降低成本。
識別未充分利用的服務
一旦團隊能夠檢視正確分配的支出和使用情況，就能夠開始識別未使用的資源，並根據產生的建議消除未使用的資源、調整週期性使用的資源規模，或重新設計運作不良的資源。
評估集中式承諾基礎折扣選項
作為降低成本的措施，FinOps團隊可以評估現有的RI、SP或CUD的使用情況，並尋找購買更多或出售/修改現有承諾的機會。
營運階段
營運階段設定了實作最佳化目標的流程。此階段強調流程的持續改進。一旦自動化流程到位，管理階層會退一步確保支出水平與公司目標保持一致。
向利益相關者交付支出資料
在營運階段，企業需要定期向利益相關者提供支出資料，使他們能夠根據預算進行跟蹤。這需要建立報告流程和自動化機制，以生成和提供報告。
成熟的FinOps實踐：最佳化與營運階段的關鍵策略
在企業雲端運算的財務管理（FinOps）實踐中，最佳化與營運階段是實作成本效益與效率提升的關鍵環節。成熟的FinOps團隊透過系統化的方法，不斷迭代改進他們對雲端資源的理解，並提升報告效率。
調整例項與服務規模
在最佳化階段，企業可能會發現他們為計算資源支付的費用超過實際需求。進入營運階段後，工程師會根據生成的建議進行調整，例如：
- 轉換至效能較低但成本更低的例項
- 以較小的儲存空間替換未使用的儲存
- 使用更符合存取需求的儲存層級
成熟的FinOps團隊會在所有主要的支出驅動因素上執行這些調整，以最大化成本效益。
建立雲端使用治理與控制
雲端運算的核心價值在於加速交付和促進創新。然而，成本控制也是企業必須考慮的因素。因此，成熟的企業會不斷評估他們對雲端服務使用的規範，確保這些規範不會阻礙創新和靈活性。
持續改進效率與創新
這是一個持續、迭代的過程，透過最佳化目標和指標來推動更好的業務成果。所謂的「指標驅動成本最佳化」，是指透過定義關鍵指標和目標閾值，並對其進行監控，以驅動未來的最佳化行動，而不是按照固定的最佳化週期進行。
自動化資源最佳化
成熟的團隊會透過程式化檢測來發現需要調整的資源規模，並自動清理未充分利用的資源，從而提高效率。
將建議整合到工作流程中
成熟的FinOps團隊不再要求應用程式負責人手動登入檢視建議，而是將架構建議、調整規模建議、現代化機會等直接推播到迭代規劃工具中。這不僅包括戰術性的成本最佳化資料，還包括戰略性的洞察，幫助團隊瞭解如何透過架構或軟體開發來提高成本效率。
將費用分攤整合到內部系統中
一旦實施了費用分攤並為團隊提供了可視性，成熟的FinOps團隊就會透過應用程式介面（API）將這些資料程式化地整合到內部報告系統和財務管理工具中。
建立策略驅動的標籤清理和儲存生命週期政策
成熟的團隊會透過策略（如「標籤或終止」或「佈署時標籤」）來程式化地清理標籤。他們還會實施策略驅動的儲存生命週期，以確保資料自動儲存在最具成本效益的層級。
重點考慮因素
在開始FinOps實踐旅程時，有幾個關鍵因素需要評估：
單位經濟效益
將雲端支出與實際業務成果掛鉤非常重要。如果企業在成長過程中雲端支出增加，只要能夠持續降低服務客戶的成本，這未必是壞事。單位經濟效益提供了一個清晰、共同的語言，使組織各層級都能有意義地討論雲端支出。
文化
營運階段是評估FinOps文化採用情況的好時機。資源利用效率低下或預留例項（RI）覆寫不足的問題，往往是由於溝通不暢和組織孤島所致。需要檢查團隊是否積極主動、是否設計出高效利用雲端的服務，並評估可用的FinOps培訓是否得到充分利用。
交付速度
交付速度受到成本和品質之間的權衡影響。管理階層可能希望與FinOps團隊成員討論特定專案，以決定是否調整這兩個槓桿來提高交付速度。
對業務的價值
管理階層可能還希望評估雲端支出是否反映了專案對業務的價值。這是另一個與FinOps團隊成員討論特定專案的機會，以決定是否繼續按照現有方式營運，或進行一些變更。
從哪裡開始？
可以從提出問題開始，啟動資訊階段。可以將FinOps生命週期視為一個閉環賽道，無論從哪個點切入，最終都會回到起點。然而，建議從資訊階段開始，在進入最佳化或營運階段之前，先獲得對雲端環境的可視性，並做好分配清理的工作。
無論處於生命週期的哪個階段，都應持續關註文化和治理。FinOps的真正力量來自於將行動和工具與文化變革相結合，從而改變整個組織使用雲端的方式。
你不需要找到所有答案
在開始告訴團隊關閉某個資源或縮減某個資源之前，必須真正瞭解成本驅動因素，並讓團隊看到他們的支出對業務的影響。這將推動一些令人驚訝的、自主的結果。例如，一家製造公司僅僅透過向團隊展示他們的支出情況，就實作了每年六位數的節省。
總之，成熟的FinOps實踐需要企業在最佳化與營運階段採取系統化的方法，透過持續改進、自動化和整合來提升成本效益和效率。同時，企業還需要關註文化、治理和單位經濟效益，以實作雲端財務管理的最佳實踐。
資訊揭露階段：您目前的狀況為何？
開始您的 FinOps 實踐，首先要提出問題。這正是資訊揭露階段的核心內容。當您找到這些問題的答案後，便能開始評估雲端狀態。在本章中，我們將探討一些您應該從何開始的問題，並對一些常見能力的理想狀態進行展望。所有這些都有助於您在進入最佳化階段時知道該聚焦於何處。
如同我們所強調的，FinOps 並非線性過程，而是一個迴圈。第一階段所獲得的能見度對於進入下一階段至關重要。您將花費大部分時間在資訊揭露階段。如果過快跳至最佳化，很容易犯下代價高昂的錯誤。正如木匠們自古以來所提醒的，「量兩次，切一次」。測量使您有所準備以進行變更，然後再根據營運指標衡量這些變更，如此反覆。您將不斷迴歸資訊揭露階段，以再次確認哪些行動對業務有益。
您首先要嘗試回答的問題是：「總雲端支出、其預測及其增長率是多少？」
如果這些數字對企業來說無關緊要，那麼在最基本的報告到位後，可能需要考慮暫停。回想第2章中討論的「知情忽視」概念。
沒有背景的資料毫無意義
當然，找到資料是不夠的，您必須對其進行解讀。您的目標是自我教育。您需要與財務、工程和業務部門的同事展開對話，討論您想要實作的目標。
要做到這一點，經驗豐富的 FinOps 從業者會提出問題，這些問題將為建立適當的分配結構奠定基礎，如第11章所述。請記住，您並非試圖解決所有問題。您的目標是找出那些將在整個 FinOps 生命週期中得到答案的問題。
這個過程還能完善第4章中討論的共同語言。它防止了對資料的不信任，以及當團隊之間缺乏協調時經常出現的相互指責。
任何改進若不在瓶頸處進行，都只是幻覺。 — Gene Kim，《鳳凰專案》
即使是最有經驗的 FinOps 從業者——那些建立了多個成熟實踐的人——在建立實踐時也會遵循 FinOps 流程的逐步成熟。您的初始目標是取得一些容易的勝利，摘取低垂的果實，建立肌肉記憶，並獲得評價。想想 DevOps，而不是瀑布式開發。想想 Gene Kim，而不是 Winston W. Royce。
首先要理解
當您開始這個階段時，您可能會立即發現一些浪費。想要立即修復它是自然且可以理解的。然而，首先要問的是：「這些浪費從何而來？」這將幫助您找出根本原因，並防止下次再次發生。換句話說，您應該抵制直接對雲端資產進行更改的誘惑，而是首先專注於回答問題。
確定需要提出哪些問題的最有效方法之一是訪談組織中的各個利益相關者。當您瞭解他們關心的問題時，便能利用這些知識為您的報告和分配結構建立所需的背景。
以下是一組問題，可以幫助您入門：
- 您想要報告什麼？是成本中心、應用程式、產品、業務單位，還是其他？
- 大部分的支出來自哪裡，即來自哪一組服務？
- 您打算進行費用分攤還是成本回報？兩者都有各自的好處，但無論哪種方式都有助於提高責任感。
- 如果您打算集中管理費率，那麼共同利益是否是優先事項，還是透過費用分攤來收回成本更為重要？
- 看到支出趨勢是否足夠，還是需要精確到一分錢的費用分攤？在初期，趨勢是目標；稍後，細粒度的分配變得重要。
內容解密：
上述段落提出了在 FinOps 資訊揭露階段應該詢問的一些關鍵問題，以幫助組織瞭解其雲端支出狀況和未來最佳化方向。首先，需要確定報告的重點，如成本中心或業務單位。其次，瞭解主要的支出來源有助於聚焦最佳化的方向。同時，決定採用費用分攤還是成本回報機制，以及是否需要精確到一分錢的費用分攤，都是關鍵決策。這些問題有助於建立合適的分配結構和報告機制，從而推動企業雲端財務管理的透明度和責任感。
圖表翻譯：
本章節主要圍繞 FinOps 的資訊揭露階段展開，描述了該階段的主要任務和目標，包括提出問題、瞭解雲端支出狀況、以及建立合適的分配結構和報告機制。下圖使用 Plantuml 圖表呈現了 FinOps 生命週期中的資訊揭露階段：
@startuml
skinparam backgroundColor #FEFEFE
skinparam componentStyle rectangle
title FinOps生命週期雲端成本最佳化
package "資料視覺化流程" {
package "資料準備" {
component [資料載入] as load
component [資料清洗] as clean
component [資料轉換] as transform
}
package "圖表類型" {
component [折線圖 Line] as line
component [長條圖 Bar] as bar
component [散佈圖 Scatter] as scatter
component [熱力圖 Heatmap] as heatmap
}
package "美化輸出" {
component [樣式設定] as style
component [標籤註解] as label
component [匯出儲存] as export
}
}
load --> clean --> transform
transform --> line
transform --> bar
transform --> scatter
transform --> heatmap
line --> style --> export
bar --> label --> export
note right of scatter
探索變數關係
發現異常值
end note
@enduml
圖表翻譯： 上圖展示了 FinOps 生命週期中的資訊揭露階段，該階段是整個流程的起點。透過提出問題和了解雲端支出狀況，組織可以建立合適的分配結構和報告機制，從而推動雲端支出的最佳化。這個過程是迴圈反覆的，不斷地評估和改進，以實作更好的財務管理和成本控制。
內容解密：
本結論總結了 FinOps 生命週期的核心要點，包括其三個主要階段、持續改進的重要性、跨功能團隊的參與、以及提供實時支出能見度的關鍵作用。同時，也強調了全面負擔和分配成本的必要性，為讀者提供了清晰的方向和指引。