FinOps-資源使用率與效率的能力

• 「資源使用率」和「資源效率」的含義
• 有關雲端資源的不同類型的“浪費”
• 提高資源效率的活動中「上游」和「下游」的含義
• 如何配置雲端資源以確保業務效率
• 系統在雲端運行後如何提升業務效率
• 使用 AutoScaling 的不同方式
• 如何贏得對旨在提高業務效率的架構變更的支持

取自FinOps Foundation官網

定義

管理資源利用率和效率旨在盡可能具成本效益地將系統效能與業務需求相匹配。

在「On-Demand」雲端模型中，我們透過在需求產生時配置具有所需量能的資源來滿足需求。資源利用率和效率的管理意味著確定在滿足業務需求的同時是否有降低資源成本的空間，如果有，則在具成本效益上的情況下進行所需的變更。

從雲端資源中獲取最佳業務價值是一項關鍵的 FinOps 能力。 目的是在需求發生時將每個雲端資源的配置與對其提出的需求進行配對。 本質上，我們的目標是找到能夠提供所需效能的最低成本解決方案。

資源使用率的定義

資源使用率 = (實際資源使用的量能 x 100) / 剩餘量能。

資源利用率是任何時間「已使用資源量能」與「剩餘資源量能」的比率。 一般來說： 資源是根據其「可用量能」來配置的，這決定了資源成本。 提高資源使用率可以提高資源效率，但是： 某些資源（例如構成BC/DR功能一部分的資源）可能使用率為零，但具有重要的商業價值。 某些資源，例如與業務冗餘的服務相關的資源，可能具有高使用率，但業務價值為零。

資源效率的定義

通常，效率是透過（產出）/（投入）的簡單比率來衡量的。 出於 FinOps 的目標，投入等於成本，FinOps感興趣的是資源為運行它所花費的費用所產出的成果。 考慮到這一點，效率可以定義為：

技術效率=（資源產出）/（資源成本）
即技術產出的單位成本，例如 每一元的交易量、傳輸 1PB 資料的成本等。

如果與具有業務價值的產出有直接聯繫，則從以下角度思考會很有幫助:
業務效率 =（業務價值）/（資源成本）
也就是說，業務產出的單位成本，或業務價值的一個要素，例如處理客戶交易請求的成本。 FinOps 是尋求最大限度地提高業務效率。

企業也對ESG這一類的議題越來越關注：
能源效率 =（業務價值）/（消耗的能源） 即，提供單位業務價值所消耗的能源，例如 處理客戶交易請求時消耗的能源。

什麼是浪費

我們經常會看到諸如「我們估計 50% 的雲端支出被浪費了」之類的說法。

上面這一句話的更詳細的解釋是，提供特定需求模式所需的效能所要的最低成本，任何高於該數字的支出都會被視為是浪費。

聽起來合乎邏輯，但沒有幫助。因為這個最低成本是多少？ 我們如何計算呢？在某些情況下可能可以計算它，但沒有必要。 我們可以根據三種類型的浪費來定義 FinOps所說的的浪費。

絕對的浪費

零使用率、零業務價值的資源。 這些資源絕對是浪費，應盡快識別並刪除。 這是提高業務效率最簡單的途徑。

配置上的浪費

已利用並增加業務價值的資源，但配置或調度不當，導致其量能無法很好地滿足需求。 在具有成本效益意義的情況下，應識別並重新配置或重新調度此類資源，以提高使用率和效率。當節省的成本超過配置工作的成本時重新配置。

架構上的浪費

系統可以重新架構，以更低的成本提供相同的效能。 重新架構作為連貫雲端策略的一部分。

系統設計已被使用並提供業務價值，但不同的架構將提高業務效率。 此類系統可能源自簡單的雲端遷移「lift and shift」方法，並且應作為組織提高雲端業務價值策略的一部分進行重新架構

為什麼重要

發展強大的資源利用率和效率能力非常重要，因為它：

• 管理資源使用率和效率是健全FinOps實踐的基礎
• 透過使用率優化快速取得成果並確保對進一步優化作業的支持
• 向投資者、利害關係人呈現 FinOps 方法的有效性
• 釋放 IT 預算，為具有重大商業價值的更具生產力和進取性的活動提供資金
• 明顯的成本節省鼓勵技術團隊採用新的實踐 — 使他們更具成本意識
• 推動 FinOps 文化變革的便利起點，因為它需要新的視角
• 建立涉及技術、業務和財務團隊的協作方法來提高雲端價值

參與人員

此能力的參與人員根據RACI模型如下:

• R — 技術團隊
• A — 技術主管或產品主管
• C — FinOps Lead、產品\業務負責人
• I — 高階主管

合於FinOps框架的領域與能力

主要領域 —
雲端資源使用優化

其他領域

• 理解雲端資源使用與成本
• Performance Tracking and Benchmarking
• 及時決策

目的與預期成果

根據預測需求，在配置資源時準確調整資源大小。 監控資源使用率和效率，並在違反定義的限制時產生告警:

• 建立並監控一組適當的資源使用率和效率指標
• 採用適當的報告和工具來促進對這些指標的監控
• 有一個明確的流程來審查資源使用率和效率指標並商定改進措施

組織需要定期識別和刪除沒有使用率、沒有業務價值的資源。FinOps 團隊有一種方法來評估使用率最佳化計畫的費用淨節省(Net Saving)，同時考量到進行所需變更的成本。定期檢視組織的雲端策略，其中可以考量架構變更以提高業務效率。

Crawl階段的目的與預期成果

如果技術人員仍然保留「地端機房」心態，並且工程師沒有意識到使用率水準會影響 IT 基礎設施成本，那麼不太可能會對資源使用率和效率低下產生特別的利害關係。 教育可能是重中之重，可能還需要有對人員的KPI。

在此階段，重點通常是識別和消除“絕對浪費”，典型目標是：

• 辨識資源使用率資料的來源 — 例如 來自雲端計費資料、基礎設施監控工具、雲端提供者見解/工具
• 定義業務效率指標 — 即與我們的業務相關的指標，可用於衡量資源在交付業務價值方面的效率。
• 識別並停用那些提供零業務價值的資源

Walk階段的目的與預期成果

此階段重點將擴大到調整資源以滿足現有架構內的需求，例如：

• 配置"報告/系統"，以便在可以透過提高使用率和效率實現節省時提供告警
• 在可預測的零需求期間的情況下，安排資源自動開啟和關閉
• 調整資源規模，使其量能更接近預測需求模式
• 量化此類資源層級變更所帶來的節省，並與進行變更的成本進行比較

Run階段的目的與預期成果

在此階段團隊將考量架構層級的選項以及資源層級的變更，以便以最佳使用率和滿足需求

• 使用auto scaling技術動態調整資源以適應需求模式
• 重新架構解決方案，以更高的效率提供所需的效能和業務價值 — 例如 透過使用雲端原生架構、容器、serverless技術等。

能力流程

1. 分析工作負載
2. 管理業務效率 — 上游活動
   — 上游資源規模調整
   — 管理需求
3. 管理業務效率 — 下游活動
   — 刪除(減少絕對的浪費)
   — 下游資源規模調整(減少配置浪費)
   — 資源擴充(減少配置浪費)
4. 管理業務效率 — 更改雲端架構

分析工作負載

• 理解工作負載的要求。
  — 它有什麼作用？ 為什麼要這樣做？ 有什麼商業價值？
  — 需要多長時間的回應？
• 需求量是多少？
  — 上限
  — 下限
  — 一段時間內的平均值
• 需求模式是甚麼？
  — 一致、穩定的水平
  — 可預測的變化－它取決於什麼？
  — 可重複的變化 — 每天？ 每週？ 每月？ 季節性？
• 分析可能需要較長區間才能充分理解

需求模式

管理業務效率 — 上游活動

我們需要滿足需求並提供高水準的業務效率，哪這樣要如何配置雲端基礎架構呢？

上游資源規模調整可確保 IT 基礎架構滿足預估的工作負載需求，同時提供高水準的業務效率。 滿足效能和業務價值要求，而不會產生不必要的更高成本。

上游資源的規模調整

應在配置資源時適當調整資源大小並進行調度，以滿足預測需求。 這避免了產生配置性浪費。 我們可以將此過程稱為“上游”規模調整。

上游規模調整 — 管理配置(Provisioning)

1. 教育工程師 — 透過教育和訓練計劃確保架構師理解雲端成本和業務效率
2. 管理提供估算工具 — 工程師可以使用該工具來正確調整資源規模和安排資源，以匹配預期需求並實現良好的使用率和業務效率水平
3. 慶祝業務效率的提高 — 宣傳新的雲端解決方案，這些解決方案旨在提供良好的使用率和業務效率。 這強化了技術團隊中的 FinOps 文化，並提升了上游規模調整的重要性。

管理需求

我們可以管理需求以更好地利用剩餘可用資源，從而提高資源使用率和效率

節流(Throttling) —
如果需求來源具有Retry能力，則可以考慮節流來平滑需求並降低其上限。 節流告知要求來源目前無法為該請求提供服務，應該稍後再嘗試。 這允許以較低量能和較低成本的資源來處理相同的工作負載。

緩衝(Buffering) —
將作業單元新增至需求佇列(Demand Queue)中，並以滿足業務需求的速率來處理這些單位。 同樣，這允許以較低量能和成本的資源提供所需的業務價值，從而提高業務效率。

管理業務效率 — 下游活動

對於已投入使用的系統，下游活動可以提高業務效率。 效能和業務價值保持不變，成本降低。

退役(刪除)

隨著雲端資產隨著時間的推移而變化，我們可能不再需要一些正在運行且收費的資源 — — 也就是說，它們不再增加任何業務價值。如果工作負載分析顯示資源使用率為零，並且進一步確認沒有業務價值，則它代表絕對浪費，應停止使用。

在這種情況下，最佳實踐是：

1. 提醒資源擁有者進行工作負載分析，列出刪除的業務價值，並詢問是否有任何理由不刪除資源
2. 商定退役的方式和時間以及負責人。 如果可能，請自動化此流程。
3. 確認退役已發生並調整預測以反映節省的費用
4. 慶祝所產生的節省和業務效率的提高，以進一步鼓勵成本意識並強化 FinOps 文化

下游資源的規模調整

我們應識別並修改配置不當、業務效率低的資源，以節省成本。 我們可以將其稱為“下游”規模調整。

下游規模資源調整 — 管理產能和進度

1. 教育工程師 — 透過教育和訓練計劃確保架構師理解雲端成本和業務效率的管理
2. 提供 Showback 儀表板/報告 — 工程師可以使用它來正確調整資源大小和安排資源以滿足需求並實現良好的使用率和業務效率水平
3. 提出調整/調度建議 — 使用工作負載分析來識別可以顯著提高業務效率的調整/調度機會，並向技術團隊推薦這些行動，並在小型商業論證的支持下
4. 慶祝所產生的節省和業務效率的提高，以進一步鼓勵成本意識並強化 FinOps 文化

自動縮放(Auto Scaling)

所有 CSP 都提供自動擴展實例的功能，以便可用量能更緊密地匹配需求。 這是透過建立一組實例並更改可用實例的數量以滿足需求來實現的。 自動縮放可以透過預先確定的計劃觸發，也可以根據自動縮放政策動態觸發。

• 計劃性縮放 — 對於可預測和可重複的需求模式，計劃自動縮放可讓我們指定群組內隨時可用的實例數量。 這使我們可以更改資源量能以更好地匹配需求，從而提高使用率和業務效率。
• 動態縮放 — 對於不太可預測的需求模式，但可以定義可用量能的上限和下限，可以建立自動縮放政策。 這會自動觸發可用實例數量的變化，以滿足不斷變化的需求。 此策政策可根據各種因素（包括利用率指標）指定更改，這些因素由自動縮放程式監控並用於自動觸發縮放操作

管理業務效率 — 變更雲端架構

雲端系統的架構可能會限制正在交付的業務價值。 在不改變架構的情況下遷移到雲端的解決方案如果經過重新架構以充分利用雲端技術，可能會顯著提高業務效率。考量到這一點，最佳實踐是：

1. 教育工程師和工程主管 — 確保工程師和技術主管理解透過替代的雲端原生架構可實現的業務效率的潛在改進。
2. 協助建立商業論證 — 分析替代雲端架構的優勢和成本，並推薦那些提供最佳投資回報的架構

資源使用率和效率這兩個術語的意思？

資源使用率是資源的已使用量能與其可用量能之間的比率。 雲端資源的成本通常與其可用量能密切相關。 量能越大，成本越高。

所以我們的目標應該是只購買滿足需求所需的可用量能，以確保相對較高的使用率。

對於雲端，我們的首要目標是最大化業務價值。 一般來說，降低可用量能以提高利用率也可以透過以更低的成本提供相同的效能來提高業務價值。

考慮到資源使用率和業務價值之間的聯繫，我們需要注意一些特殊情況

1. 零利用率但業務價值顯著 — 例如針對BC/DR準備的資源
2. 商業價值為零但利用率很高

因此，雖然使用率水平通常是業務價值的良好指標，但了解系統的功能以充分了解其業務價值非常重要。