建站
咨詢
售后
建站咨詢
新聞中心
1、背景
隨著得物電商、社區(qū)業(yè)務(wù)迅速發(fā)展，云計算已成為支撐業(yè)務(wù)運行的關(guān)鍵基礎(chǔ)設(shè)施。然而，云計算的便利性和靈活性也帶來了一系列云成本管理挑戰(zhàn)，包括成本增速過快、成本歸屬不清晰、缺乏有效成本控制手段、對云廠商高度依賴等，因此云成本治理成為各公司的重要方向。作為快速發(fā)展中的互聯(lián)網(wǎng)公司，得物在業(yè)務(wù)增長的同時，開展了成本治理和FinOps項目落地工作，實現(xiàn)年度云成本節(jié)省上億元，成功抑制云成本的不合理上漲趨勢。
創(chuàng)新互聯(lián)公司堅持“要么做到，要么別承諾”的工作理念，服務(wù)領(lǐng)域包括：成都做網(wǎng)站、成都網(wǎng)站制作、企業(yè)官網(wǎng)、英文網(wǎng)站、手機端網(wǎng)站、網(wǎng)站推廣等服務(wù)，滿足客戶于互聯(lián)網(wǎng)時代的武夷山網(wǎng)站設(shè)計、移動媒體設(shè)計的需求，幫助企業(yè)找到有效的互聯(lián)網(wǎng)解決方案。努力成為您成熟可靠的網(wǎng)絡(luò)建設(shè)合作伙伴！
此次分享得物FinOps實踐經(jīng)驗，希望能為讀者提供一些借鑒思路。
2、得物FinOps引入?
2.1 什么是FinOps？
FinOps 是“Finance”和“DevOps”的綜合體，強調(diào)運維過程中的成本管理和資源優(yōu)化。
FinOps有一個權(quán)威組織，F(xiàn)inOps 基金會，該基金會是Linux 基金會發(fā)起的項目，致力于通過最佳實踐、教育和標準來推動實踐云財務(wù)管理學科。近年發(fā)展迅速，社區(qū)擁有超過 8,700 名成員，致力于解決云的爆炸式增長以及云成本管理挑戰(zhàn)。
在當今數(shù)字化轉(zhuǎn)型的重要時刻，F(xiàn)inOps不僅僅是一個將財務(wù)和技術(shù)結(jié)合起來的領(lǐng)域，而且是云計算的關(guān)鍵領(lǐng)域之一。通過FinOps，IT和財務(wù)部門可以更好地合作，實現(xiàn)更好的業(yè)務(wù)成果和財務(wù)可持續(xù)性。因此，越來越多的企業(yè)積極開展FinOps實踐項目，并跨過了他們在實踐中所面臨的壁壘，得物正是一家在FinOps實踐中持續(xù)探索的公司。
FinOps基金會對FinOps定義：
- FinOps是一種不斷發(fā)展的云財務(wù)管理學科和文化實踐，通過幫助工程、財務(wù)、技術(shù)和業(yè)務(wù)團隊在數(shù)據(jù)驅(qū)動的支出決策上進行協(xié)作，使組織能夠獲得最大的業(yè)務(wù)價值。
- FinOps的核心是一種文化實踐，通過跨職能團隊協(xié)同工作，以實現(xiàn)更快的產(chǎn)品交付，同時獲得更多的財務(wù)控制和可預(yù)測性。
- FinOps的特點是將問責制引入云支出，F(xiàn)inOps是財務(wù)責任文化變革帶入云的可變支出模型的實踐，使分布式工程和業(yè)務(wù)團隊能夠在其云架構(gòu)和投資決策中的速度、成本和質(zhì)量之間進行權(quán)衡。
FinOps成熟度模型：
FinOps Framework定義了關(guān)于FinOps 的“爬、走、跑”成熟度特征。
在落地FinOps實踐時，了解成熟度模型和指標可以幫助團隊準確評估其當前水平，發(fā)現(xiàn)改進點和推進方向。例如，對于初步實踐的團隊，最初的重點可能是尋找成本和資源的可視化方法，而更成熟的團隊則可能更加關(guān)注云開銷和預(yù)算分析、成本優(yōu)化和分配、以及團隊間的協(xié)作和溝通等方面。
成熟度模型的應(yīng)用，可以幫助企業(yè)實現(xiàn)可持續(xù)的FinOps成果，進而達到支出透明度和控制、優(yōu)化云資源和實現(xiàn)最大化業(yè)務(wù)價值的目標。?
|
FinOps成熟度級別 |
成熟度水平特征 |
指示性目標/KPI |
|
爬 |
很少的報告和工具測量僅提供對成熟能力的好處的洞察力為衡量成功而設(shè)置的基本 KPI圍繞能力定義基本流程和策略組織內(nèi)的所有主要團隊都了解能力，但并未遵循解決“唾手可得”的計劃 |
預(yù)測支出與實際支出準確性差異為 20%基于資源的承諾折扣目標覆蓋率約為 60%應(yīng)該能夠分配至少 50% 的云支出 |
|
走 |
能力在組織內(nèi)得到理解和遵循確定了困難的邊緣情況，但決定不解決它們自動化和/或流程涵蓋了大部分能力要求確定了最困難的邊緣情況并估計了解決的工作量中到高目標/KPI 設(shè)定在成功的衡量標準上 |
預(yù)測支出與實際支出準確性差異為 15%基于資源的承諾折扣目標覆蓋率約為 70%應(yīng)該能夠分配至少 80% 的云支出 |
|
跑 |
組織內(nèi)的所有團隊都理解并遵循能力正在解決困難的邊緣情況為衡量成功設(shè)定了非常高的目標/KPI自動化是首選方法 |
預(yù)測支出與實際支出準確性差異為 12%基于資源的承諾折扣目標覆蓋率約為 80%超過 90% 的云支出可以分配 |
2.2 FinOps實踐路線
得物從2021年開始關(guān)注云成本效能。經(jīng)過對FinOps體系深入研究，反復討論，持續(xù)了近2年的落地實踐，F(xiàn)inOps成熟度級別已逐步進入到 “跑” 階段。下文會介紹得物FinOps建設(shè)的歷程，以及各階段行動路徑，供讀者參考。
結(jié)合公司現(xiàn)狀，得物借鑒FinOps社區(qū)主推的成本洞察、成本優(yōu)化、成本運營層層遞進，多管齊下的方式開展得物FinOps落地。按技術(shù)驅(qū)動、業(yè)務(wù)驅(qū)動、運營驅(qū)動三個方面來推動機制流轉(zhuǎn)。最終實現(xiàn)成本透明度和控制、優(yōu)化云資源、并最大化業(yè)務(wù)價值。
3、得物FinOps構(gòu)建歷程
3.1 FinOps - Inform(Visibility & Allocation)
成本可視化階段，F(xiàn)inOps基金會對企業(yè)云成本治理的第一步“爬”，就是需解決Inform(Visibility&Allocation) 可視化、賬單分攤的問題，這是FinOps之旅的第一階段，它賦予組織和團隊可視性、分配、基準、預(yù)算和預(yù)測能力，使其有必要為智能決策提供準確和及時的可見性。
得物從2021年開始打造基于多云環(huán)境的資管與成本運營平臺 - 成本中心，在這一階段，優(yōu)先支持了成本數(shù)據(jù)分攤能力，分攤到部門、業(yè)務(wù)域。支持成本預(yù)測、預(yù)算管控、成本結(jié)算等功能。
3.1.1 成本分攤
在數(shù)據(jù)分析前需要進行著手的事情便是基礎(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ù)。成本按實例賬單匯聚，實例級維度分攤到到業(yè)務(wù)域、組織架構(gòu)、人。支持日、周、月維度成本數(shù)據(jù)和成本預(yù)測。數(shù)據(jù)分析方面則構(gòu)建輕量化BI能力，滿足多維度分析，并輔助高層決策。
成本中心上線后帶來改進：
- 將成本按人頭歸屬后，研發(fā)成本意識得到提升，開始關(guān)注項目資源的利用率。
- 多維度的成本拆分：部門維度、產(chǎn)品維度、業(yè)務(wù)維度和場景維度。
- 支持成本預(yù)測，當月、下月各部門成本預(yù)測，便于提前規(guī)劃優(yōu)化動作。
3.1.2 預(yù)算機制
得物技術(shù)部2022年開始云上預(yù)算管控流程，由成本管理團隊組織并推動預(yù)算管控體系的落地，包括目標責任體系、信息反饋系統(tǒng)、預(yù)算指標系統(tǒng)。
- 預(yù)算編制：以半年或季度為預(yù)算周期，設(shè)置總體目標和要求，逐級分解到部門/項目，落實到具體負責人；
- 預(yù)算執(zhí)行：根據(jù)預(yù)算規(guī)劃業(yè)務(wù)，預(yù)算水位預(yù)警及工單審計聯(lián)動；
- 預(yù)算考核：對照設(shè)定的預(yù)算指標，總結(jié)預(yù)算執(zhí)行情況、差異分析、歸因分析、改進措施，形成預(yù)算反饋報告。
實際執(zhí)行中，業(yè)務(wù)發(fā)展存在并非完全沿著預(yù)算發(fā)展，因此得物采用的是固定預(yù)算+滾動預(yù)測相結(jié)合的方式，預(yù)算編制是自下而上的預(yù)算收集與審核，動態(tài)調(diào)度分配預(yù)算資源。
3.1.3 新增成本收口
成本新增管控：成本中心解決了存量成本可視化和治理閉環(huán)，對于新增資源申請，也要進行卡口，得物自研的窮奇審批平臺，可結(jié)合成本預(yù)估功能、預(yù)算體系，智能化生成資源申請審批流程，有效提高研發(fā)人員成本意識及對新增成本進行合理性評估。
所有資源的申請都要經(jīng)過如下步驟：成本預(yù)估---->預(yù)算水平判斷----->智能審批節(jié)點生成。
- 成本預(yù)估：在資源申請階段，系統(tǒng)會自動進行成本預(yù)估，幫助研發(fā)人員更好地了解資源需求對成本的影響。
- 預(yù)算管理：可拉取部門預(yù)算水位，結(jié)合預(yù)估成本，綜合展示申請資源對于本部門預(yù)算影響。
- 智能審批節(jié)點：結(jié)合預(yù)算和成本預(yù)估、預(yù)算信息，工單系統(tǒng)會自動添加相應(yīng)的審批節(jié)點，確保資源申請的合理性和合規(guī)性。
實施了上述治理措施，得物的FinOps實踐第一個難關(guān)得到解決，實現(xiàn)了能力的具備和實際應(yīng)用。這些措施幫助得物更好地管理成本，提高資源使用效率，避免不必要的成本浪費，實現(xiàn)優(yōu)化資源管理、提高效率、降低成本的目標。
3.2 FinOps - Optimize(Rates & Usage)
成本優(yōu)化階段，按照FinOps落地要求，當具備成本賬單分攤和可視化后，得物在FinOps基金會定義的成熟度模型Maturity 中由“爬” 進入到“走” 階段。進入到Optimize階段，需要進行多維度考慮，包括云產(chǎn)品計費方式最優(yōu)、商務(wù)折扣競爭力、技術(shù)降本（自研paas/彈性計算/多云等）、精細化成本運營（資源投入和業(yè)務(wù)收益的roi分析）等。
3.2.1 提升計算資源利用率
云服務(wù)器成本治理
云服務(wù)器ECS作為云上基礎(chǔ)設(shè)施，成本占比達第一，并隨著技術(shù)架構(gòu)改造的深入，ECS成本占比會逐步增加，因此，提高ECS成本合理性是云成本治理的首要任務(wù)。主要推動以下內(nèi)容：
- 計費模式優(yōu)化：包年包月計費&按量計費擇優(yōu)選擇
- 空跑或低利用率資源巡檢：制定不同巡檢規(guī)則、及時釋放閑置資源
- 服務(wù)器&&應(yīng)用的完整生命周期管理：建立服務(wù)器或者應(yīng)用的上下線管理制度確保不會出現(xiàn)死應(yīng)用或者服務(wù)器
最終成果：
|
提升利用率 |
整體容器資源利用率上升12% | |
|
節(jié)約服務(wù)器成本 |
單位資源成本提升4% |
全站容器化
作為擁抱云原生不可或缺的一環(huán)，服務(wù)容器化的實踐將提高資源利用效率，加快部署速度，并確保應(yīng)用程序在不同環(huán)境下的一致性和可重現(xiàn)性。得物自2021年開始，在KubeOne的基礎(chǔ)上建立了自己的容器平臺，啟動了全站容器化項目，成功完成了涉及數(shù)十個業(yè)務(wù)領(lǐng)域上千個應(yīng)用的容器化改造，標志著得物容器化元年的開啟。該項目的完成大幅提高了資源利用率，整體資源利用率環(huán)比上升了10%。此外，硬件成本和管理成本也得到了降低，應(yīng)用程序的可靠性和可伸縮性也得到了提高。
垂直自動伸縮（VPA）
FinOps落地實踐指的是一種運用自動化容器資源管理技術(shù)的方法，該技術(shù)能夠根據(jù)容器實時使用情況自動調(diào)整所需的CPU和內(nèi)存資源。使用垂直自動擴縮容技術(shù)（VPA），容器可以在實際需要的資源水平上運行，避免不必要的資源浪費和成本開銷。
得物依托VPA和宿主機超售技術(shù)，啟動了容器技術(shù)方案的實施，旨在降低基礎(chǔ)設(shè)施成本。
服務(wù)畫像
在實施FinOps的過程中，應(yīng)用畫像是解決單應(yīng)用資源配額問題的一個有效方法。應(yīng)用畫像主要是通過描繪在一定時間周期內(nèi)應(yīng)用集群對資源需求的情況來達成這一目的。資源包括了cpu、內(nèi)存、磁盤、網(wǎng)絡(luò)等。應(yīng)用畫像不僅可以展示應(yīng)用的當前狀態(tài)，還可以通過對固定周期的CPU、內(nèi)存等資源消耗數(shù)據(jù)進行分析，從而預(yù)估未來一段時間對某種資源使用的趨勢。下圖展示了應(yīng)用畫像的流程：
最終降本增效成果：
|
降低容器總資源量 |
整體容器總資源量下降10% | |
|
提升分配率 |
整體容器資源分配率上升10% | |
|
提升利用率 |
整體容器資源利用率上升5% | |
|
提升運維效率 |
大型活動快速容量支撐 | |
|
提升事件響應(yīng)速度 |
緊急容量需求得到快速支持 |
3.2.2 內(nèi)部結(jié)算，資源售賣模式
針對實施FinOps時遇到的產(chǎn)品定價問題，得物提出了一種差異化的產(chǎn)品定價方案，以應(yīng)對不同計算資源使用情況下的SLA需求。為此，得物自研了容器管理平臺KubeOne，實現(xiàn)了按照細分SLA標準差異化定價，并引導業(yè)務(wù)按照實際需求選用不同標準的SLA產(chǎn)品，并將分攤成本實時推送至成本中心的各維度場景成本拆分中。
3.2.3 混合部署
統(tǒng)一調(diào)度混部實現(xiàn)
實現(xiàn)容器統(tǒng)一調(diào)度平臺管理系統(tǒng)可以有效地利用集群級別的碎片資源，從而降低單位成本30%。這種解決方案還可以解決K8S集群孤島和直接暴露K8S機器api給上層平臺的問題，提高穩(wěn)定性并為后續(xù)更多的PAAS自建做好準備。
資源管理系統(tǒng)：實現(xiàn)應(yīng)用畫像、任務(wù)畫像、節(jié)點畫像，為精準調(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ù)的獨立性。在項目實施過程中，我們的工作主要集中在以下兩個方面：
混部資源的隔離與保護
在混合部署后，為提升集群資源利用率的同時保障高優(yōu)在線應(yīng)用的SLO，我們需要即刻采取措施，對離線應(yīng)用進行壓制或直接驅(qū)逐。
綁定核心可確保高優(yōu)應(yīng)用的算力，因為一臺物理主機上可分配多個 socket、每個 socket 上有多個 NUMA、每個 NUMA 內(nèi)有多個物理核，且每個物理核還有多個邏輯核。我們還可以通過將 CPU 劃分為不同級別，供高優(yōu)應(yīng)用獨占使用（見圖右）。
針對I/O資源競爭問題，不同的應(yīng)用程序可以使用不同的磁盤掛載解決。此方法有效解決I/O資源競爭問題，改善應(yīng)用程序穩(wěn)定性和性能。此外，每個應(yīng)用程序都有自己的磁盤分區(qū)，這使得備份和恢復數(shù)據(jù)更加方便。
同時，我們還優(yōu)化了內(nèi)核參數(shù)，以確保在線應(yīng)用程序可以優(yōu)先獲得所需資源，而離線應(yīng)用程序的CPU范圍也可縮小。除了縮小離線應(yīng)用程序可使用的CPU范圍，我們還將采取一系列措施，以保障在線應(yīng)用程序的SLO。
混部資源調(diào)度優(yōu)化
為了實現(xiàn)實時資源感知，我們需要通過每個節(jié)點實時采集每個WorkLoad-Pods的CPU水位情況。然而，這樣產(chǎn)生的大量數(shù)據(jù)需要聚合，以便調(diào)度器可以實時感知并做出決策。為了解決延遲和數(shù)據(jù)失效等問題，我們采用了一種名為 EXPMA（指數(shù)平均數(shù)指標）的算法來聚合數(shù)據(jù)，類似于股票指標中的移動平均線。與定期聚合不同，EXPMA可以更及時地探測到資源需求的變化，并且對歷史數(shù)據(jù)的貢獻逐漸減少，從而更好地反映當前的需求情況。
EXPMA是一種支持遞推計算的波動指標，其自身具有歷史連續(xù)權(quán)重且在當前時刻擁有最高的權(quán)重，因此非常實用。為了保持系統(tǒng)的穩(wěn)定性和正確性，我們可以準備24個槽位，并將每小時的EXPMA值寫入對應(yīng)的槽位。此外，我們采用FUTURE-SUM計算每個節(jié)點上Pod的CPU-EXPMA值，并在基于24個FUTURE-SUM的基礎(chǔ)上進行SD方差計算。根據(jù)計算結(jié)果，我們將節(jié)點的FUTURE-SD值進行排序，從而得出最適合調(diào)度Pod的節(jié)點。排序越靠前的節(jié)點越適合調(diào)度，因為這意味著在調(diào)度Pod后，未來上面Pod的CPU相位相互抵消的概率更高，從而波動率得以抑制，資源波動會更平穩(wěn)，穩(wěn)定性也更高。
混部落地情況
完成了以上一系列的能力完善后，在2022年初，得物正式啟動了實時計算平臺任務(wù)(Flink)混部項目，第一批基于 kube-adapter 與實時計算平臺的對接，實現(xiàn)了自動擴縮容和動態(tài)調(diào)度。
Flink選擇采用我們的動態(tài)資源分配，BE類型的應(yīng)用程序能夠充分利用BE范圍內(nèi)的CPU核心資源，從而有效地降低了單核成本。為任務(wù)平臺提供更為高效和低廉的的算力，進而提升其整體的資源使用率和穩(wěn)定性。
下圖為整個遷移混部的具體步驟：
截至發(fā)文，得物已經(jīng)成功完成了Flink任務(wù)的全量混部，這一成就不僅使得任務(wù)平臺的單核成本下降了50%，而且還為包括基礎(chǔ)架構(gòu)、日志平臺等在內(nèi)的10多個業(yè)務(wù)線的算力成本優(yōu)化提供了顯著的支持。這次混部的成功為未來更多的大數(shù)據(jù)離線業(yè)務(wù)混部奠定了堅實的基礎(chǔ)，并將在確保核心業(yè)務(wù)穩(wěn)定的情況下進一步將單核成本降低，實現(xiàn)更多的業(yè)務(wù)增長。
|
降低容器總資源量 |
整體容器總資源量再下降10% | |
|
提升分配率 |
GPU集群cpu被利用了起來 | |
|
提升利用率 |
集群碎片資源被得到利用 | |
|
穩(wěn)定性增強 |
重要平臺后都有多個集群支持 |
3.2.4 PAAS自建
自建KubeAI替代Pai
我們在實踐中發(fā)現(xiàn)，PaaS類服務(wù)的公有云優(yōu)勢在快速部署和簡易維護方面是無可比擬的，但相較自建，其定價更高。在得物容器化項目中，我們收集了算法團隊對于模型訓練以及模型服務(wù)管理的需求，以及其他業(yè)務(wù)部門有關(guān)AI場景的容器化需求。通過利用KubeOne容器平臺的能力，我們建立了面向AI業(yè)務(wù)場景的KubeAI平臺。這個項目的完成讓算法PAI任務(wù)的整體成本降低了35.6%。
KubeAI平臺的設(shè)計理念在于讓用戶擺脫繁瑣而重復的資源調(diào)度工作，專心致力于模型整個生命周期的開發(fā)，從需求到任務(wù)的編排，輕松管理模型的訓練和推理服務(wù)。KubeAI通過KubeOne對資源的調(diào)度能力，合理規(guī)劃資源并分配給不同的任務(wù)，包括彈性資源、非彈性資源和按一定比例超賣的資源。
不僅如此，KubeAI還支持平臺用戶的需求，為當前CV團隊的模型開發(fā)提供全面覆蓋的支持，使其可以在KubeAI上方便地進行模型訓練、管理和推理服務(wù)管理操作。同時，KubeAI還支持OpenAPI對接，并且可以與其他平臺無縫集成，如DPP召回引擎管理平臺的引擎構(gòu)建任務(wù)、風控算法平臺的模型及推理服務(wù)管理、DML平臺的搜推模型訓練任務(wù)等。綜上，KubeAI平臺的優(yōu)勢在于其極致的用戶體驗和完備的功能模塊，為模型生命周期管理提供全方面的支持。
自建Redis
隨著公司業(yè)務(wù)的快速增長，云Redis的成本也不斷增加，從成本角度來看已經(jīng)逐步形成挑戰(zhàn)。為應(yīng)對這一挑戰(zhàn)，得物在2022年下半年啟動了自建Redis研發(fā)與遷移計劃，目前取得了不錯的成果。生產(chǎn)環(huán)境接入自建的Redis涵蓋了高 QPS、高流量、大容量的特征，同時也驗證了這套方案的可靠性。經(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ù)，實現(xiàn)運維化管理，并利用先進的技術(shù)手段提高日志的查詢能力和用戶體驗。通過這一平臺，公司將獲得更高效、更經(jīng)濟、更可靠的日志管理服務(wù)，進一步提升業(yè)務(wù)的運營效率和核心競爭力。
得物日志平臺具有以下特點：
成本低廉：通過自建日志平臺，可以降低存儲成本、日志查詢成本等，從而提高整體效率。
查詢能力強：得物日志平臺具有快速、精準的查詢能力，支持關(guān)鍵詞搜索、過濾、聚合等功能。
訂閱方便：得物日志平臺提供了方便的訂閱功能，支持將日志信息推送到指定的接收方，如郵件、短信等。
運維化管理：得物日志平臺提供了完善的運維管理功能，如權(quán)限管理、監(jiān)控告警等，以確保系統(tǒng)的穩(wěn)定和安全運行。
經(jīng)過全面的項目實施與精細的成本控制，得物成功將日志平臺從云上遷移至自建環(huán)境，最終實現(xiàn)了成本總計優(yōu)化，并節(jié)約了至少30%左右的成本。這一成果不僅充分彰顯了得物在技術(shù)創(chuàng)新方面的卓越實力和經(jīng)驗，同時也為公司的發(fā)展注入了新的動力。
除以上，得物還進行了CK、LB、Flink、Hbase、kafka、Mq等paas組件自研，相比公有云paas產(chǎn)品，單位成本有較大幅度下降，自研和多云將是得物技術(shù)取得更多成本收益的方向。
3.2.5 SRE平臺能力建設(shè)
目前得物CMDB、發(fā)布系統(tǒng)已具備多云管理控制和身份驗證、網(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ù)議價有更大靈活性，進而實現(xiàn)FinOps的目標。
整體框架如下：
SRE平臺基礎(chǔ)能力決定了應(yīng)用是否可遷移至多云架構(gòu)。其主要能力包括應(yīng)用依賴關(guān)系分析、應(yīng)用調(diào)用量分析、應(yīng)用RT零容忍度分析及內(nèi)核級分析排障等。該平臺運用ebpf技術(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ù)對視頻進行加速。PCDN是一種產(chǎn)品，它通過充分利用網(wǎng)絡(luò)上空余資源并確保穩(wěn)定性，實現(xiàn)了網(wǎng)絡(luò)的加速。得物PCDN的實現(xiàn)架構(gòu)如下：
最終成果：
|
CDN多云能力 |
CDN SLA從99.9%提升到99.97%+ | |
|
CDN多云調(diào)度 |
CDN綜合成本降低10% | |
|
視頻PCDN引入 |
CDN綜合成本降低30% |
3.3 FinOps - Operate(Continuous Improvement & Operations)
成本持續(xù)改進和運營階段，到這里，F(xiàn)inOps基金會定義的成熟度模型Maturity 中由“走” 進入到“跑” 階段，得物目前正處于這個階段，持續(xù)探索中。精細化成本運營勢在必行。
3.3.1 FinOps組織協(xié)同
對標FinOps基金會建議的協(xié)同職能組織結(jié)構(gòu)，得物建立一個成本運營虛擬組織，推進云成本優(yōu)化。該組織架構(gòu)主要包括以下部門和職責：
- 成本運營崗：負責日常云成本的運營管理，監(jiān)控資源使用情況，發(fā)現(xiàn)并解決成本問題，推動各部門提高成本意識和優(yōu)化資源使用。同時負責制定預(yù)算、分析成本數(shù)據(jù)，并確保云成本的合規(guī)性和合理性。
- 業(yè)務(wù)技術(shù)研發(fā)：各業(yè)務(wù)域都會有一名研發(fā)對接人，作為該部門成本負責人，認領(lǐng)成本運營下發(fā)的優(yōu)化、預(yù)算等需求，協(xié)調(diào)部門內(nèi)部優(yōu)化落地，對部門成本健康狀況負責。
- 財務(wù)部門：從財務(wù)視角對云成本進行管理和推動。
- SRE：作為云成本技術(shù)治理的專家，負責優(yōu)化資源配置、提升系統(tǒng)性能，降低云計算成本，同時保障業(yè)務(wù)穩(wěn)定運行。
- 采購部門：負責與多家云服務(wù)商進行商務(wù)談判，爭取更優(yōu)惠的價格和服務(wù)條款，降低整體采購成本，提高企業(yè)在云市場的競爭力。
3.3.2 精細化成本運營
精細化運營的核心在于平衡成本、穩(wěn)定和效率?；跀?shù)據(jù)分析呈現(xiàn)客觀事實、基于分析結(jié)果做出成本管理策略。精細化運營包含單位成本的獲取、效率指標的構(gòu)建、持續(xù)化的跟蹤優(yōu)化
- 單位成本獲取
根據(jù)經(jīng)典的“ABC成本法”，完成云產(chǎn)品成本在生命周期各環(huán)節(jié)的拆分、挖掘成本驅(qū)動因素、建立云成本與業(yè)務(wù)大盤的關(guān)系，建立具有業(yè)務(wù)指標的單位成本。
- 效率指標構(gòu)建
“業(yè)務(wù)場景梳理—>場景成本拆分—>場景核心指標—>建立效率指標模型”，建立一個場景的效率指標，提供成本決策數(shù)據(jù)依據(jù)。
- 持續(xù)化跟蹤優(yōu)化
大量資源申請時，需要AB實驗數(shù)據(jù)支撐，由成本運營和業(yè)務(wù)部門根據(jù)AB實驗數(shù)據(jù)預(yù)估推全數(shù)據(jù)單位成本變化及效率指標數(shù)據(jù)來評估ROI，并持續(xù)監(jiān)控單位成本和效率指標是否惡化，定期復盤確認ROI是否達預(yù)期并干預(yù)優(yōu)化。
下面以得物算法分業(yè)務(wù)場景模型推全過程，來了解下具體如何實施精細化成本運營。得物算法主要服務(wù)于電商、社區(qū)業(yè)務(wù)，通過場景考核指標趨勢，來倒推算法資源成本合理性，是科學的辦法。
算法場景成本運營內(nèi)容：
如算法的一個交易瀑布流模型申請上線會走如下流程：
3.3.3 成本運營分析平臺
上文講到，在FinOps “爬” 的階段，我們建設(shè)了成本中心系統(tǒng)，支持了基礎(chǔ)的云賬單分攤、云成本預(yù)測能力，將云賬單合理的分攤給人、部門、業(yè)務(wù)域。但在Operate階段，成本的持續(xù)優(yōu)化進入深水區(qū)，需要更加完善的數(shù)據(jù)輔助分析決策，成本中心也在不斷成長。
經(jīng)過周維度的敏捷開發(fā) 持續(xù)了1年多，成本中心發(fā)展為集利用率分析、容量分析、智能算法推薦優(yōu)化、財務(wù)-業(yè)務(wù)場景&資源roi分析的 一站式運營分析平臺。已累計推薦驅(qū)動業(yè)務(wù)降本幾百萬元/月。
架構(gòu)藍圖：
成本優(yōu)化管家
成本優(yōu)化管家?guī)兔鉀Q云上資源運營難題，通過持續(xù)分析云資源性能監(jiān)控指標，付費方式、云資賬單等多個維度數(shù)據(jù)，提供合理的優(yōu)化調(diào)整建議，優(yōu)化建議在確保應(yīng)用性夠用的基礎(chǔ)上，降低資源費用，并聯(lián)動CMDB、工單系統(tǒng)、發(fā)布系統(tǒng)實現(xiàn)整體閉環(huán)：
- 優(yōu)化邏輯：低利用率降配/釋放、閑置資源釋放、付費方式調(diào)整、狀態(tài)巡檢、規(guī)格調(diào)整等
- 支持產(chǎn)品：容器應(yīng)用、常規(guī)應(yīng)用、塊存儲、負載均衡、共享帶寬、文件存儲等
大促/日常容量評估
得物22年雙12大促，憑借成本運營分析平臺，對全網(wǎng)應(yīng)用容量掃描，最終服務(wù)器擴容相比以往大促減少50%以上，并完美支持大促完成。是通過以下方法做到的：
對線上應(yīng)用日常、大促時期的資源水位合理性確立統(tǒng)一標準，避免存量資源冗余多造成浪費，防止應(yīng)用在大促時存在容量不足的風險。通過打通成本中心、CMDB、發(fā)布系統(tǒng)、監(jiān)控系統(tǒng)、工單系統(tǒng)、容器平臺、壓測平臺等系統(tǒng)的數(shù)據(jù)交互，獲取應(yīng)用在各個場景下的真實負載情況，并提供大促/日常的資源擴縮容推薦。
應(yīng)用容量評估模塊介紹：
- 評估依據(jù)：根據(jù)應(yīng)用的資源利用率、流量相關(guān)度，大促/日常/壓測期間的QPS、報錯率、Rt。根據(jù)場景設(shè)定合理的目標閾值，滿足優(yōu)化前后應(yīng)用的報錯率、Rt在合理的區(qū)間時，再基于此時的狀態(tài)對應(yīng)用做擴縮容評估
- 評估合理化：基于數(shù)據(jù)支持，再通過嚴謹?shù)脑u估方案，最終得到合理的評估推薦，有效的降低大促擴容成本，提升大促容量評估效率
- 評估閉環(huán)：平臺針對容量評估提供一鍵操作。當應(yīng)用縮容時，預(yù)測并保證應(yīng)用縮容后的CPU、內(nèi)存、錯誤率、Rt保持在合理范圍內(nèi)，保證夠用的應(yīng)用性能。當然針對負載較高的應(yīng)用也會做擴容推薦，此時就會通知和推動SRE、業(yè)務(wù)方來評估處理，提前避免資源不足的風險點。
日維度自動化對賬
為確?；A(chǔ)數(shù)據(jù)的準確性及減少資損，得物基于不同云廠商賬單，制定自動化對賬策略：
- 按照廠商、產(chǎn)品、賬單類型及計費規(guī)則建立實例級的對賬邏輯；
- 每日完成T-1日的百萬條明細訂單對賬，逐一發(fā)現(xiàn)異常實例和異常訂單，人工追溯處理異常信息；
- 每月完成千萬條明細訂單對賬，匯總異常訂單及資損，與云廠商完成結(jié)算。
結(jié)合FinOps基金會對Operate階段的預(yù)期，成本的持續(xù)改進和運營可以將Infrom和Optimize階段不斷的夯實、升級；得物精細化成本運營進入這一階段后，組織協(xié)同、體系化管控成為不可或缺的抓手；為更好的實現(xiàn)各職能協(xié)作關(guān)系，需進行FinOps人才培養(yǎng)和文化建設(shè)，考核機制也成為近期的工作重點。
3.4 FinOps - 人員能力和文化建設(shè)
為確保FinOps的順利落地，必不可少的是人員能力培養(yǎng)。SRE團隊作為最接近資源成本的一支隊伍，扮演著降本增效推進的關(guān)鍵角色。得物公司在推進FinOps的同時，也進行了SRE能力建設(shè)。在保證業(yè)務(wù)穩(wěn)定性的前提下，SRE團隊不斷探索挖掘，通過技術(shù)降低業(yè)務(wù)資源成本。
SRE驅(qū)動降本案例：節(jié)省百萬/年云成本
背景：為了優(yōu)化算法預(yù)估服務(wù)的性能和降低成本，我們需要改善在線推理服務(wù)的整體利用率。然而，當前在線推理服務(wù)因為使用過大的JVM導致了較高的GC時延，為了加快GC效率，必須保留較高的CPU算力，這進一步降低了整體利用率。
方案：我們的SRE團隊通過內(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實際上都是在降本增效的背景下應(yīng)運而生的崗位。需要不斷的打磨，提升。關(guān)于FinOps的人才培養(yǎng)，除公司要求和文化宣導外，建議考取FinOps基金會官方認證，完成系統(tǒng)化的學習，成為該領(lǐng)域?qū)＜摇?/p>
3.5 FinOps - KPI考核
FinOps 嚴重依賴關(guān)鍵績效指標 (KPI)。KPI 用于獲得可見性和度量視角，以簡化成本控制過程。FinOps KPI 可大致分為以下幾類：
- 云可見性 KPI包括與跨云環(huán)境的成本、消耗、性能、配置、安全性和可用性相關(guān)的指標
- 得物考核角色：成本中心產(chǎn)品、研發(fā)
- 云優(yōu)化 KPI包括與成本節(jié)約、預(yù)算履約、生產(chǎn)成本事件、平均修復時間、安全漏洞等相關(guān)的指標
得物考核角色：技術(shù)成本負責人、業(yè)務(wù)負責人
云治理和自動化 KPI包括與財務(wù)管理治理、運營治理、安全性和運營治理相關(guān)的指標
得物考核角色：技術(shù)成本運營、財務(wù)、采購
參考FinOps基金會考核指標，得物制定了FinOps KPI 類別的一部分跟蹤的關(guān)鍵指標。KPI 建立可衡量的基準和指標，以支持監(jiān)控云資源及其消耗。以下是跟蹤的關(guān)鍵指標：
|
FinOps KPI 類別 |
關(guān)鍵績效指標/指標 |
|
云可見性 KPI |
成本賬單分攤準確率和覆蓋度、成本預(yù)測準確性、成本優(yōu)化推薦觸達率 |
|
云優(yōu)化 KPI |
部門CPU利用率、業(yè)務(wù)/技術(shù)單位成本變化率、場景業(yè)務(wù)指標結(jié)合資源變動 |
|
云治理和自動化 KPI |
商務(wù)折扣、FinOps文化宣傳、成本洞察歸因、協(xié)助財務(wù)/CTO/業(yè)務(wù)各角色進行數(shù)據(jù)看清 |
4、總結(jié)
得物在實踐FinOps近兩年后，優(yōu)化了成本管理，通過成本洞察、治理和運營形成完整的成本管理鏈路，結(jié)合企業(yè)文化、流程和工具，實現(xiàn)高效、協(xié)同的云資源和成本管理。這幫助得物降低了云成本，提升了單位資源的產(chǎn)出。
未來得物將繼續(xù)推進成本治理，完成自建paas全量接入、擴大k8s混部范圍、服務(wù)器基礎(chǔ)機型更新迭代、應(yīng)用多云部署等，通過技術(shù)持續(xù)提升服務(wù)器利用率、擺脫云商綁定及PaaS產(chǎn)品價格約束。成本運營側(cè)，進一步完善預(yù)算、資源申請流程，把單位訂單/dau成本等效能指標拆分到各部門，加入考核kpi；聯(lián)合財務(wù)進行大宗資源申請業(yè)務(wù)roi分析，達到FinOps成本治理成熟階段。?
文章名稱：得物FinOps落地實踐
網(wǎng)頁鏈接：http://www.dlmjj.cn/article/dhjiohh.html
