雲端資源的優化 — 用得更少

29 min readMar 18, 2022

本文中我們將討論在企業在導入FinOps文化中最困難的部分 — 使用更少的雲端資源。如果我們的目標是快速的進行雲端成本優化，哪麼購買RI/CUD可能是一個快速的方式(這個部分我們會在其他文章中提到)。不過RI/CUD的購買不經過審慎的分析與評估的話，到頭來也只是浪費錢。然而RI/CUD能快速達到我們雲端省錢的原因是因為它不需要技術團隊的介入就可以達成，因為量大就可以議價。

而用得更少(Usage reduction)則需要技術團隊的支持才能辦到，所以這才是整個FinOps最困難的部分。而這一個則需要融入技術團隊的Sprints中，並且先從最容易達成的目標開始。不過容易達成的目標其實也是需要我們有一些努力才能找到的。

雲端平台商(以下簡稱CSP)向我們推銷的是pay-as-you-go的想法。但是，更準確的說法是，"無論我們是否使用它們，您都需要為我們開啟的的資源付費。" 在本文中，我們將查看部署到我們的雲端帳號中的資源，這些資源要嘛沒被使用，要嘛沒有被有效使用。

雲端世界的現實 — 資源的消耗

當我們開始關注雲端資源的使用優化(usage optimization)時，一開始經常會聽到這樣的對話:

FinOps團隊成員: Hi, 你好像在A帳號中有一個VM名字叫xxx的使用率很低，感覺沒在動。你還需要它嗎?

技術團隊成員: Oh…它還在喔?我忘了刪掉它。我等下馬上刪了它。

這個對話可以讓我們理解的是，我們可以用一隻沮喪的手拍我們的額頭。我們很快就會意識到，如果我們早點進行這樣的對話，我們可能會節省數月的資源成本。

不過事情可能沒哪麼簡單，尤其是我們是在雲端中運行大規模的資源時，我們一定會有資源是低於使用率或是忘了關閉它．當技術團隊在雲端中運作他們的系統遇到資源不足的問題時，最直覺的就是把資源加大．會這樣子做是因為技術團隊不想在半夜因為資源不足被call．

但是哪一個資源需要被檢視卻是很困難的，尤其是大規模的使用雲端資源．如同我們在之前的文章提到的，我們需要一種正確的指標來讓我們知道我們的系統到底需要多少資源來執行．技術團隊還必須了解資源規模和運營方式的任何業務因素。FinOps 運行在整個公司中會將非常有效，因為它要求公司內的所有團隊都遵循一致的工作流程，並共同努力將優化的建議付諸行動。

然而當我們開始進行資源使用減少的作業流程時，我們就可以認知到我們可以在以前在超大資源上浪費錢的地方省錢，並且可以防止在未來的雲端資源使用的浪費錢的累積。接下來我們將會看見在雲端中浪費錢的組成有什麼，以及如何偵測哪些雲端資源應該要被檢查有沒有浪費錢(三大雲都有這一類的建議系統)，可以減少使用的方法，如何讓技術團隊開始改變，並且有正確的方式追蹤我們的進程．

大規模的資源減低使用其實是一種使用雲端的文化變革．這無法一次到位，而是必須不斷優化的過程，並且每次的過程都是選擇到正確大小的資源並減少每次都開始過大的資源來使用．資源減少使用需要工程師去考量網路頻寬一樣的思考：就是另一種部署的KPI設定．

將資源大小減半通常會節省 50% 的成本 — — 或者沒有使用的資源（例如沒有attach到 VM的HDD或沒在跑的instance）的情況下，可以節省 100%。與RI不同，on-demand不是一種預購，因此我們可以隨時調整insatnce的大小或完全停止使用它。使用費率降低的選項（例如RI）可以進一步節省資源大小是正確的資源，之後我們會有其他文章專門提到RI．

一開始，我們是用看歷史使用量的方式來減少資源使用量。技術團隊對他們的基礎設施做housekeeping，以確保充資源利用最大化。下一階段通常是重構應用程式變成是雲原生的，進而使用更便宜的雲端服務，並降低雲中運營服務的總體成本(從IaaS到PaaS甚至到SaaS)。 目標不是做出完美的決定。它是根據整個業務脈絡和資料做出可能的最佳決策，然後經常重複評估它。

哪麼浪費從哪裡來的呢？

我們這裡說的浪費是指我們的系統運作中不必要的資源有開啟，而資源開啟了就要付錢。這些不必要的資源可以透過調整資源大小或資源數量來達成。

當我們的系統一開始運行在雲端中時，到底要多少資源才能跑得順。老實說，應該沒有一個人知道。如果有，哪麼這個人應該就是神了。

而這種不確定性讓技術團隊會把資源加大的開啟，以避免系統效能不足的問題。但老實說，這一種狀況其實在傳統的地端機房也會發生。只是雲端的好處在於，我們可以隨時更改大小。而地端機房設備(資源)則是買了就無法再改了。但麻煩的地方在於，雖然在雲端中可以隨時調整資源大小來省錢，但如果我們不對過大的資源做監控也是白搭。

如果技術團隊忽視根據使用率指標來維護資源，則浪費會增加。持續監控我們的資源是否過大至關重要。這是因為在部署更高效的service code後，今天正確使用的資源明天可能會大太。甚至User的行為的變化也會導致容量需求降低。

靠移除/移動減少資源使用量

雲端技術團隊通常有兩種類型:一種是團隊成員"真的忘了"把資源關閉，另一種是他們"說謊"忘了關資源。不管是哪一種，開了燈之後，離開之後忘了關燈在雲端世界中非常普遍。

然而告訴技術團隊: 不要忘了關燈，並無法解決所有的事情。因為它可能是由自動化建立的資源未設定將其將其刪除。或者團隊故意將資源留在那裡，留在哪裡等著備用，但從未採取任何後續行動。此外，可以將某些資源配置為在其上層資源被刪除時保留，例如附加到VM的Disk，並且在刪除某些資源時，CSP可以自動建立資料的快照，無論我們是否需要它。

不見得或忘記使用的雲端資源是技術團隊最容易處理的問題類型。在這種情況下，減少使用量可以像刪除資源一樣簡單，從而節省 100% 的資源成本。

另外一種關於將資料存儲在雲端資源中的需求。通常，團隊出於合規性原因將資料保留很長時間。即使我們要把刪除掉的VM中的disk留下來，也有一些方法可以減少支付的費用。例如，CSP提供多種等級的storage，我們可以將資料移動到價格較低的“cloud storage”資源（如 Azure Archive 或 AWS Glacier ）時，為價格較高的存儲產品中的資料付錢是沒有意義的。

我們需要有一套在建立資料時的資料保留政策，讓團隊清楚地知道他們需要保留哪些資料以及保留多長時間。制定保留政策後，團隊可以設定系統自動的將其資料移動到不同的存儲產品，並在適當時將其刪除。

靠調整資源大小減少使用量

要調整資源大小，我們必需對資源的使用率有可見性。這種可見性必須包含CPU，記憶體，硬碟，網路等資源使用率。

當調整大小時，我們不只對成本進行優化。我們也要同時確定這樣的調整對整體服務的效能不會有影響。技術團隊在管理雲端服務中的主要目標其實是確保服務本身不會耗盡所需的維運量能。因此，他們抵制調整資源大小的想法並不少見，尤其是那些要支援生產環境的資源。

如果技術團隊不得不停止他們手邊的工作來調查調整他們的資源大小，那麼可能會對業務產生真正的影響。在決定技術團隊是否應該專注於調整資源大小以降低成本時，我們需要考慮這些影響。通常會有少數高成本資源和一堆小資源，而這些資源只會節省很少的錢。哪倒底要不要調整資源大小其實可以有個的分界點（就是最少要省多少錢，不然就不做）。應該經常審查這個臨界值，以確保它仍然是合理的。 "目標是確保花在調整規模上的時間可以為我們省很大。"

為了避免在進行調整大小的異動時擔心對資源產生的影響，了解 FinOps 團隊在調整大小中所扮演的角色非常重要。 FinOps 是關於團隊之間的協作，不應由 FinOps 成員單獨執行。這是進行討論至關重要的地方，因為只用查看指標通常不可能推斷出技術團隊用於確定要用多少資源的方法。

中心化單位的FinOps 團隊負責對資源使用情況進行自動化分析，提供關於哪些資源好像沒有被充分利用的報告，並以寫腳本的方式提供替代的、更有效的配置(FinOps團隊中需要有此類的專家)。然後向技術團隊提供調查資源的建議，以確定任何可能阻礙調整資源大小以實現可能省錢的原因。

提供多個建議以適應資源上的現有工作負載，而不會降低工作負載效能，這一點很重要。多個建議使團隊有機會在減少資源規模後可能有的風險與可能省錢之間取得平衡。像 Apptio Cloudability 這樣的 FinOps 平台可以完成提供這些建議的作業，技術團隊可以使用 SignalFx 或CSP提供的監控工具進行進一步調查。

每個調整大小的建議都是一個可以與技術團隊討論的省錢的機會。我們必須要有全盤的了解這些挑整資源大小的工作與確保新的系統從一開始上線就可以被調整。

一般普遍的調整大小的錯誤

只依靠建議並沒有計算到用量高峰的時間
當我們在檢查在雲端資源中的工作負載(如VM)，有一點很重要，就是我們必須確認最高峰的用量值。假如我們只看平均值，哪我們可能會遺漏掉某些東西。

用使用率的變化和高峰值，然後去套用統計模型來列舉最佳匹配的資源大小，但事情可能沒哪樣簡單。大多數工具都使用某種僅基於時間序列內使用率平均值的經驗法則，然後推薦最合適的資源類型。

例如，當我們比較下圖中的兩個使用情況圖表時，兩者的平均 CPU 統計數據都是 20% 的一小時內使用率。但是，使用平均 CPU 使用率指標，我們無法判斷 CPU 是始終處於 20%（如下圖右邊所示）還是在五分之一的時間內接近最大 CPU用量並且在剩餘時間用不到0%（如下圖左邊所示）。將這些instance調整只剩一半 CPU 容量的instance會影響左邊instance在 CPU 使用高峰期間的效能。無論我們是每天、每小時還是每分鐘看一次都沒有關係。平均值並不能說明instance上發生的事情的全部情況。

只看平均使用率會產生兩種結果: 技術團隊依靠完全是虛假的建議，省錢的提議就這樣靠虛假的建議就完成了。而技術團隊會認知是浪費他們的時間，而它們的部署仍然在浪費錢。

另一種狀況更慘，一個菜鳥工程師根據建議提早行動。經過了一段時間或一個平均時間週期後，新的資源設置可能可以撐住運作。但流量高峰來臨時，系統就撐不住掛掉了。這樣子的做法讓任何可能省錢方法都大大超過了業務風險。

沒有定義出我們的資源型態
調整資源大小不應該卡在一種運算資源系列。每一個CSP都會提供多種的運算資源系列，而我們應該根據符合我們工作負載的資源型態來選擇適合的。例如，在AWS r5系列的insatnce也許就會有memory 資源過剩的情況，但CPU可能是符合需求的。這就是一個挑整資源的好時機，因為我們只需要CPU運算資源而減少memory的需求。這時r5改成c5也許是一種選擇，甚至選通用的instance。

在沒有模擬之前就調整大小

技術團隊可能會擔心資源修剪（減少服務器資源時影響效能）會產生次優的決策。但是，使用模擬的方式來預測優化的建議會如何影響infra時，我們可以做出更好的選擇來優化雲端。在進行調整資源之前，我們必須確保能夠可視化每個調整選項的影響，並考慮跨運算資源系列的多個調整建議。通過這種方式，我們可以評估可能出現修剪(如下圖)的可能性，並在與我們將進行的省錢相比時考量到這種風險。如果沒有這一步，我們可能會過於保守（省錢不多）或過於激進（效能下降/服務中斷）

由於 RI 不確定性而猶豫不決

團隊常說的一句話是：“我不想調整規模，因為這可能會影響我的 RI 覆蓋範圍並造成浪費。” 曾經有一段時間，這是一個需要謹慎考量。但現在不是了。三大 CSP 現在都有許多選項，這些選項為我們提供了更大的靈活性，讓我們可以放心地調整規模。使用具有靈活性的RI時，如果我們的使用量減少工作影響到RI，我們可以調整RI。我們將在其他文章節中介紹這些靈活性概念。

越過VM: 控制 Block storage成本的重點

擺脫沒有連結VM的volumes
整個Block storage(如AWS的EBS, GCP的persistent Disk)的重點是VM停止之後，voulme還存在．就資料保留性來說這是好的方式，不好的是如果它是不需要的話它會繼續燒錢．沒有用到的volumes被稱作未掛載或孤兒volumes，如果我們檢查它的狀態還會是“available”．這些volume在沒有掛載到VM的情況下無法有任何I/O流量。省錢的第一步就是擺脫它們。

第一個選擇就是刪掉它，不過我們要非常確定裡面的資料我們已經不要，或是備份到比較便宜的storage．為了確定這件事我們可以查看這一個volumes最後一次被掛載到VM的時間，如果是一個月前的事，哪麼可以刪掉它的機會就很大．尤其是在非生產環境．

另一個就是剛剛提到的做備份，我們可以對這個volume做快照，然後再刪掉它．快照的成本比volumes還要少．它會去除blank space ，壓縮資料並且將它存在AWS的S3或GCP的cloud storage．如果到時真的要回復資料，只要從快照restore回來就好．

聚焦在沒有throughput或沒有I/O的volumes
一但我們解決沒有掛載到VM的volumes．下一步就是尋找有掛載但沒在運作的volumes．這通常發生在這台VM是被關掉．為了找到這些有掛起來但沒在用的volumes，我們通常需要觀察volume network throughput與IOPS．如果最近10這兩個指標都沒有任何流量，哪這一個volume大概也沒有在用．

優先管理我們的block storage成本
使用block storage volume我們有兩種屬性跟計費有關：分別是空間大小與IOPS．儲存空間是以每GB單位計價，並且與所在的Region與volume type(HDD或 SSD)有關．而在效能方面IOPS越高，價錢越貴．而volumes常常是我們在優化成本時最常被忽略的一塊．

減少含有較高IOPS volumes的數量
含有較高保證的 IOPS volume(如 AWS PIOPS或 Azure Premium Disk)是不便宜的，不過卻很容易去修改它．使用過去的監控資料來定位未充分利用的disks並讓工程師在可能的情況下更改它們可以大大降低disk成本。

利用elastic volumes的優勢
當我們在用 AWS EBS時，volumes的size成長是可以逐步調整的(IOPS也是)，甚至是在使用中時也可以調整volume type．這完全不需要有維護時間或downtime．這句有一個很大的成本節約優勢，因為您不再需要過度配置我們的storage。

重新設計來達成減少使用量

重新設計我們的服務或平台應該是最困難的方式了。因為我們需要技術團隊的工程師去改寫程式，更改部署，甚至兩個都要一起做。這樣的方式有助於我們的程式與部署更朝向雲原生的服務並且從這裡得到效益。

資源縮放(scaling)

更改資源大小並不是省錢的全部答案，因為資源的大小可以剛好符合我們業務運作的時間，過了業務時間就會閒置(這種狀況在地端機房一定會出現)。一般班工程師絕不會去更改資源大小，因為哪意味著在我們的業務時間內就會出現效能問題。

技術團隊也許會重新架構他們的平台/程式來符合雲原生，雲原生的程式可以最大程度的利用雲端的彈性。最常用的方法就是在業務繁忙時期使用資源的水平縮放，並且在業務時間過後將資源自動縮小。所以平台/程式必須夠適應這種動態的縮放，而這大部分都需要重新設計我們的applicatiob code。不然就無法享有這種優勢。

排程的運作

大概很少公司的軟體開發是24小時的，一些領著瘋狂薪水的瘋狂公司例外。而在這種時候，開發與測試環境也許就可以關閉。一般開發團隊只在同一個區域位置而不是跨國團隊的開發，哪麼正常來說一周使用到開發/測試環境的時間大概是40–50小時，哪另外的118–128小時的時間是閒置的。不管是哪一種團隊(集中或跨國)，只要資源閒置的時間遠大於使用的時間，都應該考慮在沒有使用時關閉它。

而這種方式需要以自動化的方式來達成它。因為用人工的方式會有人為上的錯誤，自動化可以準時且完全的確認開啟/關閉我們在這些環境中需要的資源。有關於自動化的部分我們會再FinOps 生命週期的營運(operate)階段再詳細討論到。

對RI的影響

剛開始實行FinOps可能會常有這種問題，“我所有的預購資源呢？” 如果存在承諾的預購，例如CUD 或RI，則我們會想到使用量的變化會導致我們的預購資源未得到充分利用。通常，我們可以在要買 RI 或 CUD 等費率優化的方法之前執行使用資源優化來避免此問題。

通常資源優化都需要時間來調整，而且會常常超出我們的預期。調整資源大小是一件非常與系統很緊密的事情，也是一個漫長的過程。工程師們為他們的基礎設施汗流浹背。說“嗯，應該在更大或更小的instance上”並不容易。進行這些更改需要測試週期和真正的努力。因此，我們應該採取的方法是，如果我們能夠集中購買RI，進行良好的投資，並針對RI使用率很低的，那麼調整資源大小最終會趕上。

優先事項往往會改變，並且我們都要經常性的去滅火。無論我們認為自己有多少資源浪費，我們都應該接受這些就是事實並尋求立即獲得 RI 或 CUD 的覆蓋率。我們可以從 20–25% 的覆蓋率開始，然後隨著清理工作緩慢增長。

除非我們購買了所有雲端使用量(就是包場)，否則使用優化應該仍然是可能的。展望未來，我們應該在要預購資源之前考慮組織可用的使用優化量。大多數CSP允許交換或更改預購的資源以匹配新的使用參數。通過一些計劃，我們可以避免被鎖定在不正確的預購資源中，並通過在進行變動時修改預購來開始減少使用量。

效益與人力工時

當我們檢視所有可能的使用量減少的建議，我們必須考量到這個可能的省錢與技術團隊投入的人力資源與工時還有對我們生產環境的風險是甚麼。如果我們投入的資源(時間與實行變更)是大於省錢，哪麼我們也許就可以略過這些使用量減少的建議。基本上，我們應該去除低價值與高風險的省錢建議。

剛剛提到的技術團隊的人力與工時，另外一個思考面向是: 如果省去大量人力與工時的效益是大於省錢的行動，哪麼意味著技術團隊可以把省下來的工時做其他有效益的事。哪這些有效益的事也不必多請工程師來做。

我們不應該在未先調查這些變更的影響之前進行變更。有時團隊在不了解其影響的情況下執行變更 — — 或者更糟糕的是，設置自動化來強制調整資源大小。這可能會導致生產環境發生問題。

在投入時間執行變更以減少使用量之前，團隊應確定改回變更之前(就是回復上一動的良好狀態)的可能性。如果我們預計在接下來的幾週內工作量會增加，而減少使用量的行動所需的時間意味著我們必須在之後幾乎立即增加工作量，那麼這不是一個很好的時間投資。此外，我們還必須考慮其他專案，檢查進行變更可以實現的效益。如果我們在調整現在被替換的instance的大小的幾天後有新的release，那麼再次將時間花在其他地方以獲得更好的業務收益，因為這樣的兩種變動太近了。

雖然節省的費用可能看起來很小，尤其是與企業的整個雲端成本相比，但重要的是要記住隨著時間的推移省的錢會越來越多。通過刪除不必要的資源，我們可以避免在此後的每個月的帳單中為該資源付費。

無伺服器(serverless)的運算

Serverless是CSP運行服務器並動態管理機器資源分配的模型。它的定價基於實際執行的功能，而不是基於預先購買的容量單位(例如CPU/Memory)。

它消除了我們前面討論的許多未使用或未充分利用資源的問題。使用Serverless，我們"真正"只需為我們正在使用的資源付費。未使用的資源通常不容易被消除。與啟動server instance並在需要時部署軟體來相比，Serverless架構通常可以非常快速地處理requests。

但改成Serverless並非沒有成本，也絕不是解決資源浪費問題的靈丹妙藥。FinOps 基金會內部就預測和比較Application的serverless成本與其當前的計算密集型架構的最佳方法進行了一場討論。提出了幾種特殊的方法，最後討論表明這種做法仍在不斷發展。

最終，構建任何Serverless遷移計劃的複雜性在於執行，與省錢幾乎沒有關係。從大型server insatnce轉移到許多concurrent lambda execution的建議是沒有意義的，因為與實現該目標的技術團隊的人力與時間資源相比，這樣做所帶來的省錢是微不足道的。在大多數情況下，擔心Serverless的forecast或優化沒有什麼意義，因為真正的成本不是雲端帳單，而是應用程式的重新架構。簡而言之：Serverless很便宜，但為serverless重構我們的系統則不然。因此，對於新專案而不是現有應用程式，Serverless通常是更好的選擇。

但是，我們可以用一個完全不同的角度來評估Serverless：TCO(總體成本)，或構建解決方案所需的技術團隊的成本，以及產品/服務上市時間對成功和獲利能力的影響。請記住，Serverless等於是我們把很多責任/風險轉嫁給了CSP，通常是DevOps 工程師會處理的職責（服務器管理、擴展、配置、修補等）成為三大雲的責任，這讓開發團隊可以自由地專注於更快地交付程式功能。

大多數的人的很多時候關注的焦點都放在了雲端的基礎設施本身的成本上。但是軟體開發中最大的成本通常是人。在檢視serverless論點的雙方時，請仔細考慮這一點。當我們考慮從單體(Monolithic)應用程式遷移到Serverless應用程式時，工程師成本（例如薪資）可能會抵消任何基礎設施的省錢。回到效益與人力工時的考量中，我們應該考慮重新設計Serverless服務的(TCO)和可能的省錢之間的差異。

但是，當我們在建立新的全新Serverless服務時，節省工程師成本可能是值得的。 Serverless既可以加快新產品上市時間（注意:不是改舊系統），又可以顯著降低持續的維運人力的需求。這些效益讓我們將資源重定向到構建產品而不是維護server。

關於Serverless的整個討論 — — 就像所有關於 FinOps 的事情一樣 — — 應該基於 FinOps 的目標：“這不是為了省錢；而是為了賺錢”。在我們的雲端帳單上，Serverless實際上最終對某些系統來說可能更貴，或者它可能會為其他系統節省大量費用。 為實現這些省錢而產生的真正成本將是工程師成本，但我們從Serverless中獲得的真正效益很可能是更短的產品上市時間。當我們談及競爭優勢時，機會成本超過了許多實際成本。

不是所有的浪費都是浪費

如果我們開始對擁有超大資源的每個人大吼大叫，最終我們的FinOps團隊也會開始大吼大叫。（當然，在使用 FinOps 時，我們不必大吼大叫。）成功的 FinOps 會利用跨職能團隊相互討論的價值。了解有合理的理由過度配置資源可以改變我們在調整資源大小時使用的語氣。許多財務主管可能會向CEO or GM提出一份使用了一些超大資源的清單，並說有很大的浪費，然後就會跟技術團隊主管產生了緊張關係。

在我們確認哪些團隊負責哪些資源之前，我們是無法確定是否存在過度配置的正當理由。重要的是有人花一些時間調查資源過大的原因，並對其資源大小進行調整或提供資源為何會是如此大小的背景。這就是為什麼我們將使用量減少這個任務下放給負責每個應用程式的團隊的原因。雖然中央集權式的 FinOps 團隊可以幫助提供有關調整資源規模的建議和最佳實踐，但最終行動需要落在應用程式或服務的負責人身上。

過度配置的一個合理原因是hot/arm DR(Disaster recovery)。某個資源的大小允許生產環境的流量快速轉移到該資源身上，滿足團隊服務的RTO(recovery time objectives)。另一個原因可以應用在發生故障時需要額外容量的服務。在正常的日常運作中，服務不需要額外的容量。然而，它在故障的情況下就需要額外的容量。

即使是能夠完全優化的團隊也會感到訝異。優化機會通常是不受FinOps團隊控制的外部因素出現。CSP調降價格、效能提升、有新的realease、架構更改或類似事件都可能觸發優化或調整資源規模的需求。然而，FinOps團隊幾乎沒有能力預見這些事件或為它們制定計劃。因此，由於外部因素造成的績效上升可能並不完全公平。

同樣，FinOps 是關於團隊之間的協作。在沒有實際管理雲端資源的團隊協助下下調整資源大小可能會導致服務出現問題，也可能導致未來的優化工作出現問題。

我們的使用優化工作流程應該是追踪這些原因。我們可以使用工單系統來定義此工作流程，並記錄相關的溝通和資源調查工作。工單系統還我們追踪一段時間內的操作並計算出我們有哪些未完成的任務及其當前狀態。

如果存在過度配置資源的業務需求，我們就不再將其歸類為浪費。一旦擁有該資源的團隊提供了確定資源規模的正當理由，就可以制定一個流程來標記所調查的資源，進而從我們的追蹤中刪除省錢的建議。我們要記住的是，即使只是對最終沒有採取行動或可採取行動的省錢機會進行調查，也可能是 FinOps 團隊與其他相關團隊合作並建立信任的重要機會。

調整雲端資源的成熟度級別(爬,走,跑)

爬，走，跑策略是會不斷出現在FinOps文化中的，而它也是套用在資源使用的優化中．我們不應該一次想試著解決所有的浪費狀況．相反的，我們應該確定最有可能為組織省錢的減少資源使用的方法。在爬行階段，通常就是閒置資源．

當我們這樣做時，我們就建立了一種回報制度，這種制度會向組織顯示問題的規模和省錢的可能。然後我們可以標準這個問題清單的前十名並且檢視將工程師這類的資源投入到解決問題的效能會是如何．讓這個回饋循環顯示我們的團隊所付出的努力的結果，可以讓組織內的人相信這個過程，並且它向組織表明持續的人力資源投入是有其效益的。

從小地方著手可以降低組織的風險，因為許多減少使用量的策略都伴隨著不斷變化的資源和(或)對外服務的軟體。在任何時候減少運作中的變動的資源數量將降低這些變動可能會極大地影響業務的機會。

高階的工作流程：自動的選擇不要調整資源大小

也許優化資源最困難的部分是讓技術團隊與業務團隊負起責任並進行必要的行動．單單只有優化建議無法讓FinOps團隊是有效能的．因為，實施所需要變動的工作流程和實踐是才是省錢的地方。

案例：

以下是一個財星500大的生技公司如何實施其FinOpS的跑(Run)階段優化工作流程的真實案例。 FinOps 團隊負責領導向基於雲端計算（AWS 和 Azure）的All-in 遷移，並負責雲端平台、FinOps 以及地端機房的全球化管理。

團隊每兩週召開一次會議，審查各種優化任務的狀態，討論障礙以及如何修復它們，並計劃未來的資源優化，例如未來的優化規模、RI 購買、RI 轉換等，這些都安排在一個共同的日曆上，然後同步到他們的專案追蹤管理平台的優化。下物圖顯示了每個owner分配的優化任務，並根據進度使用相關的顏色編碼。

這個公司的資源大小調整是完全自動化的．一開始，他們的FinOps團隊會在Apptio Cloudability上跑一個調整資源大小的腳本．這個優化腳本的建議稍後可以在一個系統中被查詢，並且提交變更請求來對所有非生產環境的insatnces進行變更審查。如果變更被核可，系統就會送一封email給系統負責人，通知他們有一個調整資源大小的機會。

這一套自動化工作流程（如下圖）運行並在整個組織內使用，讓每個人都對流程都是有信心的。如果系統負責人選擇調整資源大小，它會在系統中宣告指定的日期和時間自動執行。一旦執行了調整資源大小的建議，他們就會發布與調整大小相關的成本避免(cost avoidance)。如果該團隊選擇不做，該資料也會被記錄到系統中。然後FinOps團隊需要試圖理解為什麼Application owner會選擇退出這個過程。

自動變更系統是一個高階（跑的階段）FinOps 流程。在跑的階段之前至少，我們應該考慮追踪我們的優化建議並讓團隊手動實施所需的變更。我們之前討論過使用工單系統來追踪調整資源大小的建議，我們能從工單系統得的feedback比監控更深入。使用工單系統應該讓我們能夠識別：

有多少的可優化的調查可以進到我們的建議中
有多少的可優化的調查最終可以有省錢與沒有實際進行行動的比較
有多久(平均)時間我們的優化建議是還沒有下一步的
有多少的雲端技術團隊是會執行我們的優化建議的

節費追蹤

與費率優化不同，我們的雲端帳單中不會有詳細資訊來顯示我們通過使用優化到底總共省了多少錢。除非我們有一個流程可以讓我們將insatnce大小的變化直接歸因於減少使用量的努力，否則所有這些花了大量人力與時間的效益將難以追踪。

使用優化(Usage optimization)也稱為成本規避，因為節省帳單的唯一跡象是沒有被收費。查看帳單，我們可能會注意到"使用量的減少"，並且很想將其總結為我們的使用優化工作所節省的費用。但是，僅僅因為我們建議技術/業務團隊考慮調整資源的大小並不意味著他們根據我們的建議進行了變更。或者，我們可能會看到資源的使用量增加，即使該團隊可能正在實施我們所建議的資料大小調整。這其實是不夠，任何雲端資源使用量的減少都可能被其他專案的新資源使用所掩蓋。因此，試圖展示我們在整個雲端資源中的單一節費將是非常困難。

Apptio Cloudability的 FinOps Practice Management — Rob Martin有這樣提到:
我們使用“小型商業論證”，這是我們在識別省錢的機會時產生的。這些可能是調整資源規模，它們可能是服務轉換（hosted DB versus managed DB，EFS 到 S3 等），它們可能是VM系列遷移（r3 到 r5 instance family）或其他專案。我們記錄它們並隨著時間的推移對其進行追踪，以建立一個可運作的建議和優化機會的分類帳本。它們是 FinOps 團隊用來追踪和量化全年活動的關鍵工具。

一些建議可以很簡單的追蹤其成本影響。例如，r5 instance可以比 r3 instance節省 45%。每天我們開啟 r3 卻不運作它，我們就是在浪費錢。但是，還有一些重要的技術原因可能會阻止我們從 r5s（例如 EMR 版本的兼容性）遷移到r3，因此除了機會價值之外，我們還需要了解實施它的成本以及實施技術障礙的背景.

建議的變更也可能會產生機會成本 — — 例如，需要正在從事其他專案的重要團隊資源，或者延遲其他系統搬到雲端。這些結果可能使這種變更在財務上是不可取的。

當技術團隊從外部獲得優化建議時，技術團隊可能會有防衛心態。 FinOps 團隊應將這些作為開始對話的機會。我們應該詢問有關理由和服務使用的問題，而不是將它們作為商業論證來提出。一個正式商業論證似乎會提供明確和有建設性的方向，但它會給技術團隊帶來很大的壓力，來證明他們過去的行動和選擇是合理的。

對於定期與技術/業務團隊（或支出最高的）開會的 FinOps 團隊，在每次會議中討論建議的優化措施是有效的。這樣，他們可以在一次會議中作為潛在機會提出，技術團隊可以調查哪些是可能的/可行的，然後他們可以在一個月內與 FinOps 團隊合作建立小型商業論證。在隨後的會議中，他們可以回報進度，並可以為他們的團隊報告成本避免情況。這會將節省的費用（或未完成的原因）記錄在 FinOps 分類帳和會議記錄中。它還為中心化的 FinOps 團隊提供資訊，用於評估 RI 採購和折扣談判。

追踪使用優化工作的另一種方法是查看正在提出的優化建議。如果我們總結今天實施所有的優化建議可以節省的總體潛在成本，然後將該數字與我們在過去某個時候可以節省的費用進行比較，我們可以確定組織是否得到了更多優化或更少優化。採用這個潛在的總體節省數字，並計算出與我們在相同資源類型上的總支出相比的百分比，我們可以確定潛在的節省百分比。

例如，假設我們有 1萬美元的server instance總體潛在節省建議。如果我們目前在server instance上花費 10萬美元，那麼我們的營運成本可能會降低 10%。如果我們將節省建議和總支出分開，我們可以將一個團隊與另一個團隊進行比較。

具效能的 FinOps 專家關注具有"最高潛在節省百分比"的團隊。他們幫助這些團隊理解優化的建議，解釋如何在有意義的情況下選擇不執行優化建議，並提供有關調整資源大小影響的專業知識。

（總成本 — 節省機會）/總成本的這個公式是一個百分比優化的指標，可以肯定地說。如果我們構建 100% 優化，我們的分數是 100。如果我們不這樣做，它會更低。我們可以隨著時間的推移追踪累積的未優化成本作為追踪器，但我們應該用某些激勵方式鼓勵優化工作和優化架構。

結論

使用量優化(Usage optimization)通常比費率優化(rate optimization)更難，並且通常涉及多個團隊需要一起作業，以便由正確的團隊實施正確的建議、調查和變更。通過使用量優化可以實現的節省將是非常可觀的。

總結一下:

使用量優化是關於當我們不需要時能夠使用更少的資源
對資源浪費的可視化可以引領組織走向精實文化，而相關團隊也會開始認知到資源浪費的影響
使用量優化是會有正式的工作流程的，特別是把自動化的功能加上來時就會產生最好的效益
使用量優化在減少雲端費用中是最難的部分，並且應該在FinOps各階段(爬/走/跑)當中謹慎的實行
密切追踪資源優化的節省以顯示 FinOps 工作的影響，並定期與相關團隊合作調查優化的機會，請記住並非所有機會都可以採取行動。

由於我們已經根據建議更動資源使用量，使用量優化可能會導致費率優化問題。在執行費率優化時考慮使用資源優化至關重要，以避免對會發生變化的資源使用做出採購的承諾(commitments)。