雲端成本最佳化 FinOps 實踐

FinOps 雲端成本最佳化並非一蹴可幾，需要從理解每小時資料的價值開始，才能更精細地規劃資源使用並有效利用承諾折扣。此外，不同月份天數和資源費率的變動性，也需要更精確的成本計算方式。透過成本避免和費率降低這兩個槓桿，可以有效控制雲端支出。實務上，建議將使用量降低（成本避免）分散至應用程式所有者，而費率降低則由集中化的 FinOps 團隊負責，以兼顧效率和專業性。

重視每小時資料的重要性

你可能會好奇為什麼需要考慮每小時（甚至每秒）的資料和資源級別的細粒度。難道每天或每週的標籤級別粒度不夠嗎？簡單來說，不夠，而且當你的 FinOps 實踐成熟後，絕對不夠。

每小時資料的必要性

每小時資料對於執行更高階別的 FinOps 功能至關重要，例如根據承諾的折扣規劃。採購 Savings Plans (SP)、Reserved Instances (RI) 或 Committed Use Discounts (CUD) 的依據是你一段時間內執行特定型別資源的數量，相對於不預留資源的損益平衡點。如果你只統計一個月的資源使用量，你就無法獲得這個重要的細節。要確定你需要多少資源，你必須檢視每個小時（或每秒）執行的資源數量，以及使用量的基準。

程式碼範例：計算每小時資源使用量

import pandas as pd

# 假設我們有一個 DataFrame 記錄了每小時的資源使用量
data = {
    '時間': ['2023-01-01 00:00', '2023-01-01 01:00', '2023-01-01 02:00'],
    '資源使用量': [10, 15, 12]
}
df = pd.DataFrame(data)

# 將時間列轉換為 datetime 型別
df['時間'] = pd.to_datetime(df['時間'])

# 計算每小時的平均資源使用量
average_usage = df['資源使用量'].mean()
print(f"每小時平均資源使用量：{average_usage}")

內容解密：

1. 我們首先匯入 pandas 函式庫，用於資料處理。
2. 建立一個包含時間和資源使用量的 DataFrame。
3. 將時間列轉換為 datetime 型別，以便進行時間相關的操作。
4. 計算每小時的平均資源使用量，以此作為決策的依據。

月份不是固定的單位

想像一家公司在年初啟動了一項新的成本最佳化計劃。它在 1 月 1 日開始實施一系列成本削減措施：「我們關閉了未使用的例項，調整了其他例項的大小，並購買了一些 Savings Plans。」下個月，雲端賬單下降了 10%。成功！

但等一下，如果你將 2 月的天數除以 1 月的天數，你會得到 90%。這看似顯而易見，但你無法統計有多少次因為不同月份的天數差異而讓團隊誤以為他們有效地降低了成本。然後，到了 3 月 31 日，成本反而比上個月增加了 10%，這才引起了恐慌。

月份天數比較

圖表翻譯： 此圖示比較了1月和2月的天數對總成本的影響，闡述了簡單比較每月成本的誤導性。

雲端計費與時間息息相關，而不是固定的月份。雲端計費不像許多財務團隊慣用的固定月份那樣。如果你想要進行同類別比較，你需要檢視相同長度的時間，無論是 10 天還是 10 小時。

一美元不是一美元

同樣地，特定資源型別在特定時間段內的費率可能會與其他時間段內的相同資源型別的費率不同。與你擁有或租賃的硬體不同，雲端費率可能會根據雲端提供商是否提供了折扣而大幅變動。

此外，SP 或 RI 的預付款攤銷可能會進一步改變這個等式。你需要決定是否將這些因素納入你的使用者所看到的費率中。我們建議納入這些因素，因為這樣顯示的金額將更好地代表你稍後進行費用分攤的金額。

程式碼範例：計算攤銷後的費率

# 假設我們有一個 RI 的預付款和攤銷期
upfront_cost = 1000
amortization_period = 12  # 月

# 計算每月的攤銷成本
monthly_amortized_cost = upfront_cost / amortization_period
print(f"每月攤銷成本：{monthly_amortized_cost}")

內容解密：

1. 設定 RI 的預付款和攤銷期。
2. 計算每月的攤銷成本，將預付款均攤到攤銷期內。
3. 輸出每月的攤銷成本，用於後續的費用計算。

調整雲端支出的兩個槓桿

雲端支出的簡單公式給出了影響雲端支出的兩個基本槓桿：使用量和費率。

支出 = 使用量 × 費率

這將成為決定如何最佳化和誰來執行最佳化行動的關鍵部分。首先讓我們看看如何最佳化，然後再討論誰來執行最佳化。

第一個槓桿是減少使用量，這被稱為成本避免。你可以透過終止閒置資源、調整過大資源的大小、在非峰值時段減少執行的資源數量，或者在夜間和週末完全關閉資源來實作。

第二個槓桿是為所使用的資源支付更少的費用，這被稱為費率降低。你可以透過利用雲端計費結構（如 Savings Plans、Reserved Instances 和 Committed Use Discounts）來實作。此外，還有根據使用量的批次折扣（如 GCP 的持續使用折扣）或一些雲端提供商為大規模使用者提供的自定義定價計劃。

誰應該避免成本，誰應該降低費率？

在最佳化任務中，誰負責每個過程一直存在爭議。根據我們與數百家公司的合作經驗，我們有一個堅定的觀點：

最成功的 FinOps 實踐將使用量的減少（即避免成本）去中心化，將費率的降低（即減少費率）集中化。

去中心化的決策者，即應用程式的所有者，他們直接做出基礎設施選擇，因此最有資格決定是否關閉、調整大小或改變需求形狀。由於他們對工作負載需求非常熟悉，他們可以檢視利用率資料並決定是否終止看似閒置的例項。

另一方面，這些應用程式的所有者通常不具備購買 RI 或 CUD 的最佳位置。他們有時會誤解這些金融工具的工作原理，或者不瞭解公司資本成本等重要相關概念。集中的 FinOps 團隊可以檢視整個雲端資產以尋找節省機會。他們可能具備採購或財務分析技能，能夠理解現金流分析的細微差別，並同時瞭解技術需求和財務約束。

雲端成本管理的核心原則：集中與分散的平衡

雲端成本管理是企業在雲端運算環境中必須面對的重要課題。有效的成本管理需要結合集中控制和分散決策的策略，以達到最佳的成本效益。

集中化費率降低策略

集中化費率降低是雲端成本管理的關鍵原則之一。透過集中化的團隊來管理費率降低，可以更有效地利用雲端服務供應商提供的各種折扣方案，例如承諾使用折扣（Commitment-Based Discounts）。這種方法可以避免個別團隊各自為政，導致整體折扣覆寫率降低和未使用的承諾容量增加。

集中化管理的好處包括：

1. 提高折扣覆寫率：透過集中管理不同團隊的資源使用情況，可以更準確地評估整體的資源需求，從而提高折扣覆寫率。
2. 降低未使用容量：集中化管理可以避免個別團隊重複購買相同的資源承諾，從而減少未使用的容量。
3. 最佳化成本結構：集中化的團隊可以根據整體的資源使用情況，最佳化成本結構，降低整體成本。

舉例來說，假設有兩個團隊，分別在白天和夜間有高峰的資源使用量。如果這兩個團隊各自購買資源承諾，可能會導致其中一個團隊的承諾未被充分利用。但是，如果由集中化的團隊來管理，就可以根據整體的資源使用情況，購買適當的資源承諾，從而降低整體成本。

程式碼範例：計算資源承諾的成本效益

def calculate_commitment_savings(day_usage, night_usage, commitment_rate):
    # 計算總資源使用量
    total_usage = day_usage + night_usage
    
    # 計算資源承諾的成本效益
    savings = total_usage * commitment_rate
    
    return savings

# 範例用法
day_usage = 1000  # 白天的資源使用量
night_usage = 800  # 夜間的資源使用量
commitment_rate = 0.2  # 資源承諾的折扣率

savings = calculate_commitment_savings(day_usage, night_usage, commitment_rate)
print(f"資源承諾的成本效益：{savings}")

內容解密：

1. calculate_commitment_savings 函式用於計算資源承諾的成本效益。
2. day_usage 和 night_usage 分別代表白天和夜間的資源使用量。
3. commitment_rate 代表資源承諾的折扣率。
4. 函式計算總資源使用量，並根據折扣率計算成本效益。

分散化的使用量降低策略

與集中化費率降低策略相反，使用量降低策略則需要分散到各個團隊。雲端成本管理的另一個原則是「每個人都負責自己的雲端使用」。透過教育和培訓工程團隊，使他們瞭解如何有效地使用雲端資源，可以降低整體的使用量。

分散化的好處包括：

1. 提高工程團隊的主動性：透過教育和培訓，工程團隊可以主動地最佳化雲端資源的使用，降低成本。
2. 更好地理解業務需求：分散化的團隊可以更好地理解業務需求，從而做出更合理的資源使用決策。
3. 提高成本意識：透過將成本資料和建議提供給工程團隊，可以提高他們的成本意識，從而做出更有效的成本管理決策。

雲端成本管理的流程

@startuml
skinparam backgroundColor #FEFEFE
skinparam componentStyle rectangle

title 雲端成本最佳化 FinOps 實踐

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的實踐

FinOps是一場無限遊戲。正如賽門·西奈克（Simon Sinek）在《無限賽局》（The Infinite Game）中所說，無限遊戲沒有明確的終點，參與者可以來來去去，規則也可以改變。在這樣的遊戲中，沒有贏家或輸家，只有領先者和落後者。

獲得組織支援的挑戰

在實踐FinOps的過程中，我們經常聽到從業者提出兩個問題：如何讓高層管理者支援FinOps實踐？以及如何讓整個組織在不同角色中廣泛採納這一實踐？本章將探討獲得技術和財務長官層支援的常見方法。

FinOps採用路線圖

圖6-1概述了在組織內建立FinOps實踐和文化時需要通知的關鍵角色和里程碑。

圖6-1：FinOps採用路線圖（原創來源：Mike Eisenstein和Dean Oliver，Accenture, LLP）

來自業界的反思

在撰寫本文第二版時，Mike Fuller向我坦白說，當他們撰寫第一版時，Atlassian對FinOps的態度並不認真。當時，FinOps只是他工作職責的一部分，他花了多年時間思考和管理Atlassian的雲支出，但這並不是他的全職工作。

實際上，在公司內部，沒有人將FinOps作為全職工作。公司也沒有從上到下的C級目標來推動FinOps的成果。目標設定不一致，公司更關注的是完成遷移和快速交付產品，而不是積極地進行最佳化和流程改進。

內容解密：

這段內容反映了許多公司在早期階段對FinOps的態度。他們可能已經開始實踐FinOps，但尚未將其視為一項重要的、全公司範圍內的優先事項。

FinOps成熟度的不同層次

我們意識到，公司的FinOps實踐成熟度通常有幾個不同的層次。在向長官層推銷FinOps之前，瞭解公司目前所處的層次至關重要。通常，這與公司的雲採用旅程和優先考慮的成果相關。

向不同層次的長官層推銷FinOps

根據公司的成熟度不同，向長官層推銷FinOps的方法也會有所不同。在早期階段，公司可能正在進行一些與FinOps相關的活動，如審查支出或偶爾進行最佳化，但尚未形成完整的生命週期或採用相關框架。

圖表翻譯：

圖6-1展示了不同成熟度階段下需要關注的關鍵角色和里程碑。公司應根據自身所處階段，選擇合適的方法來推行FinOps實踐。

不同執行層級的不同推銷策略

為了確保成功，讓我們再次參考第1章中討論的FinOps成熟度模型。在早期階段，你需要根據想要實作的成果，提出相應的推銷方案。首先，你必須評估組織目前所處的位置。

在成熟度較低的階段，公司可能正在進行一些與FinOps相關的活動，但尚未形成完整的生命週期或採用相關框架。根據不同的成熟度階段，需要採取不同的推銷策略。

內容解密：

這段內容強調了根據公司的FinOps成熟度階段，採取合適的推銷策略的重要性。不同階段需要不同的關注點和目標。

匯入FinOps的策略與演進

匯入FinOps的初始階段，需要準備充分的說服理由來說服各級主管。根據Warren Buffett的名言：「睿智的人在開始時做的事，愚蠢的人在最後才做。」這句話提醒我們，在初期階段就應當做好FinOps的匯入規劃。

初始匯入的關鍵問題

在進行初始匯入的提案時，需要回答以下關鍵問題：

1. 為什麼要匯入FinOps？
   參考本文的前幾章，瞭解匯入FinOps的原因和動機。

2. 對各級主管的益處
   不同層級的主管（如CEO、CFO、CTO等）有不同的關注點和績效指標。清楚闡述FinOps對他們各自的益處，有助於獲得支援。

3. 對企業雲端採用的益處
   說明FinOps框架如何幫助企業在雲端採用過程中達成預期的成果，例如成本分配、最佳化等。

4. 如何幫助其他重要專案
   FinOps不僅能最佳化成本，還能協助其他專案，如安全、GreenOps和永續發展等。闡述FinOps如何與這些領域產生協同效應。

5. 現有財務框架的侷限性
   現有的IT財務框架可能無法滿足雲端環境下的需求。需要解釋為什麼需要FinOps，以及它如何與其他框架互補。

進階提案的重點

當FinOps實踐逐漸成熟後，需要進一步投資以提升其能力。這時，提案的重點應放在：

1. 衡量現有能力的成熟度
   評估組織在各項FinOps能力上的成熟度，明確指出需要改進的領域。

2. 具體預期成果
   根據Table 6-1中的能力領域，提出具體的改進目標和預期成果，例如：

   • 成本分配：提高成本正確分配至各團隊的比例。
   • 預測：增加預測的可靠性和可預測性。
   • 單位成本衡量：幫助團隊開始衡量特定產品的業務價值指標，並將其與報告結合。

3. 所需的資源投入
   說明需要哪些資源來達成上述目標，例如其他團隊的時間投入、額外的資金或人員組態。

不同主管的不同訴求

不同層級的主管會有不同的關注點，因此需要準備不同的提案內容。例如：

• CEO可能關注整體的雲端成本和業務效益。
• CFO可能關注成本控制和預算管理。
• CTO可能關注技術效率和創新能力。

案例分析

以Mike的案例為例，初始提案是為了改善成本削減，而在進階階段，則轉變為提升工程效率。他提出的問題是：「如何讓工程師避免陷入困境並提高釋出速度？」透過提升工程成本效率，可以讓技術長官者節省資金並支援更多的創新專案。

向不同層級的行政主管進行有效的FinOps提案

在組織中實施FinOps時，需要根據不同的物件進行量身定做的提案。不同的行政主管，如技術長（CTO）、財務長（CFO）等，都有不同的關注點和目標。

不同角色的關注點

雖然各方都對成本文約感興趣，但他們的核心動機各不相同。如今，很少有公司是從零開始實施FinOps，大多數公司已經有一定的FinOps活動。因此，需要描繪出當前狀況、未來方向以及長期旅程的益處。

FinOps團隊擴充套件計劃示例

下表是向技術行政主管提出的FinOps擴充套件計劃的一部分，包括額外的人員組態，如資料工程師、分析師、成本工程師、自動化工程師和團隊負責人。

有效的FinOps提案應該包括預期的成果，例如組織需要多少承諾才能降低費率，需要多少新的人員組態，以及需要哪些團隊的承諾來建立業務價值模型。

向行政主管提案

截至2022年，大多數FinOps團隊都隸屬於技術行政主管，如CIO或CTO。越來越多的團隊隸屬於CFO或相關的混合角色。提案的第一步是向CTO（或其他相關的CxO）描繪出當前狀況，包括現有的報告可視性以及公司在FinOps框架關鍵能力方面的成熟度評估。

需要回答的問題

• 工程師的日常工作如何改變？
• 組織需要引入哪些計劃和儀式？
• 工程經理如何開始思考FinOps？
• 組織如何確保擁有正確的資源？
• 在可視性優勢方面，組織可以推動哪些單位經濟和報告？

還可以透過回答一些具體場景的問題來進一步完善提案，例如：

• 組織應該如何規劃成本避免：透過減少使用量還是降低費率？
• 如果有更多時間和人員維護SPs或CUDs，組織可以獲得多少？
• 如果能夠更有效地管理承諾和資源利用率，去年可以節省多少？

向不同的行政主管進行提案

在向不同的行政主管提案時，需要根據他們的目標、擔憂、關鍵資訊和有用的KPI進行量身定做的簡報。透過瞭解每個行政主管的動機，FinOps倡導者可以更有效地描述FinOps的價值，減少獲得認同所需的時間和努力。

不同行政主管的目標和關注點

• 技術長（CTO）：關注工程收益，如提高效率和降低成本。
• 財務長（CFO）：關注更好的成本報告、更準確的預測和降低預算差異。

重點整理

在向行政主管提案時，需要根據不同的物件進行量身定做的簡報，強調FinOps對組織的價值。透過瞭解每個行政主管的動機，可以更有效地描述FinOps的價值，減少獲得認同所需的時間和努力。

圖表翻譯：

此圖示展示了不同行政主管在FinOps中的關注點與目標，包括業務長官者、工程團隊和財務團隊的不同需求。