返回文章列表

FinOps實踐 最佳化雲端成本與團隊協作

本文探討 FinOps 的實踐,涵蓋目標設定、流程建立、資源最佳化、團隊協作及自動化成本管理等關鍵導向。文章提供實務經驗與程式碼範例,闡述如何有效降低雲端成本,並提升團隊在成本管理上的效率。同時也探討了自動化工具的選擇、整合與衝突管理,以及安全性考量,提供企業在實踐 FinOps 時的全面性。

雲端運算 成本管理

FinOps 的核心在於透過有效的資源管理和團隊協作,將雲端成本最佳化。設定明確的目標並建立相關流程是實踐 FinOps 的第一步,同時也需要考量如何激勵團隊參與並有效處理團隊不作為的情況。此外,移除閒置資源是最佳化資源使用的常見策略,需要建立明確的流程和追蹤機制。自動化在 FinOps 中扮演重要角色,能有效降低人力成本並提升效率。選擇合適的自動化工具,無論是自建或購買第三方工具,都需考量成本效益、安全性、功能相容性和合規要求。整合不同自動化工具並有效管理潛在衝突,才能發揮自動化的最大效益。

實踐 FinOps:最佳化資源使用與團隊協作

目標設定與流程建立

在 FinOps 的實踐中,設定明確的目標是至關重要的。這些目標通常在最佳化階段被定義,而在營運階段則需要建立相關的流程來實作它們。企業需要清晰地定義誰應該做什麼以及什麼時候完成這些任務。

使用最佳化與團隊協作

在資源使用最佳化方面,一個常見的問題是團隊是否願意實施變革。能夠展示團隊可以實作的整體節省額度,以及其他團隊已經達到的節省效果,將有助於說服團隊參與這個過程。

激勵與協作

使用積極的激勵措施來與工程團隊建立合作,避免形成對立的局面。然而,這種激勵措施並不總是足夠的,某些情況下需要與不遵循 FinOps 指導原則的團隊合作。

重點關注關鍵議題

在評估團隊表現時,不應僅僅根據總支出金額進行排名,因為不同團隊的預算和責任本就不同。更重要的是瞭解哪些團隊超出了預算,而哪些團隊則達到了預期目標。這種關注點有助於聚焦於真正重要的議題。

處理團隊不作為

當團隊不優先處理目標達成時,管理階層的支援至關重要。管理階層需要明確表示達成目標對於整個組織的成功非常重要。當團隊想要犧牲支出以換取速度時,需要獲得管理階層的批准,並將這種例外情況納入預算中。

理解團隊優先事項

大多數員工都不希望看到組織浪費資金。因此,當團隊不遵循 FinOps 團隊的建議時,通常是因為他們有其他優先事項。瞭解這些優先事項可以避免意見衝突。

將營運落實到行動

讓我們來看一個透過移除閒置資源來最佳化使用的例子。FinOps 團隊定義了一個檢測閒置資源並估計潛在節省的流程。在 FinOps 生命週期的最佳化階段,FinOps 從業者會測量閒置資源的數量。

假設有 15 萬美元的潛在成本避免額度,並設定了 5 萬美元的目標。我們定義了一個流程,明確了對工程團隊的期望、他們應該多快回應建議,以及如何將資源排除在流程之外。我們為這些閒置資源生成報告並釋出給負責的團隊。

跟蹤進度與提供支援

隨著團隊移除閒置資源,潛在的成本避免額度從最初的 15 萬美元減少。工程團隊也會看到分配給他們的建議數量減少。這兩種結果都有助於展示團隊努力的影響。

對於那些不遵循流程的團隊,他們的建議和潛在節省不會改變,或者更糟糕的是會增加。管理階層應該重申遵循流程以移除閒置資源的重要性,並對未遵循流程的團隊施加壓力。FinOps 團隊應該與未達到目標的團隊合作,確定如何幫助他們。

程式碼範例:檢測閒置資源

import boto3

def detect_idle_resources():
    # 初始化 AWS 資源
    ec2 = boto3.client('ec2')
    cloudwatch = boto3.client('cloudwatch')

    # 取得所有 EC2 例項
    instances = ec2.describe_instances()

    # 篩選閒置資源
    idle_instances = []
    for instance in instances['Reservations'][0]['Instances']:
        instance_id = instance['InstanceId']
        # 檢查 CPU 使用率
        cpu_usage = cloudwatch.get_metric_statistics(
            Namespace='AWS/EC2',
            MetricName='CPUUtilization',
            Dimensions=[{'Name': 'InstanceId', 'Value': instance_id}],
            StartTime='2023-01-01T00:00:00Z',
            EndTime='2023-01-01T23:59:59Z',
            Period=300,
            Statistics=['Average'],
            Unit='Percent'
        )
        if cpu_usage['Datapoints'][0]['Average'] < 5:  # 假設閒置閾值為 5%
            idle_instances.append(instance_id)

    return idle_instances

#### 內容解密:
此程式碼範例展示瞭如何使用 AWS SDK for PythonBoto3檢測閒置的 EC2 例項
1. 首先我們初始化了 EC2 和 CloudWatch 的客戶端
2. 然後我們取得了所有的 EC2 例項並遍歷它們以檢查 CPU 使用率
3. 對於每個例項我們使用 CloudWatch 取得其 CPU 利用率的平均值
4. 如果平均 CPU 使用率低於設定的閾值例如 5%),則將該例項標記為閒置
5. 最後傳回所有被標記為閒置的例項 ID

## 自動化成本管理
當需要頻繁執行重複性任務時自動化能夠減少人力投入並保持一致性在FinOps領域有許多機會可以實作自動化本章將探討一些常見的FinOps自動化任務以及自動化的好處和挑戰

### 自動化的定義
FinOps自動化涵蓋多個方面包括帳單處理基礎設施管理帳單資料處理異常警示報告生成預留例項或節省計劃管理標籤/帳戶/訂閱/專案建立和維護使用最佳化與適當調整資源規模根據需求進行預測性自動擴充套件選擇佈署時的例項大小在Spot和On-Demand之間遷移工作負載或將雲端支出資料交付給外部系統等

### 是否應該自動化?
決定是否自動化取決於組織的雲端和FinOps成熟度技術能力以及對將重複性流程從人工轉移到電腦的舒適度要回答這個問題需要考慮兩個方面首先確定希望透過自動化實作的結果其次將自動化與組織內的手動流程進行比較判斷自動化是否是實作預期結果的更好方法

### 自動化的目標
重要的是要確定實際的業務成果而不僅僅是自動化如何實作該成果例如閒置資源治理的目標不是簡單地刪除閒置資源而是消除這些資源所帶來的成本同樣標籤治理旨在推動對標籤標準的遵循透過刪除或警示不符合標準的資源來實作這一目標

#### 閒置資源治理
閒置資源治理的目標是降低成本透過自動化可以避免閒置資源的成本從而減少雲端帳單的衝擊這也有助於組織養成良好的習慣思考新雲端產品中可能出現的浪費

#### 標籤治理
標籤治理透過移除或警示不符合標準的資源推動對標籤標準的遵循衡量自動化的影響是透過跟蹤不符合標籤標準的資源數量

#### 排程資源
對於排程資源目標是透過減少非工作時間的資源使用來降低成本

### 自動化與手動任務的比較
表面上看自動化似乎是更好的選擇但實際上需要進行比較如果目標是節省資金那麼應該將自動化可能產生的節省與購買或建立自動化的成本進行比較同時考慮內部安全性和維護因素

使用第三方平台進行自動化時需要檢查持續成本如果計劃中的自動化無法在合理時間內為組織節省資金或者維護自動化的成本超過潛在節省那麼佈署該自動化就沒有明顯的商業利益

有時自動化的目標不是節省資金例如標籤治理旨在推動對標籤標準的採用最終提高顯示回報的準確性並推動團隊對雲端支出的責任感

在所有情況下都需要驗證自動化是否有助於實作目標例如如果對無效標籤資源的警示沒有與企業政策相結合那麼自動化可能會增加噪音而無法實作提高合規性的目標

### 自動化的好處
人類會犯錯而自動化可以糾正這些錯誤自動化還可以減少團隊的工作量例如透過自動化為資源新增補充標籤資料可以減少需要應用的標籤數量避免人為錯誤並確保額外標籤資料的一致性應用

#### 自動化的範例
```python
import boto3

def lambda_handler(event, context):
    # 初始化EC2客戶端
    ec2 = boto3.client('ec2')
    
    # 取得所有例項
    response = ec2.describe_instances()
    
    # 迭代例項並新增標籤
    for reservation in response['Reservations']:
        for instance in reservation['Instances']:
            instance_id = instance['InstanceId']
            # 新增額外標籤
            ec2.create_tags(
                Resources=[instance_id],
                Tags=[
                    {'Key': 'extra_tag', 'Value': 'extra_value'}
                ]
            )
    
    return {
        'statusCode': 200,
        'statusMessage': 'OK'
    }

內容解密:

此程式碼範例展示瞭如何使用AWS Lambda函式為EC2例項新增額外的標籤。首先,它初始化了一個EC2客戶端,然後取得了所有EC2例項的列表。接著,它遍歷這些例項,並為每個例項增加了一個額外的標籤。這個過程可以根據實際需求進行調整,例如從外部資料來源(如CMDB)取得額外標籤的資訊。

自動化成本管理的挑戰與工具選擇

在匯入自動化的過程中,初期可能會面臨比預期更複雜的管理或故障排除問題,甚至可能暫時退回手動流程。然而,隨著雲端使用規模的擴大、免費開源工具的普及,或是因為其他原因而實施相關工具時,你可能會發現自動化的成本效益分析變得更加有利。

自動化工具的選擇:購買 vs. 自建

在討論任何商業工具時,購買還是自建的爭論總是不可避免。對於 FinOps(財務營運)來說,我們建議從第三方工具開始,最初使用雲端供應商提供的原生工具,後續再根據支出規模和複雜度選擇 SaaS 供應商。成功的自主開發工具通常需要深入瞭解什麼對你的組織有效,而這通常來自於使用多種現有的商業解決方案。

為什麼從第三方工具開始?

  • 避免常見陷阱:使用成熟的第三方工具可以幫助你避免一些常見的錯誤。
  • 加速自動化交付:第三方工具可以加快自動化的實施。
  • 深入瞭解組織需求:透過使用商業解決方案,你可以更好地理解什麼對你的組織有效。

成本考量

在考慮成本與效益時,「你不知道你不知道的事」這句老話非常適用。許多有經驗的公司和承包商可以分享他們對 FinOps 自動化實踐和流程的見解,引導你的組織實作最大的效益。

自建 vs. 購買

  • 現實地評估自建能力:比較你能自建什麼和你能購買什麼非常重要。
  • 第三方工具的優勢:第三方工具通常已經準備好展示其價值,並且有一支團隊專注於維護和改進工具。

其他考慮因素

除了成本,還有其他因素需要考慮,例如:

  • 安全性影響:自建工具可能帶來額外的安全風險。
  • 功能相容性:第三方工具的功能可能與你的環境不相容,或無法與現有的系統整合。
  • 合規要求:某些行業有特定的合規要求,如 FedRAMP、HIPAA、SOC 2 或 PCI,第三方工具供應商可能不具備相關認證。

自動化工具佈署選項

在選擇自動化工具時,還需要考慮佈署選項:

雲端原生

  • 雲端服務提供商的指令碼:可以在雲端賬戶中執行的指令碼,由雲端服務提供商或更廣泛的社群提供。
  • Function-as-a-Service 平台:例如 AWS Lambda。

自建

  • 內部開發和維護:由內部團隊開發和執行的軟體。
  • 功能開發:由內部團隊負責。

詳細分析與決策

在決定是否自建自動化工具時,必須比較自建所有所需功能的努力(包括衡量工具有效性的方法、持續維護和更新)與購買解決方案的成本。同時,也應該仔細評估任何第三方供應商工具的缺失功能或合規要求。

圖表說明

@startuml
skinparam backgroundColor #FEFEFE
skinparam componentStyle rectangle

title FinOps實踐 最佳化雲端成本與團隊協作

package "安全架構" {
    package "網路安全" {
        component [防火牆] as firewall
        component [WAF] as waf
        component [DDoS 防護] as ddos
    }

    package "身份認證" {
        component [OAuth 2.0] as oauth
        component [JWT Token] as jwt
        component [MFA] as mfa
    }

    package "資料安全" {
        component [加密傳輸 TLS] as tls
        component [資料加密] as encrypt
        component [金鑰管理] as kms
    }

    package "監控審計" {
        component [日誌收集] as log
        component [威脅偵測] as threat
        component [合規審計] as audit
    }
}

firewall --> waf : 過濾流量
waf --> oauth : 驗證身份
oauth --> jwt : 簽發憑證
jwt --> tls : 加密傳輸
tls --> encrypt : 資料保護
log --> threat : 異常分析
threat --> audit : 報告生成

@enduml

圖表翻譯: 此圖示呈現了選擇自動化工具的決策過程。首先,需要決定是否使用自動化工具。如果選擇使用,則評估成本與效益,並考慮安全性與合規性。接下來,決定是選擇雲端原生還是自建方案。雲端原生方案涉及使用雲端服務提供商的指令碼,而自建方案則需要內部開發和維護。

自動化成本管理的挑戰與整合之道

在雲端運算環境中,自動化成本管理已成為企業節省成本、提升效率的關鍵。然而,隨著企業雲端規模的擴大,不同團隊可能會採用各自的自動化工具,導致重複建設和管理混亂。因此,如何選擇適合的自動化工具並確保其協同工作,成為企業面臨的重要課題。

自動化工具的選擇

企業在選擇自動化工具時,通常面臨「自建」或「購買」第三方工具的決策。自建工具能夠根據企業特定需求進行客製化,但需要投入大量資源進行開發和維護。購買第三方工具則能夠快速佈署,但可能需要依賴供應商的支援。

自建自動化工具

自建工具的最大優勢在於能夠完全符合企業的特定需求。然而,這種方式需要企業擁有足夠的技術能力和資源來開發和維護這些工具。此外,自建工具還需要考慮可擴充套件性和與其他系統的整合能力。

第三方自託管工具

第三方自託管工具提供了一種折衷方案。企業可以使用開源或商業軟體,在自己的環境中執行和管理這些工具。例如,Capital One 開發的 Cloud Custodian 是一個廣受推薦的開源工具。然而,企業需要考慮執行和自定義這些工具的成本。

第三方 SaaS 工具

第三方 SaaS(軟體即服務)工具提供了最簡單的佈署方式。供應商會提供易於使用的介面和預設的整合方案,企業只需支付月費即可使用這些工具。然而,這種模式也帶來了安全性問題,因為企業需要信任第三方供應商來管理其資料和系統。

混合模式:購買與自建的結合

在實際操作中,許多企業採用混合模式,即結合第三方工具和自建自動化程式。例如,HERE Technologies 的 Jason Fuller 使用供應商的 FinOps 平台進行報告和分析,但依賴自定義的內部自動化程式碼(根據開源工具 Cloud Custodian)來執行實際的變更。這種混合模式允許企業利用第三方工具的優勢,同時保持對關鍵基礎設施的控制。

自動化工具的整合與衝突

當企業佈署多個自動化工具時,需要確保這些工具之間能夠協同工作,而不是相互衝突。整合不同工具可以帶來更大的價值,例如將自動化工具與現有的票務系統整合,以實作自動化的工單生成。

避免重複建設

企業應該避免使用多個不同的工具來執行相同的任務。例如,如果已經有一個票務系統,就應該選擇能夠與該系統整合的 FinOps 工具,而不是建立一個獨立的任務追蹤系統。

事件處理與擴充套件

如果自動化工具不支援直接整合,企業可以利用事件處理機制來擴充套件其功能。例如,透過接收自動化工具生成的事件通知,並建立擴充套件程式將這些事件連線到其他軟體包。

自動化衝突的管理

當多個自動化工具同時執行時,可能會出現衝突。例如,一個工具試圖啟動伺服器,而另一個工具試圖關閉它。為瞭解決這個問題,企業需要對整個組織進行教育,讓各團隊瞭解現有的自動化措施,並協調規劃新的自動化任務。

理想情況下,自動化工具應該能夠檢測到與外部因素的衝突,並發出警示。例如,如果自動化工具在短時間內多次停止伺服器例項,它應該傳送警示並防止進一步的變更。

自動化成本管理的挑戰與實踐

在匯入自動化工具進行成本管理時,企業可能會面臨來自團隊成員或工具之間的衝突。瞭解這些挑戰並採取適當的措施至關重要。

與團隊成員的衝突

自動化工具可能會與團隊成員的需求相衝突。例如,當自動化工具停止某個伺服器例項,而團隊成員需要存取該伺服器時,就會產生衝突。這種情況可能導致團隊成員重新啟動例項,但隨後又被自動化工具停止。為避免這種情況,必須對團隊成員進行教育,讓他們瞭解如何將資源排除在自動化之外。

Joe Daly曾經擔任Cardinal Health和Nationwide的雲端最佳化總監,他分享了一個因手動刪除與生產環境相關的非生產資源而意外關閉生產環境的故事。這再次強調了對團隊成員進行自動化教育的重要性。

安全與保密

安全性是任何FinOps自動化工具的主要關注點。自動化工具通常需要對雲端環境具有很高的存取許可權,這可能導致拒絕服務攻擊、資料遺失、損壞或保密性破壞。

許多企業因為安全顧慮而不願使用第三方工具。然而,自行開發的軟體也不一定是完全安全的。因此,必須確保所有自動化工具都具有盡可能少的許可權,同時保護軟體免受外部威脅。

如何開始自動化成本管理

  1. 從簡單開始:先選擇簡單的工具和自動化目標,避免一開始就嘗試構建複雜的自動化系統。
  2. 先以通知模式執行:初始自動化應以通知模式執行,自動發現和警示潛在問題,但不進行修復。
  3. 建立對自動化的信心:瞭解自動化區域將採取的操作,並與團隊分享結果,以建立信心。
  4. 進行大量測試:在開發/測試帳戶中先執行自動化操作,然後再擴充套件到更廣泛的使用者基礎。
  5. 不要全部自行開發:依賴商業或開源工具,不僅可以節省時間,還能獲得最新的經過戰鬥測試的解決方案。
  6. 衡量績效:衡量自動化的績效,以確保其達到預期效果。

自動化的物件

成功的FinOps從業者擁有許多自動化工具。一些常見的自動化解決方案包括:

標籤治理(Tag Governance)

定義組織的標籤標準後,可以使用自動化來確保其被遵循。首先識別缺少標籤或標籤應用錯誤的資源,然後讓負責的團隊成員糾正標籤違規行為。接著,可以停止或阻止資源以強制業主採取行動。

排程資源啟動/停止(Scheduled Resource Start/Stop)

資源管理和自動化使您能夠排程資源在不使用時停止,並在需要時重新啟動。這種自動化通常佈署在開發和測試環境中。

使用量減少(Usage Reduction)

減少自動化可以移除浪費,或至少向負責的團隊成員傳送警示,以推動更好的成本最佳化。可以從Trusted Advisor(針對AWS)、第三方成本最佳化平台或資源指標直接取得資源資料,以向團隊成員傳送警示,或在某些環境中自動停止或調整資源大小。

重點整理

  • 自動化成本管理需要與團隊成員的教育和培訓相結合,以避免衝突。
  • 安全性是自動化工具的主要關注點,必須確保工具具有盡可能少的許可權。
  • 從簡單的自動化開始,逐步建立信心和擴充套件功能。
  • 常見的自動化解決方案包括標籤治理、排程資源啟動/停止和使用量減少。