關於作者：
葉翠，嗶哩嗶哩技術專家;
馬永志，嗶哩嗶哩高階運維工程師。
1. 背景
目前，降本增效是各大網際網絡公司的重要方向，IT成本佔網際網絡公司成本的大部分。 如何有效降低成本？ 如何促進各業務線的合作？ 您如何平衡成本、質量和效率？ 本文將介紹嗶哩嗶哩的IT成本管理和優化思想，並介紹嗶哩嗶哩通過FINOs的實施促進成本洞察、技術優化、運營優化、提高資源效率的經驗。 2022年，隨著B站DAU的穩步增長，花費的IT成本金額將低於21年同期，為公司節省數億成本。 專案團隊還獲得了公司2022年度技術突出貢獻獎。
2. 歷史
IT成本管理主要用於預算管理，整個會計年度的預算編製在每個會計年度開始時完成。 在預算編製過程中，將業務目標轉化為成本，結合技術優化方案，設定降本目標。 將業務增長目標與成本降低目標相結合，得出成本目標。
預算已經定好了，降本目標也定好了，那麼按部就班地實施好嗎？ 暴露了幾個問題：
在預算過程中，技術中臺參與不夠，業務直接提出預算，最終將資源需求告知技術中臺。
預算內的需求成了白名單，採購流程直接通過，預算控制不夠，容易造成浪費。
業務角度缺乏全域性計費，業務對成本的感知，預算外優化動力不足，成本控制難以超出預期，甚至可能達不到預期。
其中最重要的乙個問題就是最後乙個問題，如果企業沒有意識到資源效率和成本，那麼就很難評估降本的收益，企業就沒有足夠的動力去降低成本。
3. 效率** - 感知資源利用率
既然已經發布了降低成本的目標，行動迫在眉睫。
一開始，我們延續了傳統的思維方式，說到降本增效，第一反應就是各種資源的利用率。 與所有網際網絡公司的敏捷性類似，基於我們內部的平台和資源，我們整合了監控系統、資產管理系統、混合雲HCM系統等基礎資料，並利用資料平台的資料倉儲能力，快速構建了資源資料倉儲、資料儀錶盤和告警機制。 根據歷史資料，我們希望支援諸如估算業務資源和設定成本降低目標等活動。
根據B站的成本佔比資料，重點關注頻寬資源和計算資源的利用率。
頻寬資源包括CDN頻寬、雲頻寬和IDC頻寬。
計算資源包括自有伺服器、雲主機和租用裸金屬伺服器。
目前，我們已經實現了不同廠商同型別資源不同指標的規範化，比如多雲場景下不同雲廠商指標的對齊。 對於 GPU 等資源，還將考慮訓練和推理等不同場景的利用率。
為了更好地與其他團隊對接，我們還為公司內部各類技術平台建立了效率模型，重點關注計算、儲存等不同平台模型，以容器平台為例
關注以上指標可以有效評估容器平台的資源效率，支援平台管理資源水位線，衡量利用效率和技術優化空間。
經過一段時間的實踐，我們還是發現，儘管拉著資源使用者談利用率，檢查各部門閒置機器，甚至定期製作各種排行榜，但降本進度還是很慢。 技術中間平台與業務部門銜接困難、研發人員成本意識不足、降本產出無法量化等核心問題仍難以解決。
那段時間，行業內越來越多的企業開始注重降本增效，經過與其他企業相關從業者的多次交流和討論，乙個概念逐漸出現在我們面前——FinOps（財務運營）。
四、FINOPS的概念——確定行動步驟
FinOps 由 FinOps 基金會定義，是一種不斷發展的雲財務管理學科和文化實踐，它使組織能夠通過幫助工程、財務、技術和業務團隊在資料驅動的支出決策上進行協作來獲取最大的業務價值。
目前，雲原生已經成為技術選型的共識，嗶哩嗶哩大部分內部平台和系統也都選擇了雲原生的路徑。 嗶哩嗶哩的雲原生建立在私有雲和公有雲的多雲環境中，其中私有雲的底層資源是租用的IDC和自有的伺服器資產。 FinOps的整個框架不僅適用於公有雲上的資源和成本管理，也適用於私有雲，整體工作思路和邏輯是一樣的。
從上面的 FinOps 框架中可以看出，FinOps 中涉及許多角色：
企業高管。 業務負責人。
工程和運營團隊。
財務與採購。
FinOps 從業者。
作為 FinOps 從業者，您需要與業務、平台、運維、基礎設施工程、財務和採購團隊合作，以有效管理和優化 IT 成本。
FinOps 的生命週期分為三個階段：
成本洞察。 成本優化。
成本工序。 經過對相關理論的反覆研究，我們基於FINOPS的視角，為B站設定了降低成本的實驗路徑：
成本量化奠定了基礎，並通過計費提高了業務對成本的感知。
技術成本降低和運營成本降低的“雙軌”正在並行推進。
通過事前規劃、事中控制、事後分析等多項措施，將成本指標納入業務計畫和業務採購的考量中，成本控制貫穿於資源全生命週期的管理中。
5. 引入財務視角——洞察技術成本
所有技術需求的開發都離不開其底層資源，各種IT資源的成本需要由財務部門納入各業務線的ROI評估中。 但之前很長一段時間，業務線可能只有乙個大概的預算數字，沒有詳細了解，自然不能當真。 沒有定量分析的基礎，就很難明確優化的目標和方向。
為了更好地衡量技術成本，將每個IT資源的採購成本換算成每個業務甚至每個活動，為了明確每個業務線的錢花在哪裡，了解其IT成本和具體結構，我們首先在財務中引入兩個概念。
1. 資本支出和運營支出
資本支出（Capital Expenditure）：與預算現金流量相對應，是指實際支出的金額。
OPEX（運營費用）：一次性硬體費用按會計科目折舊計算，頻寬業務的非一次性支出與CAEX相同。
要將 CAPEX 轉換為 OPEX，您需要計算總擁有成本 （TCO），並在資產的整個生命週期內分配購買硬體資產的一次性成本。 以某伺服器為例，直接採購成本為CAPEX，TCO模型的計算方法是將採購成本分攤到未來每個月使用的成本，再將伺服器每個月使用的其他資源的成本相加
1） 伺服器 TCO-month 是伺服器的每月 TCO 量。
2）折舊是單台機器按標準會計準則計算的月折舊金額。
3）NET是租用IDC中所有網路裝置的月折舊。
4）IDC是指當月IDC發生的所有費用，包括機櫃、電費、維護等。
5）LINE為IDC之間專線的月費。
6） F1 是單台伺服器分配函式，用於計算單台伺服器除折舊外的每月成本。
2. 定價
嗶哩嗶哩的業務建立在公有雲和私有雲之上，如果你想讓每個企業都了解成本，你需要公有雲和私有雲來計費和拆分賬戶。 將 IT 資源與相應的成本聯絡起來。 如果技術中間平台想要擁有與公有雲相同的計費、計費和對賬能力，就需要統一設計和公升級。 每個技術中間平台都需要設計SKU（即平台銷售的產品），設定最佳策略，然後統計每個業務的資源使用情況，最後實現對內部業務的計費和計費。
SKU 旨在與公有雲平台保持一致，以便進行成本比較。 還需要考慮公司的實際業務場景需求。 例如，容器平台的某個 CPU 產品的定價模型如下：
7）成本總計是容器平台SKU對應的自有伺服器總成本，N是SKU對應的所有伺服器的總成本。
8）價格CPU是CPU的價格。
9） 比率 CPU 是 CPU 成本因子，用於計算與伺服器中 CPU 相關的成本。
10） CPU Total 是所有計算機對應的邏輯核心總數。
11）LoadFactor為利用率水印，參考值為近期SKU對應的物理伺服器的合理水印。
12） （CPU total*loadfactor） 是理論上的總服務量。
對於其他技術中間平台的SKU，上述“單價=TCO理論總服務量對應的SKU”模型基本適用。 由於技術中間平台沒有盈利壓力，賬單只是為了合理反映業務成本，推動業務提高資源使用效率，因此平台資源利用率的提高使得可供銷售的資源更多，降低了單一資源的單價，業務也可以從成本中獲益。
3. 計費
成本 = 單價×使用量 現在單價可用，您需要確定商家中每個 SKU 的數量。 我們將使用統計資料大致分為兩類，共享和獨佔。 我們以上面容器平台的SKU為例：
13） t 表示資源的持續時間。
14） 使用共享是共享資源的使用統計方法，限制是服務應用容器的 CPU 資源限制。
15） Usage Excless為獨享資源使用統計方法，capacity為服務所在池物理資源上限，loadfactor為資源利用率上限。
在實際計算中，即使A（獨佔類）和B（共享類）消耗的CPU相同，A的計算量也會高於B。 因為即使A所在的資源池中沒有執行的服務，其獨佔特性也使得其他服務無法排程，造成浪費。 因此，在成本量化方面，按照資源池的理論最大使用量進行計費。 反之，共享資源池中的閒置節點可以排程其他服務，並按服務實際申請的容器限額收費。
通過區分獨佔和共享使用統計邏輯，更多的業務方選擇費用更低的共享資源，伺服器資源的所有權逐漸從業務端向技術中臺轉移，這使得中臺承擔了更多的容量管理工作。 最初，在公司的採購伺服器流程中：估計業務目標 - >轉換後的機器數量 - >滿足採購需求 - > 中臺交付資源技術中間平台不會過多參與整機數量的評估，中間平台最終會交付和託管企業需要購買多少臺伺服器的服務。
現在，整個過程已改進為：估算業務目標 - >中颱的算力需求 - >評估全球算力缺口 - >提出採購需求。中颱會收集各種業務需求，然後結合自身存量資源，提出與缺口算力相對應的採購需求，從而減少資源採購。
4. 賬單
成本=單價*使用量“，可以從折舊（OPEX）的角度客觀反映平台的閒置和超賣情況，促進技術中間平台和業務的協同優化，量化成本效益。
技術中間平台：角色轉變為負責單價，通過提高資源利用率，公升級技術架構，減少平台上底層資源的購買，多個商家的議價能力，降低各種SKU的單價，每個優化專案都可以明確地轉化為成本效益，使技術中間平台的成本更具競爭力。
業務端：通過管理應用例項數量、儲存容量、規模、使用時長以及共享和獨享模式切換，減少SKU使用率。
雙方攜手並進，實現合作共贏，優化IT成本。
賬單生成後，接下來的一大問題就是讓企業主了解賬單並審查成本，從而確定後續優化的方向。 賬單確認流程由統一的計費系統實現，具體的成本分配規則、資源定價、計費流程均在系統中定義。 系統中還有針對各種資源的IT成本模型，可以量化資源和成本之間的關係，最終將每個IT成本統一的形式傳送到業務端。
依託計費系統，公有雲和私有雲的成本可以統一顯示在賬單中，企業可以通過檢視賬單了解完整的IT成本結構。 每個月，在收到系統推送的賬單後，各業務的技術負責人需要在系統中完成對賬審核並確認賬單。 如果您對賬單詳情有任何疑問，可以在系統中標記反饋，計費平台會更正賬單。
其實這裡溝通成本很多，商家剛收到賬單的時候，很難看懂賬單，需要有人在場"譯本"一下。 業務是從業務的角度出發的，計費是從資源的角度出發的，各種資源的含義需要解釋和解釋乙個業務或乙個功能對應哪些資源。
對賬最困難的方面是“資源歸屬業務”的準確性。 挑戰來自於公司組織架構的各種調整，業務和資源的不斷變化，以及歷史包袱，部分歷史資源歸屬不明確。
為確保歸因的準確性，歸因對映從服務樹 （CMDB） 同步。 每個微服務應用程式都有自己的 appID（應用程式標識）。 計費系統使用 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計費值計算的，所以它並不完全等於位元率，但它與位元率趨勢相同。 如果位元速率較低，則單次頻寬會更低，位元速率優化效果會體現在此指標中。 編碼團隊通過窄帶高畫質轉碼系統等技術方案，優化了15%的頻寬，**1。
點播檢視數**這關係到業務發展，很難準確**，如果增長超出預期，整體IT成本將大幅增加，存在超出預算的風險。
頻寬單價：雲點播使用多種頻寬資源，包括雲廠商提供的按需頻寬、自建CDN頻寬、PCDN、MCDN等低成本頻寬。 不同資源的單價不同，這些頻寬的佔比會影響雲點播的整體單價。
（2）點播頻寬優化
從以上簡化的模型分析可以分析出，點播頻寬的優化主要基於降低位元速率和單價，實際優化專案如下：
通過窄帶高畫質編碼系統，推出並擴大**1的覆蓋範圍，位元速率進一步降低。
基於機器學習的優化轉碼**，提公升優化位元速率覆蓋率。
優化 *** 的清晰度策略。
提高低成本頻寬PCDN和MCDN的比例，降低頻寬的平均單價。
自建CDN專線互聯互通，降低回源成本。
內容分層：冷內容被排程到邊緣資源，減少回源頻寬。
調峰，與其他業務頻寬共峰復用。
除了點播頻寬外，上述直播、網路動態、網路靜態都同時優化，思路也是從成本模型資料分析入手，計算優化前的成本，優化後的收益驗證。
2. 伺服器成本優化
伺服器硬體優化不同於頻寬，主要用利用率來衡量優化效果，用TCO或OPEX來計算和評估技術改造優化方案。
（1） 伺服器硬體迭代
英特爾 CPU 從 Skylake = > CascadeLake = > iceLake = >Sapphire Rapids 進行了改進，每一代都在功耗和單核效能上增加。
來自羅馬的 AMD CPU = > 公尺蘭 = > 熱那亞，每一代都有改進的工藝和效能。
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）自研或公有雲
一般來說，公有雲中的SaaS服務具有快速部署、易維護的優勢，但比自建甚至雲端的IaaS產品更昂貴。
同類自研產品在公司私有雲上投入了大量的前期成本，並且擁有相對成熟的技術積累和專業的運維團隊，經過一定程度的標準化後，可以滿足同類產品在雲上的功能需求。 對於無法替代或轉化的低回報的自研產品，將通過調整使用場景和計費方式或尋找更好的同類產品進行替換。
隨著嗶哩嗶哩自建機房節點和傳輸網路建設的完善，未來更多的雲專案可以復用基礎業務和基礎設施，從而實現恆定私有雲+公有雲的混合部署，實現此類服務的混合雲解決方案。 基於上述實施措施的實踐，嗶哩嗶哩自主研發的HTTPDNS網域名稱解析、DSA動態加速等服務，節省了一半以上的成本。
4. 總結
如下圖所示，除了頻寬、伺服器、公有雲之外，IT成本還有很多其他的資源成本，所有的成本都需要分析和優化。 在分析和推進的過程中，形成了一套完整的成本模型。 隨著業務的不斷增長，成本模型和優化方案也在不斷增長。
7. 運營優化——多方溝通協作
運營優化圍繞兩個方面進行：
成本運營，依託預算、成本賬單和成本模型，及時與各方同步成本情況和問題。
資源運營，依託資源效率的最佳資料，及時發現和預防資源浪費。
1.成本運算
預算控制：為了將成本降低到極致，達到最佳成本，預算控制需要更加嚴格。 執行採購的預算實際時間可能比預算計畫時間晚了比較長，內部和外部都有變化，需要根據變化及時調整金額，以儘量減少金額。
決算分析：每月根據計費資料進行成本分析，重點溝通超預算或其他有改進空間的成本專案，溝通範圍為業務研發負責人、FinOps基礎平台、財務、採購等角色負責人。 對超出預算的風險進行預警，並一起討論改進措施和策略。
計費分析：協助業務理解賬單，從業務角度觸發賬單，分析單項DAU成本，為業務成本降低提供指標和決策依據。
成本：針對新的技術改造方案或專案，構建成本模型，確定成本改進的最優方案。
成本決策：構建成本模型並不難，但難點在於如何在追求更好的成本的同時兼顧穩定性和效率。 成本優化通常伴隨著技術公升級和技術改造，大量的人力投入會影響原計畫的迭代效率，系統公升級往往會帶來不穩定。 追求使用廉價資源也會影響系統的質量，系統設計需要兼顧容錯和備份策略。 一般來說，如果沒有強有力的管理來做出成本決策，降本增效的效果會大打折扣。
2. 資源運營
公有雲主機：結合利用率監控、混合雲平台和**業務賬單資料，對資源效率進行監控，發現不合理的冗餘容量和不再使用的資源，及時推進縮減、降級等操作。
公有雲服務：在資源檢查過程中，如果發現無人認領或不完整的資源，如仍在計費的閒置、未掛載的雲硬碟、歷史較長的快照等，我們會定期公告和清除。
IDC伺服器：對於利用率極低的伺服器，我們將推動將容器納入資源池，並盡可能容器化。
其他資源：各項服務的合理使用也需要操作學生注意，比如超長簡訊會拆分為多個計費，合理設計的簡訊模板可以節省大量成本。
總結與展望
通過FINOPS的實踐，嗶哩嗶哩實現了成本洞察=>成本優化=>運營優化的完整閉環。 通過效能資料、成本計費、持續優化、運營等關鍵行動，在不增加IT成本的情況下，實現了業務增長，為公司節省了數億成本。 未來，FinOps將繼續向實時資料驅動的決策和成本方向探索**，追求更極致的IT成本，提高毛利率。
引用
1]《finops foundation - what is finops?》：
2]《從量化到優化，細解有贊線下資料降本之路》：
作者丨崔燁， 馬 永志**丨***嗶哩嗶哩科技 （ID： Bilibili-TC） DBAPLUS社群歡迎技術人員投稿，投稿郵箱editor@dbapluscn