1、背景

隨著得物電商、社區業務迅速發展，云計算已成為支撐業務運行的關鍵基礎設施。然而，云計算的便利性和靈活性也帶來了一系列云成本管理挑戰，包括成本增速過快、成本歸屬不清晰、缺乏有效成本控制手段、對云廠商高度依賴等，因此云成本治理成為各公司的重要方向。作為快速發展中的互聯網公司，得物在業務增長的同時，開展了成本治理和FinOps項目落地工作，實現年度云成本節省上億元，成功抑制云成本的不合理上漲趨勢。

此次分享得物FinOps實踐經驗，希望能為讀者提供一些借鑒思路。

2、得物FinOps引入?

2.1   什么是FinOps？

FinOps 是“Finance”和“DevOps”的綜合體，強調運維過程中的成本管理和資源優化。

FinOps有一個權威組織，FinOps 基金會，該基金會是Linux 基金會發起的項目，致力于通過最佳實踐、教育和標準來推動實踐云財務管理學科。近年發展迅速，社區擁有超過 8,700 名成員，致力于解決云的爆炸式增長以及云成本管理挑戰。

在當今數字化轉型的重要時刻，FinOps不僅僅是一個將財務和技術結合起來的領域，而且是云計算的關鍵領域之一。通過FinOps，IT和財務部門可以更好地合作，實現更好的業務成果和財務可持續性。因此，越來越多的企業積極開展FinOps實踐項目，并跨過了他們在實踐中所面臨的壁壘，得物正是一家在FinOps實踐中持續探索的公司。

FinOps基金會對FinOps定義：

• FinOps是一種不斷發展的云財務管理學科和文化實踐，通過幫助工程、財務、技術和業務團隊在數據驅動的支出決策上進行協作，使組織能夠獲得最大的業務價值。
• FinOps的核心是一種文化實踐，通過跨職能團隊協同工作，以實現更快的產品交付，同時獲得更多的財務控制和可預測性。
• FinOps的特點是將問責制引入云支出，FinOps是財務責任文化變革帶入云的可變支出模型的實踐，使分布式工程和業務團隊能夠在其云架構和投資決策中的速度、成本和質量之間進行權衡。

FinOps成熟度模型：

FinOps Framework定義了關于FinOps 的“爬、走、跑”成熟度特征。

在落地FinOps實踐時，了解成熟度模型和指標可以幫助團隊準確評估其當前水平，發現改進點和推進方向。例如，對于初步實踐的團隊，最初的重點可能是尋找成本和資源的可視化方法，而更成熟的團隊則可能更加關注云開銷和預算分析、成本優化和分配、以及團隊間的協作和溝通等方面。

成熟度模型的應用，可以幫助企業實現可持續的FinOps成果，進而達到支出透明度和控制、優化云資源和實現最大化業務價值的目標。?

2.2   FinOps實踐路線

得物從2021年開始關注云成本效能。經過對FinOps體系深入研究，反復討論，持續了近2年的落地實踐，FinOps成熟度級別已逐步進入到 “跑” 階段。下文會介紹得物FinOps建設的歷程，以及各階段行動路徑，供讀者參考。

結合公司現狀，得物借鑒FinOps社區主推的成本洞察、成本優化、成本運營層層遞進，多管齊下的方式開展得物FinOps落地。按技術驅動、業務驅動、運營驅動三個方面來推動機制流轉。最終實現成本透明度和控制、優化云資源、并最大化業務價值。

3、得物FinOps構建歷程

3.1   FinOps - Inform(Visibility & Allocation)

成本可視化階段，FinOps基金會對企業云成本治理的第一步“爬”，就是需解決Inform(Visibility&Allocation) 可視化、賬單分攤的問題，這是FinOps之旅的第一階段，它賦予組織和團隊可視性、分配、基準、預算和預測能力，使其有必要為智能決策提供準確和及時的可見性。

得物從2021年開始打造基于多云環境的資管與成本運營平臺 - 成本中心，在這一階段，優先支持了成本數據分攤能力，分攤到部門、業務域。支持成本預測、預算管控、成本結算等功能。

3.1.1 成本分攤

在數據分析前需要進行著手的事情便是基礎數據匯聚。在這里不得不提得物CMDB系統，CMDB是一套自研的基礎資源管理平臺，涵蓋了云上、云下（IT資產）等資源管理。云上應用向下管理資源，向上掛在技術組織架構、業務域等不同維度，總體形成了一棵應用樹。以應用為中心，把組織架構部門/業務域、人、應用、資源關系串了起來。

成本中心通過對接云廠商、CMDB、發布系統、內部監控系統，獲取所有成本關聯數據。成本按實例賬單匯聚，實例級維度分攤到到業務域、組織架構、人。支持日、周、月維度成本數據和成本預測。數據分析方面則構建輕量化BI能力，滿足多維度分析，并輔助高層決策。

成本中心上線后帶來改進：

• 將成本按人頭歸屬后，研發成本意識得到提升，開始關注項目資源的利用率。
• 多維度的成本拆分：部門維度、產品維度、業務維度和場景維度。
• 支持成本預測，當月、下月各部門成本預測，便于提前規劃優化動作。

3.1.2 預算機制

得物技術部2022年開始云上預算管控流程，由成本管理團隊組織并推動預算管控體系的落地，包括目標責任體系、信息反饋系統、預算指標系統。

• 預算編制：以半年或季度為預算周期，設置總體目標和要求，逐級分解到部門/項目，落實到具體負責人；
• 預算執行：根據預算規劃業務，預算水位預警及工單審計聯動；
• 預算考核：對照設定的預算指標，總結預算執行情況、差異分析、歸因分析、改進措施，形成預算反饋報告。

實際執行中，業務發展存在并非完全沿著預算發展，因此得物采用的是固定預算+滾動預測相結合的方式，預算編制是自下而上的預算收集與審核，動態調度分配預算資源。

3.1.3 新增成本收口

成本新增管控：成本中心解決了存量成本可視化和治理閉環，對于新增資源申請，也要進行卡口，得物自研的窮奇審批平臺，可結合成本預估功能、預算體系，智能化生成資源申請審批流程，有效提高研發人員成本意識及對新增成本進行合理性評估。

所有資源的申請都要經過如下步驟：成本預估---->預算水平判斷----->智能審批節點生成。

• 成本預估：在資源申請階段，系統會自動進行成本預估，幫助研發人員更好地了解資源需求對成本的影響。
• 預算管理：可拉取部門預算水位，結合預估成本，綜合展示申請資源對于本部門預算影響。
• 智能審批節點：結合預算和成本預估、預算信息，工單系統會自動添加相應的審批節點，確保資源申請的合理性和合規性。

實施了上述治理措施，得物的FinOps實踐第一個難關得到解決，實現了能力的具備和實際應用。這些措施幫助得物更好地管理成本，提高資源使用效率，避免不必要的成本浪費，實現優化資源管理、提高效率、降低成本的目標。

3.2   FinOps - Optimize(Rates & Usage)

成本優化階段，按照FinOps落地要求，當具備成本賬單分攤和可視化后，得物在FinOps基金會定義的成熟度模型Maturity 中由“爬” 進入到“走” 階段。進入到Optimize階段，需要進行多維度考慮，包括云產品計費方式最優、商務折扣競爭力、技術降本（自研paas/彈性計算/多云等）、精細化成本運營（資源投入和業務收益的roi分析）等。

3.2.1 提升計算資源利用率

云服務器成本治理

云服務器ECS作為云上基礎設施，成本占比達第一，并隨著技術架構改造的深入，ECS成本占比會逐步增加，因此，提高ECS成本合理性是云成本治理的首要任務。主要推動以下內容：

• 計費模式優化：包年包月計費&按量計費擇優選擇
• 空跑或低利用率資源巡檢：制定不同巡檢規則、及時釋放閑置資源
• 服務器&&應用的完整生命周期管理：建立服務器或者應用的上下線管理制度確保不會出現死應用或者服務器

最終成果：

全站容器化

作為擁抱云原生不可或缺的一環，服務容器化的實踐將提高資源利用效率，加快部署速度，并確保應用程序在不同環境下的一致性和可重現性。得物自2021年開始，在KubeOne的基礎上建立了自己的容器平臺，啟動了全站容器化項目，成功完成了涉及數十個業務領域上千個應用的容器化改造，標志著得物容器化元年的開啟。該項目的完成大幅提高了資源利用率，整體資源利用率環比上升了10%。此外，硬件成本和管理成本也得到了降低，應用程序的可靠性和可伸縮性也得到了提高。

垂直自動伸縮（VPA）

FinOps落地實踐指的是一種運用自動化容器資源管理技術的方法，該技術能夠根據容器實時使用情況自動調整所需的CPU和內存資源。使用垂直自動擴縮容技術（VPA），容器可以在實際需要的資源水平上運行，避免不必要的資源浪費和成本開銷。

得物依托VPA和宿主機超售技術，啟動了容器技術方案的實施，旨在降低基礎設施成本。

服務畫像

在實施FinOps的過程中，應用畫像是解決單應用資源配額問題的一個有效方法。應用畫像主要是通過描繪在一定時間周期內應用集群對資源需求的情況來達成這一目的。資源包括了cpu、內存、磁盤、網絡等。應用畫像不僅可以展示應用的當前狀態，還可以通過對固定周期的CPU、內存等資源消耗數據進行分析，從而預估未來一段時間對某種資源使用的趨勢。下圖展示了應用畫像的流程：

最終降本增效成果：

3.2.2 內部結算，資源售賣模式

針對實施FinOps時遇到的產品定價問題，得物提出了一種差異化的產品定價方案，以應對不同計算資源使用情況下的SLA需求。為此，得物自研了容器管理平臺KubeOne，實現了按照細分SLA標準差異化定價，并引導業務按照實際需求選用不同標準的SLA產品，并將分攤成本實時推送至成本中心的各維度場景成本拆分中。

3.2.3 混合部署

統一調度混部實現

實現容器統一調度平臺管理系統可以有效地利用集群級別的碎片資源，從而降低單位成本30%。這種解決方案還可以解決K8S集群孤島和直接暴露K8S機器api給上層平臺的問題，提高穩定性并為后續更多的PAAS自建做好準備。

資源管理系統：實現應用畫像、任務畫像、節點畫像，為精準調度提供數據決策支持

聯邦調度可以根據每個集群的資源情況和特定應用或任務的自定義需求選擇最適合的集群，然后將該應用分發到相應集群的kube-apiserver。這種分散式的調度可以最大程度地優化資源的利用，并有效地保障不同業務的獨立性。在項目實施過程中，我們的工作主要集中在以下兩個方面：

混部資源的隔離與保護

在混合部署后，為提升集群資源利用率的同時保障高優在線應用的SLO，我們需要即刻采取措施，對離線應用進行壓制或直接驅逐。

綁定核心可確保高優應用的算力，因為一臺物理主機上可分配多個 socket、每個 socket 上有多個 NUMA、每個 NUMA 內有多個物理核，且每個物理核還有多個邏輯核。我們還可以通過將 CPU 劃分為不同級別，供高優應用獨占使用（見圖右）。

針對I/O資源競爭問題，不同的應用程序可以使用不同的磁盤掛載解決。此方法有效解決I/O資源競爭問題，改善應用程序穩定性和性能。此外，每個應用程序都有自己的磁盤分區，這使得備份和恢復數據更加方便。

同時，我們還優化了內核參數，以確保在線應用程序可以優先獲得所需資源，而離線應用程序的CPU范圍也可縮小。除了縮小離線應用程序可使用的CPU范圍，我們還將采取一系列措施，以保障在線應用程序的SLO。

混部資源調度優化

為了實現實時資源感知，我們需要通過每個節點實時采集每個WorkLoad-Pods的CPU水位情況。然而，這樣產生的大量數據需要聚合，以便調度器可以實時感知并做出決策。為了解決延遲和數據失效等問題，我們采用了一種名為 EXPMA（指數平均數指標）的算法來聚合數據，類似于股票指標中的移動平均線。與定期聚合不同，EXPMA可以更及時地探測到資源需求的變化，并且對歷史數據的貢獻逐漸減少，從而更好地反映當前的需求情況。

EXPMA是一種支持遞推計算的波動指標，其自身具有歷史連續權重且在當前時刻擁有最高的權重，因此非常實用。為了保持系統的穩定性和正確性，我們可以準備24個槽位，并將每小時的EXPMA值寫入對應的槽位。此外，我們采用FUTURE-SUM計算每個節點上Pod的CPU-EXPMA值，并在基于24個FUTURE-SUM的基礎上進行SD方差計算。根據計算結果，我們將節點的FUTURE-SD值進行排序，從而得出最適合調度Pod的節點。排序越靠前的節點越適合調度，因為這意味著在調度Pod后，未來上面Pod的CPU相位相互抵消的概率更高，從而波動率得以抑制，資源波動會更平穩，穩定性也更高。

混部落地情況

完成了以上一系列的能力完善后，在2022年初，得物正式啟動了實時計算平臺任務(Flink)混部項目，第一批基于 kube-adapter 與實時計算平臺的對接，實現了自動擴縮容和動態調度。

Flink選擇采用我們的動態資源分配，BE類型的應用程序能夠充分利用BE范圍內的CPU核心資源，從而有效地降低了單核成本。為任務平臺提供更為高效和低廉的的算力，進而提升其整體的資源使用率和穩定性。

下圖為整個遷移混部的具體步驟：

截至發文，得物已經成功完成了Flink任務的全量混部，這一成就不僅使得任務平臺的單核成本下降了50%，而且還為包括基礎架構、日志平臺等在內的10多個業務線的算力成本優化提供了顯著的支持。這次混部的成功為未來更多的大數據離線業務混部奠定了堅實的基礎，并將在確保核心業務穩定的情況下進一步將單核成本降低，實現更多的業務增長。

3.2.4 PAAS自建

自建KubeAI替代Pai

我們在實踐中發現，PaaS類服務的公有云優勢在快速部署和簡易維護方面是無可比擬的，但相較自建，其定價更高。在得物容器化項目中，我們收集了算法團隊對于模型訓練以及模型服務管理的需求，以及其他業務部門有關AI場景的容器化需求。通過利用KubeOne容器平臺的能力，我們建立了面向AI業務場景的KubeAI平臺。這個項目的完成讓算法PAI任務的整體成本降低了35.6%。

KubeAI平臺的設計理念在于讓用戶擺脫繁瑣而重復的資源調度工作，專心致力于模型整個生命周期的開發，從需求到任務的編排，輕松管理模型的訓練和推理服務。KubeAI通過KubeOne對資源的調度能力，合理規劃資源并分配給不同的任務，包括彈性資源、非彈性資源和按一定比例超賣的資源。

不僅如此，KubeAI還支持平臺用戶的需求，為當前CV團隊的模型開發提供全面覆蓋的支持，使其可以在KubeAI上方便地進行模型訓練、管理和推理服務管理操作。同時，KubeAI還支持OpenAPI對接，并且可以與其他平臺無縫集成，如DPP召回引擎管理平臺的引擎構建任務、風控算法平臺的模型及推理服務管理、DML平臺的搜推模型訓練任務等。綜上，KubeAI平臺的優勢在于其極致的用戶體驗和完備的功能模塊，為模型生命周期管理提供全方面的支持。

隨著公司業務的快速增長，云Redis的成本也不斷增加，從成本角度來看已經逐步形成挑戰。為應對這一挑戰，得物在2022年下半年啟動了自建Redis研發與遷移計劃，目前取得了不錯的成果。生產環境接入自建的Redis涵蓋了高 QPS、高流量、大容量的特征，同時也驗證了這套方案的可靠性。經過測算，從云Redis遷移到自建Redis，成本收益至少 50%。

為了研發無感下云，我們自建 Redis 服務也采用了類似云 Redis 的架構。整套系統由 ConfigServer、Proxy、Redis-server 等核心組件構成，整體架構圖如下所示：

自建日志平臺替代SLS

為了降低公司的日志存儲成本，提高日志查詢的能力，同時為業務方提供更加便捷的日志訂閱服務，公司決定推出自己的日志平臺替代SLS。該平臺將統一管理公司內部的日志數據，實現運維化管理，并利用先進的技術手段提高日志的查詢能力和用戶體驗。通過這一平臺，公司將獲得更高效、更經濟、更可靠的日志管理服務，進一步提升業務的運營效率和核心競爭力。

得物日志平臺具有以下特點：

成本低廉：通過自建日志平臺，可以降低存儲成本、日志查詢成本等，從而提高整體效率。

查詢能力強：得物日志平臺具有快速、精準的查詢能力，支持關鍵詞搜索、過濾、聚合等功能。

訂閱方便：得物日志平臺提供了方便的訂閱功能，支持將日志信息推送到指定的接收方，如郵件、短信等。

運維化管理：得物日志平臺提供了完善的運維管理功能，如權限管理、監控告警等，以確保系統的穩定和安全運行。

經過全面的項目實施與精細的成本控制，得物成功將日志平臺從云上遷移至自建環境，最終實現了成本總計優化，并節約了至少30%左右的成本。這一成果不僅充分彰顯了得物在技術創新方面的卓越實力和經驗，同時也為公司的發展注入了新的動力。

除以上，得物還進行了CK、LB、Flink、Hbase、kafka、Mq等paas組件自研，相比公有云paas產品，單位成本有較大幅度下降，自研和多云將是得物技術取得更多成本收益的方向。

3.2.5 SRE平臺能力建設

目前得物CMDB、發布系統已具備多云管理控制和身份驗證、網絡安全和漏洞管理等能力。同時依托分布式部署監控采集端部署，具備跨云統一視圖的可視化監控能力、雙活網絡環境能力。保證生產、測試網絡資源規劃符合高可用原則。這些基礎平臺能力使得得物可以有效控制云資源成本并優化資源配置，最終靈活的多云騰挪，在服務容災和商務議價有更大靈活性，進而實現FinOps的目標。

整體框架如下：

SRE平臺基礎能力決定了應用是否可遷移至多云架構。其主要能力包括應用依賴關系分析、應用調用量分析、應用RT零容忍度分析及內核級分析排障等。該平臺運用ebpf技術實現，如下圖所示：

3.2.6 CDN的多廠商容災和調度

作為互聯網廠商，CDN成本是重要的網絡流量成本。為優化得物CDN，主要有兩個方向：1）引入多云容災和調度能力；2）引入PCDN技術對視頻進行加速。PCDN是一種產品，它通過充分利用網絡上空余資源并確保穩定性，實現了網絡的加速。得物PCDN的實現架構如下：

最終成果：

3.3  FinOps - Operate(Continuous Improvement & Operations)

成本持續改進和運營階段，到這里，FinOps基金會定義的成熟度模型Maturity 中由“走” 進入到“跑” 階段，得物目前正處于這個階段，持續探索中。精細化成本運營勢在必行。

3.3.1 FinOps組織協同

對標FinOps基金會建議的協同職能組織結構，得物建立一個成本運營虛擬組織，推進云成本優化。該組織架構主要包括以下部門和職責：

• 成本運營崗：負責日常云成本的運營管理，監控資源使用情況，發現并解決成本問題，推動各部門提高成本意識和優化資源使用。同時負責制定預算、分析成本數據，并確保云成本的合規性和合理性。
• 業務技術研發：各業務域都會有一名研發對接人，作為該部門成本負責人，認領成本運營下發的優化、預算等需求，協調部門內部優化落地，對部門成本健康狀況負責。
• 財務部門：從財務視角對云成本進行管理和推動。
• SRE：作為云成本技術治理的專家，負責優化資源配置、提升系統性能，降低云計算成本，同時保障業務穩定運行。
• 采購部門：負責與多家云服務商進行商務談判，爭取更優惠的價格和服務條款，降低整體采購成本，提高企業在云市場的競爭力。

3.3.2 精細化成本運營

精細化運營的核心在于平衡成本、穩定和效率。基于數據分析呈現客觀事實、基于分析結果做出成本管理策略。精細化運營包含單位成本的獲取、效率指標的構建、持續化的跟蹤優化

• 單位成本獲取

根據經典的“ABC成本法”，完成云產品成本在生命周期各環節的拆分、挖掘成本驅動因素、建立云成本與業務大盤的關系，建立具有業務指標的單位成本。

• 效率指標構建

“業務場景梳理—>場景成本拆分—>場景核心指標—>建立效率指標模型”，建立一個場景的效率指標，提供成本決策數據依據。

• 持續化跟蹤優化

大量資源申請時，需要AB實驗數據支撐，由成本運營和業務部門根據AB實驗數據預估推全數據單位成本變化及效率指標數據來評估ROI，并持續監控單位成本和效率指標是否惡化，定期復盤確認ROI是否達預期并干預優化。

下面以得物算法分業務場景模型推全過程，來了解下具體如何實施精細化成本運營。得物算法主要服務于電商、社區業務，通過場景考核指標趨勢，來倒推算法資源成本合理性，是科學的辦法。

算法場景成本運營內容：

如算法的一個交易瀑布流模型申請上線會走如下流程：

3.3.3 成本運營分析平臺

上文講到，在FinOps “爬” 的階段，我們建設了成本中心系統，支持了基礎的云賬單分攤、云成本預測能力，將云賬單合理的分攤給人、部門、業務域。但在Operate階段，成本的持續優化進入深水區，需要更加完善的數據輔助分析決策，成本中心也在不斷成長。

經過周維度的敏捷開發 持續了1年多，成本中心發展為集利用率分析、容量分析、智能算法推薦優化、財務-業務場景&資源roi分析的 一站式運營分析平臺。已累計推薦驅動業務降本幾百萬元/月。

架構藍圖：

成本優化管家

成本優化管家幫忙解決云上資源運營難題，通過持續分析云資源性能監控指標，付費方式、云資賬單等多個維度數據，提供合理的優化調整建議，優化建議在確保應用性夠用的基礎上，降低資源費用，并聯動CMDB、工單系統、發布系統實現整體閉環：

• 優化邏輯：低利用率降配/釋放、閑置資源釋放、付費方式調整、狀態巡檢、規格調整等
• 支持產品：容器應用、常規應用、塊存儲、負載均衡、共享帶寬、文件存儲等

大促/日常容量評估

得物22年雙12大促，憑借成本運營分析平臺，對全網應用容量掃描，最終服務器擴容相比以往大促減少50%以上，并完美支持大促完成。是通過以下方法做到的：

對線上應用日常、大促時期的資源水位合理性確立統一標準，避免存量資源冗余多造成浪費，防止應用在大促時存在容量不足的風險。通過打通成本中心、CMDB、發布系統、監控系統、工單系統、容器平臺、壓測平臺等系統的數據交互，獲取應用在各個場景下的真實負載情況，并提供大促/日常的資源擴縮容推薦。

應用容量評估模塊介紹：

• 評估依據：根據應用的資源利用率、流量相關度，大促/日常/壓測期間的QPS、報錯率、Rt。根據場景設定合理的目標閾值，滿足優化前后應用的報錯率、Rt在合理的區間時，再基于此時的狀態對應用做擴縮容評估
• 評估合理化：基于數據支持，再通過嚴謹的評估方案，最終得到合理的評估推薦，有效的降低大促擴容成本，提升大促容量評估效率
• 評估閉環：平臺針對容量評估提供一鍵操作。當應用縮容時，預測并保證應用縮容后的CPU、內存、錯誤率、Rt保持在合理范圍內，保證夠用的應用性能。當然針對負載較高的應用也會做擴容推薦，此時就會通知和推動SRE、業務方來評估處理，提前避免資源不足的風險點。

日維度自動化對賬

為確保基礎數據的準確性及減少資損，得物基于不同云廠商賬單，制定自動化對賬策略：

• 按照廠商、產品、賬單類型及計費規則建立實例級的對賬邏輯；
• 每日完成T-1日的百萬條明細訂單對賬，逐一發現異常實例和異常訂單，人工追溯處理異常信息；
• 每月完成千萬條明細訂單對賬，匯總異常訂單及資損，與云廠商完成結算。

結合FinOps基金會對Operate階段的預期，成本的持續改進和運營可以將Infrom和Optimize階段不斷的夯實、升級；得物精細化成本運營進入這一階段后，組織協同、體系化管控成為不可或缺的抓手；為更好的實現各職能協作關系，需進行FinOps人才培養和文化建設，考核機制也成為近期的工作重點。

3.4  FinOps - 人員能力和文化建設

為確保FinOps的順利落地，必不可少的是人員能力培養。SRE團隊作為最接近資源成本的一支隊伍，扮演著降本增效推進的關鍵角色。得物公司在推進FinOps的同時，也進行了SRE能力建設。在保證業務穩定性的前提下，SRE團隊不斷探索挖掘，通過技術降低業務資源成本。

SRE驅動降本案例：節省百萬/年云成本

背景：為了優化算法預估服務的性能和降低成本，我們需要改善在線推理服務的整體利用率。然而，當前在線推理服務因為使用過大的JVM導致了較高的GC時延，為了加快GC效率，必須保留較高的CPU算力，這進一步降低了整體利用率。

方案：我們的SRE團隊通過內存分析發現，可以引入JDK17的ZGC來降低GC的STW時間，從而抑制甚至消除RT99的毛刺抖動。并且SRE工程師直接深入分析和理解業務源碼，幫助業務優化緩存模型架構代碼。

成果：通過優化，業務的RT性能翻翻，錯誤率下降10倍，大幅提升穩定性。從而以不犧牲 穩定性 和 性能 的情況下，大幅降低CPU資源的成本。

Devops和FinOps實際上都是在降本增效的背景下應運而生的崗位。需要不斷的打磨，提升。關于FinOps的人才培養，除公司要求和文化宣導外，建議考取FinOps基金會官方認證，完成系統化的學習，成為該領域專家。

3.5   FinOps - KPI考核

FinOps 嚴重依賴關鍵績效指標 (KPI)。KPI 用于獲得可見性和度量視角，以簡化成本控制過程。FinOps KPI 可大致分為以下幾類：

• 云可見性 KPI包括與跨云環境的成本、消耗、性能、配置、安全性和可用性相關的指標

• 得物考核角色：成本中心產品、研發

• 云優化 KPI包括與成本節約、預算履約、生產成本事件、平均修復時間、安全漏洞等相關的指標

• 得物考核角色：技術成本負責人、業務負責人

• 云治理和自動化 KPI包括與財務管理治理、運營治理、安全性和運營治理相關的指標

• 得物考核角色：技術成本運營、財務、采購

參考FinOps基金會考核指標，得物制定了FinOps KPI 類別的一部分跟蹤的關鍵指標。KPI 建立可衡量的基準和指標，以支持監控云資源及其消耗。以下是跟蹤的關鍵指標：

4、總結

得物在實踐FinOps近兩年后，優化了成本管理，通過成本洞察、治理和運營形成完整的成本管理鏈路，結合企業文化、流程和工具，實現高效、協同的云資源和成本管理。這幫助得物降低了云成本，提升了單位資源的產出。

未來得物將繼續推進成本治理，完成自建paas全量接入、擴大k8s混部范圍、服務器基礎機型更新迭代、應用多云部署等，通過技術持續提升服務器利用率、擺脫云商綁定及PaaS產品價格約束。成本運營側，進一步完善預算、資源申請流程，把單位訂單/dau成本等效能指標拆分到各部門，加入考核kpi；聯合財務進行大宗資源申請業務roi分析，達到FinOps成本治理成熟階段。?