FinOps-工作負載的管理與自動化能力
- 描述工作負載管理的概念
- 了解此能力在 FinOps 框架中的發揮位置
- 了解此能力的重要性
- 描述應該參與哪些角色來建立和維護這種能力
- 描述此能力將如何透過成熟度模型發展
- 描述與此能力相關的最佳實踐
- 了解與此能力相關的各種工具
- 描述此能力與傳統 IT 有何不同
工作負載管理(Workload Management)主要在雲端資源使用優化領域發揮作用，它使我們能夠在工作負載需求上升與下降時管理資源的配置。
組織的工作負載管理策略也透過其對基於承諾的折扣的影響對雲端費率最佳化產生影響。
一個很好的例子是，在一個企業中，有一些帳號推動了該企業的整體 EC2 使用。 他們的工作量極具彈性。 查看成本和資源使用情況，我們會看到非常高與非常低的用量。 雖然看到團隊以這種方式管理他們的運算資源很棒，而且這正是我們希望看到的，但其資源使用的彈性性質使得規劃節費計劃比其使用非常靜態(傳統地端)的情況要困難得多。
這使得我們的 FinOps 團隊在處理 SP(Saving Plan) 投資時格外小心，以涵蓋一些高度資源使用時間。 也許最有趣的是，它使我們的團隊更快地找到 SP 覆蓋範圍以及我們願意如何允許高覆蓋範圍影響我們的SP的利用率之間的容忍水平。
這種能力在組織協調領域內也有相當深刻的交互，其中 FinOps 文化強調以更有利於雲端的方式管理工作負載的重要性，這可能是實施FinOps 所需的更重大行為變革的要點。
定義
工作負載管理和自動化專注於僅在需要時運行資源，並建立自動調整在任何特定時間運行資源的機制。
與專注於將資源大小與需求相匹配的資源利用和效率一樣，工作負載管理和自動化使 FinOps 團隊能夠最有效地匹配供應與需求，並有效優化雲端使用。
重點是最後一部分：在資源利用率和效率將資源大小與工作負載需求相匹配的情況下，工作負載管理和自動化將供應與該需求相匹配。
有兩種不同的方法來整合此功能：
- 是使用Auto Scaling等服務根據需求動態配置和取消配置資源
- 為了更可預測的需求，CSP 提供了排程方法根據需要安排資源在一天中的特定時間和一周中的幾天開啟和關閉。
CSP以基於時間/效度的成本模型提供服務，其中計費以秒增量累計。 這與傳統 IT 模型形成鮮明對比，在傳統 IT 模型中，地端機房安裝的所有設備都是預先購買的，並且可以 24x7x365 運行，並需要額外運作成本(人力/水電/機房空間/軟硬維護費)。
現代軟體範式是在硬體上進行更具彈性的設計，這些硬體旨在極其短暫，其中通常包括中斷處理並將自動運算擴展納入架構中。 相較之下，可以提升並轉移到公有雲的舊有應用程式將遵循傳統 IT 模型，並且通常缺乏動態增加/減少運算容量的能力。
但是，如果應用程式存在高度可預測的使用模式，例如測試環境中的辦公時間使用，工程師可以使用更簡單的方法來最佳化其工作負載，根據這些時間表安排工作負載的啟用和關閉。
為何此能力重要?
- CSP按需提供資源，預設沒有承諾（大量預購），並以非常細緻度的增量（小時、分鐘、秒、毫秒）計費
- 在地端機房，購買的設備無論使用與否都始終運行，但在雲端中，每個增量運行時間週期都會產生費用
- 越來越多的軟體工作負載被建構為在關閉、休眠、中斷或暫停的硬體上彈性運行
- 每個工作日運行按小時計費的資源 8 小時，並建立適當的開啟和關閉機制，可將每週營運成本降低 76%，比基於承諾的折扣提供的折扣更大
參與角色(Personas)依據RACI模型有:
- R — 產品團隊的技術人員
- A — 產品負責人/經理/技術團隊領導者
- C — 業務利害關係人、產品使用者、技術人員、財務、採購
- I — 所有人
成功的衡量因素
要了解各個產品團隊的計劃，需要進行高度的協作，但假設 FinOps 團隊與最重要的雲端使用者保持密切聯繫，則可以理解團隊正在將其工作負載設計為動態的，並辨識不利容量變化的工作負載。 後者應記錄下來並與更廣泛的其他團隊分享，以幫助他們進行規劃和設計。 建議運算資源使用者將其instance標記為「always on」或「variable」也可能會有所幫助，因為這也可能提供有關始always on instance的基準運算成本的見解。
另一個允許FinOps 專業人員推斷一定程度的運算工作負載變化的關鍵效能指標可能是與正確調整資源大小或idle instance的潛力相關的統計資料的減少，因為臨時性的instance很少會在開啟很長的時間，以至於任何CSP 演算法都可以將它們標記為效率低下。
就新的工作負載而言，團隊通常會在引入任何類型的動態擴展或縮減之前首先完成工作負載，因此一旦他們達到MVP 里程碑，我們可能會開始看到運算使用量的一些高低峰，如果團隊沒有將成本融入原始設計中，他們就會回頭優化成本。
最後，FinOps 團隊可能希望產生報告來識別「always on」的資源，甚至透過某種記分卡或其他指標來衡量觀察到的彈性水平，這些指標可以與其他資源組或整個組織的運算資源進行比較用法。
Crawl階段
在此階段，許多團隊可能會專注於 MVP，大多數團隊不太可能立即將雲端的彈性融入他們的工作負載設計中(不過如果是Cloud Native可能就是另一回事)，但可能會優先考慮首次發布後的效率提升。 然而，其中一些團隊可能不了解管理雲端工作負載的價值，並且需要接受有關雲端最佳實踐的教育。
根據組織是否在短時間內將大量應用程式遷移到雲端，可能有許多傳統供應商產品不支援必要的動態運算配置和刪除配置。
Walk階段
在此階段，團隊中應該有一部分正在設計彈性基礎設施。 這可以透過 FinOps 團隊完成的任何工作負載變化報告來觀察。
此時，大多數團隊應該了解工作負載管理和自動化最佳實踐和期望，但尚未實施。
我們可能會注意到，引入工作負動態性的大部分作業都是圍繞著標準運算服務(VM or Cluster)而不是資料庫、分析環境等進行的。
此外，在此階段，FinOps 團隊可能會注意到與前一階段相比，調整規模和(或)閒置instance優化機會有所減少，因為足夠的團隊將實施這些實踐。
Run階段
在此階段，此能力應該成為任何雲端部署的質押和預期。 FinOps 團隊可能會注意到用於實現彈性的各種方法，其中包括auto-scaling、instance scheduling或pause/resume功能，具體取決於目標服務和CSP。動態運算配置可以在運算實例之外的多種技術中觀察到。
最佳實踐
辨識工作負載
我們已經認知到了這樣一個事實：工作負載管理和自動化完全屬於技術或產品團隊的職責範圍。 在辨識最有利動態性的工作負載時，這一點同樣重要。 由於產品團隊和工程師最了解應用程式的功能，因此中心化FinOps 團隊在沒有充分理解的情況下很難辨別它們。 這就是頻繁協作非常重要的地方，因為這將是我們的回饋循環，使我們能夠識別資源可以或不可以可變的場景。
這些場景應該記錄下來並在整個雲端開發團隊中共享，並且在評估雲端的新工作負載時也具有重要價值。
在產品團隊可能使用傳統企業供應商軟體產品的情況下，最確定的是該產品不支援任何類型的動態運算功能。 任何滿足此標準的已知產品都應進行標記，並考慮透過提供類似功能的雲端原生解決方案和(或)客製化開發的解決方案進行現代化。
最後，在雲端中開發的任何新應用程式都應採用現代應用程式開發範式，其中最肯定包括高度的彈性作為應用程式需求的基本面向。
辨識資源
接下來，如何識別始終在運行但在一天中或大部分時間內處於閒置狀態或嚴重未充分利用的資源。 雖然這仍然是技術和產品團隊的責任，但身為 FinOps 專業人員，我們必須主動識別這些情況。 有多種工具（包括雲端原生工具和第三方工具）可用於此作業。
作為一個簡單的開始，FinOps 團隊可以查看閒置或未充分利用實例的 CSP 報告。 報告為閒置或未充分利用的實例很可能是始終處於開啟狀態的實例。 如果 FinOps 團隊正在為閒置或未充分利用的實例產生報告，則應該知道對這些發現的回應將涉及透過自動擴展或排程導入運算資源的可變性。
除了這些 CSP 報告之外，我們還可以觀察到一致的、沒有變化的成本概況，並將其與網路、記憶體或 CPU 使用率等統計資料進行比較。 如果可以識別可變使用率的模式並且看起來是一致的，則可能有機會導入一些instance schedule(例如只有上班時間有在動)。 如果模式是很分散，則需要動態的trun/off能力。
套用Metadata
之前，我們討論了一些實踐，可讓我們辨識可以或不能導入彈性的工作負載。 此實踐將導入標記已知可變資源和預期持續運作資源的概念。
這個的價值是兩倍。 它使產品團隊能夠深入了解哪些資源被考慮用於彈性。 換句話說，他們在有意義的地方導入了彈性，並選擇了資源的一致運行，這不利於動態性。評估了針對該團隊的任何與潛在效率相關的嘗試。
其次，當這些資源被一致標記時，FinOps 人員可以更輕鬆地搜尋、比較和對比always on的實例與具有可變性的實例的成本。 這可能會讓 FinOps 團隊進一步強調工作負載可變性的重要性。
產品團隊的成熟度將是這裡的關鍵，因為在成熟一段時間後會多次導入可變性。 其他團隊可能會進行此類評估，以便將其融入他們的系統建置中。
工作負載效率報告
第一步也是最基本的步驟是回報低效率工作負載管理的「症狀」。 即使是中度成熟的 FinOps 組織也可能以某種方式報告或追蹤閒置和未充分利用的實例。 在帳號/專案/團隊層級觀察到的閒置和未充分利用的執行個體越多，我們就越有可能發現這些工作負載非常一致。
正如我們已經討論了標instance以呈現意圖“動態”或“一致”的概念，請理解我們將必須以這種方式標記很大一部分instance，但如果是這種情況，那麼我們可能會在此基礎上創建一些有利害關係的KPI。 也許應用單位成本，例如「一致」與「動態」的每小時平均成本，或者可以比較兩個類別之間每個實例 1 天的成本。 可能需要根據實例類型定義一些分組才能進行有效比較。
另一種選擇是以小時為單位收集計算成本和使用統計數據，這可以為每個帳號/專案/標籤提供兩個非常強大的結果（取決於我們的資料）：
- 每小時的視覺效果使動態性或一致性一目了然
- 能夠根據工作負載效率納入一些記分卡評分
無論 FinOps 團隊基於此能力執行什麼報告，都必須為客戶提供一些有效的解決措施。 可能是重新建構解決方案以使用更現代的方法（例如容器或無伺服器），或引入實例的動態擴展或調度。 如果無法以某種方式修改工作負載，團隊應確保實例大小適當或考慮使用 Spot instance。 所有這些替代方案在實施之前都需要進行一些考量。
定義模式
許多組織將為常見應用程式類型（single page application）或常見支援元素（data ingestion/data streaming patterns）建立架構模式或模型，其中封裝了組織所需的跨學科技術方法。 這些模式最好與 CSP 提供的最佳實踐概念相匹配，例如Well Architected Framework（AWS、Azure、GCP）。 在遵循這些建議的框架時，成本效率是考慮的支柱之一。關於三大公有雲的WAF可參閱本部落格的相關文章。
FinOps 團隊應該與架構團隊建立密切的合作關係，架構團隊最終負責建立模式或部署模型。 這使得 FinOps 能夠影響模式，並允許架構和成本管理策略之間的模仿。
自動化其模式
定義和發布的任何模式還應該包括可重用的代碼，或至少包括代碼範例，這將減少產品團隊採用該模式的工作量，並且還將在架構中創建一定程度的一致性整個組織。這可以參考本部落格的企業架構的組件重複使用相關文章。
包含可重複使用代碼將使 FinOps 團隊有機會影響模式的各個方面，這可能會增強他們識別和報告感興趣場景的能力。 一個很好的例子是我們之前討論過的「動態」與「一致」的建議標籤。 如果模式的一部分是透過自動擴展來部署實例，則有機會在代碼中包含這些標籤，這些標籤將識別必須與自動擴展根據工作負載需求部署的實例保持一致的。 這只是一個範例，但可能還有許多其他機會根據特定模式以所需的方式標記資源。
架構模式和可重複使用代碼是宣告式雲端資源治理的一種形式，架構團隊正在定義如何部署資源，但在大多數情況下，使用者能夠以可能偏離預期目的的方式修改代碼的型態。 雖然這個討論不是關於治理本身，但模式的發展確實開始進入這個領域。
預防性自動化是指防止部署不必要的配置，而不是允許部署它們並使用自動化回應來事後修正。 話雖這麼說，最好的做法是盡可能傾向於預防性自動化功能。 這比較困難，可能需要可以在 CI/CD 層級進行評估的第三方產品，或者包含雲原生服務（例如 AWS Service Catalog 或Azure Policy）才能完成，因此最好僅在關鍵場景中考慮這一點，或將其作為成熟度目標。
但總的來說，除了這項功能之外，FinOps 團隊也應該高度重視實踐各方面的自動化。
工具
AWS
- Auto Scaling
- Instance scheduler
- Redshift Pause/Resume
- RDS Stop/Start
Azure
- Autoscale
- VM schedule
- Automation Schedule
GCP
- Autoscaling
- Cloud Scheduler
