FinOps 與 GreenOps 雲端成本與可持續性協同增效

– 14 分鐘閱讀

雲端可持續性日益受到重視，它與 FinOps 的成本最佳化原則密切相關。將可持續性視為非功能性需求，如同安全性、效能等要素，對於整體 IT 戰略至關重要。雲端可持續性的責任分屬供應商和消費者，供應商負責自身營運的可持續性，而消費者則需有效利用雲端資源。FinOps 與 GreenOps 並非獨立運作，而是需要分享知識和最佳實務，共同達成成本效益和環境友善的目標。例如，評估不同區域的碳強度，選擇更環保的區域佈署服務，並持續最佳化資源使用效率，減少不必要的浪費。

許多 FinOps 最佳實務，例如調整過大運算例項、移除閒置資源、升級老舊例項等，同樣適用於 GreenOps。然而，並非所有 FinOps 方法都與 GreenOps 目標一致，例如費率最佳化可能導致保留未充分利用的資源，反而增加碳排放。因此，在制定決策時，需要權衡成本和可持續性，並在團隊間達成共識。選擇雲端服務區域時，成本和可持續性也可能存在衝突，需要仔細比較不同地區的綠色能源使用率和價格，才能做出最佳決策。隨著 FinOps 實踐的成熟，團隊需要建立明確的流程和自動化機制，例如自動化資源管理、權益管理和預算警示，以確保持續最佳化成本和碳排放。

雲端可持續性：FinOps 與 GreenOps 的協同作用

雲端運算的可持續性是實作整體可持續性雲端戰略的關鍵組成部分，並且與 FinOps 的原則直接相關。簡而言之，它反映了將可持續性轉化為非功能性需求（NFR），並將其嵌入整個 IT 組織的重要性，使其成為與無障礙性、安全性、效能、成本和可用性並列的關鍵考慮因素。

可持續性分享責任模型

在雲端運算中，可持續性的責任被劃分為供應商（例如微軟、谷歌或亞馬遜）和消費者（即您）。供應商負責其自身營運的可持續性，而消費者的責任則在於如何使用雲端資源以實作可持續性目標。

雲端可持續性分享責任模型

圖表翻譯： 此圖示呈現了供應商與消費者在雲端可持續性方面的責任劃分，以及資源使用效率、成本最佳化和碳足跡最小化之間的關係。

FinOps 與 GreenOps 的協同作用

許多情況下，可持續性需要在現有的 FinOps 實踐中增加一個新的衡量指標。目標是將環境影響納入組織的決策過程中，就像引入成本考量一樣。這並不是說 FinOps 從業者將成為新的 GreenOps 從業者，而是兩者需要分享知識和實踐經驗。

程式碼範例：評估不同區域的碳強度

import requests

def get_carbon_intensity(region):
    url = f"https://api.electricitymap.org/v3/carbon-intensity/{region}"
    response = requests.get(url)
    return response.json()

# 使用範例
region = "tw"
carbon_intensity = get_carbon_intensity(region)
print(f"Region {region} carbon intensity: {carbon_intensity}")

內容解密：

  1. 此程式碼使用 requests 函式庫向 Electricity Maps API 傳送 GET 請求，以取得指定區域的碳強度資料。
  2. get_carbon_intensity 函式接受一個 region 引數，並傳回該區域的碳強度資料。
  3. 在使用範例中，我們查詢了台灣區域（“tw”）的碳強度，並列印出結果。

GreenOps 的補救措施

從 FinOps 的角度來看，有一些常見的領域可以開始著手實作成本文約，同樣適用於 GreenOps。以下是一些初始步驟：

  • 過大的運算例項
  • 遺棄的例項仍在執行
  • 服務執行在老舊、低效的例項上
  • 錯誤組態的微服務
  • 未終止的運算例項或開發環境仍在執行
  • 過度保留的儲存快照
  • 資料儲存在錯誤的儲存層級
  • 服務執行在錯誤的區域/可用區域

這些只是初始步驟，實際上還有許多其他領域可以改進。與工程團隊合作最佳化程式碼可以帶來顯著的好處，但需要大量的思考、規劃和工程時間。自動化可以幫助管理這些浪費領域，不僅對 FinOps 有益，也對 GreenOps 有所幫助。

避免FinOps與GreenOps目標衝突

並非所有的FinOps功能都與GreenOps的目標保持一致，有些甚至會與GreenOps的目標背道而馳。以費率最佳化為例，承諾使用雲端資源以節省成本的做法並不能幫助減少碳排放。成本和可持續性可能會朝著不同的方向發展。承諾降低未充分利用資源的費率將提高雲端成本效率，但也可能限制您減少雲端使用量，進而減少碳排放。您可能節省了資金，但對未使用資源的費率最佳化可能會鼓勵您保留這些資源，而不是將其關閉。這可能會阻止您減少實際上不需要的雲端資源所產生的碳排放。

不同地區的雲端服務成本與可持續性比較

在比較營運雲端服務的地區時，成本並不總是與可持續性相符。表19-1顯示了在不同Google Cloud地區執行單個e2-highcpu-32計算資源的比較。資料來源於Google Cloud定價頁面和Google Cloud碳能耗頁面。單純根據價格比較地區，愛荷華州、南卡羅來納州、哥倫布市和奧勒岡州均為每月578美元。當您同時考慮可持續性時，愛荷華州和奧勒岡州成為更優選擇，而南卡羅來納州的綠色能源使用率最低。此表還突出了使用全國平均值的問題：綠色能源的平均使用率為54%，但九個地區中有五個實際上使用了不到54%的綠色能源。

表19-1：Google Cloud中單個e2-highcpu-32例項的價格與綠色能源使用比較

地區位置綠色能源百分比每月價格
us-central1愛荷華州97%$578
us-east1南卡羅來納州25%$578
us-east4北維吉尼亞州64%$651
us-east5哥倫布市64%$578
us-south1達拉斯40%$682
us-west1奧勒岡州88%$578
us-west2洛杉磯53%$694
us-west3鹽湖城31%$694
us-west4拉斯維加斯21%$651
平均值-54%$631

從全球角度來看，這種比較變得更加明顯。在撰寫本文時，挪威的電力碳強度為每千瓦時31克CO2e，而美國北維吉尼亞州則為620克，相差2000%。

FinOps決策對GreenOps的影響

純粹根據財務影響選擇營運服務的地區可能會對您的GreenOps可持續性目標產生負面影響。在進行可持續性權衡時，旨在達成成本與可持續性之間的平衡協定。使相關團隊達成一致，將有助於他們與工程團隊合作，避免衝突。

第20章：營運：使團隊與業務目標保持一致

沒有行動流程，目標永遠無法實作。當您進入FinOps的營運階段時，您將致力於支援和加強前兩個階段所確定的要素。

實作目標

最佳化階段設定目標，而營運階段則採取行動。這裡不會設定新的目標——這是您根據商業案例和背景，對已經設定的目標做出決策並付諸實施的地方。

讓我們以關閉非工作時間內不需要的資源為例，並應用正確的操作順序。在資訊階段，您識別出可以從關閉中受益的資源。在最佳化階段，您衡量潛在節省並根據這些指標設定節省目標。在營運階段，您定義開啟和關閉資源的流程，並啟用自動化以提高資源採用新流程的可能性。這是您透過定義可在整個組織內實施的流程來引入可擴充套件性和複製性的階段。

營運階段並不總是導致行動。如果您認為最佳化階段是您識別最佳化機會並為行動建立小型商業案例的地方，那麼營運階段就是您決定是否採取行動的地方。

程式碼範例：自動化資源管理

import schedule
import time

def turn_off_resources():
    # 在此處加入關閉資源的程式碼
    print("Resources turned off")

def turn_on_resources():
    # 在此處加入開啟資源的程式碼
    print("Resources turned on")

# 設定每天下班後關閉資源
schedule.every().day.at("18:00").do(turn_off_resources)
# 設定每天上班前開啟資源
schedule.every().day.at("08:00").do(turn_on_resources)

while True:
    schedule.run_pending()
    time.sleep(1)

內容解密：

此程式碼範例展示瞭如何使用Python的schedule函式庫來自動化資源的管理。透過定義turn_off_resources和turn_on_resources函式，並使用schedule.every().day.at()方法來排程這些函式在特定時間執行，從而實作每天定時開啟和關閉資源的功能。這樣的自動化流程有助於減少不必要的資源浪費，進而降低成本並提高可持續性。

營運：將團隊與業務目標相結合

大多數資訊都是無關緊要的。知道該忽略什麼可以節省時間、減少壓力，並改善你的決策。 — Shane Parrish, Farnam Street

在生命週期的每次迭代中，另一個目標會逐漸清晰，並在此基礎上建立新的流程和自動化。在建立流程的過程中，你可能會發現更多想要實作的目標。當發生這種情況時，請回到資訊和最佳化階段，以正確衡量和設定新流程的目標。保持生命週期的每次迭代都小而快速，以便正確衡量你所做的每項改變。

強化你的 FinOps 團隊

隨著時間的推移，大多陣列織都會僱用經驗豐富的 FinOps 從業者來充實其內部團隊，如我們在第三章中所討論的那樣。然而，近年來，這個領域的新工作數量激增，超過了市場上經驗豐富的人才儲備。IDC 在 2022 年估計，60% 的企業已經擁有或正在建立 FinOps 團隊。人才競爭非常激烈。許多組織最初轉向 FinOps 顧問，以增強和啟動他們的團隊，同時尋求內部 FinOps 培訓和吸引外部人才。所有主要的全球諮詢公司和大型會計師事務所現在都擁有 FinOps 實踐，包括埃森哲、德勤、安永、畢馬威、普華永道等，以及系統整合商，如 HCL、SADA、SoftwareONE、Virtasant 等。

然而，每個公司的這些實踐的成熟度和規模差異很大，因此務必確認他們是否是 FinOps 認證服務提供商，並核實他們所僱用的 FinOps 認證專業人員的數量。

流程

在第一次完成生命週期迴圈時，大多陣列織都專注於瞭解他們目前的成本。這包括建立相關流程，以識別他們擁有的帳戶、瞭解帳單的組織方式，並實施某種形式的支出分析工具，無論是直接從雲端服務提供商那裡還是從第三方 FinOps 平台，以實作更高階別的功能，如完整的回扣或容器報告。

之後，你的組織最重要的目標應該驅動你所建立的流程。對成本敏感的組織將專注於成本效率作為最重要的目標，而專注於快速創新的組織則會選擇專注於促進速度。

自動化遵循流程

許多流程共同構成了成功的 FinOps 實踐。自動化遵循流程。在建立自動化之前，你需要為自動化建立流程。定義誰負責流程（或“擁有”流程）、組織的哪些部分必須遵循流程，以及流程對哪些目標有所貢獻。明確定義的營運模式概述了對員工的期望。

當你採用第三方自動化工具（在第 21 章中介紹）時，它們通常會規定流程必須如何運作。使用這些工具時，你可能需要調整你定義的流程以適應它們。

首先，弄清楚如何將專案新增到新流程（入職），團隊應該做什麼（責任），團隊如何被告知何時應該遵循流程以及遵循流程的結果（可見性/警示），最後開始遵循流程（行動）。

入職

情況會發生變化，尤其是在使用雲時。你的組織可能會增加現有的雲佈署或進行公司合併。所有流程都應明確定義雲成長所帶來的變化；否則，你最終會得到一個適用於現在但不適用於近期的流程。不要只考慮現在，還要考慮未來可能發生的事情，並開始思考哪些部分的流程需要演變，以便為未來的變化和成功做好準備。在行動需要採取之前，應獲得將要執行該流程的團隊的支援，並向他們說明隨著實踐的成熟，預期會有變化。向團隊傳達新流程旨在實作的目標和結果。

Mike 的雲故事

在 Atlassian，有特定的流程來入職新的雲帳戶。這些流程定義瞭如何將帳戶新增到現有的計費結構中，以及如何在新帳戶中新增 FinOps 工具。治理工具被新增到帳戶中，從而實作閒置資源管理和權益建議。帳戶中的任何現有 RI 都由 FinOps 團隊集中管理。這種治理建立了帳戶管理的標準方法，無需個別團隊管理其 RI，並隨著時間的推移實作更多的節省。隨著 FinOps 實踐的成熟，被治理的專案將不斷演變，例如當我們從使用 Trusted Advisor 的計算最佳化轉向使用 Compute Optimizer 的建議時。這使我們能夠涵蓋除基本計算之外的更多雲端服務。負責治理的核心團隊不斷致力於提供更好的工具，以應對下一個數量級的規模。

責任

每個流程都應分配給一個負責人。有效的流程清楚地定義了誰在什麼時候做什麼，以及如何做它。團隊是每天、每週、每月還是在其他頻率遵循流程？請記住，有些流程將由 FinOps 從業者遵循（如購買承諾），而其他流程則是分散的（如權益和用量最佳化）。

分配給團隊的責任將隨著流程的成熟而增長。定期溝通期望的增加將減少團隊聲稱不知道自己應該做什麼以及何時的可能性。

透過 FinOps 生命週期的每次迭代，你都在這些流程上進行構建。在成本可見性旅程開始時，例如，當團隊收到成本報告時，他們唯一的期望可能是閱讀它。以後，團隊可能會被要求調查和解釋超過一定門檻的任何成本。再往後，團隊可能會被要求在預測顯示目標無法實作時修改預算和預測。同樣，你正在逐步成熟 FinOps。如果沒有首先建立完善的成本分配策略和正確預測的預算，就不可能讓團隊在第一次完成 FinOps 生命週期時調查成本。

在攝影棚和劇院燈光設計中，有一句格言提醒燈光技術人員一次只移動一盞燈——這樣，他們可以在進行其他調整之前看到每項改變的影響。這裡也是如此：如果你同時更改與你的權益或標記相關的流程，以及與你的預留例項或節省計劃管理相關的流程，你可能無法輕易確定哪項改變推動了你帳單中的變化。

可見性

在採取行動之前和之後，你都必須建立可見性。在營運階段，啟用可見性的流程確保每個人都意識到需要進行哪些更改以及正在進行哪些更改。最常見的營運流程包括成本分配、預算和預測。它們提供了對支出和使用情況的可見性，使團隊能夠做出明智的決定並採取行動以最佳化成本。

FinOps 生命週期

圖表翻譯： 此圖示展示了FinOps生命週期的迴圈過程，以及流程與自動化之間的相互關係。首先，透過資訊（Inform）階段收集資料，接著進入最佳化（Optimize）階段進行成本最佳化，然後進入營運（Operate）階段實施和管理，最後再回到資訊階段，形成迴圈。另外，圖中也呈現了流程（Processes）與自動化（Automation）之間的相互促進關係，說明瞭兩者在FinOps實踐中的重要性。

程式碼範例：自動化權益管理

def automate_rightsizing(instance_type, current_utilization):
    # 檢查目前的使用率是否低於閾值
    if current_utilization < 0.3:
        # 如果是，則建議降級到更小的例項型別
        recommended_instance_type = get_smaller_instance_type(instance_type)
        return recommended_instance_type
    else:
        # 如果不是，則保持現有的例項型別
        return instance_type

def get_smaller_instance_type(instance_type):
    # 邏輯：根據目前的例項型別傳回更小的例項型別
    instance_types = {
        'large': 'medium',
        'medium': 'small',
        'small': 'xsmall'
    }
    return instance_types.get(instance_type, instance_type)

# 使用範例
current_instance_type = 'large'
current_utilization = 0.2
recommended_instance = automate_rightsizing(current_instance_type, current_utilization)
print(f"Recommended instance type: {recommended_instance}")

內容解密：

  1. automate_rightsizing函式：此函式根據目前的使用率來決定是否需要調整例項型別。如果使用率低於0.3，則建議降級到更小的例項型別。
  2. get_smaller_instance_type函式：此函式根據目前的例項型別傳回更小的例項型別。它使用一個字典來對映例項型別的大小。
  3. 邏輯說明：程式碼首先檢查目前的使用率。如果使用率太低，它會呼叫get_smaller_instance_type來取得更小的例項型別。這樣的自動化有助於節省成本並最佳化資源利用率。
  4. 使用範例：程式碼展示瞭如何使用automate_rightsizing函式來取得建議的例項型別。這對於自動化權益管理非常有用，可以根據實際的使用情況動態調整資源。

流程與團隊協作在FinOps中的重要性

在FinOps的實踐中，流程的建立和團隊之間的協作對於實作業務目標至關重要。透過明確的流程和責任劃分，可以提高團隊之間的信任度，並促進有效的合作。

提高可見度與溝通效率

為了讓團隊及時瞭解事件的發展，應該自動生成報告或警示，並使用FinOps共同語言來確保報告清晰易懂。同時，提供培訓和檔案，確保所有員工都熟悉這種語言。

預測和異常檢測應該根據當前指標進行，以便在問題出現之前採取行動。例如，AWS Budgets允許根據預測的月末支出組態警示。

隨著時間的推移，流程和溝通通路將變得越來越重要。FinOps團隊可以將開發團隊、財務團隊和業務團隊聚集在一起，瞭解什麼資訊可以幫助他們更有效地規劃和做出決策。

內容解密：

  1. 自動生成報告或警示的目的是提高可見度，讓團隊及時瞭解事件的發展。
  2. 使用FinOps共同語言可以確保報告清晰易懂，避免混淆。
  3. 預測和異常檢測可以幫助團隊在問題出現之前採取行動，避免損失。

流程的建立與執行

行動階段是FinOps實踐中最關鍵的一環。在這個階段，組織需要建立明確的流程來實作其FinOps目標。這些流程可以從生成新的報告到開啟或關閉實際的雲資源。

程式碼範例：

import boto3

# 建立AWS Budgets客戶端
budgets = boto3.client('budgets')

# 定義預算閾值
threshold = 0.8

# 取得當前預算
response = budgets.describe_budgets(
    AccountId='123456789012'
)

# 檢查預算是否超過閾值
for budget in response['Budgets']:
    if budget['CalculatedSpend']['ActualSpend']['Amount'] > threshold * budget['BudgetLimit']['Amount']:
        # 傳送警示
        print(f"預算 {budget['BudgetName']} 已超過 {threshold*100}% 的閾值！")

內容解密：

  1. 程式碼使用AWS SDK for Python（Boto3）來與AWS Budgets服務互動。
  2. 定義了一個預算閾值（threshold），用於檢查當前預算是否超過該閾值。
  3. 程式碼取得當前預算，並檢查是否超過閾值。如果超過，則傳送警示。

責任劃分與文化建設

流程的建立不僅可以提高效率，還可以促進團隊之間的文化建設。透過明確責任劃分，可以讓團隊瞭解自己的貢獻對於組織目標的重要性。

@startuml
skinparam backgroundColor #FEFEFE
skinparam componentStyle rectangle

title FinOps 與 GreenOps 雲端成本與可持續性協同增效

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團隊與開發團隊、財務團隊和業務團隊進行溝通，共同為組織目標做出貢獻。

玄貓 BlackCat

玄貓 BlackCat

技術愛好者，專注於分享程式開發、雲端技術與 AI 應用的心得體會。