中國信通院：騰訊云&降本之源-云原生成本管理白皮書（2022）（34頁）.pdf

《中國信通院：騰訊云&降本之源-云原生成本管理白皮書（2022）（34頁）.pdf》由會員分享，可在線閱讀，更多相關《中國信通院：騰訊云&降本之源-云原生成本管理白皮書（2022）（34頁）.pdf（34頁珍藏版）》請在三個皮匠報告上搜索。

1、降本之源云原生成本管理白皮書降本之源云原生成本管理白皮書編寫單位騰訊云計算（北京）有限責任公司中國信息通信研究院作業幫教育科技（北京）有限公司騰訊云原生 讓用云更簡單 更有效0408010203100808091014101011141719222527目錄CONTENTS前言一、背景介紹二、云原生成本管理模型2.1 資源利用率現狀2.2 云原生成本管理模型2.2.1 成本洞察2.2.2 成本優化2.2.3 成本運營三、最佳實踐3.1 成本洞察3.1.1 成本采集及資源追蹤3.1.2 資源使用可視化3.1.3 費用可視化3.2 成本優化3.2.1 設置合理的資源請求和限制3.2.2 動態調度3

2、.2.3 多維度彈性3.2.4 在離線混部3.2.5 GPU 共享3.2.6 優化矩陣3.3 成本運營3.3.1 建立成本優化團隊3.3.2 推動成本意識文化3.3.3 數據驅動成本優化3.3.4 在流程中考慮成本四、總結五、企業客戶降本案例113.1.4 成本分配133.1.5 賬單管理27282829293.3.5 量化成本優化交付的業務價值293132Keith ChanCNCF 中國區總監兼 Linux 基金會亞太區策略規劃總監、騰訊云 TVP前言云原生使組織能夠在現代云環境（例如公共云、私有云和混合云）中構建和運行可擴展的應用程序,更快地創新并使企業能夠更敏捷地對市場作出反應。憑借彈

3、性計算、自動擴展、計量計費和按使用付費模型等功能，云原生計算可幫助組織擺脫昂貴的永遠在線的基礎架構，并將這些節省用于新功能開發。冗余、容錯、松散耦合的服務和云原生架構自動化的自動恢復導致的彈性增加和停機時間減少也可能導致間接成本節約。使用容器和微服務構建應用程序的一個巧妙之處在于，云原生應用程序使開發人員可以更輕松地訪問和重用為早期項目創建的組件。這有幾個云原生的優點，可以降低開發成本并制作更好的應用程序：云原生是應用程序開發的未來，具有巨大的業務影響潛力能夠快速有效地將想法轉化為生產。云原生已賦能許多其他技術，例如 邊緣計算、人工智能、區塊鏈、5G 應用等。抓住云原生變得特別重要,你準備好了

4、以下了沒:1.創建一個更加面向服務的組織。而不是傳統的基于功能的結構，圍繞特定的服務或能力組織您的團隊。2.使用現代和最新的架構。云原生意味著使用微服務和反應速度更快的架構類型。3.重新組織您的架構以跟上云原生開發的步伐。業務應該能夠以與技術人員相同的速度足夠快地生成需求。4.大多數云原生關鍵基礎設施都是開源的，例如 Kubernetes，你知道如何參與開源社區以了解云原生的最新發展，甚至成為貢獻者的一份子嗎？降低開發過程的復雜性：開發人員可以將更多時間花在項目的細節上，而不是構建通用框架上。它還允許在更短的時間內開發更復雜的應用程序?？s短上市時間：更快的交付意味著更快的客戶更滿意，這也意味著

5、抓住時間敏感機會的潛力。簡化測試：經過審查的微服務出現的問題更少，減輕了管道后期的負載。當開發人員知道服務有效時，他們所要做的就是設計兼容性。模塊化設計：模塊化設計使外觀和功能的標準化更容易。擁有多個應用程序或服務的公司可以利用這一點來降低客戶的學習曲線。1數字經濟已成為我國經濟增長的重要引擎，云計算從部分企業數字化轉型的載體，轉變為整個經濟社會發展的基石與樞紐。萬千企業數字化轉型提速換擋，對云計算的使用效能提出了更高的要求，云計算迎來了全新的發展機遇。相較于傳統云計算架構，云原生具備更靈活的資源管理、更敏捷的應用迭代、更高效的模塊協同以及更穩定的業務保障能力，云原生帶動技術架構、應用效能、云

6、化效益的全方位提升，為企業數字化轉型提供了有效的實踐工具和方法論。根據中國信息通信研究院調查數據顯示，云原生已進入黃金發展期，其核心技術開始在大規模生產環境中深入應用，金融、政府、制造、電信、醫療等行業的云原生用戶占比較 2020 年均有顯著提升，云原生化開始從業內的頭部企業逐步下沉到中小企業，從領先企業的嘗鮮變為主流企業的必備。同時，云原生技術給企業帶來的價值中，提升資源利用率節約成本連續兩年排名第一，2021 年已有九成用戶認可該項價值，排名前五的另外四項價值分別是：提升彈性效率、提升交付效率、簡化運維系統以及便于現有系統的功能擴展。云原生已成為企業基于云實現降本增效的最佳實踐。但隨著企業

7、用云程度不斷加深，云上支出浪費嚴重，云原生平臺自身的成本治理成為企業上云突出訴求。彈性按需是云原生的資源利用優勢，但如果資源配置策略設置不合理可能會導致資源的浪費；云原生資源利用的計量方式如果不夠靈活，會使得企業難以準確調控用云成本；云邊緣、混合多云、云數智融合等模式在幫助提升工作效率、實現應用靈活部署的同時也帶來了異構資源管理的新挑戰。因此，企業在應用云原生架構之后，需要考慮如何管理、優化和使用云原生服務，如何通過降低云原生成本，進一步提升業務的數字化轉型效果。云原生成本管理面臨問題難定位、路徑難選擇、成效難持續三大挑戰，資源成本優化是云原生降本的關鍵路徑。云原生成本管理一是需要掌握成本支出

8、態勢，準確定位資源浪費的根源；二是需要選擇適合平臺架構和業務特點的資源優化策略，并規避因資源優化導致對業務穩定性的影響；三是實現成本優化后還需要保證其持久性。資源成本優化從基于賬單優化的成本可視、基于資源優化的成本節約以及基于模式優化的成本運營從三方面幫助降低云原生平臺成本。云原生成本管理白皮書將基于中國信息通信研究院與騰訊云對行業發展趨勢和企業客戶訴求的準確把握、對云原生優化的技術研究與實踐經驗，提出一套體系化的云原生成本優化方法論和最佳實踐路徑，結合行業優秀案例，幫助企業改善用云成本充分發揮云原生的效能和價值，為企業的數字化轉型提供可靠的保障。一、背景介紹2云原生并非一項單純的技術，更是一

9、種思想，是技術、企業管理方法的集合，云原生追求的是在包括公有云、私有云、混合云等動態環境中構建和運行規?；瘧玫哪芰?，追求的是業務持續平滑的變更能力。Kubernetes 是云原生技術棧的核心，是眾多云原生項目的粘合劑。Kubernetes 遵循聲明式系統原則，將其管控的對象都抽象成標準 API，并通過多種控制器完成云原生平臺的高度自動化。比如云用戶可以通過定義 Pod 對象，并指定需要運行的容器鏡像，以及容器所需的 CPU、內存等計算資源。該對象被提交至 Kubernetes 以后，Kubernetes 會依據用戶請求運行容器進程，并按需求確保該應用進程的資源配額。這使得應用可以以較低成本接

10、入到 Kubernetes 平臺中來，并依靠 Kubernetes 自動化機制實現低運維乃至免運維?；诒O控平臺收集的數據，Kubernetes 可根據應用的實時指標數據，預測應用資源用量，并通過自動化橫向或縱向擴縮容能力，及時調整應用的副本數量以及資源用量，及時回收空閑資源，提升資源使用率。提升資源利用率是云原生技術棧的核心目標之一，資源利用率的提升意味著以更少的計算節點用承載更多的應用實例，極大的降低云用戶的資源開銷，也契合國家節能減排的政策號召。二、云原生成本管理模型32.1 資源利用率現狀根據中國信息通信研究院調查數據顯示，云原生技術給企業帶來的價中，提升資源利用率以節約成本連續兩年排

11、名第一，2021 年，已有九成用戶認可該項價值。如圖1所示，2020 年 CNCF 中國云原生調查報告中指出，生產系統中使用 Kubernetes 的比例已從 2019 年的 72%增長到了 82%，越來越多的企業在云上使用基礎設施資源、通過 Kubernetes 平臺來管理應用，Kubernetes 已經無處不在。圖1 Kubernetes 近年部署率提升資源利用率以節省成本提升彈性伸縮效率提升交付效率簡化運維系統開放架構方便現有系統上的功能擴展選項2020年2021年76%90.59%63%76.98%38%66.83%30%67.57%25%48.02%4圖3 資源利用率調查但是，隨著企

12、業用云程度加深，越來越多的應用遷移到云原生架構上，原本天然具備降本增效特點的云原生架構如果資源配置不當也會引起大量云上資源閑置、云支出浪費。2021 年 CNCFFinOps Kubernetes Report調研報告顯示，遷移至 Kubernetes 平臺后，68%的受訪者表示所在企業計算資源成本有所增加，36%的受訪者表示成本飆升超過 20%，調查結果如圖 2 所示。這都說明即使是資源利用率更高的云原生架構也需要合理的資源成本管理。Kubernetes 集群的成本主要集中在工作節點的運行成本，資源利用率過低是計算成本高企的最主要原因。在 Kubernetes 集群中，資源利用率體現為運行的

13、所有 Pod 消耗的資源與集群上可用資源總量的比率，據麥肯錫早期報告，全球服務器資源利用率不到 6%，資源利用率低下導致了大量的資源浪費。針對相同統計口徑，騰訊云對 1000 多云客戶進行了資源利用情況分析，抽樣超過一萬計算節點，實際使用率如圖 3 所示：圖2 遷移至 Kubernetes 平臺后成本變化調查結果42%的節點資源利用率低于 10%72%的節點資源利用率低于 20%15%的節點資源利用率在 20%-30%只有不到13%的客戶點利用率大于 30%5在線業務流量通常有較明顯的波動周期，且波谷時間常大于波峰時間，波谷時期的資源有較多閑置，這也成為了資源利用率較低的另一主因。例如公交系統

14、通常在白天負載增加，夜晚負載減少；游戲業務通常在周五晚上開始出現波峰，在周日晚開始出現波谷。如圖 5 所示，同一業務在不同的時間段對CPU 資源的用量不同，若用戶以固定資源需求申請 CPU 資源，當業務負載較低時，CPU 資源利用率就會很低。將統計數據匯總，我們可以看到，計算節點的平均資源利用率在 10%左右，這意味著云用戶 90%的計算資源成本是閑置的，這造成了高企的云成本，形成了極大的浪費。針對此種狀況，下文分析了主要原因：Kubernetes Pod 的資源需求（Resource Request）字段用于管理容器對 CPU 和內存資源預留，保證容器至少可以達到的資源量，該部分資源不能被其

15、他容器搶占。如何設置資源需求是一個難題，若設置過小，當業務負載變高時，業務所需的計算資源無法被確保，可能會造成計算變慢、延遲過高等影響業務指標的情況。為避免此情況發生的可能性，用戶通常會將 Request 設置得很高，以保證服務的可靠性。但實際上，業務在大多數時段時負載不會很高。以 CPU 為例，圖4是某個實際業務場景下容器的資源預留（Request）和實際使用量（CPU_Usage）關系圖：資源預留遠大于實際使用量，兩者之間差值所對應的資源不能被其他負載使用，因此 Request 設置過大勢必會造成較大的資源浪費。資源預留過多，普遍存在 50%以上的浪費圖4 CPU 資源利用率業務資源使用率

16、波峰波谷現象普遍，低峰時資源浪費嚴重圖5 資源利用率的波動現象6計算作業依據其提供服務的特性和業務目的可分為在線業務和離線業務兩類：在線業務通常白天負載較高，且對時延要求較高，必須優先調度和運行；而離線的計算型業務通常對運行時段和時延要求相對較低，可以在在線業務負載波谷時段運行。此外，有些業務屬于計算密集型，對 CPU 資源消耗較多，而有些業務屬于內存密集型，對內存消耗較多。如圖 6 所示，將負載峰值在不同時段的業務，或者將在線和離線作業混部在一起，可有效的以離線作業填補在線作業的負載低谷時段，進而提升資源利用率。將需求不同資源的作業有效的部署在相同節點，可充分利用各種資源，提升總體資源利用率

17、。不同類型的業務，對資源的需求不同圖6 負載峰值在不同時段的業務混部部分客戶做完成本優化項目后，短期內確實節省了很多成本。但是隨著時間推移，業務的變遷，舊的成本優化方案可能會失效，云成本又開始上升，這個持續成本優化帶來很大挑戰。業務開發團隊在系統架構、系統設計時，缺乏對成本的考量，這可能使業務上線后的資源開銷較大?？蛻粜枰獜慕M織、文化、流程等多維度提升對云成本的認知，在系統設計之初就將云成本納入考量范圍之內。圖7 優化方案的決策平衡相比于傳統云服務器，Kubernetes 的動態性為資源計量和成本分攤變得更復雜，Kubernetes 作為一個開放式平臺，鼓勵資源共享，但同時缺少有效的成本觀測和

18、分配機制。多個容器應用可以被動態調度在同一個計算節點上，簡單將底層云資源與應用一一映射并評估成本的傳統手段已經失效。如何發現和觀測成本管理上的問題，比如針對資源閑置、應用閑置、以及前述資源利用率過低等問題，如何能快速有效的發現并分析。定位到問題后，如何制定優化方案，這些方案會不會對現有的架構帶來挑戰，如何在權衡成本、性能、穩定性、業務價值后作出最佳決策，如圖 7 所示。針對資源利用率低的現狀，我們對數十個客戶進行了訪談，了解到他們在成本管理時的挑戰：7圖8 云原生成本管理模型基于資源利用率的現狀和挑戰，我們整理了三階段云原生成本管理模型，如圖 8 所示：成本洞察：成本采集及資源跟蹤、成本可視化

19、、成本分配和賬單管理成本優化：提供可靠、便利、智能的優化方案成本運營：從組織、文化、流程等方面建設成本運營體系 云環境下的資源使用和成本支出是比較復雜的，團隊或組織需要通過一定的工具或方案對各種產品進行定義、定價、計費及統計，并對各類資源的使用率、使用量等指標進行持續追蹤，能幫助團隊盡可能多地搜集到云成本情況，為后邊成本可視化以及成本分配提供數據基礎。2.2.1 成本洞察成本采集及資源追蹤Kubernetes 的成本分配比傳統的云環境面臨更多挑戰，團隊需要定義一致的標簽和命名空間來改善分配，對于任何組織、部門及職能團隊，基于多維度（如云產品、環境、業務線）的資源和成本的可視化分析，能夠幫助團隊

20、有效地建立起相應的問責機制，并根據獲取到的實時數據快速制定優化方案及措施。成本可視化和成本分配云賬單的繁冗性和復雜性給用戶帶來非常大的不便，團隊或組織需要對賬單進行統一高效的管理，一是根據實際的業務需求，將賬單按組織、部門、項目業務維度，年、月周期維度等進行詳細化的拆分。二是將各類賬單進行統一分析，包括過去一段時間的使用情況、未來使用趨勢分析、各部門成本使用情況等方面，并給出合理的規劃及更改建議。三是將分析后賬單情況按業務部門、周期、自定義等維度定期推送給團隊，方便團隊及時得到相應的賬單。賬單管理2.2 云原生成本管理模型8對于固定資源池，對負載峰值在不同時段的在線應用、在離線應用進行混部，做

21、到分時復用針對 GPU 資源，實現資源的池化和共享云上資源優化并非是通過一系列標準動作后得出的一個終態恒定值。如同追求系統穩定性冗余大量資源，追求極致成本而犧牲業務穩定性同樣不可取。業務本身是變化的，適合的系統架構及管理方式同樣如此，我們鼓勵從組織、文化、流程等方面建設成本運營體系，根據目標持續不斷調整和優化。此階段的優化方案包括：2.2.3 成本運營從流程、組織、文化等方面建設成本運營體系建立成本優化團隊推動成本優化意識數據驅動成本優化在流程中考察成本量化成本優化交付的業務價值基于成本可視化和成本分配等手段，有了數據作為度量依據，團隊能夠圍繞其業務目標及業務場景制定對應的成本優化目標。針對云

22、原生場景，云上資源成本優化不僅僅是對云資源規格、數量的調整，也包含了對業務的架構優化、以及通過彈性能力和資源混部等手段提升資源利用率。此階段的優化方案包括：2.2.2 成本優化提供可靠、便利、智能的優化方案正確評估應用容量，設置合適的資源請求通過動態調度解決資源碎片的問題，提高裝箱率回收業務波谷時的冗余，通過彈性和混部做到按需使用9三、最佳實踐本章內容將從成本洞察、成本優化、成本運營三個維度展開，結合企業實際落地情況提供成本管理的最佳實踐。幫助企業上云、云原生改造時兼顧成本優化，助力企業數字化轉型。成本洞察是成本管理的第一步，現有的 Kubernetes 集群中，只能看到資源的使用情況，而無法

23、分析和觀察更具體的成本維度的數據。成本洞察的重點在于從成本的角度觀察集群的成本使用情況，主要包含資源使用可視化、費用可視化，以及成本分配。3.1 成本洞察隨著云計算的發展，云上各種的產品和資源也是日益復雜，要想實現對成本的可視，那么必須要有專業的方案以及統一的標準對云成本進行定量、定價及采集，并對資源進行持續跟蹤，從而做到云成本使用心中有數，以下是實現成本采集及資源追蹤具體的要求：對各類公有云成本產品進行收集，并詳細記錄賬單情況。對企業私有云進行資源的定義、定價、計費、統計，然后對私有云成本使用情況賬單進行采集對企業資源使用情況進行持續追蹤，包括資源使用量、資源使用方式、資源利用率等。3.1.

24、1 成本采集及資源追蹤得益于云原生的發展，Kubernetes 周邊的生態已經相對完善。監控方面，Prometheus 和 Grafana 的組合已經成為了云原生領域監控的標準。成本的管理實際上就是資源的使用管理，如何快速并且準確的識別出資源的分配、消耗、以及浪費，是成本優化的前提條件。因此成本洞察首先要做到的是資源消耗和資源利用率的可視化，這里舉幾個資源使用情況可視化的例子：展示業務的資源分配、消耗，資源使用效率分析 Top10 資源消耗的業務，分析 Top10 資源利用率低的業務展示資源消耗的走勢圖展示不同維度的資源使用情況，包含 Kubernetes 概念的維度：例如命名空間、工作負載、

25、Pod 等；也包含用戶自定義的維度：例如部門、組織、團體、項目等3.1.2 資源使用可視化10成本分配是一件很有挑戰的事情，不同的團隊關心的成本角度是不一樣的，比如：對于開發來說，他們希望能夠區分開發環境的成本和生產環境的成本。對于管理著來說，想知道到底是什么業務驅動了成本的上漲，即時發現不合理的商業邏輯。云原生成本分配標簽設計原則Kubernetes 的成本分配比傳統的云環境面臨更多挑戰，團隊需要定義一致的標簽和命名空間來改善分配，精確分配資源成本是在 Kubernetes 環境中創建成本可見性和實現高效成本利用的首要步驟。以下是成本分配的建議：明確業務云資源費用類型企業往往選擇公共的 IT

26、 團隊來支付云費用，公共的 IT 團隊再將成本分配給業務部門或業務應用的所有者。假如在共享 Kubernetes 集群上運行不同業務團隊的工作負載，通過云廠商本身的費用賬單再分配就變得非常困難。所以，成本分配的第一步是梳理并明確共享的資源有哪些，如計算資源、存儲資源、網絡資源、云廠商的 PaaS 服務如日志等等。云原生架構業務標簽配置理清楚共享成本類型之后，就要建立可持續的公平分配的方法?；谠圃軜?，用戶可以為云上運行的應用添加標簽來標識資源的所有者。建立合理的標簽模型是成本分配最為關鍵的一個步驟。3.1.4 成本分配在獲取資源實際用量后，對接云資源計費系統獲取資源單價，即可計算出云資源的

27、實際使用費用。相比資源用量可視化，費用視角的可視化是企業財務和采購角色更關注的視角，他們更加關注費用支出的合理性、費用歸屬是否明確等等，提升資源利用率的本質就是控制和減少費用支出，從而節約成本。3.1.3 費用可視化下面展示費用可視化的日常應用場景：分析集群的下月預估成本，分析每個資源對象的下月預估成本查看集群成本曲線查看業務增長曲線和成本曲線對比，評估成本增長是否過快根據推薦的方案預估的成本節省，為執行動作做成本角度的建議多維度的成本觀測：從計算資源維度以及用戶自定義的業務維度多周期的觀測：支持不同時長的周期定義，如日、周、月、或由用戶自定義保存歷史重要數據，定期生成報告，回顧和對比11標簽

28、的設計盡量易讀，并且要保證簡化，滿足業務訴求即可。用戶應該能直接從標簽讀懂其含義，但又不能設計得過于冗長。另外，簡化的同時也要保證標簽一致性，如果一個團隊使用“prod”的標簽值，而另一個團隊使用“production”，這些標簽的分組方式會有所不同。成本的標記也有多種方式，例如騰訊云提供標簽幫助云用戶有效分隔不同的云資源，此外還有多層級的 CAM（Cloud Access Management，騰訊云訪問管理）賬戶結構、項目等功能幫助有效分類不同的成本。資源標簽是云用戶分類云資源的有效手段，不同云用戶對標簽的使用不盡相同，云服務商對標簽的語法限制、字符集和長度等合法性進行校驗。這種極大的靈活

29、性會讓云用戶有相同的疑問，到底該如何定義標簽呢？易讀簡化且一致采用標準化命名格式，使后續的 API 集成更加便捷。例如：統一用英文小寫，單詞之間用下劃線隔開。值得注意的是：您可能開始使用“R&D”標記資源，但后來意識到某些服務不支持&字符，因此命名盡量考慮使用最通用標準的方式，例如此時應該使用 r_and_d。命名標準化如果還是不確定如何設置標簽，這里有一個使用標簽的最佳實踐：最佳實踐獲得較好的成本分配方式的關鍵是：盡早且始終如一的執行某種分配策略。例如在月初創建一個資源，到月底才打標簽，那有一個月的成本沒有分配。標簽設置的策略也應該盡早進行，也應該盡量保證始終如一的執行下去，否則每次標簽的改

30、動實際上都會導致歷史數據的丟失。越早越好該原則應該明確如何定義標簽的鍵，以及標簽可能包含的適當值，這些鍵值對將應用于所有資源。工程師開始開發應用程序之前，就應該將標簽定義原則傳達給工程師以確保良好的標簽覆蓋率。雖然許多公司有很多沒有被標記的存量業務，但不必擔心，梳理業務標簽為時未晚。標簽標準在開始制定時越深思熟慮，未來修訂的可能性就越小。隨著企業在云上的擴展，它將產生數千甚至數百萬個資源，每個資源都有自己的標簽，更改標記策略意味著團隊必須更新所有這些資源。標簽定義原則標簽原則不應該強迫團隊應用太多標簽。要求過多的標簽只會導致對標準的抵觸，從而導致不合規。最好只針對所需的核心元數據要求標簽。與其

31、根據需要定義所有標簽，不如定義可選標簽，明確描述團隊在選擇這樣做時應如何實施它們。選擇正確數量的標簽12一個成本中心/業務標簽，它清楚地定義了資源成本應在組織的位置。是屬于固定的、集的成本中心？還是單獨計算某種業務的具體成本？例如：可以設置類似 cost_allocation=cost_center 或 cost_al-location=business 的標簽標識資源屬于哪個服務，允許組織區分團隊正在運行的服務之間的成本。是訂單服務的成本？還是物流服務的成本？例如：可以設置類似 business_type=order 或 business_type=logistics 的標簽資源所有者標簽，

32、用于幫助識別負責資源的個人/團隊。例如：可以設置類似 resource_owner=xiao-ming 或 resource_owner=wechat 的標簽資源名稱標簽，可以理解成自定義資源名稱。例如云廠商定義的云服務器的名字為 CVM，某個實例名為 ins-dfkjdkd，為了方便資源的統計，可以給這些云資源加上一個 cloud_resource=computer 的標簽，表明這是個計算資源幫助確定開發、測試和生產之間的成本差異的環境標簽。例如：可以設置類似 environment=devel-opment 或 environment=production 的標簽用于標識資源所屬的服務層部

33、分的層標簽（例如，前端、網絡、后端）。例如：可以設置類似 service_layer=frontend 或 service_layer=backend 的標簽云賬單是企業獲得成本支出的第一手資料，賬單的可讀性往往影響到企業對成本開支的判斷，一個完備的云賬單體系應滿足各部門精細化的需求，能摸清各種云產品的支出情況，并能及時給到部門或組織反饋。因此對于企業的云賬單體系要提高管理水平，幫助企業提高賬單分析的效率，使賬單更好地服務于企業，以下幾個方面是賬單管理的落實步驟：3.1.5 賬單管理對企業賬單按云產品維度進行賬單的拆分。對企業賬單按組織、部門、項目等業務維度進行賬單的拆分。對企業賬單按包年、包

34、月等周期維度進行賬單的拆分。對企業賬單按自定義維度進行賬單拆分。對企業賬單的使用情況進行分析，包括過去支出、浪費情況，未來支出趨勢，優化建議等方面。提供業務維度包括組織、部門、項目等方面的賬單推送。提供周期維度包括年度、季度、月度等方面的賬單推送。13理想情況下，業務應該根據實際情況，設置合理的 Resource Request 和 Limit。Request 用于對資源的占位，表示容器至少可以獲得的資源；Limit 用于對資源的限制，表示容器至多可以獲得的資源。這樣的設置有利于容器的健康運行，資源的充分使用。此外，當多個團隊將業務部署到同一個共享集群以后，每個團隊都傾向將自己容器的 Reso

35、urce Request 和 Limit 設置得很高，以保證自己負責的業務的穩定性。如果你使用的是騰訊云容器服務 TKE（Tencent Kubernetes Engine，簡稱TKE）的控制臺，創建負載時會給所有的容器設置如下默認值。CPU（核）Request0.25256Limit0.51024CPU（核）設想你是個集群管理員，現在有四個業務部門使用同一個集群，你的責任是保證業務穩定性的前提下，讓業務真正做到資源的按需使用。為了有效提升集群整體的資源利用率，這時就需要限制各業務使用資源的上限，以及通過一些默認值防止業務過量使用。3.2.1 設置合理的資源請求和限制有了完整的成本洞察能力后，

36、即可查看企業整體成本效率。企業進而能夠圍繞其業務目標及業務場景制定對應的優化方案，本小節將具體介紹成本優化的最佳實踐。我們再回顧下前文分析的資源浪費的常見現象：主要資源優化方向包括：正確評估應用容量，設置合適的資源請求通過動態調度解決資源碎片的問題，提高裝箱率回收業務波谷時的冗余，通過彈性做到按需使用對應用進行混部，做到分時復用針對 GPU 資源，實現資源的池化和共享3.2 成本優化應用設置了過大的資源配額應用波峰波谷明顯，波谷時資源浪費嚴重存在不同類型的業務，對資源要求不同14資源需求是 Kubernetes Pod 中容器定義的可選屬性，用戶可以不為 Pod 設置資源Request 和 L

37、imit，也可以將值設置得很大。集群管理員可以為不同的業務設置不同資源使用默認值以及范圍，這可以有效減少業務創建時的工作量同時，限制業務對資源的過度侵占。Limit Range 適用于一個命名空間下的單個容器，可以防止用戶在命名空間內創建對資源申請過小或過大容器；當用戶不設置容器資源需求時，Limit Range 可為容器添加默認資源。Limit Ranges 主要作用于如下方面：計算資源：對所有容器設置 CPU 和內存使用量的范圍存儲資源：對所有 PVC 能申請的存儲空間的范圍比例設置：控制一種資源 Request 和 Limit 之間比例默認值：對所有容器設置默認的 Request/Lim

38、it，如果容器未指定自己的內存請求和限制，將為它指定默認的內存請求和限制使用Limit Range限制資源為了更細粒度的劃分和管理資源，可以在騰訊云容器服務 TKE 上設置命名空間級別的 Resource Quota 以及 Limit Ranges。如果你管理的某個集群有四個業務，為了實現業務間的隔離和資源的限制，你可以利用命名空間和資源配額。命名空間是 Kubernetes 集群里面的一個隔離分區，一個集群里面通常包含多個命名空間，資源配額用于設置命名空間資源的使用配額。例如 Kubernetes 用戶可將不同的業務部署在不同的命名空間里，再為不同的命名空間設置不同的資源配額，以限制一個命名

39、空間對集群整體資源的使用量，達到預分配和限制的效果。資源配額主要作用于如下方面，詳細信息可查看2。計算資源：所有容器對 CPU 和 內存的 Request 以及 Limit 的總和存儲資源：所有 PVC 的存儲資源請求總和對象數量：PVC/Service/Configmap/Deployment 等資源對象數量的總和使用資源配額（Resource Quota）劃分資源資源配額使用場景給不同的項目/團隊/業務分配不同的命名空間，通過設置每個命名空間資源的資源配額以達到資源分配的目的設置一個命名空間的資源使用數量的上限以提高集群的穩定性，防止一個命名空間對資源的過度侵占和消耗15即使有了資源配額和

40、 Limit Range 設置，多業務視角的資源調配依然無法做到靈活多變。例如，當用戶的業務負載提升，確實需要較多資源時，配額的限制會阻止快速擴容。配額的分配通常需要申請和審批流程，這限制了彈性和創新速度。并且，資源配額限制的是同一個命名空間的應用實例，當一個命名空間里存在多個工作負載時，工作負載之間也會發生資源搶占，導致某些負載資源使用受限。Limit Range 的作用范圍也是針對一個命名空間下的所有業務實例，而同一命名空間里可能存在主業務容器也會存在輔助容器，如果都設置成固定的大小值也會造成資源浪費或不夠的現象。因此不管是資源配額，還是 Limit Ranges，它們的限制范圍都是命名空

41、間級別，粒度較粗。圖 9 是一個實際生產集群的資源使用情況，該集群的 CPU 總量為 1906 核，CPU 的分配率接近 60%，即集群中所有容器的 CPU Request 之和占集群 CPU 總量的 60%（CPU 申請量）。但實際集群中所有容器的 CPU 使用量之和僅為 13.4 核，CPU總體利用率不到 0.8%，CPU 的利用率非常低。出現這種現象的根本原因在于容器的 Request 設置不合理，Request 的設置占集群整體資源的 60%，而實際使用量僅占不到 0.8%。Request 和 Usage 之間存在較大的優化空間。智能 Request 推薦設置資源使用默認值，以防用戶遺

42、漏，也可以避免 QoS 驅逐重要的 Pod將不同特征的業務部署在不同的命名空間中，且為不同命名空間設置不同的Limit Range可在一定程度上提升資源利用率限制容器對資源使用的上下限，保證容器正常運行的情況下，限制其請求過多資源Limit Range使用場景Request 的設置基于云用戶對業務負載的深刻理解，不同業務的 Request 設置各不相同，并且同一業務在不同時間段的 Request 設置也應該隨業務負載波動及時調整。業務部門通常習慣將 Request 設置較大，以鎖定資源保證業務工作負載的穩定性。但從圖 9 可以看出，即使設置使用量十倍的冗余，集群總體核數也僅需要 134 核左右

43、，但實際用戶的 Request 為 1906*60%=1143 核。圖9 某生產集群的資源分配和實際用量16智能 Request 推薦基于業務的實際資源使用情況，給用戶推薦更合理的 Requst 數值，且可以自定義冗余倍數，避免因為流量突發導致的業務不穩定性。配合上彈性集群能力（Cluster Autoscaler），可以在負載低谷期及時縮減集群的整體規模，以達到降本的目的。以圖 9 為例，CPU 的實際使用量細節如圖 10 所示，沒有超過 40 核，即使設置十倍的 Requst 的冗余，此時集群規模僅需 400 核，相較之前的 1906 核，使用智能推薦的 Request 將節?。?906-

44、400）/1906=79%。若某個 CPU 密集型業務實例，被調度到內存密集型的節點上，導致內存密集型的 CPU 被占滿，但內存幾乎沒怎么用，會造成較大的資源浪費。如果能為此類節點設置一個標記，標明該類節點是 CPU 密集型，隨后在創建業務負載時也設置一個標記，標明這個負載需要在CPU密集型節點運行。Kuberne-tes 的調度器會將這個負載調度到 CPU 密集型的節點上，這種尋找最合適的節點的方式，將有效提升資源利用率。3.2.2 動態調度圖10 某生產集群的CPU實際用量細節節點親和性動態調度（負載感知）原生的 Kubernetes 調度策略傾向于調度 Pod 到節點剩余資源較多的節點上

45、，比如默認的 LeastRe-questedPriority 策略。但是原生調度策略的資源分配是靜態的，Request 不能代表資源真實使用情況，因此當業務負載降低時，Kubernetes 調度器的可用資源與集群的實際閑置資源會有較大偏差。如果調度器可以基于節點的實際資源利用率進行調度，將一定程度上解決資源浪費的問題。騰訊云容器服務TKE自研的動態調度器所做的就是這樣的工作。動態調度器的核心原理如下圖 11 所示：節點親和性非常適合在一個集群中有不同資源需求的工作負載同時運行的場景。比如說，騰訊云的云虛擬機（CVM節點）有 CPU 密集型，也有內存密集型。如果某些業務對 CPU 的需求遠大于內

46、存，此時使用普通的 CVM 機器，勢必會對內存造成較大浪費。此時可以在集群里添加一批 CPU 密集型的 CVM，并且把這些對 CPU 有較高需求的 Pod 調度到這些 CVM 上，這樣可以提升 CVM 資源的整體利用率。同理，還可以在集群中管理異構節點（比如 GPU 機器），在需要 GPU 資源的工作負載中指定需要 GPU 資源的量，調度機制則會幫助你尋找合適的節點去運行這些工作負載。節點親和性使用場景17圖12 重調度器和動態調度器的關系除了降低資源浪費，動態調度器還可以很好的緩解集群調度熱點的問題。動態調度器會統計過去一段時間調度到節點的 Pod 數目，避免往同一節點上調度過多的 Pod動

47、態調度器支持設置節點負載閾值，在調度階段過濾掉超過閾值的節點在企業的運維工作中，除了成本，系統的穩定性也是十分重要的指標。如何在兩者間達到平衡，可能是很多運維人員心中的“痛點”。一方面，為了降低成本，資源利用率當然是越高越好，但是資源利用率達到一定水位后，負載過高極有可能導致節點資源過載而觸發的主動驅離或因 CPU 競爭導致的業務指標抖動等問題。為了減小企業成本控制之路上的顧慮，騰訊云容器服務 TKE 還提供了“兜底神器”重調度器 來保障集群負載水位在可控范圍內。重調度器是動態調度器是一對好搭檔，它們的關系可以參考下圖 12，就像它的名字一樣，它主要負責“保護”節點中已經負載比較“危險”的節點

48、，優雅驅逐這些節點上的業務。圖11 動態調度器動態調度器的使用場景重調度18以游戲服務為例，從周五晚上到周日晚上，游戲玩家數量暴增。如果可以將游戲服務器在星期五晚上前擴大規模，并在星期日晚上后縮放為原始規模，則可以為玩家提供更好的體驗。如果使用 HPA，可能因為擴容速度不夠快導致服務受影響。HPC 使用場景Kubernetes Pod 垂直自動擴縮（Vertical Pod Autoscaler，以下簡稱 VPA）可以自動調整 Pod 的 CPU 和內存預留，幫助提高集群資源利用率并釋放 CPU 和內存供其它 Pod 使用。相較于水平自動伸縮功能 HPA，VPA 具有以下優勢：VPA 擴容不需

49、要調整 Pod 副本數量，擴容速度更快。VPA 可為有狀態應用實現擴容，HPA 則不適合有狀態應用的水平擴容。Request 設置過大，使用 HPA 水平縮容至一個 Pod 時集群資源利用率仍然很低，此時可以通過 VPA 進行垂直縮容提高集群資源利用率。通過 VerticalPodAutoscaler 垂直擴縮容如果你的業務是存在波峰波谷的，固定的資源 Request 注定在波谷時會造成資源浪費，針對這樣的場景，如果波峰的時候可以自動增加業務負載的副本數量，波谷的時候可以自動減少業務負載的副本數量，將有效提升資源整體利用率。HPA（Horizontal Pod Autoscaler）可以基于一

50、些指標（例如 CPU、內存的利用率）自動擴縮 Deployment 和 StatefulSet 中的 Pod 副本的數量，達到工作負載穩定的目的，真正做到按需使用。3.2.3 多維度彈性通過 HorizontalPodAutoscaler 按指標彈性擴縮容流量突發：突然流量增加，負載過載時會自動增加 Pod 數量以及時響應自動縮容：流量較少時，負載對資源的利用率過低時會自動減少 Pod 的數量以避免浪費假設你的業務是電商平臺，雙十一要進行促銷活動，這時可以考慮使用 HPA 自動擴縮容。但是 HPA 需要先監控各項指標后，再進行反應，可能擴容速度不夠快，無法及時承載高流量。針對這種有預期的流量暴

51、增，如果能提前發生副本擴容，將有效承載流量井噴。HPC（HorizontalPodCronscaler）是騰訊云容器服務 TKE 自研組件，旨在定時控制副本數量，以達到提前擴縮容、和提前觸發動態擴容時資源不足的影響，相較社區的 CronHPA，額外支持：與 HPA 結合：可以實現定時開啟和關閉 HPA，讓你的業務在高峰時更彈性例外日期設置：業務的流量不太可能永遠都是規律的，設置例外日期可以減少手工調整 HPC單次執行：以往的 CronHPA 都是永久執行，類似 Cronjob，單次執行可以更靈活的應對大促場景通過 HorizontalPodCronscaler 定時擴縮容HPA 使用場景19圖

52、13 ClusterAutoscaler 原理VPA 自動伸縮特性使容器服務具有非常靈活的自適應能力。應對業務負載急劇飆升的情況，VPA 能夠在用戶設定范圍內快速擴大容器的 Request。在業務負載變小的情況下，VPA 可根據實際情況適當縮小 Request 節省計算資源。整個過程自動化無須人為干預，適用于需要快速擴容、有狀態應用擴容等場景。此外，VPA 可用于向用戶推薦更合理的 Request，在保證容器有足夠使用的資源的情況下，提升容器的資源利用率。上面提到的 HPA 和 HPC，都是在業務負載層面的自動擴縮副本數量，以靈活應對流量的波峰波谷，提升資源利用率。但是對于集群整體而言，資源總

53、數是固定的，HPA 和 HPC 只是讓集群有更多空余的資源，是否有一種方法，能在集群整體較“空”時回收部分資源，能在集群整體較“滿”時擴充集群整體資源？因為集群整體資源的使用量直接決定了賬單費用，這種集群級別的彈性擴縮將真正節省使用成本。如圖 13 所示，CA（Cluster Autoscaler）用于自動擴縮集群節點數量，以真正實現資源利用率的提升，并直接作用于用戶的費用，是降本增效的關鍵。VPA 使用場景通過 ClusterAutoscaler 自動調整節點數量在業務波峰時，根據業務突增的負載擴容合適的節點在業務波谷時，根據資源的空閑情況釋放多余的節點CA 使用場景20圖14 在虛擬節點部

54、署業務虛擬節點并不是節點，而是一種調度能力，支持將標準 Kubernetes 集群中的 Pod 調度到集群服務器節點之外的資源中。騰訊云容器服務的虛擬節點會將開啟該功能的集群中，符合調度條件的 Pod 調度到由彈性容器服務維護的云上計算資源中。部署在虛擬節點上的 Pod 具備云服務器一致的安全隔離性，具備與部署在集群既有節點上的 Pod 一致的網絡隔離性、網絡連通性，如圖 14 所示。通過虛擬節點獲得 Serverless 能力圖 15 展示了虛擬節點與普通 Kubernetes 集群擴縮容的耗時對比，從中可以看出，虛擬節點的擴容比節點的創建流程更快，有效應對流量突發場景；虛擬節點瞬時縮容，有

55、效避免浪費。圖15 普通 Kubernetes 集群與支持虛擬節點的 Kubernetes 集群擴縮容對比21減少集群資源 buffer，應對長期運行服務波峰虛擬節點可以不占用集群服務器節點資源，快速的部署大量 Pod。適用于長期運行且資源負載特征為潮汐型的應用。使用虛擬節點可以減少集群預留 buffer，將集群的節點維護在資源利用率更高、使用和預留更合理的水平。在業務波峰進行擴容時會自動的優先調度到節點上，消耗預留的節點資源，再調度到虛擬節點上為集群補充更多的臨時資源，這些資源會隨著 Pod 縮容自動退還。適合將短時間運行、資源需求量大的任務，手動調度到虛擬節點上。無需在部署這些負載前后進行

56、集群節點的擴縮容，降低了擴縮節點的時間周期和維護成本?？梢栽诓渴疬@些任務的時候，指定虛擬節點進行調度，就不會占用集群其他服務運行的節點資源。且任務運行結束 Pod 退出會自動退還資源并停止計費，不需要人力或程序再干預。虛擬節點使用場景替代節點擴縮容，應對短期運行任務競價實例（Spot Instance）是云服務器 CVM 的一種新實例運作模式，它最核心的特點是折扣售賣和系統中斷機制。但正如它的名字一樣，您和其他同時使用競價實例的用戶存在一定的競爭關系。在特定場景下，實例可能會被回收，我們官方將這種回收定義為系統主動中斷（庫存波動）。當前階段，在騰訊云的競價實例模型下，僅會因為競價實例資源池庫存

57、不足而產生中斷。資源管控系統會自動根據實時庫存變化回收這些折扣售賣的實例。當您成功購買一個競價實例后，它的使用和按量計費的 CVM 實例基本毫無區別，包括控制臺操作、遠程登錄、服務部署、關聯 VPC 等。在豐富的實踐與探索中，我們發現，Spot 非常適合容器、無狀態服務、CI/CD、強化學習、離線轉碼、大數據分析等具有容錯能力的業務應用，尤其是基于云原生框架構建的應用，在這些場景下可以在巨幅降低成本（80%以上）的前提下，保證業務的穩定性。競價實例使用場景競價實例提高集群資源利用率有幾種方式，一是集群本身合理配置應用申請資源，盡量運行更多的作業。二是在波谷時段填充其他作業，運行更多的作業。第一

58、種方式適合不同類型的應用混部，應用之間資源互補，高峰時段錯開。若是同種類型的應用，應用都在同一時段處于高峰，這種情況適合第二種方式。本節主要闡述基于方式二的混部，即在線離線混部。3.2.4 在離線混部混部概念22在線離線混部是通過在在線作業運行過程中填充離線作業，來提高資源利用率。離線任務不能無限填充，需要保證在線作業不受影響，保證其 SLO 在可接受范圍內，同時離線作業要能快速上線下線，當在線作業需要資源的時候，及時出讓。另外，離線運行起來之后，還要保證離線作業的成功率，不能因為頻繁出讓資源，而導致失敗率很高?；觳扛拍钪袑妙愋头譃樵诰€作業和離線作業，混部要解決的問題是如何通過填充離線作業

59、把集群各個時段的在線空閑資源利用起來。集群每個時段的空閑資源會發生變化，這就要求離線作業要快速上線下線。那什么樣的作業適合混部？在線作業特點包括但不限于運行時間長，有很強的時延敏感型，資源潮汐現象，如廣告業務。而離線作業的特點包括但不限于運行時間短、計算需求大、容錯率高、時延不敏感，允許重運行，典型的是 Hadoop 生態下的 MapReduce、Spark 作業。結合一些實際的混部場景：例如在線應用分為兩類，容器化和非容器化的。容器化的應用有基于 Kubernetes 和 Mesos 的。離線場景主要也有兩類，分別是 Hadoop 類的大數據，以及基于 Kuber-netes 的各種離線應用

60、慮。由于場景比較多，混部也確定了兩個主要目標：在保證服務質量的前提下，盡可能提升資源使用率。技術路線有幾個原則：一是通用技術，方便開放到社區。二是要符合云原生使用方式，第三，降低對應用的依賴，不能引入太多假設，也要兼容主要生態?；觳繄鼍皥D16 混部場景23設計以 Kubernetes 為依托，實現了以下關鍵技術，如：（1）任務定級：制定了任務級別標準，用于對應不同優先級資源。（2）調度增強：因離線任務量大，運行時間短，原生的 Kubernetes 調度器無法滿足大批量需求，同時也缺少一些批量調度特性，如 gang scheduling?；诖嗽黾右粋€批量調度器，跟原生調度器并行，通過一個協調器

61、進行協調，防止資源被重復調度。（3）資源復用：每個 Kubernetes 的 kubelet 節點通過 daemonset 部署一個 agent 組件，用于實現負載預測、閑置資源回收、離線資源配額分配和資源隔離等功能。（4）資源畫像：預測在線作業的各類資源使用情況，指導離線作業調度和隔離。（5）存算分離：通過 Ceph 或騰訊云云硬盤CBS（Cloud Block Storage，簡稱CBS）分布式存儲技術，解決離線作業需要大量存儲空間及磁盤 IO 問題。（6）任務避讓：解決節點負載不均衡問題，重新調度離線作業到低負載節點和實現負載升高按優先級驅逐任務功能。（7）干擾檢測：分析在線作業的時延數

62、據，如本身暴露的時延指標、CPI 數據或硬件指標數據，來判斷在線作業是否受影響?；觳考軜嬺v訊數據平臺部通過多年大規模資源調度的研究，設計了如圖 17 所示的在線離線混部架構：圖17 在離線混部架構24GPU 共享包含兩個關鍵技術點：精細調度與 GPU 隔離。前者在保證業務負載可被調度到同一張 GPU 卡上的同時，通過諸如 binpack、spread 或負載感知等調度策略，保證負載按照要求分布。亦或者依賴 GPU 拓撲感知調度，將一批負載親和到同一 GPU 拓撲上，保證之間計算和數據傳輸的最大性能。而后者則保證在共享 GPU 資源時，業務互相之間不受干擾，這也是維持業務穩定性的關鍵所在。GPU

63、 資源包括算力和顯存，對這兩種資源均需提供強有力的 QoS 保障和完全的隔離能力。只有如此，才能使得 GPU 共享帶來的利用率提升產生的價值最大化。如圖 19 所示，騰訊云TKE qGPU 滿足的正是這樣的場景。你可以通過安裝該產品在騰訊云容器服務TKE 集群上創建 qGPU 節點池，并在創建負載時指定 qGPU 算力與顯存。TKE qGPU 會幫助你將負載調度到同一張 GPU 卡上，并同時提供算力和顯存的強隔離。GPU 利用率會隨著共享技術有質的提升，你也無需擔心共享帶來的資源競爭會損害業務。隨著機器學習的不斷發展，使用 GPU 提供的并行算力已經非常普遍。很多廠商基于 Kubernetes

64、平臺，將應用容器化，并使用 GPU 資源，但是通常都是將一張完整的 GPU 卡分配給一個 Kubernetes Pod。對于某些場景，比如深度學習模型訓練，這種分配方式可以提供比較好的隔離性，單卡的利用率也可維持一個不錯的水準。但對于模型開發和模型推理則會比較浪費。隨著 GPU 卡越來越多，獨占 GPU 卡帶來的資源浪費會越來越嚴重。大家的訴求很自然的會想到將更多推理服務共享同一張 GPU 卡，進而提高集群 GPU 利用率，正如圖 18 所示。3.2.5 GPU 共享圖18 GPU共享25圖19 TKE qGPU26云成本優化并非是通過一系列標準動作后得出的一個終態恒定值，而是一個持續迭代和優

65、化的過程。很多企業做成本優化都是項目制，做完項目后效果很好，但是很快反彈了。所以我們需要從組織、文化、流程等方面建設成本運營體系，這已經成為業界共識，FinOps 應運而生?！癋inOps 是云的運營模式。FinOps 實現了一種轉變系統、最佳實踐和文化的組合以提高組織了解云成本和進行權衡的能力。與 DevOps 通過打破孤島和提高敏捷性來徹底改變開發的方式相同，FinOps 通過將技術、業務和財務專業人士與一組新流程聚集在一起來增加云的業務價值?！鄙厦娴恼鹿澑攀隽顺杀緝灮母鞣N手段，那么在何種場景下應該用何種技術手段，每種手段的效果和實現難度如何評估呢？我們將這些能力歸入四個象限，橫坐標為成

66、本，縱坐標為難度，如圖 20 所示。3.2.6 優化矩陣圖20 優化方案的難度和效果注釋：(EKS，騰訊云彈性容器服務 Elastic Kubernetes Service)FinOps 基金會的定義很好的涵蓋了它的本質：3.3 成本運營27我們結合 FinOps 和客戶實踐整理了成本運營五大關鍵步驟：建立一個成本優化團隊，它可以是一個現有的個人或者團隊，也可以是整個組織中由財務、技術和業務利益相關者組成的新團隊。他們負責在團隊里宣傳成本意識的文化，確定成本優化的方向，推動成本優化的最佳實踐，協調整個組織的成本優化工作。比如，可以定期舉行成本優化會議，回顧和復盤成本管理中遇到的一些問題，從而推

67、動持續改進。此團隊需要采取多學科方法，并具備項目管理、數據科學、財務分析和軟件/基礎設施開發的能力。他們可以執行成本優化（集中式方法）、影響技術團隊執行優化（分散式）或將兩者相結合（混合式），從而推進完成成本優化的目標?？梢詫φ粘杀緝灮繕耍ɡ缳Y源利用率）來衡量團隊的執行和交付能力。同時必須確保團隊獲得高級管理層的支持。支持者即成本優化理念的倡導者，他們會為此部門提供升級支持，確保按組織確定的優先級開展成本優化活動。此部門及其支持者會共同確保組織在有效利用云資源并繼續創造業務價值。3.3.1 建立成本優化團隊成本意識是指節約成本和控制成本的觀念，成本管理需要大家共同參與，只有團隊具備了良好的

68、成本意識，才能建立降低成本的主動性，才能讓各種成本優化的舉措、方法和要求得以很好的貫徹和執行。提高全員的成本意識是較長時期的任務，我們需要營造有利于提高成本意識的氛圍和推動成本意識的管理?？梢杂腥缦路绞酵苿映杀疽庾R文化：在培訓中強調成本的重要性和控制成本的必要性建立激勵機制，比如通過紅黑榜的方式讓業務團隊之間進行競爭，對于成本管理做的好給予一定獎勵，對于做的差的要定期復盤，確定后面的改進方向和舉措，也可以運用一些 KPI 手段來進行管理，讓員工意識到成本管理的嚴肅性。積極倡導成本是企業的核心競爭力，成本優化能夠帶來真正意義上的商業價值。3.3.2 推動成本意識文化建立成本優化團隊推動成本優化意

69、識數據驅動成本優化在流程中考慮成本量化成本優化交付的業務價值28所有成本優化都是由指標驅動的，所有指標都需要可實現的目標。數據驅動是指將采集的數據有效組織，并對相關的信息進行整合和提煉，在數據的基礎上經過訓練和擬合形成自動化的決策模型。對應到云原生成本運營，同樣適用，企業的IT團隊往往會制定驅動團隊成本優化的指標，通常是 CPU/內存使用率。還有更精細的如閑置的存儲資源、閑置的 IP 資源、無用的快照、無用的云盤等等。通過設立目標來制定團隊成本運營的指引方向。需要注意的是：目標是可衡量的，能夠驅動團隊采取下一步行動的，目標會受多方面的因素影響，明確目標之后就是要建立能夠準確獲取當前值與目標值的

70、差距的途徑，并能夠持續的觀察當前值的變化，通過不斷優化問題，做出正向的反饋，逐步靠近并達到目標值，進而制定下一階段的目標。具體的落地可以借助云廠商或開源社區提供的各種可觀測性儀表盤，目前行業內的儀表盤的能力能夠覆蓋90%以上的場景，如果需要更精細化且結合業務的數據，則需要企業自身投入研發。3.3.3 數據驅動成本優化在新的和現有的組織流程中建立成本意識，需要在軟件生命周期全過程中去考慮成本，可以包括以下方案：成本優化左移（DevFinOps），通過工具或者自動化加快成本優化，工程師在架構設計時需要考慮成本指標，保證能夠和業務目標保持一致。確保變更管理包含成本度量，以量化變更對成本的影響，這樣有

71、助于解決與成本相關的問題。成本優化是運維或者說運營能力的核心組成部分；例如我們可以采用目前的故障管理流程來調查和確定成本管理異常的根本原因。在組織中開展成本意識的培訓和認證，有助于建立自我管理成本的組織。3.3.4 在流程中考慮成本由于成本優化是一項必要的投資，因此量化業務價值之后，您就可以向利益相關者說明投資回報。如果能夠量化業務價值，在未來的成本優化投資中，就可以從利益相關者那里得到更多支持，并獲得一個框架來衡量組織成本優化活動的成果。3.3.5 量化成本優化交付的業務價值29這里有個單位經濟學的概念，成本優化的最終目標是將成本追溯到業務收益，這不是在云上花費的美元，而是每次預訂、每可用座

72、位里程、每張機票、每筆客戶交易、每百萬活躍用戶所花費的美元。如果云成本在 6 個月內從 100 萬上升到 200 萬是不是很糟糕？如果我的商品訂單數在那段時間內翻了一番怎么辦？那么它是中性的。如果我的商品訂單數在那段時間內增加了三倍怎么辦？然后，我們只漲了 100 萬就是非常好的一個成本優化的結果。30四、總結云原生底層的 Kubernetes 平臺采用資源預留機制來管理容器可用資源，為避免因資源過小影響服務的可靠性，用戶通常會預留遠大于實際使用量的資源，導致大量資源浪費。部分業務流量存在波峰波谷，如果資源固定設置為波峰時期的需求量，那么波谷時資源利用率就會很低，長時間的低資源利用率也會導致資

73、源浪費。不同類型的業務對資源的需求不同，如果不考慮業務資源需求的互補性，只針對單一業務配置資源，將很難實現總體資源利用率的最優化。云原生平臺底層資源共享、應用動態部署，底層云資源與應用無法一一對應，很難進行準確的成本觀測，從而很難精準定位到成本浪費的根源。定位到問題根源后，選擇成本優化的路徑需要綜合考慮成本、性能、穩定性和業務價值等多方因素，既要有切實有效的優化能力又不能對現有架構引入新的風險。由于業務動態變化，有效的成本優化機制運行一段時間后容易失效，如何實現持續的成本優化又成為新的問題。一是成本采集及資源追蹤，需要針對復雜的云上資源提出統一的成本定量、定價和采集標準，并對資源進行持續跟蹤。

74、二是資源使用可視化，基于完善的云原生監測工具建立多維細粒度的資源利用率觀測體系。三是費用可視化，相比資源利用率企業運營更關注成本，需要建立合理的計量計費方法，將資源利率可視化轉換為費用可視化，并延展到費用歷史分析、趨勢預測等。四是成本分配，合理的資源標簽模型是建立可持續的公平的成本分配方法的關鍵。五是賬單管理，完備的云賬單體系應滿足各部門精細化的需求，能摸清各種云產品的支出情況，并能及時給到部門或組織反饋。成本優化方案需要圍繞企業業務目標及業務場景制定，包括五大措施。一是設置合理的資源請求和限制，通過更細粒度的資源劃分和管理，智能化的資源配額推薦和動態彈性伸縮，防止不同團隊為保證業務穩定性過度

75、侵占和消耗資源。二是動態調度，在調度應用時考慮業務資源利用類型與節點類型的匹配度、節點的真實負載，以及在應用部署后根據真實負載進行重調度。三是多維度彈性，通過靈活的負載、節點擴縮容策略應對多種業務負載波動。四是在離線混部，基于在離線業務對資源需求互補的特點，通過在在線作業運行過程中填充離線作業，來提高資源利用率。五是 GPU 共享，針對機器學習場景，通過精細調度與 GPU 隔離技術，在保證業務互不干擾的前提下實現推理服務共享同一張 GPU，大幅提升 GPU 利用率。資源配置不當是引起云原生成本浪費的主要原因云原生成本管理面臨問題難定位、路徑難選擇、成效難持續三大挑戰成本洞察是定位云原生成本管理問題的基礎成本優化是減少云原生成本浪費的有效路徑云原生成優化并不是成本管理的重點，因為成本優化的成效并不是恒定的，而是需要持續的迭代和優化。所以建立成熟的成運營體系才是成本管理的治本之法。成本運營包含五大關鍵步驟，包括建立成本優化團隊、推動成本優化意識、數據驅動成本優化、在流程中考慮成本、量化成本優化交付的業務價值。成功的云原生成本管理非一時之功，需要從組織、文化、流程等多個方面來共同推動。成本運營是實現云原生成本持續優化的長遠之道31