1、背景

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

此次分享得物FinOps實(shí)踐經(jīng)驗(yàn)，希望能為讀者提供一些借鑒思路。

2、得物FinOps引入?

2.1   什么是FinOps？

FinOps 是“Finance”和“DevOps”的綜合體，強(qiáng)調(diào)運(yùn)維過程中的成本管理和資源優(yōu)化。

FinOps有一個權(quán)威組織，F(xiàn)inOps 基金會，該基金會是Linux 基金會發(fā)起的項(xiàng)目，致力于通過最佳實(shí)踐、教育和標(biāo)準(zhǔn)來推動實(shí)踐云財務(wù)管理學(xué)科。近年發(fā)展迅速，社區(qū)擁有超過 8,700 名成員，致力于解決云的爆炸式增長以及云成本管理挑戰(zhàn)。

在當(dāng)今數(shù)字化轉(zhuǎn)型的重要時刻，F(xiàn)inOps不僅僅是一個將財務(wù)和技術(shù)結(jié)合起來的領(lǐng)域，而且是云計算的關(guān)鍵領(lǐng)域之一。通過FinOps，IT和財務(wù)部門可以更好地合作，實(shí)現(xiàn)更好的業(yè)務(wù)成果和財務(wù)可持續(xù)性。因此，越來越多的企業(yè)積極開展FinOps實(shí)踐項(xiàng)目，并跨過了他們在實(shí)踐中所面臨的壁壘，得物正是一家在FinOps實(shí)踐中持續(xù)探索的公司。

FinOps基金會對FinOps定義：

• FinOps是一種不斷發(fā)展的云財務(wù)管理學(xué)科和文化實(shí)踐，通過幫助工程、財務(wù)、技術(shù)和業(yè)務(wù)團(tuán)隊(duì)在數(shù)據(jù)驅(qū)動的支出決策上進(jìn)行協(xié)作，使組織能夠獲得最大的業(yè)務(wù)價值。
• FinOps的核心是一種文化實(shí)踐，通過跨職能團(tuán)隊(duì)協(xié)同工作，以實(shí)現(xiàn)更快的產(chǎn)品交付，同時獲得更多的財務(wù)控制和可預(yù)測性。
• FinOps的特點(diǎn)是將問責(zé)制引入云支出，F(xiàn)inOps是財務(wù)責(zé)任文化變革帶入云的可變支出模型的實(shí)踐，使分布式工程和業(yè)務(wù)團(tuán)隊(duì)能夠在其云架構(gòu)和投資決策中的速度、成本和質(zhì)量之間進(jìn)行權(quán)衡。

FinOps成熟度模型：

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

在落地FinOps實(shí)踐時，了解成熟度模型和指標(biāo)可以幫助團(tuán)隊(duì)準(zhǔn)確評估其當(dāng)前水平，發(fā)現(xiàn)改進(jìn)點(diǎn)和推進(jìn)方向。例如，對于初步實(shí)踐的團(tuán)隊(duì)，最初的重點(diǎn)可能是尋找成本和資源的可視化方法，而更成熟的團(tuán)隊(duì)則可能更加關(guān)注云開銷和預(yù)算分析、成本優(yōu)化和分配、以及團(tuán)隊(duì)間的協(xié)作和溝通等方面。

成熟度模型的應(yīng)用，可以幫助企業(yè)實(shí)現(xiàn)可持續(xù)的FinOps成果，進(jìn)而達(dá)到支出透明度和控制、優(yōu)化云資源和實(shí)現(xiàn)最大化業(yè)務(wù)價值的目標(biāo)。?

2.2   FinOps實(shí)踐路線

得物從2021年開始關(guān)注云成本效能。經(jīng)過對FinOps體系深入研究，反復(fù)討論，持續(xù)了近2年的落地實(shí)踐，F(xiàn)inOps成熟度級別已逐步進(jìn)入到 “跑” 階段。下文會介紹得物FinOps建設(shè)的歷程，以及各階段行動路徑，供讀者參考。

結(jié)合公司現(xiàn)狀，得物借鑒FinOps社區(qū)主推的成本洞察、成本優(yōu)化、成本運(yùn)營層層遞進(jìn)，多管齊下的方式開展得物FinOps落地。按技術(shù)驅(qū)動、業(yè)務(wù)驅(qū)動、運(yùn)營驅(qū)動三個方面來推動機(jī)制流轉(zhuǎn)。最終實(shí)現(xiàn)成本透明度和控制、優(yōu)化云資源、并最大化業(yè)務(wù)價值。

3、得物FinOps構(gòu)建歷程

3.1   FinOps - Inform(Visibility & Allocation)

成本可視化階段，F(xiàn)inOps基金會對企業(yè)云成本治理的第一步“爬”，就是需解決Inform(Visibility&Allocation) 可視化、賬單分?jǐn)偟膯栴}，這是FinOps之旅的第一階段，它賦予組織和團(tuán)隊(duì)可視性、分配、基準(zhǔn)、預(yù)算和預(yù)測能力，使其有必要為智能決策提供準(zhǔn)確和及時的可見性。

得物從2021年開始打造基于多云環(huán)境的資管與成本運(yùn)營平臺 - 成本中心，在這一階段，優(yōu)先支持了成本數(shù)據(jù)分?jǐn)偰芰Γ謹(jǐn)偟讲块T、業(yè)務(wù)域。支持成本預(yù)測、預(yù)算管控、成本結(jié)算等功能。

3.1.1 成本分?jǐn)?/h4>

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

成本中心通過對接云廠商、CMDB、發(fā)布系統(tǒng)、內(nèi)部監(jiān)控系統(tǒng)，獲取所有成本關(guān)聯(lián)數(shù)據(jù)。成本按實(shí)例賬單匯聚，實(shí)例級維度分?jǐn)偟降綐I(yè)務(wù)域、組織架構(gòu)、人。支持日、周、月維度成本數(shù)據(jù)和成本預(yù)測。數(shù)據(jù)分析方面則構(gòu)建輕量化BI能力，滿足多維度分析，并輔助高層決策。

成本中心上線后帶來改進(jìn)：

• 將成本按人頭歸屬后，研發(fā)成本意識得到提升，開始關(guān)注項(xiàng)目資源的利用率。
• 多維度的成本拆分：部門維度、產(chǎn)品維度、業(yè)務(wù)維度和場景維度。
• 支持成本預(yù)測，當(dāng)月、下月各部門成本預(yù)測，便于提前規(guī)劃優(yōu)化動作。

3.1.2 預(yù)算機(jī)制

得物技術(shù)部2022年開始云上預(yù)算管控流程，由成本管理團(tuán)隊(duì)組織并推動預(yù)算管控體系的落地，包括目標(biāo)責(zé)任體系、信息反饋系統(tǒng)、預(yù)算指標(biāo)系統(tǒng)。

• 預(yù)算編制：以半年或季度為預(yù)算周期，設(shè)置總體目標(biāo)和要求，逐級分解到部門/項(xiàng)目，落實(shí)到具體負(fù)責(zé)人；
• 預(yù)算執(zhí)行：根據(jù)預(yù)算規(guī)劃業(yè)務(wù)，預(yù)算水位預(yù)警及工單審計聯(lián)動；
• 預(yù)算考核：對照設(shè)定的預(yù)算指標(biāo)，總結(jié)預(yù)算執(zhí)行情況、差異分析、歸因分析、改進(jìn)措施，形成預(yù)算反饋報告。

實(shí)際執(zhí)行中，業(yè)務(wù)發(fā)展存在并非完全沿著預(yù)算發(fā)展，因此得物采用的是固定預(yù)算+滾動預(yù)測相結(jié)合的方式，預(yù)算編制是自下而上的預(yù)算收集與審核，動態(tài)調(diào)度分配預(yù)算資源。

3.1.3 新增成本收口

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

所有資源的申請都要經(jīng)過如下步驟：成本預(yù)估---->預(yù)算水平判斷----->智能審批節(jié)點(diǎn)生成。

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

實(shí)施了上述治理措施，得物的FinOps實(shí)踐第一個難關(guān)得到解決，實(shí)現(xiàn)了能力的具備和實(shí)際應(yīng)用。這些措施幫助得物更好地管理成本，提高資源使用效率，避免不必要的成本浪費(fèi)，實(shí)現(xiàn)優(yōu)化資源管理、提高效率、降低成本的目標(biāo)。

3.2   FinOps - Optimize(Rates & Usage)

成本優(yōu)化階段，按照FinOps落地要求，當(dāng)具備成本賬單分?jǐn)偤涂梢暬螅梦镌贔inOps基金會定義的成熟度模型Maturity 中由“爬” 進(jìn)入到“走” 階段。進(jìn)入到Optimize階段，需要進(jìn)行多維度考慮，包括云產(chǎn)品計費(fèi)方式最優(yōu)、商務(wù)折扣競爭力、技術(shù)降本（自研paas/彈性計算/多云等）、精細(xì)化成本運(yùn)營（資源投入和業(yè)務(wù)收益的roi分析）等。

3.2.1 提升計算資源利用率

云服務(wù)器成本治理

云服務(wù)器ECS作為云上基礎(chǔ)設(shè)施，成本占比達(dá)第一，并隨著技術(shù)架構(gòu)改造的深入，ECS成本占比會逐步增加，因此，提高ECS成本合理性是云成本治理的首要任務(wù)。主要推動以下內(nèi)容：

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

最終成果：

全站容器化

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

垂直自動伸縮（VPA）

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

得物依托VPA和宿主機(jī)超售技術(shù)，啟動了容器技術(shù)方案的實(shí)施，旨在降低基礎(chǔ)設(shè)施成本。

服務(wù)畫像

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

最終降本增效成果：

3.2.2 內(nèi)部結(jié)算，資源售賣模式

針對實(shí)施FinOps時遇到的產(chǎn)品定價問題，得物提出了一種差異化的產(chǎn)品定價方案，以應(yīng)對不同計算資源使用情況下的SLA需求。為此，得物自研了容器管理平臺KubeOne，實(shí)現(xiàn)了按照細(xì)分SLA標(biāo)準(zhǔn)差異化定價，并引導(dǎo)業(yè)務(wù)按照實(shí)際需求選用不同標(biāo)準(zhǔn)的SLA產(chǎn)品，并將分?jǐn)偝杀緦?shí)時推送至成本中心的各維度場景成本拆分中。

3.2.3 混合部署

統(tǒng)一調(diào)度混部實(shí)現(xiàn)

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

資源管理系統(tǒng)：實(shí)現(xiàn)應(yīng)用畫像、任務(wù)畫像、節(jié)點(diǎn)畫像，為精準(zhǔn)調(diào)度提供數(shù)據(jù)決策支持

聯(lián)邦調(diào)度可以根據(jù)每個集群的資源情況和特定應(yīng)用或任務(wù)的自定義需求選擇最適合的集群，然后將該應(yīng)用分發(fā)到相應(yīng)集群的kube-apiserver。這種分散式的調(diào)度可以最大程度地優(yōu)化資源的利用，并有效地保障不同業(yè)務(wù)的獨(dú)立性。在項(xiàng)目實(shí)施過程中，我們的工作主要集中在以下兩個方面：

混部資源的隔離與保護(hù)

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

綁定核心可確保高優(yōu)應(yīng)用的算力，因?yàn)橐慌_物理主機(jī)上可分配多個 socket、每個 socket 上有多個 NUMA、每個 NUMA 內(nèi)有多個物理核，且每個物理核還有多個邏輯核。我們還可以通過將 CPU 劃分為不同級別，供高優(yōu)應(yīng)用獨(dú)占使用（見圖右）。

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

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

混部資源調(diào)度優(yōu)化

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

EXPMA是一種支持遞推計算的波動指標(biāo)，其自身具有歷史連續(xù)權(quán)重且在當(dāng)前時刻擁有最高的權(quán)重，因此非常實(shí)用。為了保持系統(tǒng)的穩(wěn)定性和正確性，我們可以準(zhǔn)備24個槽位，并將每小時的EXPMA值寫入對應(yīng)的槽位。此外，我們采用FUTURE-SUM計算每個節(jié)點(diǎn)上Pod的CPU-EXPMA值，并在基于24個FUTURE-SUM的基礎(chǔ)上進(jìn)行SD方差計算。根據(jù)計算結(jié)果，我們將節(jié)點(diǎn)的FUTURE-SD值進(jìn)行排序，從而得出最適合調(diào)度Pod的節(jié)點(diǎn)。排序越靠前的節(jié)點(diǎn)越適合調(diào)度，因?yàn)檫@意味著在調(diào)度Pod后，未來上面Pod的CPU相位相互抵消的概率更高，從而波動率得以抑制，資源波動會更平穩(wěn)，穩(wěn)定性也更高。

混部落地情況

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

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

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

截至發(fā)文，得物已經(jīng)成功完成了Flink任務(wù)的全量混部，這一成就不僅使得任務(wù)平臺的單核成本下降了50%，而且還為包括基礎(chǔ)架構(gòu)、日志平臺等在內(nèi)的10多個業(yè)務(wù)線的算力成本優(yōu)化提供了顯著的支持。這次混部的成功為未來更多的大數(shù)據(jù)離線業(yè)務(wù)混部奠定了堅實(shí)的基礎(chǔ)，并將在確保核心業(yè)務(wù)穩(wěn)定的情況下進(jìn)一步將單核成本降低，實(shí)現(xiàn)更多的業(yè)務(wù)增長。

3.2.4 PAAS自建

自建KubeAI替代Pai

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

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

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

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

為了研發(fā)無感下云，我們自建 Redis 服務(wù)也采用了類似云 Redis 的架構(gòu)。整套系統(tǒng)由 ConfigServer、Proxy、Redis-server 等核心組件構(gòu)成，整體架構(gòu)圖如下所示：

自建日志平臺替代SLS

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

得物日志平臺具有以下特點(diǎn)：

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

查詢能力強(qiáng)：得物日志平臺具有快速、精準(zhǔn)的查詢能力，支持關(guān)鍵詞搜索、過濾、聚合等功能。

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

運(yùn)維化管理：得物日志平臺提供了完善的運(yùn)維管理功能，如權(quán)限管理、監(jiān)控告警等，以確保系統(tǒng)的穩(wěn)定和安全運(yùn)行。

經(jīng)過全面的項(xiàng)目實(shí)施與精細(xì)的成本控制，得物成功將日志平臺從云上遷移至自建環(huán)境，最終實(shí)現(xiàn)了成本總計優(yōu)化，并節(jié)約了至少30%左右的成本。這一成果不僅充分彰顯了得物在技術(shù)創(chuàng)新方面的卓越實(shí)力和經(jīng)驗(yàn)，同時也為公司的發(fā)展注入了新的動力。

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

3.2.5 SRE平臺能力建設(shè)

目前得物CMDB、發(fā)布系統(tǒng)已具備多云管理控制和身份驗(yàn)證、網(wǎng)絡(luò)安全和漏洞管理等能力。同時依托分布式部署監(jiān)控采集端部署，具備跨云統(tǒng)一視圖的可視化監(jiān)控能力、雙活網(wǎng)絡(luò)環(huán)境能力。保證生產(chǎn)、測試網(wǎng)絡(luò)資源規(guī)劃符合高可用原則。這些基礎(chǔ)平臺能力使得得物可以有效控制云資源成本并優(yōu)化資源配置，最終靈活的多云騰挪，在服務(wù)容災(zāi)和商務(wù)議價有更大靈活性，進(jìn)而實(shí)現(xiàn)FinOps的目標(biāo)。

整體框架如下：

SRE平臺基礎(chǔ)能力決定了應(yīng)用是否可遷移至多云架構(gòu)。其主要能力包括應(yīng)用依賴關(guān)系分析、應(yīng)用調(diào)用量分析、應(yīng)用RT零容忍度分析及內(nèi)核級分析排障等。該平臺運(yùn)用ebpf技術(shù)實(shí)現(xiàn)，如下圖所示：

3.2.6 CDN的多廠商容災(zāi)和調(diào)度

作為互聯(lián)網(wǎng)廠商，CDN成本是重要的網(wǎng)絡(luò)流量成本。為優(yōu)化得物CDN，主要有兩個方向：1）引入多云容災(zāi)和調(diào)度能力；2）引入PCDN技術(shù)對視頻進(jìn)行加速。PCDN是一種產(chǎn)品，它通過充分利用網(wǎng)絡(luò)上空余資源并確保穩(wěn)定性，實(shí)現(xiàn)了網(wǎng)絡(luò)的加速。得物PCDN的實(shí)現(xiàn)架構(gòu)如下：

最終成果：

3.3  FinOps - Operate(Continuous Improvement & Operations)

成本持續(xù)改進(jìn)和運(yùn)營階段，到這里，F(xiàn)inOps基金會定義的成熟度模型Maturity 中由“走” 進(jìn)入到“跑” 階段，得物目前正處于這個階段，持續(xù)探索中。精細(xì)化成本運(yùn)營勢在必行。

3.3.1 FinOps組織協(xié)同

對標(biāo)FinOps基金會建議的協(xié)同職能組織結(jié)構(gòu)，得物建立一個成本運(yùn)營虛擬組織，推進(jìn)云成本優(yōu)化。該組織架構(gòu)主要包括以下部門和職責(zé)：

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

3.3.2 精細(xì)化成本運(yùn)營

精細(xì)化運(yùn)營的核心在于平衡成本、穩(wěn)定和效率。基于數(shù)據(jù)分析呈現(xiàn)客觀事實(shí)、基于分析結(jié)果做出成本管理策略。精細(xì)化運(yùn)營包含單位成本的獲取、效率指標(biāo)的構(gòu)建、持續(xù)化的跟蹤優(yōu)化

• 單位成本獲取

根據(jù)經(jīng)典的“ABC成本法”，完成云產(chǎn)品成本在生命周期各環(huán)節(jié)的拆分、挖掘成本驅(qū)動因素、建立云成本與業(yè)務(wù)大盤的關(guān)系，建立具有業(yè)務(wù)指標(biāo)的單位成本。

• 效率指標(biāo)構(gòu)建

“業(yè)務(wù)場景梳理—>場景成本拆分—>場景核心指標(biāo)—>建立效率指標(biāo)模型”，建立一個場景的效率指標(biāo)，提供成本決策數(shù)據(jù)依據(jù)。

• 持續(xù)化跟蹤優(yōu)化

大量資源申請時，需要AB實(shí)驗(yàn)數(shù)據(jù)支撐，由成本運(yùn)營和業(yè)務(wù)部門根據(jù)AB實(shí)驗(yàn)數(shù)據(jù)預(yù)估推全數(shù)據(jù)單位成本變化及效率指標(biāo)數(shù)據(jù)來評估ROI，并持續(xù)監(jiān)控單位成本和效率指標(biāo)是否惡化，定期復(fù)盤確認(rèn)ROI是否達(dá)預(yù)期并干預(yù)優(yōu)化。

下面以得物算法分業(yè)務(wù)場景模型推全過程，來了解下具體如何實(shí)施精細(xì)化成本運(yùn)營。得物算法主要服務(wù)于電商、社區(qū)業(yè)務(wù)，通過場景考核指標(biāo)趨勢，來倒推算法資源成本合理性，是科學(xué)的辦法。

算法場景成本運(yùn)營內(nèi)容：

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

3.3.3 成本運(yùn)營分析平臺

上文講到，在FinOps “爬” 的階段，我們建設(shè)了成本中心系統(tǒng)，支持了基礎(chǔ)的云賬單分?jǐn)偂⒃瞥杀绢A(yù)測能力，將云賬單合理的分?jǐn)偨o人、部門、業(yè)務(wù)域。但在Operate階段，成本的持續(xù)優(yōu)化進(jìn)入深水區(qū)，需要更加完善的數(shù)據(jù)輔助分析決策，成本中心也在不斷成長。

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

架構(gòu)藍(lán)圖：

成本優(yōu)化管家

成本優(yōu)化管家?guī)兔鉀Q云上資源運(yùn)營難題，通過持續(xù)分析云資源性能監(jiān)控指標(biāo)，付費(fèi)方式、云資賬單等多個維度數(shù)據(jù)，提供合理的優(yōu)化調(diào)整建議，優(yōu)化建議在確保應(yīng)用性夠用的基礎(chǔ)上，降低資源費(fèi)用，并聯(lián)動CMDB、工單系統(tǒng)、發(fā)布系統(tǒng)實(shí)現(xiàn)整體閉環(huán)：

• 優(yōu)化邏輯：低利用率降配/釋放、閑置資源釋放、付費(fèi)方式調(diào)整、狀態(tài)巡檢、規(guī)格調(diào)整等
• 支持產(chǎn)品：容器應(yīng)用、常規(guī)應(yīng)用、塊存儲、負(fù)載均衡、共享帶寬、文件存儲等

大促/日常容量評估

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

對線上應(yīng)用日常、大促時期的資源水位合理性確立統(tǒng)一標(biāo)準(zhǔn)，避免存量資源冗余多造成浪費(fèi)，防止應(yīng)用在大促時存在容量不足的風(fēng)險。通過打通成本中心、CMDB、發(fā)布系統(tǒng)、監(jiān)控系統(tǒng)、工單系統(tǒng)、容器平臺、壓測平臺等系統(tǒng)的數(shù)據(jù)交互，獲取應(yīng)用在各個場景下的真實(shí)負(fù)載情況，并提供大促/日常的資源擴(kuò)縮容推薦。

應(yīng)用容量評估模塊介紹：

• 評估依據(jù)：根據(jù)應(yīng)用的資源利用率、流量相關(guān)度，大促/日常/壓測期間的QPS、報錯率、Rt。根據(jù)場景設(shè)定合理的目標(biāo)閾值，滿足優(yōu)化前后應(yīng)用的報錯率、Rt在合理的區(qū)間時，再基于此時的狀態(tài)對應(yīng)用做擴(kuò)縮容評估
• 評估合理化：基于數(shù)據(jù)支持，再通過嚴(yán)謹(jǐn)?shù)脑u估方案，最終得到合理的評估推薦，有效的降低大促擴(kuò)容成本，提升大促容量評估效率
• 評估閉環(huán)：平臺針對容量評估提供一鍵操作。當(dāng)應(yīng)用縮容時，預(yù)測并保證應(yīng)用縮容后的CPU、內(nèi)存、錯誤率、Rt保持在合理范圍內(nèi)，保證夠用的應(yīng)用性能。當(dāng)然針對負(fù)載較高的應(yīng)用也會做擴(kuò)容推薦，此時就會通知和推動SRE、業(yè)務(wù)方來評估處理，提前避免資源不足的風(fēng)險點(diǎn)。

日維度自動化對賬

為確保基礎(chǔ)數(shù)據(jù)的準(zhǔn)確性及減少資損，得物基于不同云廠商賬單，制定自動化對賬策略：

• 按照廠商、產(chǎn)品、賬單類型及計費(fèi)規(guī)則建立實(shí)例級的對賬邏輯；
• 每日完成T-1日的百萬條明細(xì)訂單對賬，逐一發(fā)現(xiàn)異常實(shí)例和異常訂單，人工追溯處理異常信息；
• 每月完成千萬條明細(xì)訂單對賬，匯總異常訂單及資損，與云廠商完成結(jié)算。

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

3.4  FinOps - 人員能力和文化建設(shè)

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

SRE驅(qū)動降本案例：節(jié)省百萬/年云成本

背景：為了優(yōu)化算法預(yù)估服務(wù)的性能和降低成本，我們需要改善在線推理服務(wù)的整體利用率。然而，當(dāng)前在線推理服務(wù)因?yàn)槭褂眠^大的JVM導(dǎo)致了較高的GC時延，為了加快GC效率，必須保留較高的CPU算力，這進(jìn)一步降低了整體利用率。

方案：我們的SRE團(tuán)隊(duì)通過內(nèi)存分析發(fā)現(xiàn)，可以引入JDK17的ZGC來降低GC的STW時間，從而抑制甚至消除RT99的毛刺抖動。并且SRE工程師直接深入分析和理解業(yè)務(wù)源碼，幫助業(yè)務(wù)優(yōu)化緩存模型架構(gòu)代碼。

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

Devops和FinOps實(shí)際上都是在降本增效的背景下應(yīng)運(yùn)而生的崗位。需要不斷的打磨，提升。關(guān)于FinOps的人才培養(yǎng)，除公司要求和文化宣導(dǎo)外，建議考取FinOps基金會官方認(rèn)證，完成系統(tǒng)化的學(xué)習(xí)，成為該領(lǐng)域?qū)＜摇?/p>

3.5   FinOps - KPI考核

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

• 云可見性 KPI包括與跨云環(huán)境的成本、消耗、性能、配置、安全性和可用性相關(guān)的指標(biāo)

• 得物考核角色：成本中心產(chǎn)品、研發(fā)

• 云優(yōu)化 KPI包括與成本節(jié)約、預(yù)算履約、生產(chǎn)成本事件、平均修復(fù)時間、安全漏洞等相關(guān)的指標(biāo)

• 得物考核角色：技術(shù)成本負(fù)責(zé)人、業(yè)務(wù)負(fù)責(zé)人

• 云治理和自動化 KPI包括與財務(wù)管理治理、運(yùn)營治理、安全性和運(yùn)營治理相關(guān)的指標(biāo)

• 得物考核角色：技術(shù)成本運(yùn)營、財務(wù)、采購

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

4、總結(jié)

得物在實(shí)踐FinOps近兩年后，優(yōu)化了成本管理，通過成本洞察、治理和運(yùn)營形成完整的成本管理鏈路，結(jié)合企業(yè)文化、流程和工具，實(shí)現(xiàn)高效、協(xié)同的云資源和成本管理。這幫助得物降低了云成本，提升了單位資源的產(chǎn)出。

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