返回文章列表
玄貓（BlackCat）

FinOps匯入關鍵角色與推動策略

本文探討 FinOps 匯入的關鍵角色（CEO、CTO、CFO、工程主管）及其目標、痛點和 FinOps 如何協助達成目標。文章也提供匯入 FinOps 的路線圖，涵蓋規劃、推廣、組織準備、實施策略和 FinOps 基礎框架的應用，並輔以程式碼範例和圖表說明，幫助組織有效最佳化雲端投資，實作業務目標。

雲端計算 成本管理
FinOps 雲端成本 成本最佳化 雲端治理 成本分配 KPI

FinOps 的匯入需要跨部門協作，特別是 CEO、CTO、CFO 和工程主管等關鍵角色的參與。CEO 需確保雲端投資與業務目標一致，CTO 負責利用技術創造競爭優勢，CFO 則關注成本可視性和預測性，而工程主管則致力於提高交付速度並控制成本。FinOps 能夠將工程決策與業務成果連結，提供雲端支出預測，並促進組織進行合理的雲端投資。匯入 FinOps 的路線圖包含規劃、推廣、組織準備和實施策略等階段。在規劃階段，需進行研究、制定計劃並取得高層支援；推廣階段則需溝通 FinOps 的價值並蒐集團隊反饋；組織準備階段則需評估 FinOps 準備度並吸引利益相關者；最後的實施策略階段則需從簡單開始，逐步演進，並重視文化變革。

匯入 FinOps 的關鍵角色與推動策略

在匯入 FinOps 的過程中，駕駛員（Driver）必須影響多個關鍵角色，以確保雲端投資與業務目標保持一致。本章節將探討這些關鍵角色的主要目標、痛點以及 FinOps 如何幫助他們實作目標。

關鍵角色及其目標

CEO 角色

CEO 的主要目標是確保雲端投資與業務目標保持一致。常見的業務和 FinOps 目標包括：

  • 加速公司年度增長
  • 取得戰略性競爭優勢
  • 加快上市時間
  • 以具成本效益的方式提供創新、領先市場的解決方案

CEO 常見的痛點包括：

  • 雲端支出不可預測，有時混亂
  • 無法清楚瞭解工程計劃與業務目標之間的聯絡
  • 不確定公司雲端投資的回報

關鍵績效指標（KPI）包括：

  • 收入增長
  • 毛利率
  • 銷售成本（COGS）
  • 單位成本經濟學

FinOps 的好處：

  • 將工程決策與業務成果相連線
  • 預測雲端支出如何隨著業務增長而增長
  • 引導組織進行良好的雲端投資

CTO/CIO 角色

CTO/CIO 的目標是利用技術為企業帶來市場和競爭優勢。常見的目標和痛點包括：

  • 加速公司年度增長
  • 提供創新且具成本效益的解決方案
  • 面臨巨大的壓力，需要證明或降低雲端賬單
  • 缺乏對支出的管控
  • 工程師不滿意

KPI 包括：

  • 營收增長
  • 毛利率
  • COGS
  • 新功能/產品上市時間
  • 工程生產力

FinOps 的好處：

  • 預測雲端支出增長
  • 推動組織進行良好的雲端投資
  • 使工程組織能夠更自由地利用新的雲端技術並更快地向市場交付解決方案

CFO 角色

CFO 的目標是提高成本報告和預測的準確性和可預測性。常見的目標和痛點包括：

  • 成本可視性和精確性
  • 整體單位成本/COGS 降低
  • 在增長期間管理成本，在平穩/下降期間不成比例地降低成本

痛點包括：

  • 雲端支出不可預測，有時混亂
  • 不確定公司雲端投資的回報
  • 成本波動和創新與預算週期不一致

KPI 包括：

  • 營收增長
  • 毛利率
  • COGS
  • 單位成本經濟學
  • 可預測性

FinOps 的好處：

  • 增加對雲端成本的問責制
  • 增加對預算和預測模型的依賴
  • 直接影響公司利潤

工程主管角色

工程主管的目標是提高交付速度，同時具備成本效益並促進創新。常見的目標和痛點包括：

  • 對應用程式/服務負責的工程團隊進行問責
  • 為工程團隊提供指導，識別異常和最佳實踐，實作成本效益高的應用程式/服務

痛點包括：

  • 工程師工作量不斷增加，導致不滿意
  • 長交付週期
  • 無法預測對預算的影響

KPI 包括：

  • 按基礎設施成本劃分的收入
  • 每項佈署服務的成本和服務利用率
  • 向企業展示和收費 IT 成本

FinOps 的好處：

  • 增加對雲端成本的可視性
  • 將雲端成本與單位經濟學相連線
  • 對利用率進行更多問責制

FinOps 匯入路線圖

匯入 FinOps 需要一個結構化的路線圖。以下是根據開放原始碼 Adopting FinOps 工作小組的 sprint 輸出的階段：

第一階段：組織內部的 FinOps 規劃

本階段的目標是為您的組織制定一個適合的 FinOps 轉型計劃，該計劃應根據您可用的資源和最重要的目標進行調整。

  1. 進行研究：找出組織內正確的利益相關者。
  2. 尋求高層支援：需要高層的支援以及培養支援者來建立動力。

本章節提供了匯入 FinOps 的基本框架和關鍵角色，幫助組織瞭解如何透過 FinOps 實踐來最佳化雲端投資並實作業務目標。

圖表翻譯：FinOps 駕駛員與角色互動圖示

此圖示呈現了 FinOps 駕駛員如何與不同角色互動，以協助翻譯需求並建立橋樑，使他們能夠更自主地協同工作。

圖表翻譯： 此圖表顯示了 FinOps 駕駛員在不同角色之間的協調作用。駕駛員負責翻譯各方的需求、建立合作橋樑，並促進不同部門之間的協作，以實作共同的業務目標。

匯入FinOps的策略與規劃

匯入FinOps（Financial Operations）是一項需要周密計劃和跨部門協作的工作。以下將詳細闡述如何規劃和執行FinOps的匯入。

階段1：規劃FinOps匯入

研究與訪談

在匯入FinOps之前，需要進行深入的研究和訪談，以瞭解組織的現狀和痛點。

  • 研究可能的倡導者或執行發起人，並使用自定義的FinOps介紹資料或針對性的訪談問題來確定採用策略。
  • 在對話過程中研究組織所面臨的痛點，例如雲端成本超出業務預算、成本超支的普遍看法、雲端使用者缺乏成本可視性等。
  • 在對話過程中，研究受影響的群體、團隊和個人，找出誰受到這些痛點的影響。

制定計劃

根據研究和訪談的結果，制定一個未來狀態的藍圖，這應該能夠吸引業務部門的注意。

  • 確定工具需求，判斷現有的工具是否能夠滿足計劃的需求。
  • 為FinOps功能確定組織歸屬，可能歸屬於CCoE（Cloud Center of Excellence）、財務部門或IT部門。
  • 識別早期的採用者團隊，他們可以成為推廣FinOps的福音者。
  • 確定用於衡量FinOps功能的KPI（關鍵績效指標），並找出衡量業務部門和應用團隊等利益相關者的參與度和績效的方法。
  • 準備一個在第二階段使用的溝通計劃。

取得支援

匯集培養的支援者，並向他們解釋為什麼採用FinOps很重要。

  • 強調目前的狀態、痛點和其他問題。
  • 識別潛在的威脅，並提供如果不採取行動可能發生的情景。
  • 展示成熟的FinOps對組織的意義。
  • 研究可以被利用的機會。
  • 提出實施計劃的路線圖。

初步資源分配

成功的FinOps需要專門的資源和相關的技能。

  • 請求發起人的支援，招募其他高階長官人作為發起人。
  • 組成一個由真正的組織影響者和利益相關者組成的變革聯盟。
  • 獲得預算批准以招募人員。
  • 根據需求選擇原生工具、第三方工具或自製工具。

階段2：推廣FinOps以獲得組織採用

FinOps是一種文化變革，需要組織內不同團隊和角色的支援。因此，設計用於鼓勵採用FinOps實踐的溝通和反饋迴圈至關重要。

溝通價值

如何讓關鍵利益相關者推廣FinOps：

  • 傳達變革的核心價值。
  • 分享對未來組織願景的簡要總結。
  • 分享高層次的路線圖。

蒐集團隊反饋

與受影響的團隊（如財務主管、產品主管和首席工程師）進行FinOps對話：

  • 提供對FinOps是什麼的理解。
  • 瞭解他們的問題，並解釋/教育他們FinOps如何幫助他們。
  • 討論擬議的KPI，並根據對話反饋進行調整。

定義初始FinOps模型

您的模型應包括資源、營運模型、跨功能互動模式和相關KPI，以報告進展。

重點解讀

在匯入FinOps的過程中，需要注意以下重點：

  1. 早期勝利的重要性：正如Jason Rhoades在Intuit的經驗分享所述，早期取得顯著成果對於獲得高層支援至關重要。透過展示實際節省的成本或解決了特定的雲端成本問題，可以使FinOps的價值更具體、更易於被高層理解。
  2. 溝通與反饋：有效的溝通和反饋機制是推動FinOps實踐成功的關鍵。需要定期與利益相關者溝通，並根據反饋調整策略。
  3. 資源分配：成功的FinOps需要專門的資源和相關技能。因此，獲得預算支援和招募適當的人才至關重要。

匯入FinOps的組織準備

在成功推廣並獲得對文化變革的支援後，現在的工作是評估和吸引業務的各個部分。這個階段的目標是開始在組織內啟動FinOps的飛輪效應，以便能夠在FinOps框架的各個能力和領域中逐步成熟。

評估FinOps準備度

對組織在關鍵能力方面的成熟度進行評估通常包括以下內容：

  • 定義標籤、中繼資料和組織分類別法。
  • 佈署、組態和測試工具。
  • 完成第一波KPI（關鍵績效指標）。KPI/業務採用率指標可以在「採用期」內演變，以創造逐步成熟的FinOps心態，而不是一次性推動完全成熟。
  • 定義使用量和支出門檻，用於警示和報告限制。
  • 定義和準備根據角色的自助服務儀錶板。這些儀錶板應顯示重要的指標，如第一波KPI、成本分配、預算異常、最佳化建議和其他利益相關者感興趣的檢視。
  • 準備包含單位成本計算的預測模型。

吸引利益相關者

現在，您已準備好開始實施模型所需的持續節奏和流程：

  • 確定業務部門對承諾水平的興趣（企業折扣談判、RI/SP/CUD等總成本）。
  • 與早期採用者團隊合作，取得最佳化成果（例如，關閉不再使用的測試環境或例項，以顯示實質性的節省）。
  • 取得一些額外的早期治理成果，以實施FinOps（例如，標記政策、租用即服務自動化等）。
  • 開始定期會議的節奏。FinOps/CCoE團隊應與業務部門、應用團隊、從業者和利益相關者定期溝通，以實施最佳實踐並追蹤KPI。

對組織的FinOps實踐團隊型別的對齊

我們通常看到三種型別的FinOps實踐團隊：集中式、分權式和中心輻射式。

集中式FinOps團隊

集中式FinOps團隊直接向CIO、CFO或CTO匯報，並作為業務部門的服務。他們可能是CCoE的一部分，也可能不是。如果組織沒有CCoE，具有雲支出的業務部門會與專門的FinOps團隊合作，共同開展FinOps活動，而專門的FinOps團隊會集中管理諸如承諾型折扣等最能從集中化中受益的能力。

優點

權威、專業知識、規模經濟

缺點

眾多利益相關者，需要啟用和教育，說服需要高層支援

分權式FinOps團隊

分權式FinOps團隊與特定的業務部門對齊，並為該業務部門的最佳利益服務。每個具有大量雲支出的業務部門都會在其內部擁有專門的FinOps人員，但沒有一個超級的中央團隊來推動整個組織的最佳實踐和可重複的模式。

優點

非常敏捷，與工程團隊緊密結合

缺點

無法最大化費率、重複勞動、容易失去關鍵人才

中心輻射式團隊

中心輻射式團隊允許集中式和分權式的結合。主要業務部門在輻射端擁有專門的FinOps資源，中心的FinOps團隊則專注於最大化費率和啟用更多的輻射端。

優點

主要業務部門擁有專門的FinOps資源，中心的FinOps團隊專注於最大化費率和啟用更多的輻射端

缺點

團隊需要更多的投資、培訓和徵才合適的人才

資源分配：全職、兼職和借調

最終，您的FinOps團隊資源應該完全致力於FinOps；然而，它們通常一開始是以虛線匯報的方式，按一定比例分配時間。兩種模式的結合也很常見：您有專門的FinOps負責人，他與財務或工程合作夥伴有虛線匯報關係。

在初期，不要害怕考慮外部承包商或顧問來啟動、加速甚至執行您的中央實踐的一部分。很難僱用到熟悉FinOps的優秀人才；有時，您可以使用的顧問是最佳選擇。 FinOps基金會有一個FinOps認證服務提供商列表。

通常，非專職的虛擬FinOps團隊可以讓公司開始進行FinOps。利用它來建立一些能力，例如瞭解您的雲支出和識別最大的成本驅動因素的基本知識。當您擅長這一點時，您的成功就成為您爭取專門資源資金的籌碼。從小處著手，尋找勝利，並廣泛宣傳它們。

重要觀念：展示價值以獲得支援

如Mike在Atlassian所發現的那樣，他們知道最佳化支出是有價值的，並且需要了解成本，但直到他能夠展示這種影響有多大時，他才獲得了擴大專門團隊的支援。這是根據真實世界的例子，而不是預測的硬資料所帶來的結果。 FinOps人員組態的美妙之處在於它通常能夠自我支付。很少能對高層說：「給我五個資源，我就能把錢還給你。」

但是，如果您的提案被駁回，沒有獲得團隊資金，該怎麼辦？是時候看看企業為什麼做出這樣的選擇了。這可能是我們所謂的「深口袋綜合症」，即優先事項是無論如何都要遷移，而高層希望團隊首先擔心完成這件事。

落實FinOps的組織採用策略

要使企業成功採用FinOps，需要謹慎規劃、瞭解高層管理者的動機，並深入研究組織的運作方式。FinOps的實施需要從簡單的系統開始，逐步演進，避免過度複雜的計畫。

從簡單開始，逐步演進

根據約翰·蓋爾（John Gall）在《系統學：系統如何運作以及如何失敗》（Systemantics: How Systems Work and Especially How They Fail）中的名言：「一個有效的複雜系統總是由一個簡單有效的系統演變而來。一個從頭開始設計的複雜系統永遠無法運作，也無法透過修補使其運作。」這意味著，FinOps的採用計畫應該簡單明瞭，專注於最關鍵的部分。

具體步驟：

  1. 定義關鍵利益相關者：找出對FinOps實施至關重要的團隊和人員。
  2. 評估現有技能和資源：確定現有的技能組合和資源，並找出需要填補的空白。
  3. 制定可實作的目標：設定明確且可實作的目標，以推動FinOps實踐。
  4. 規劃成本分配策略：開始規劃如何有效地進行成本分配。

重視文化變革

實施FinOps不僅僅是技術上的改變，更是一種文化上的轉變。這種變革需要時間，可能會持續數年。企業需要準備好讓FinOps實踐隨著時間的推移而逐漸成熟。

如同人體的免疫系統一樣，FinOps實踐不會一開始就完美無缺。它需要從基本的系統開始，透過經驗學習，逐漸發展出適應不斷變化環境的能力。

FinOps基金會框架

FinOps基金會框架是一套不斷演進的構建模組，能夠幫助企業根據自身的雲端成熟度和複雜度建立FinOps實踐。本章節將介紹該框架的結構，並說明如何將其應用於企業的FinOps實踐中。

框架的主要組成部分

  1. 原則：指導FinOps實踐的基本原則。
  2. 角色：定義了參與FinOps實踐的不同角色和責任。
  3. 成熟度特徵：描述了FinOps實踐在不同成熟度階段的特徵。
  4. 關鍵能力：列出了成功實施FinOps實踐所需的關鍵能力。

成本分配範例程式碼（使用Python）：

def allocate_cost(cloud_cost, departments):
    """
    將雲端成本分配到不同的部門。

    :param cloud_cost: 總雲端成本
    :param departments: 部門列表，每個部門包含名稱和使用率
    :return: 各部門的成本分配結果
    """
    total_usage = sum(dept['usage'] for dept in departments)
    allocation_results = []

    for dept in departments:
        allocation_percentage = dept['usage'] / total_usage
        allocated_cost = cloud_cost * allocation_percentage
        allocation_results.append({
            'department': dept['name'],
            'allocated_cost': allocated_cost
        })

    return allocation_results

# 範例用法
cloud_total_cost = 10000
departments_usage = [
    {'name': 'IT', 'usage': 30},
    {'name': 'Marketing', 'usage': 20},
    {'name': 'Sales', 'usage': 50}
]

allocation_result = allocate_cost(cloud_total_cost, departments_usage)
for result in allocation_result:
    print(f"部門：{result['department']}, 分配成本：{result['allocated_cost']}")

內容解密：

此Python函式allocate_cost用於根據各部門的使用率將總雲端成本進行分配。首先，它計算所有部門的總使用率，然後根據每個部門的使用率佔總使用率的比例來計算其應分配的成本。最後，傳回每個部門的成本分配結果。此範例展示瞭如何在實際操作中應用成本分配的概念。

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框架包括原則、角色、成熟度特徵和關鍵能力四個主要部分，分別指導實踐、定義責任、評估成熟度和實作成功實踐，共同構成了完整的FinOps實踐體系。

FinOps 基礎框架：實踐與組織成熟度的關鍵

FinOps 基礎框架（FinOps Foundation Framework）不僅是雲端財務管理實踐的核心，更是組織內部溝通與協作的根本。它為評估組織的 FinOps 成熟度提供了標準化的基礎，幫助關鍵利益相關者達成共識。

實踐的操作模型

將 FinOps 框架視為實踐的操作模型，而非單純的任務清單。由於每個組織的需求與挑戰各不相同，框架提供了一套全面的活動集合，讓實踐者能夠根據實際需求靈活運用。

以園藝為例，每天都需要根據園地的狀況調整工作內容——種植、修剪、澆水、施肥等。同樣地，FinOps 實踐也需要根據組織的即時需求，動態調整優先順序和實施策略。

框架模型解析

FinOps 基礎框架概覽

此圖示展示了 FinOps 基礎框架的主要組成部分，包括原則、角色、成熟度和階段等核心元素。

原則

FinOps 的所有活動都必須遵循第一章中介紹的核心原則。這些原則貫穿於所有的領域、功能、角色和階段，確保實踐的一致性和價值導向。

角色

雖然 FinOps 實踐者需要參與框架的各個方面，但其他相關角色同樣需要理解框架的結構。業務長官者關注領域成果和投資重點，而技術團隊則需要了解他們的工作如何影響特定的功能實作。

成熟度

框架適用於不同成熟度的實踐。隨著組織的成長，會逐步採用更多功能並提高成功指標。每個功能都有其對應的成熟度評估，實踐者應根據組織需求選擇合適的成熟度目標，而非盲目追求最高階別。

階段

FinOps 生命週期包含三個階段：資訊（Inform）、最佳化（Optimize）和營運（Operate）。這些階段幫助組織以迭代和迴圈的方式，不斷改進和提升實踐水平。

網域與功能實作

FinOps 框架透過網域和功能的組合來實作核心概念。網域代表了業務期望達到的高層次成果，而具體的功能則進一步細化了這些成果的實作路徑。

表格：網域列表與主要成果

| 網域 | 主要成果 | |

|

| | （具體網域列表請參考 FinOps 基礎網站） | （各網域對應的主要成果） |

#### 內容解密：

此表格展示了 FinOps 框架中的網域及其對應的主要成果。網域代表了業務期望達到的高層次目標，而主要成果則具體描述了在該網域下應達到的效果。實踐者可以根據這些資訊來評估組織在不同網域的成熟度，並制定相應的改進計劃。

重點與實踐建議

  1. 靈活應用框架：避免將框架視為僵化的任務清單，而應根據組織需求動態調整實踐內容。
  2. 關注成熟度：根據組織的實際情況選擇合適的功能和成熟度目標，避免盲目追求高成熟度。
  3. 持續迭代改進：透過 FinOps 生命週期階段，不斷最佳化實踐過程，提升管理水平。

總之，FinOps 基礎框架為雲端財務管理實踐提供了全面而靈活的操作模型。透過深入理解框架的各個組成部分，並結合組織的實際需求進行實踐，可以有效提升 FinOps 的成熟度和價值實作。