FinOPs的生命週期 — 優化階段

10 min readMar 26, 2022

當我們進入優化階段時，我們將重點轉移到近乎即時的決策、識別異常情況和有效支出上。我們使用指標方式(metric-driven)設定目標，以便我們的組織可以了解它設定的績效的表現。

一旦組織和團隊獲得授權，他們就需要優化他們的雲端足跡。雲端平台商(以下簡稱CSP)提供了多種優化手段。 On-Demand的容量是最貴的。為了鼓勵提前進行預購計劃和增加預購量，CSP為預購提供折扣，這些雲端資源預購通常涉及複雜計算（Reserved instance(AWS) / Committed Use Discount(GCP)。

此外，團隊和組織可以通過調整資源大小(rightsizing)和關閉任何資源的浪費來優化環境。小型商業案例將成本、預期的省錢和進行變更以達到優化的效益結合在一起，並建立目標和指標，為行動奠定基礎。

在優化階段我們檢視優化雲端環境的機會。我們需要:

定義我們的定位，目標，指標
可優化的雲端資源清單
優化使用 — workload的管理
優化使用 — 調整雲端資源大小(Rightsizing)
優化費率 — 雲端資源容量的預購
優化費率 —暫時性且非保證的( Spot/Preemptive)運算資源
優化費率 — 折扣的談判
建立商業案例

定位，目標，指標

任何優化的首要目標應該是良好的成本分配。如果沒有充分了解所有成本和固定下來其費用，優化將偏離目標。節省成本可以成為一個目標 — — 但不是唯一（或最重要）的目標，我們可以問自己這一個問題： “我怎樣才能花適量的錢為企業帶來最大的利益？”，其實就是我們該使用哪種雲端模型。

例如。當工作負載可能因業務成長而翻倍時，不要去制定“比去年節省 “50%”的目標。節省去年”每單位成本”的 50% 將是一種更好的表達方式（但可能更難衡量）
請記住FinOps的鐵三角(如下圖:便宜，快速，品質)。我們的目標"不應該"是做得更好、更少、更快，因為這等於又要馬兒好又要馬兒不吃草。這個鐵三角是需要權衡取捨的。

OKR 讓我們明確的寫出期望實現的目標和關鍵結果。而在FinOps中實踐OKR會著重三個重點:

可信度 — 其實就是信任，建立其透明度．如果沒有信任，說穿了我們也只是一個努力提供服務的人．OKR讓我們可以逐漸在組織間建立信任．其中一個關鍵部分是每個利害關係人需要的足夠細緻的雲端費用資料並能定期更新（每天、每週、每月）。這些更新資料必須簡單易懂。這些數字還必須與他們的會計部門在月底向他們報告的內容相關聯。
可持續性 — 很多時候，新的 FinOps 團隊沒有用持續的方式處理他們的工作，例如不強制執行自動標籤作業。有意義的資料需要由對其有意義的人來管理。我們可以做一個標籤存儲庫，由應用程式產品經理與跟業務有關的人員來維護，這樣我們就可以將所有應用程式資料和業務資料與雲端資源關聯起來，而不依賴於工程師，因為這些資料對工程師沒有意義。
控制 — 當我們要加速時(FinOps鐵三角)就需要控制。我們需要在每個application/product 團隊對於雲端使用的控制上加上"問責制"。要實現這樣的控制就必須設立一個直接的chargeback模式，分享的知識，與鼓勵使用者適應這個作業方式。

對組織要進行某個Business之前，組織一定會對這一項Business設立一筆預算。雲端成本也在其中，與其等待雲端成本突破我們的容忍度，然後想一些不適合的方式壓下成本，不如設定一個費用預設值並隨著專案進展追踪雲端支出，這將始終有助於避免收到帳單後的驚嚇。

定出KPI

KPI 是一種舊的績效指標。但最重要的是，讓我們的定位和目標可以實現、有辦法進行行動且清楚明瞭。

在FinOps的循環中每次重新檢視。上次我們得到了我們想要的嗎？如果是，那麼請多重複它。隨著時間的推移，我們可以不斷增加目標，因為我們改進了我們的定位和目標，並在我們的行動中變得更加細緻和成熟，如同品質管理大師愛德華茲·戴明的P.D.C.A。

並將我們的目標和機會放到一個追踪系統。如果組織是有敏捷文化的，請建立待處理的待辦事項。讓我們對我們的工作方式、工作內容、優先順序建立一個可視化系統。在比較成本與正在使用雲端資源的情況時考量一下預購容量覆蓋率的差異，另外根據使用場景我們會提議使用暫時性且非保證的( Spot/Preemptive)運算資源嗎?還是用預購容量?還是兩種都用。

組織是用KPI 是用來衡量 FinOps 團隊的績效嗎？如果是以下是建立KPIs與Objectives的問題

我們希望通過 KPI "促成什麼樣的行為"？
哪些 KPI 與我們組織的目標相吻合？
KPI 是在衡量誰的行動？

可以參考的KPIs範例可能如下:

預購容量的覆蓋率（是成本或資源使用？）
預購容量的使用率
優化的機會佔支出的百分比
Spot(或Preemptive)/Low Priority佔運算(compute)的百分比

可優化的清單

重點有以下三個

在優化階段，我們將確定要嘗試的優化內容。
尋找容易達成和艱困的元素的組合。
隨著我們變得更進階，它會變得更難（更少容易達成的目標）

而以下是我們可以避免與節費的事項:

100%可以避免的 — 關掉我們沒在使用的，例如，假日期間dev/test等非生產環境不會用到。
節省50%成本的 — 購買我們會正確有效使用的RI/CUD
節省25%成本的 —調整我們沒有正確使用的資源大小。例如管理我們在storage 資料的生命週期，時間到了就刪掉或是移到更便宜的空間等級。
節省0–100%成本的 — 用不同的東西做一樣的事。例如，要使用DB，可以從IaaS改成PaaS。或是Application跑在VM上的，可能可以改成容器，甚至serverless的方式。

Workload的管理

重要的是關掉或撤除不需要使用的資源。再來是:

有些作業不適用於某些工作負載
永遠都要與工程和平台團隊完成協商
盡可能的自動化

而在這一部分，FinOps的成熟度等級分別是:

爬: 手動的關閉我們沒在使用的資源

走:依時間性的定期關閉資源。例如，晚上或假日

跑:自動識別並終止被識別為沒有運做且沒有預定關閉時間的資源

調整大小(Rightsizing)

調整大小永遠必須用協作的方式進行，因為中央極權式的 FinOps 團隊無法單獨做到這一點．從尋求協助，交談，討論，同意，然後是商業案例．從簡單可得的成果開始，然後移動到困難的部分。並且定期與團隊討論任何優化的機會，而不僅僅是在出現“問題”時．同時與架構師團隊一起檢視架構，讓他們站在我們這邊，了解計劃中的變化．注意我們在雲端中的任何試驗，不要為臨時的東西去預購雲端資源容量（標籤是識別這一點的好機會）．

所以：

每個優化目標都是討論的機會(這是FinOPs的六個原則中的第一個)

而我們該從哪裡開始調整呢？

去除沒有用上或閒置的資源
儲存的種類(type)與類別(classes)
使用率極低的資源
將舊世代的instances改成效能較好的

持續與開發團隊每月的一次討論

確定整個月內有調整資源大小的機會
每個人都應該尋找調整資源的機會（這是FinOPs的六個原則中的第三個）

我們也要認知到良好的workload匹配與識別變化同樣重要，且需與架構和平台團隊保持定期的資訊同步與討論會議．進而進行有可能的架構/平台變更．驗證服務和資源的持續使用情況，而這是不是"試驗和測試"．

調整大小的清單

"資源優化"與"資源預購"存在著"競合"關係，因為:

如果我們要調整資源的大小就不該有預購容量
如果我們要調整資源的大小應該要檢查我們現有預購資源覆蓋率的影響

然而我們也需要我們自己的節奏來執行上面兩種作業，執行的時機為:

基於時間
基於指標
基於優化的機會

而這些執行的時機點的決策是建立於詳盡的分析之上。FinOps 可以為開發團隊提供及時的資訊，以便他們採取行動，同時允許他們在Sprints中進行優化。

優化費率

優化費率的方式有很多種，中央集權式的FinOPs團隊可以執行這一類的作業，包括:

購買 RI(AWS)/Saving s Plan (Azure)/ CUD(GCP)是最容易也是初階的費率優化
使用Spot/Pre-emptible instances，以達到節費的概念
以及與CSP或經銷商談判價格

我們也需要考量要購買這些預購(RI/SP/CUD)的容量，這些要預購量的大小必須是從技術團隊而來。還有很多在預購容量時需要考量的，特別是AWS，例如:

購買的RI是可轉換其他類型/大小或是標準的，意思是預購容量可以讓我們有彈性的轉換組合嗎?
在CSP的Region/Zone裡資源是否足夠我們的需要，這個在Azure常會有這樣的狀況。某個Region資源不夠開啟VM。
All-upfront(一次付)/partial(部分付款)/No-upfront(分期付)，這在AWS有這樣的選擇，GCP則只有分期付。而這樣的方式跟組織的內部"資本成本"有關。
預購容量的覆蓋目標。我們購買的量要覆蓋到現有使用資源的多少比例呢?(千萬不要是100%，因為辦不到。也不要是20%，因為目標太低)

同時財務面需要考量預購現金支出與效益的chargeback方法。

下圖為一個RI採購範例，其中x軸是每天運作的時間，Y軸是我們RI的覆蓋率。每一個區塊都代表單一的insatnce(假設大小是一樣的)以及每小時的運作。

從上途中我們可以看到，每年的每一天有10小時的運作時間(不過基本上我們應該是希望它24小時運作)。我們可以看到有四成的RI(由下往上算的四行A-F區塊)的使用率有100%，疊加到第五行則有90%使用率，到第六行有80%以此類推。沒有使用到的部分就是資源浪費。

預購的頻率

若我們要進行預購的頻率該是如何的呢?下圖是一個用量測的方式來告訴我們應該要預購的容量，基本上為每個月進行一次。

重點如下:

指定一個人負責進行預購（理想情況下是具有技術知識的財務人員）
定期、小額和無爭議的採購
按照既定的時間表迭代地進行預購
主動進行所預購的雲端資源的修改和交換

暫時性且非保證的運算資源

三大CSP都有提供這種類型的雲端資源。

AWS Spot Instance
GCP Preemptible VMs
Azure Low Priority VMs, Spot VMs

CSP這麼做通常是有閒置的容量沒有客戶正式的使用的話，他們就會用這種方式將他們的機器使用率最大化。但這類型的資源在使用上的諸多限制，不過卻可以在很短的時間內隨時啟用。而且通常價格比On-Demand費率低 70–80%，但有一些Applications不適合放到這樣的資源上，特別是無法承受無預警中斷後無法再很容易的恢復到中斷哪一刻的程序與資料。適合生產環境使用。

雲端資源的費率折扣

無論CSP或雲端資源的類型是哪種，折扣都是相似的。我們對CSP的預購承諾無非就是"金錢和時間"，因為CSP自己需要可預測性（跟我們的地端機房的運作是一的，但規模可能比我們大上上千倍）。而折扣總是會更高，以換取更多的:

要花的錢與承諾要花多久
租約期
我們需要放棄雲端的靈活性

所以對CSP來說能夠預測我們的需求並了解我們可以對任何折扣或預購做出哪些承諾非常重要。

而折扣的效益可以通過多種方式分配

如何將實際效益套用於各種instance和services
戰略舉措優先
用部門/群體/團隊間的總體雲端支出來劃分
將剩下來的費用作為一個儲蓄池或成為運作FinOps 功能的基金
使用各種“混合費率”方法平均分佈

而組織的Chargeback/Showback 策略將在很大程度上決定折扣應該怎麼分配。一般會使用通用成本指標（列出成本、調整成本、攤銷成本、混合成本等）來保持優化Business case的一致性。