雲端成本最佳化關鍵策略

雲端成本管理日益受到重視，企業需要一套有效的策略來控制和降低雲端支出。本文除了探討如何減少不必要的資源浪費，也深入分析無伺服器運算的成本效益，並提供實務上的最佳化建議。考量到人力成本往往是軟體開發中最大的支出，在評估無伺服器架構時，需要仔細權衡重構應用程式的成本與潛在效益。對於綠地專案，無伺服器架構的優勢更為明顯，因為它可以縮短上市時間並減少持續的維運需求。此外，FinOps 的目標並非僅僅節省成本，而是創造價值，因此在制定成本最佳化策略時，需要考量更廣泛的商業目標。

最佳化雲端資源使用：減少浪費的關鍵策略

在進行變更以減少雲端資源使用之前，團隊應該評估這些變更被逆轉的可能性。如果預期未來幾週的工作負載將會增加，而調整資源大小所需的時間意味著幾乎立即需要再次擴增，那麼這將不是一個好的投資。此外，還需要考慮其他專案，檢視透過變更所能實作的效益。如果在調整資源大小後幾天內就推出新的服務，而這些服務又會取代現有的資源，那麼這段時間本可以花在對業務更有益的其他地方。

長期節省的重要性

儘管與整體雲端成本相比，節省的金額可能看起來微不足道，但必須記住，這些節省會隨著時間累積。透過移除不必要的資源，可以避免在未來的每個月帳單中為該資源付費。

無伺服器運算：新的成本控制模式

無伺服器運算是一種由雲端服務供應商執行伺服器並動態管理機器資源分配的模式。計價根據實際執行的活動，而不是預先購買的容量單位。

這種模式消除了許多前面討論到的未使用或未充分利用資源的問題。在無伺服器架構下，使用者真正只需為實際使用的資源付費。未使用的資源通常不容易被閒置。無伺服器架構通常能夠快速處理請求，而不需要啟動新的伺服器例項並佈署軟體。

無伺服器運算的成本與效益分析

轉向無伺服器運算並非毫無成本，也不是浪費問題的萬能藥。最近，FinOps 基金會內部就如何預測和比較應用程式的無伺服器成本與當前運算密集型架構的成本進行了深入討論。討論中提出了幾種優秀的方法，最終顯示出這種做法仍在不斷演變。

總擁有成本（TCO）的考量

最終，構建任何遷移計畫到無伺服器的複雜性在於執行，與成本文省關係不大。建議從大型伺服器例項遷移到多個平行的無伺服器執行例項是沒有意義的，因為這樣做的成本相關節省與所需的工程工作相比微不足道。對於大多數情況來說，擔心無伺服器的預測或最佳化是沒有意義的，因為真正的成本不在雲端帳單上，而是在於應用程式的重構。簡而言之：無伺服器可以很便宜，但為無伺服器進行重構並不便宜。因此，無伺服器通常更適合新的綠地專案，而不是現有的應用程式。

然而，有一個完全不同的角度可以評估無伺服器：總擁有成本（TCO），即構建解決方案所需的工程團隊的成本，以及上市時間對服務成功和盈利能力的影響。請記住，無伺服器允許將許多責任委託給雲端服務供應商。DevOps 工程師通常處理的職責（伺服器管理、擴充套件、組態、修補等）成為 AWS、Google Cloud 或 Azure 的責任，這使得開發團隊能夠專注於更快地交付差異化功能。

人力成本的重要性

人們往往（甚至在這本文中）過度關注基礎設施本身的成本。但軟體開發中最大的成本通常是人力成本。在考慮從單體式應用程式遷移到無伺服器架構時，人力成本（例如薪水）可能會抵消任何基礎設施的節省。回到效益與努力的比較，您應該考慮重新設計服務以適應無伺服器的整體成本與潛在的成本降低之間的關係。

綠地專案的優勢

但是，當您建立一個新的綠地無伺服器服務時，人力成本的節省可能是值得的。請記住，無伺服器既可以加快上市時間（透過避免重建現成的功能），又可以大幅減少持續的維運需求。這些好處使您可以將資源重新定向到構建產品，而不是維護伺服器。

FinOps 的目標：創造價值而非僅僅節省成本

關於無伺服器的整個討論——就像所有 FinOps 相關的話題一樣——應該以 FinOps 的目標為基礎：它不是關於節省錢；它是關於賺錢。在您的雲端帳單上，無伺服器實際上可能對於某些應用程式來說更昂貴，或者它可能為其他應用程式節省大量資金。您為實作這些節省而產生的真實成本將是人力成本，但您從無伺服器中獲得的真實好處可能是更短的上市時間。當涉及到競爭優勢時，機會成本遠遠超過許多真實成本。

不是所有的浪費都是浪費

如果您開始對擁有看似過度組態資源的每個人大喊大叫，那麼最終您的團隊也會反過來對您大喊大叫。（當然，在進行 FinOps 時，您不需要大喊大叫，因為團隊之間存在協作、信任和共同認可的流程。）成功的 FinOps 充分利用了跨功能團隊之間的對話價值。瞭解對資源進行過度組態有正當理由，可以改變您在調整資源大小時的語言和語氣。許多財務主管曾經因為拿著一份過度組態資源的清單，直接向高管指控普遍和猖獗的浪費，從而與工程主管產生了緊張關係。

圖表翻譯：

圖表翻譯： 此圖示呈現了一個持續評估與最佳化雲端資源使用的流程。首先從評估開始，判斷是否需要進行變更。如果需要變更，則進一步評估可行性，並考慮其他專案的效益後決定是否實施變更。若實施變更，則執行並持續監控與最佳化；若不實施，則繼續監控。整個過程形成一個迴圈，以確保資源的最佳利用。

資源使用最佳化的挑戰與實踐

在雲端運算環境中，資源使用最佳化是一項持續且重要的任務。工程長官層需要根據可靠的資訊和對雲端環境及業務優先事項的深入瞭解，來決定是否要優先解決資源浪費的問題。節省成本的機會必須以清晰、易於理解的方式呈現，以便與其他優先事項進行比較。

系統性浪費的處理

當系統性浪費被有意識地決定時，應設法將其過濾掉（最好有時間限制，以便稍後重新檢視），以免它們掩蓋真正可解決的機會。排除待檢視專案的過程也應受到監督。

在確認資源負責團隊的意見之前，不能確定過度組態是否有合理的原因。重要的是有人花時間調查資源過度組態的原因，並根據調查結果調整資源大小或提供資源大小的合理說明。這就是為什麼要將使用量減少的責任分散給各應用程式的負責團隊。

過度組態的合理原因

過度組態有時是出於災難復原或備份需求。例如，某些資源需要額外的容量以應對故障情況，雖然在正常運作期間不需要這些額外的容量，但在故障發生時卻至關重要。

即使是已經最佳化的團隊，也可能受到外部因素的影響，例如價格變動、效能提升或服務更新等，這些都可能觸發最佳化的需求。因此，由於外部因素而進行的評分可能並不完全公平。

與團隊合作的最佳化

FinOps 需要不同團隊之間的協作。若未經管理資源的團隊同意就調整資源大小，可能會對服務和未來的最佳化工作造成問題。除非應用程式的健康狀態和效能優先於成本文省，否則工程團隊往往會對調整資源大小持懷疑態度。

一旦與效能相關的調整資源大小建議得到信任和接受，團隊就會開始接受這些建議。您的使用最佳化工作流程應允許記錄這些原因，並使用票務系統來定義工作流程和記錄溝通及調查結果。

內容解密：

此段落強調了 FinOps 中跨團隊協作的重要性。票務系統的使用可以幫助記錄和追蹤最佳化過程中的溝通和調查結果，從而提高透明度和效率。

成熟的使用最佳化策略

在 FinOps 中，採用漸進式改進策略是一個重複的主題。使用最佳化也不例外。您不應試圖一次性解決所有的浪費使用問題，而應找出最有可能為組織節省資金的使用減少方法。在早期階段，這通常是閒置資源。

內容解密：

此策略強調了逐步實施最佳化的重要性，從低風險的閒置資源開始，逐步擴充套件到其他領域。

自動化最佳化工作流程

實施變更所需的行動才是實作節省的關鍵。某 Fortune 500 生物技術公司的 FinOps 團隊透過自動化權利調整流程，提高了效率。他們的權利調整流程是完全自動化的，從 FinOps 團隊啟動權利調整指令碼開始，將建議查詢到表格中，並為所有非生產例項提交變更請求。如果變更獲得批准，則會向應用程式所有者傳送電子郵件，通知他們有權利調整節省成本的機會。

圖表翻譯： 此圖表展示了自動化權利調整工作流程。首先，FinOps 團隊啟動權利調整指令碼，然後將建議查詢到表格中，並提交變更請求。如果變更獲得批准，則通知應用程式所有者，並執行權利調整，最後發布成本避免資料。

內容解密：

此自動化流程提高了效率，並使應用程式所有者能夠及時瞭解節省成本的機會。透過這種方式，可以更好地理解為什麼某些團隊可能會選擇離開該過程，從而進一步最佳化流程。

自動化調整與追蹤節省：成熟的FinOps實踐

自動化環境變更是先進的FinOps流程，建議成熟的團隊採用。至少應考慮追蹤建議並讓團隊手動實施必要的變更。

追蹤與實施變更

使用票證系統（如JIRA）來追蹤調整建議，可以幫助識別：

• 對建議的調查數量
• 調查後實際節省與未採取行動的比例
• 建議未被處理的平均時間
• 積極實施建議的團隊數量
• 拒絕調整的業務或技術理由

將票證分配給負責人可以提高團隊的責任感。例如，將最佳化建議以特定票證型別分配給特定團隊，可以促使他們規劃或關閉該票證。

自動化變更的限制

一次性自動調整或調整執行中的資源通常不是成功的模式。在使用基礎設施即程式碼（IaC）的組織中，正確的做法是修改程式碼並重新佈署環境，而不是在執行時進行臨時調整。

追蹤節省

與價格最佳化不同，雲端賬單中沒有直接顯示使用最佳化所帶來的折扣或節省。除非有流程可以直接將例項大小的變更歸因於使用減少的工作，否則很難追蹤這些努力的效益。

使用最佳化通常被視為成本避免，因為賬單中唯一的跡象是費用的減少。然而，這種減少可能被其他專案的新資源使用所掩蓋，使得很難顯示個別節省。

小型商業案例

一些FinOps團隊使用「小型商業案例」來記錄所有節省機會，例如調整大小、廢棄資源、虛擬機器現代化等，並追蹤這些機會是否被實施。這是一種量化FinOps團隊活動和證明成本避免主張的有效方法。

技術考量與機會成本

某些建議容易追蹤其成本影響，例如從r3例項遷移到r5例項可以節省45%的成本。然而，技術障礙或機會成本（如需要重要團隊資源或延遲其他系統遷移）可能會使變更在財務上不可行。

與團隊合作

FinOps團隊應將最佳化建議視為與團隊對話的機會，而不是簡單地呈現商業案例。這樣可以避免給團隊帶來壓力，使他們更願意與FinOps團隊合作。

定期會議討論最佳化

在定期會議中討論最佳化建議，可以幫助團隊調查可行性、建立小型商業案例並安排活動。這樣可以將節省或未能實施的原因記錄在案，並為評估承諾和折扣活動提供資訊。

追蹤使用最佳化工作

另一種方法是計算所有推薦最佳化的總潛在節省，並將其與過去的潛在節省進行比較，以確定組織是否變得更加最佳化。將潛在節省除以同類別資源的總支出，可以得出潛在節省百分比。

計算潛在最佳化節省

計算潛在最佳化節省時，應考慮其正面影響的持續時間。例如，終止孤立物件每月節省1,000美元，應考慮「如果沒有FinOps浪費計劃，這個物件會繼續存在多久」。

圖表翻譯： 此圖示展示了追蹤與實施使用最佳化的步驟，包括使用票證系統、分配責任人、追蹤結果、計算潛在節省以及定期會議討論最佳化建議。

玄貓解析：雲端成本最佳化 - 使用最佳化與費率最佳化

在雲端成本管理中，最佳化使用量和費率是兩個重要的策略。FinOps 團隊需要有效地追蹤和計算節省的成本，並將其呈現給長官層。在本篇文章中，我們將探討使用最佳化和費率最佳化的重要性、挑戰和最佳實踐。

使用最佳化：減少浪費，實作精簡文化

使用最佳化旨在確保工作負載只使用所需的資源，並且只在需要時執行。這種方法可以帶來顯著的成本文省，但通常需要多個團隊的協作。使用最佳化的關鍵挑戰在於找出浪費的資源並實施正確的建議。

使用最佳化的最佳實踐

• 提供高品質的資源調整建議，以避免工程團隊的阻力。
• 與工程團隊合作，討論和回答問題，而不是強制實施建議。
• 建立正式的工作流程，結合自動化，以實作最佳結果。
• 追蹤最佳化節省的成本，以展示 FinOps 工作的影響。

費率最佳化：降低雲端資源成本

費率最佳化旨在降低雲端資源的成本。這種方法主要由中央 FinOps 團隊管理，因為他們擁有組織雲端使用的最高層級檢視、購買專屬折扣的專業技能和知識，以及跨業務管理雲端費率的責任。

費率最佳化的關鍵要素

• 瞭解雲端成本的複雜性，包括多種購買選項、不同的計費時間和數量增量、各種付款結構和承諾選項。
• 使用預留例項（Reserved Instances）、節省計劃（Savings Plans）、承諾使用折扣（Committed Use Discounts）等工具來調整費率。
• 計算（Total Cost – Savings Opportunities）/ Total Cost 公式是一個百分比最佳化的指標，可以用來評估最佳化程度。

程式碼範例：計算最佳化百分比

def calculate_optimization_percentage(total_cost, savings_opportunities):
    """
    計算最佳化百分比。

    Args:
    total_cost (float): 總成本。
    savings_opportunities (float): 節省機會。

    Returns:
    float: 最佳化百分比。
    """
    if total_cost == 0:
        return 0
    optimization_percentage = ((total_cost - savings_opportunities) / total_cost) * 100
    return optimization_percentage

# 範例用法
total_cost = 1000
savings_opportunities = 200
optimization_percentage = calculate_optimization_percentage(total_cost, savings_opportunities)
print(f"最佳化百分比：{optimization_percentage}%")

內容解密：

此程式碼範例展示瞭如何計算最佳化百分比。首先，我們定義了一個函式 calculate_optimization_percentage，它接受 total_cost 和 savings_opportunities 作為輸入引數。然後，我們檢查 total_cost 是否為零，以避免除以零的錯誤。如果 total_cost 不為零，我們計算最佳化百分比並傳回結果。在範例用法中，我們計算了總成本為 1000 和節省機會為 200 時的最佳化百分比。

雲端成本最佳化流程

圖表翻譯： 此圖表展示了雲端成本最佳化的流程。首先，從「開始」節點開始，然後進入「使用最佳化」階段，旨在減少浪費和最佳化資源使用。接著，進入「費率最佳化」階段，透過調整費率來降低雲端資源的成本。最後，進入「持續監控和改進」階段，以確保成本最佳化措施的有效性和持續性。整個流程最終會達到「結束」節點，表示雲端成本最佳化的完成。

雲端成本最佳化：理解不同計費模式

雲端運算的成本管理是企業在使用雲端服務時面臨的一大挑戰。其中，計算資源的費用往往佔據了總成本的最大比例。瞭解不同雲端服務提供商的計費模式，可以幫助企業更好地最佳化成本。

主要雲端服務提供商的計費模式比較

目前，市場上主要有三大雲端服務提供商：AWS、Google Cloud 和 Azure。它們提供了多種計費模式，以滿足不同客戶的需求。以下表格總結了這三大提供商的主要計費模式：

隨用隨付（On-Demand/Pay-As-You-Go）

隨用隨付是雲端服務提供商最基本的計費模式。當客戶沒有預先承諾使用特定資源時，他們將按照隨用隨付的價格計費。這種計費模式提供了最大的靈活性，客戶可以隨時啟動或停止使用資源，而不會受到任何懲罰。然而，隨用隨付的價格通常是最高的。

內容解密：

• 隨用隨付計費模式適用於無預警的工作負載或測試環境。
• 由於沒有預先承諾，客戶需要為使用的資源支付最高價格。
• 這種模式適合短期或不穩定的工作負載。

搶佔式例項（Spot Resource Usage）

搶佔式例項是一種利用雲端服務提供商閒置資源的計費模式。客戶可以設定一個願意支付的最高價格，當市場價格低於這個價格時，客戶就可以使用這些資源。然而，當市場價格超過客戶設定的價格或資源不再可用時，雲端服務提供商可能會回收這些資源。因此，搶佔式例項適合於能夠容忍中斷的工作負載，例如批次處理。

內容解密：

• 搶佔式例項的價格通常遠低於隨用隨付的價格，可節省高達 91% 的成本。
• 由於資源可能會被回收，客戶需要設計能夠容忍中斷的應用程式。
• 這種模式適合於批次處理、資料分析和無狀態的工作負載。

長期承諾折扣（Commitment-Based Discounts）

長期承諾折扣是一種透過承諾在一定期間內使用特定資源或達到一定消費金額而獲得的折扣。這種折扣可以透過不同的形式實作，例如預留例項（Reserved Instances）、節省計劃（Savings Plans）等。透過做出長期承諾，客戶可以獲得比隨用隨付更低的價格。

內容解密：

• 長期承諾折扣適用於穩定且可預測的工作負載。
• 客戶需要根據自己的需求選擇適合的承諾方案，以獲得最大的折扣。
• 這種模式需要仔細規劃，以確保能夠滿足承諾的使用量或消費金額。

儲存定價（Storage Pricing）

儲存定價是另一個重要的成本組成部分。不同的雲端服務提供商提供了多種儲存服務，具有不同的可用性、耐用性和效能。客戶可以根據自己的需求選擇適合的儲存服務，以達到成本和效能的最佳平衡。

內容解密：

• 儲存定價與資料的存取模式密切相關。
• 熱資料（經常存取的資料）應該存放在高用性、高效能的儲存服務中，而冷資料（不常存取的資料）可以存放在較低成本、較低可用性的儲存服務中。
• 資料生命週期管理是最佳化儲存成本的關鍵。

@startuml
skinparam backgroundColor #FEFEFE
skinparam componentStyle rectangle

title 雲端成本最佳化關鍵策略

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

圖表翻譯： 此圖示展示了根據資料存取頻率選擇合適儲存服務的流程。經常存取的資料被存放在高用性儲存中，而不常存取的資料則被存放在低可用性儲存中，以達到成本最佳化。