節省數億IT成本，B站FinOps最佳化實踐

　　 一、背景

　　當前，降本增效是各大網際網路公司的重要方向，IT成本則佔據了網際網路公司成本的大頭。如何有效的降本？如何推動各業務線配合？如何平衡成本、質量和效率？本文將介紹B站的IT成本管理和最佳化的思路，介紹B站透過落地FinOps，推進成本洞察、技術最佳化和運營最佳化，提升資源效率的經驗。2022年，在B站DAU穩步增長的情況下，IT成本花費金額低於21年同期，為公司節省了數億成本。專案團隊也獲得了公司2022年度技術突出貢獻獎。

　　 二、歷史

　　IT的成本管理主要是針對預算的管理，每財年開始的時候完成整個財年的預算編制。在預算編制的過程中，將業務目標轉化為成本，結合技術最佳化方案，定下來降本目標。業務增長目標加上降本目標得出成本目標。　　

　　預算定好了，降本目標也定好了，那是不是按部就班的執行就好了？這中間暴露出來幾個問題：

　　預算過程中技術中臺參與不夠，業務直接提預算，技術中臺最後被告知資源需求。

　　預算內的需求變成白名單，採購流程時直接pass，預算控制力度不夠，容易造成浪費。

　　缺乏業務視角的全域賬單，業務對成本無感知，預算外的最佳化動力不足，成本控制很難超預期，甚至可能不達預期。

　　其中最重要的是最後一個問題，業務對資源效率和成本無感知，那麼降本的收益也就難以評估，業務的降本動力就會不足。

　　 三、效能大盤——感知資源利用率

　　既然降本目標已經下達，行動就迫在眉睫。

　　一開始我們延續傳統思路，提到降本增效，第一反應就是各類資源利用率。與所有網際網路公司的敏捷性相同，我們基於內部的平臺和資源，整合監控系統、資產管理系統、混合雲HCRM系統等基礎資料，使用資料平臺的數倉能力，快速搭建了資源數倉、資料看板與告警機制。基於歷史資料，希望支援業務資源預估和制定降本目標等活動。

　　根據B站的成本佔比資料，我們重點設立了核心關注的是頻寬資源和計算資源的利用率相關指標。

　　頻寬資源涵蓋各類CDN頻寬、雲頻寬和IDC頻寬；

　　計算資源則涵蓋自有伺服器、雲虛擬機器、租賃裸金屬伺服器等資源。

　　當前我們已經實現，針對對不同供應商，將同類資源的不同指標進行歸一化，例如多雲場景下不同雲廠商的指標對齊。對於GPU這類資源，還會考量訓練、推理等不同場景下的利用率等。

　　為了更好的聯動其他團隊，我們還給公司內各類技術中臺建立效能模型，注重計算、儲存等各類平臺模型都有不同，以容器平臺為例：　　

　　關注以上指標，可有效評估容器平臺的資源效能，支援平臺做資源水位線管理，度量使用效率和技術最佳化空間。

　　經過一段時間的實踐，儘管拉著資源使用者聊利用率、巡檢各部門空閒機器、甚至定期製作各類排名榜單，我們還是發現降本工作推進緩慢。技術中臺與業務部門間難以聯動、研發人員缺乏成本意識、無法量化降本產出等核心問題依舊難以解決。

　　那段時間，碰上行業內越來越多公司開始重視降本增效，在與其他公司的相關從業者多次交流討論後，一個概念逐漸出現到我們眼前——FinOps（Financial Operations）。

　　 四、FinOps概念——確定行動步驟

　　按照FinOps Foundation給出的定義，FinOps是一種不斷髮展的雲財務管理規範和文化實踐，透過幫助工程、財務、技術和業務團隊，基於資料驅動，在支出決策上展開合作，使得組織能夠獲取最大的業務價值。

　　當前雲原生成為技術選型的共識，B站內部平臺和系統也大多選擇了雲原生的道路。B站的雲原生是搭建在私有云、公有云的多雲環境上的，其中私有云底層資源為租賃IDC和自有伺服器資產。FinOps的整個框架不僅適用於公有云上的資源和成本管理，也同樣適用於私有云，整體的工作思路和邏輯是一致的。　　

　　從上面FinOps Framework可以看到，參與Finops的角色很多：

　　企業高管

　　業務負責人

　　工程和運維團隊

　　財務和採購

　　FinOps實踐者

　　做為FinOps實踐者，需要聯合業務、平臺、運維、基礎工程、財務和採購團隊一起，對IT成本進行有效管理和最佳化。

　　FinOps的生命週期分為三個階段：

　　成本洞察

　　成本最佳化

　　成本運營

　　在反覆研究相關理論後，我們定下了B站基於FinOps視角下降本的實驗路徑：

　　成本量化打基礎，透過賬單提升業務對成本的感知。

　　技術降本和運營降本“雙駕馬車”並行推進。

　　透過事前計劃、事中控制、事後分析多項舉措，將成本的指標納入業務方案和商務採購的考量，成本控制貫穿在整個資源生命週期的管理。　　

　　 五、引入財務視角——洞察技術成本

　　所有技術需求的開展都離不開其底層資源，而各類IT資源的成本，需要納入財務對各業務線的ROI考核中。但在之前很長一段時間內，業務線可能只有一個預算的大概數字，並不瞭解細節，自然也不能引起重視。也就沒有量化分析的基礎，很難明確最佳化的目標和方向。

　　為了更好的衡量技術成本，將每一筆IT資源的採購成本，折算到每個業務甚至每次活動中，為了讓每個業務線都能清楚錢花到哪裡去了，瞭解其IT成本及具體構，我們首先引入財務中的兩個概念。

　　1、CAPEX和OPEX

　　CAPEX（Capital Expenditure，即資本性支出）：對應預算現金流口徑，指實際支出的金額。

　　OPEX（Operating Expense，即運營支出）：硬體一次性支出按照會計科目折舊計算，頻寬服務類非一次性支出和CAPEX一致。

　　想要將CAPEX轉化為OPEX，就需要計算TCO（Total Cost of Ownership），將採購硬體資產的一次性成本分攤到該資產的生命週期裡。以一臺伺服器為例，直接採購成本即為CAPEX，將採購成本分攤到今後使用的每個月，再增加伺服器每月配套使用的其他資源成本，即可得到TCO模型：　　

　　（1）其中Server_Tco-month為一臺伺服器每月的TCO金額。

　　（2）Depreciation為按照標準會計準則，單臺機器的每月折舊金額。

　　（3）Net為租賃IDC中所有網路裝置的每月折舊。

　　（4）Idc為當月IDC中發生的所有成本，含機櫃、電力、維護等。

　　（5）Line為連線IDC間內網專線線路的每月費用。

　　（6）f_1是單臺伺服器分攤函式，以算出除折舊外，單臺伺服器的每月其他成本。

　　2、定價

　　B站的業務搭建在公有云和私有云上，想要各個業務瞭解成本，需要公有云和私有云都能計費和拆帳。將IT資源和對應的成本掛鉤。技術中臺想要和公有云一樣具備計費、出賬和對賬的能力，則需要統一設計和升級。各技術中臺需設計計費的SKU（即平臺售賣的產品），定好價格策略，然後統計各業務的資源用量，最終實現向內部業務計費出賬。

　　SKU設計時即考慮和公有云平臺對齊，以便和公有云成本對比。又需要兼顧公司的實際業務場景需求。例如，容器平臺的一種CPU產品定價模型如下：　　

　　

　　（7）Cost_total是該類容器平臺SKU對應自有伺服器的總成本，n為該SKU對應的所有伺服器。

　　（8）Price_cpu為CPU定價。

　　（9）Ratio_cpu為CPU成本系數，用於折算伺服器中CPU關聯的成本。

　　（10）Cpu_total是對應所有機器的總邏輯核數。

　　（11）loadfactor為利用率水位線，參考值為近期該SKU對應物理伺服器的合理水位線。

　　（12）(Cpu_total*loadfactor)就為理論上的總服務量。

　　對於其他技術中臺的SKU，基本適用以上“單價=SKU對應TCO/理論總服務量“的模式。由於技術中臺沒有盈利壓力，賬單只是為了合理的反應業務成本，推動業務提升使用資源的效率，所以平臺資源利用率的提升讓可售賣的資源更多了，降低了單個資源的單價，業務從成本上也能受益。

　　3、計費

　　成本=單價*用量。單價有了，接下來需要確定業務各SKU的計費用量了。我們大致將用量的統計方式分成了兩類，共享與獨佔。還是以容器平臺的上述SKU為例：　　

　　

　　（13）t為資源使用時長。

　　（14）Usage_shared為共享類資源用量統計方式，Limit是該服務申請容器的CPU資源限制。

　　（15）Usage_exclusively為獨佔類資源用量統計方式，Capacity為該服務所在pool的所在物理資源上限，loadfactor為該資源利用使用率上限。

　　在實際計算中，即使A（獨佔類）、B（共享類）兩個服務實際消耗的CPU相同，A的計費用量也會高於B的。因為A所在資源池就算無服務執行，其獨佔的特性也使其他服務無法排程進來，造成浪費。因此在成本量化上，按其資源池理論最大使用量進行收費。相對的，共享資源池內的空閒節點可排程其他服務，按服務實際申請容器的limit進行收費。

　　透過區分獨佔、共享用量統計邏輯，更多的業務方選擇收費更低的共享類資源，伺服器資源的歸屬逐漸從業務方，轉向技術中臺，這使得中臺承擔更多的容量管理工作。原本在公司採購伺服器流程中：預估業務目標->轉化機器數量->提出採購需求->中臺交付資源，技術中臺不會過多參與整機數量評估，業務需求採買多少伺服器，中臺最終就交付、託管多少臺的服務。

　　而現在，整個流程改進為：預估業務目標->中臺轉化算力需求->評估全域性算力缺口->提出採購需求。中臺會收集各業務需求，再結合自身存量資源，提出缺口算力對應的採購需求，從而減少資源採買。

　　4、賬單

　　“成本=單價*用量”，可以從折舊（Opex）的角度，客觀反映出平臺空閒與超賣情況，推動技術中臺和業務協同最佳化，並量化成本收益。

　　技術中臺：角色轉變為對單價負責，透過提升資源利用率、技術架構升級，減少平臺底層資源採買，多供應商的議價能力，降低各類SKU的單價，各最佳化專案可以明確的轉化為成本收益，讓技術中臺的成本更具競爭力。

　　業務方：透過治理應用例項的數量/儲存量、規模、使用時長、共享與獨佔方式切換，降低SKU的用量。

　　雙方齊頭並進，合作共贏，最佳化IT成本。　　

　　賬單生成好了，下個主要問題是讓業務負責人瞭解賬單並Review成本，從而確定後續最佳化方向。賬單的確認流程由統一的出賬系統實現，具體成本分攤的規則、資源定價和出賬的流程都在系統裡定義。系統裡還有各類資源IT成本模型，能夠量化資源與成本關係，最終將每一種IT成本以統一的形式傳送給業務方。

　　依託於出賬系統，公有云和私有云成本都能在統一的賬單裡展示，業務檢視賬單就能知道完整的IT成本構成。每月各業務技術負責人在收到系統推送的賬單後，需完成對賬Review，並在系統中確認賬單。如對賬單細節有疑問可在系統中標註反饋，出賬平臺將修正賬單。

　　這裡其實包含了很多的溝通成本，業務剛開始收到一份賬單，是很難看懂賬單的，需要有人"翻譯"一下。業務是業務視角，賬單是資源視角，一個業務或者一個功能對應到哪些資源上，各類資源的含義都需要解釋和說明。

　　對賬中最困難的其實是“資源歸屬業務”的準確性問題。挑戰來自公司組織架構的各種調整，業務和資源的不斷變化，還有歷史包袱，有些歷史資源歸屬不清等等。

　　為確保歸屬的準確性，歸屬對映關係從服務樹（CMDB）同步。每一個微服務應用都有自身的APPID（Application Identification）。出賬系統透過APPID來進行應用的唯一定位與關聯相關資源的專案、部門和負責人等資訊。基於CMDB的APPID（服務/應用粒度）=>專案=>組織架構=>業務的關係，實現多維度的成本視角，應用視角，部門視角或者業務視角。

　　非服務樹（CMDB）支援的資源，則透過各平臺自身維護的歸屬對映，以實現多種方式的成本歸屬。例如大資料平臺基於工作空間的歸屬關係。

　　與此同時，成本資料的實時性也影響到成本監測和最佳化分析的有效性。日級別或者更加實時的賬單，能協助業務快速發現和定位成本問題，及時調整專案投入。提升實時性也是後續賬單系統的迭代方向。　　

　　總結一下，整個流程就是：平臺出賬=>業務對賬=>賬單分析=>針對性最佳化=>最佳化效果反映到下一出賬週期的資源對賬，這樣一套閉環流程。透過對賬，將IT成本及時同步給Finops中各類干係人，強化成本責任制，為IT成本最佳化決策提供資料支撐。同時反映IT成本最佳化效果、預算執行情況等指標。

　　 六、成本最佳化思路——實操經驗總結

　　成本賬單有了，效能大盤也有了，接下來該在哪些方向上推進成本最佳化呢？如何有效推進成本最佳化落地呢？

　　首先讓我們來分析一下成本資料。B站的主要業務是點播、直播、電商、遊戲等，做為一個以影片為主的網站，B站的每年IT成本花費中，頻寬佔比最大，其次是硬體，最後是公有云&其他IT服務類成本。想要做到成本最佳化的收益最大化，那麼在各類成本資源項上都需要投入最佳化。

　　從業務角度看，不同的資源需求有著不同的成本模型。

　　從資源角度看，不同的計費方式有著不同的最佳化思路。

　　頻寬計費：一般雲廠商為日95月平均，也有月95，即每5分鐘打點，取一個週期打點的95峰值。也有包埠的頻寬計費方式。可以透過削峰填谷的方法最佳化成本。

　　機櫃計費：月租為主，也有電櫃分離的計算方式，透過機櫃電力合適的配比最佳化成本。

　　伺服器：一次性成本，透過維保增加從而減少攤銷成本。透過提升CPU利用率減少硬體採購。

　　配件：透過改配，打破硬體的瓶頸，提升硬體效能，節省成本。

　　雲服務：按照用量計費，不同雲服務的計費方式差異大，彈性是最大的優勢。對彈性需求高的業務適用，例如遊戲。

　　1、頻寬成本最佳化

　　頻寬成本是成本的最大頭，從使用角度可以分為點播頻寬、直播頻寬、Web頻寬。其中Web頻寬又細分為動態頻寬和靜態頻寬。

　　點播頻寬：點播業務使用的流媒體頻寬。成本最高，最佳化投入最大。

　　直播頻寬：直播業務使用的流媒體頻寬。成本僅次於點播頻寬，最佳化方向區別於點播。

　　Web動態頻寬：動態介面使用的頻寬，CDN回源率100%，不可快取。

　　Web靜態頻寬：圖片、js、apk等靜態檔案使用的頻寬，可快取。

　　（1）點播頻寬成本模型

　　下面以點播頻寬舉例，點播頻寬的成本模型如下：

　　點播頻寬成本 = 平均單次播放頻寬 * 點播播放次數 * 頻寬單價。

　　平均單次播放頻寬：是用來衡量單次播放的成本，這裡的頻寬計算的是95計費值，所以不完全等於位元速率，但是和位元速率趨勢相同。位元速率低則單次播放頻寬更低，位元速率的最佳化效果會體現在此指標上。編碼團隊透過窄帶高畫質轉碼系統，AV1等技術方案最佳化15%的頻寬。

　　點播播放次數：和業務發展相關，難以準確預測，如超預期增長，則整體IT成本會有不小的增加，有超預算的風險。

　　頻寬單價：點播使用的頻寬資源多樣，既有云廠商提供的點播頻寬，又有自建CDN頻寬，還有PCDN、mCDN等廉價頻寬。不同資源單價不一樣，這些頻寬的佔比影響了點播的綜合單價。

　　（2）點播頻寬最佳化思路

　　從上述簡化的模型分析可以分析出點播頻寬的最佳化主要是思路是降低位元速率和降低單價，實際推進的最佳化專案主要如下：

　　透過窄帶高畫質編碼系統，上線並擴大AV1覆蓋，進一步降低位元速率

　　基於機器學習做最佳化轉碼預測，提升最佳化位元速率的覆蓋

　　最佳化影片播放的清晰度策略

　　提升廉價頻寬PCDN、mCDN佔比，降低頻寬平均單價

　　自建CDN專線互聯，降低迴源成本

　　內容分層，冷的內容排程到聚邊資源，降低迴源頻寬量

　　削峰填谷，和其他業務頻寬共峰複用

　　除了點播頻寬，上述的直播、Web動態、Web靜態都同步推進最佳化，思路也是從成本模型資料分析出發，最佳化前核算成本，最佳化後驗證收益。

　　2、伺服器成本最佳化

　　伺服器硬體最佳化不同於頻寬，主要使用利用率來衡量最佳化效果，同時採用TCO或者Opex來核算和評估技改最佳化方案。

　　（1）伺服器硬體迭代

　　英特爾CPU從Skylake => Cascadelake => Icelake =>Sapphire Rapids，每一代在功耗和單核效能上都有提升。

　　AMD CPU從Rome => Milan => Genoa，每一代工藝和效能上都有提升。

　　GPU從T4、V100、A10、A100到A800，工藝和效能也在變化。

　　網路的架構也從10Gbps，到25Gbps，再到100Gbps甚至200G。

　　硬體的迭代速度是飛速的，每一次的硬體迭代，也重新整理了單位算力的成本的下限。既然新的硬體更有成本優勢，那麼應該儘量引導業務配合硬體升級，每個硬體代次的迭代成本最佳化效果都是非常顯著的。

　　同時，硬體功耗的增長也是飛速的，機櫃從3KW、4KW、8KW到10KW，機櫃和電力成本最佳化的收益也會非常可觀。在IDC的佈局和選擇上，可以選擇更加廉價的資源，將接入的POP點和IDC解耦，以達到效能和成本的最優。

　　（2）伺服器虛擬化和混部

　　基於K8S構建的私有云容器平臺，是伺服器成本最佳化的主力。平臺也發表過多篇文章分享混部和VPA技術。讓我們來整體看下最佳化思路，還記得前面講的效能模型嗎？容器平臺的最佳化就是基於資源的效能模型。　　

　　提升容器總資源量：將伺服器資源儘量都容器化，讓更多的業務都搭建在容器之上，不止業務應用，其他的技術中臺的應用也要儘量接入到容器平臺中。

　　提升池化率（可售賣的資源量/總資源量）：提高池化率主要是在有限的資源上，儘量增加可售賣的資源量，讓更多的資源都是透過統一的容器排程。

　　提升分配率（已售賣的資源量/可售賣的資源量）：不同分配率的資源池可以考慮合併，減少資源碎片和冗餘。

　　提升利用率（使用資源量/已售賣的資源量）：利用率不足將造成資源的極度浪費，透過建立應用畫像，利用超賣、VPA、HPA等有效手段，資源利用率得到大幅提升。

　　除了以上的手段，混部也是提升利用率的一大利器。利用不同業務的潮汐效應，分時複用資源。轉碼做為算力密集型業務，最早嘗試混部。目前B站已經對離線-離線，線上-離線間進行了混部，也有相關的技術分享文章。

　　當前在推進的主要是AI場景下的混部，也就是推廣搜業務的混部。AI業務不僅是計算密集型，訪存頻寬也非常高，會觸達硬體瓶頸，造成雪崩效應，因此混部策略需要更加謹慎。

　　3、公有云成本最佳化

　　不同於伺服器資源，公有云承擔彈性保障、降低延遲、海外部署等用途。而公有云的成本最佳化，是為在支援業務正常發展的前提下，最大程度使用公有云資源即買即用的特性。

　　根據資源型別與其對應的計費方式，公有云上資源大致可分為網路流量、雲伺服器等IaaS資源、雲上SaaS服務等資源。不同資源，需對症下藥。

　　（1）根據業務特性適配資源

　　雲上專案根據業務特性，會產生波形截然不同的網路流量，而云廠商提供的網路流量產品也根據特點還有不同的計費方式。需同時考慮此二者關係，才能做到網路成本最優。

　　常見的網路類產品計費模式有按頻寬計費和按流量計費：

　　按頻寬計費：適用於業務流量峰值在不同時間段分佈平均，無明顯的流量波動場景

　　按流量計費：適用於業務流量波動較大，有突發的場景。

　　除計費模式外，網路線路型別也有不同選擇，例如動態BGP、靜態BGP、三大運營商單線、公網或混合雲專線等，會讓成本有較大差異，同樣需要根據業務的架構方案及成本模型進行選擇。

　　對於頻寬、運營商佔比穩定、且技術方案可兜底單點故障的專案，優先使用三大運營商單線。

　　對於頻寬波動大、三大運營商無法覆蓋、海外部署或流量較小的專案，優先使用BGP。

　　而跨地域頻寬較高、回源量大的專案則考慮使用混合雲專線。

　　在此基礎上還可考慮其他策略，例如將多個專案的網路流量放進一個共享頻寬包，可實現頻寬的共峰收益。

　　（2）預先規劃與定期釋放

　　IaaS類資源多以例項*使用時長的形式計費，因此可在申請階段就控制新增資源量。大型專案的容量、例項組合和付費策略在申請時就要求有明確規劃。

　　申請方提交資源需求後，FinOps各方會基於業務特點、成本等考慮，確定供應商、地域、資源型號等事宜。

　　（3）自研or公有云

　　通常情況下，公有云的SaaS類服務擁有快速部署、簡易維護等優勢，但相較自建乃至雲上IaaS產品會有更高的定價。

　　同類自研產品在公司內私有云已投入大量前期成本，擁有較為成熟的技術積累和專業運維團隊，在經過一定的標準化改造，可滿足雲上同類產品的功能需求。而對於自研暫無法替代或改造收益不高的產品，會透過調整使用場景、計費方式或尋找價格更優的同類產品替代。

　　隨著B站自建機房節點與傳輸網路建設程度提升，後續更多雲上專案可複用基礎服務和基礎設施，做到常量私有云+公有云混合部署，突發公有云彈性兜底，實現此類服務的混合雲方案。基於上述執行辦法的實踐，B站的自研HTTPDNS域名解析、DSA動態加速等服務，已節省超過一半的成本。

　　4、小結

　　如下圖，IT成本除了頻寬、伺服器、公有云，還有很多其他資源成本，各項成本FinOps都需要分析並推動最佳化。在分析和推進的過程中，形成了一套完整的成本模型。隨著業務不斷的發展，成本模型和最佳化方案也在不斷進步。　　

　　 七、運營最佳化——多方溝通協同

　　運營最佳化是圍繞兩個方面開展的：

　　成本運營，依託於預算、成本賬單和成本模型，及時和各方同步成本情況和問題。

　　資源運營，依託於資源效能大盤資料，及時發現並制止資源浪費現象。

　　1、成本運營

　　預算控制：為了降本做到極致，達到成本最優，預算控制需要更加嚴格。預算實際執行採購的時間可能和預算規劃時間已經間隔比較長了，內部和外部都發生了變化，需要及時根據變化進行調整，儘量減少金額。

　　決算分析：每月基於賬單資料進行成本分析，將超預算或者其他有改進空間的成本項進行重點溝通，溝通範圍為業務研發負責人、基礎平臺負責人、財務、採購等FinOps各角色。對超預算的風險進行預警，共同商議改進措施和策略。

　　賬單分析：協助業務理解賬單，從業務角度觸發，分析單DAU成本，為業務降本提供指標和決策依據。

　　成本核算：對於技術改造的新方案或專案，構建成本模型，決策出成本改進的更優解。

　　成本決策：成本的模型搭建不難，難的是如何在追求成本更優的情況下，兼顧穩定性和效率。成本最佳化通常伴隨著技術升級和技術改造，大量的人力投入會影響原來計劃的迭代效率，系統升級也常常會帶來不穩定因素。追求廉價資源的使用，也會影響系統的質量，需要系統設計上能考慮到容錯和兜底策略。總的來說，如果沒有強有力的管理層做成本決策，降本增效的效果將會大打折扣。　　

　　2、資源運營

　　公有云主機：結合利用率監控、混合雲平臺及供應商賬單資料，需要監控資源效能情況，發現不合理的冗餘容量、不再使用的資源，及時推進縮容、降配等操作。

　　公有云服務：資源巡檢過程中，若發現無人認領、未清退完全的資源，例如閒置未掛載的卻仍在計費的雲硬碟，歷史悠久的快照等，會定期公示並清退。

　　IDC伺服器：對於利用率極低的伺服器，推進納入容器的資源池中，儘量容器化。

　　其他資源：各服務使用的合理性也需要運營同學關注，例如超長簡訊會拆成多條計費，合理設計簡訊模板，能節省大量成本。

　　 總結與展望

　　B站透過對FinOps的實踐，實現了成本洞察=>成本最佳化=>運營最佳化的完整閉環。透過效能資料、成本賬單、持續最佳化和運營等關鍵行動，達成了業務增長而IT成本金額不增長，為公司節省了數億成本。後續FinOps將繼續在實時資料驅動決策、成本預測等方向繼續探索，追求更加極致的IT成本，提升毛利率。