一、背景
當前，降本增效是各大互聯(lián)網(wǎng)公司的重要方向，IT成本則占據(jù)了互聯(lián)網(wǎng)公司成本的大頭。如何有效的降本？如何推動各業(yè)務線配合？如何平衡成本、質(zhì)量和效率？本文將介紹B站的IT成本管理和優(yōu)化的思路，介紹B站通過落地FinOps，推進成本洞察、技術(shù)優(yōu)化和運營優(yōu)化，提升資源效率的經(jīng)驗。2022年，在B站DAU穩(wěn)步增長的情況下，IT成本花費金額低于21年同期，為公司節(jié)省了數(shù)億成本。項目團隊也獲得了公司2022年度技術(shù)突出貢獻獎。
二、歷史
IT的成本管理主要是針對預算的管理，每財年開始的時候完成整個財年的預算編制。在預算編制的過程中，將業(yè)務目標轉(zhuǎn)化為成本，結(jié)合技術(shù)優(yōu)化方案，定下來降本目標。業(yè)務增長目標加上降本目標得出成本目標。
預算定好了，降本目標也定好了，那是不是按部就班的執(zhí)行就好了？這中間暴露出來幾個問題：
- 預算過程中技術(shù)中臺參與不夠，業(yè)務直接提預算，技術(shù)中臺最后被告知資源需求。
- 預算內(nèi)的需求變成白名單，采購流程時直接pass，預算控制力度不夠，容易造成浪費。
- 缺乏業(yè)務視角的全域賬單，業(yè)務對成本無感知，預算外的優(yōu)化動力不足，成本控制很難超預期，甚至可能不達預期。
其中最重要的是最后一個問題，業(yè)務對資源效率和成本無感知，那么降本的收益也就難以評估，業(yè)務的降本動力就會不足。
三、效能大盤——感知資源利用率
既然降本目標已經(jīng)下達，行動就迫在眉睫。
一開始我們延續(xù)傳統(tǒng)思路，提到降本增效，第一反應就是各類資源利用率。與所有互聯(lián)網(wǎng)公司的敏捷性相同，我們基于內(nèi)部的平臺和資源，整合監(jiān)控系統(tǒng)、資產(chǎn)管理系統(tǒng)、混合云HCRM系統(tǒng)等基礎數(shù)據(jù)，使用數(shù)據(jù)平臺的數(shù)倉能力，快速搭建了資源數(shù)倉、數(shù)據(jù)看板與告警機制?；跉v史數(shù)據(jù)，希望支持業(yè)務資源預估和制定降本目標等活動。
根據(jù)B站的成本占比數(shù)據(jù)，我們重點設立了核心關(guān)注的是帶寬資源和計算資源的利用率相關(guān)指標。
- 帶寬資源涵蓋各類CDN帶寬、云帶寬和IDC帶寬；
- 計算資源則涵蓋自有服務器、云虛擬機、租賃裸金屬服務器等資源。
當前我們已經(jīng)實現(xiàn)，針對對不同供應商，將同類資源的不同指標進行歸一化，例如多云場景下不同云廠商的指標對齊。對于GPU這類資源，還會考量訓練、推理等不同場景下的利用率等。
為了更好的聯(lián)動其他團隊，我們還給公司內(nèi)各類技術(shù)中臺建立效能模型，注重計算、存儲等各類平臺模型都有不同，以容器平臺為例：
關(guān)注以上指標，可有效評估容器平臺的資源效能，支持平臺做資源水位線管理，度量使用效率和技術(shù)優(yōu)化空間。
經(jīng)過一段時間的實踐，盡管拉著資源使用者聊利用率、巡檢各部門空閑機器、甚至定期制作各類排名榜單，我們還是發(fā)現(xiàn)降本工作推進緩慢。技術(shù)中臺與業(yè)務部門間難以聯(lián)動、研發(fā)人員缺乏成本意識、無法量化降本產(chǎn)出等核心問題依舊難以解決。
那段時間，碰上行業(yè)內(nèi)越來越多公司開始重視降本增效，在與其他公司的相關(guān)從業(yè)者多次交流討論后，一個概念逐漸出現(xiàn)到我們眼前——FinOps（Financial Operations）。
四、FinOps概念——確定行動步驟
按照FinOps Foundation給出的定義，F(xiàn)inOps是一種不斷發(fā)展的云財務管理規(guī)范和文化實踐，通過幫助工程、財務、技術(shù)和業(yè)務團隊，基于數(shù)據(jù)驅(qū)動，在支出決策上展開合作，使得組織能夠獲取最大的業(yè)務價值。
當前云原生成為技術(shù)選型的共識，B站內(nèi)部平臺和系統(tǒng)也大多選擇了云原生的道路。B站的云原生是搭建在私有云、公有云的多云環(huán)境上的，其中私有云底層資源為租賃IDC和自有服務器資產(chǎn)。FinOps的整個框架不僅適用于公有云上的資源和成本管理，也同樣適用于私有云，整體的工作思路和邏輯是一致的。
從上面FinOps Framework可以看到，參與Finops的角色很多：
- 企業(yè)高管
- 業(yè)務負責人
- 工程和運維團隊
- 財務和采購
- FinOps實踐者
做為FinOps實踐者，需要聯(lián)合業(yè)務、平臺、運維、基礎工程、財務和采購團隊一起，對IT成本進行有效管理和優(yōu)化。
FinOps的生命周期分為三個階段：
- 成本洞察
- 成本優(yōu)化
- 成本運營
在反復研究相關(guān)理論后，我們定下了B站基于FinOps視角下降本的實驗路徑：
- 成本量化打基礎，通過賬單提升業(yè)務對成本的感知。
- 技術(shù)降本和運營降本“雙駕馬車”并行推進。
- 通過事前計劃、事中控制、事后分析多項舉措，將成本的指標納入業(yè)務方案和商務采購的考量，成本控制貫穿在整個資源生命周期的管理。
五、引入財務視角——洞察技術(shù)成本
所有技術(shù)需求的開展都離不開其底層資源，而各類IT資源的成本，需要納入財務對各業(yè)務線的ROI考核中。但在之前很長一段時間內(nèi)，業(yè)務線可能只有一個預算的大概數(shù)字，并不了解細節(jié)，自然也不能引起重視。也就沒有量化分析的基礎，很難明確優(yōu)化的目標和方向。
為了更好的衡量技術(shù)成本，將每一筆IT資源的采購成本，折算到每個業(yè)務甚至每次活動中，為了讓每個業(yè)務線都能清楚錢花到哪里去了，了解其IT成本及具體構(gòu)，我們首先引入財務中的兩個概念。
1、CAPEX和OPEX
- CAPEX（Capital Expenditure，即資本性支出）：對應預算現(xiàn)金流口徑，指實際支出的金額。
- OPEX（Operating Expense，即運營支出）：硬件一次性支出按照會計科目折舊計算，帶寬服務類非一次性支出和CAPEX一致。
想要將CAPEX轉(zhuǎn)化為OPEX，就需要計算TCO（Total Cost of Ownership），將采購硬件資產(chǎn)的一次性成本分攤到該資產(chǎn)的生命周期里。以一臺服務器為例，直接采購成本即為CAPEX，將采購成本分攤到今后使用的每個月，再增加服務器每月配套使用的其他資源成本，即可得到TCO模型：
- （1）其中Server_Tco-month為一臺服務器每月的TCO金額。
- （2）Depreciation為按照標準會計準則，單臺機器的每月折舊金額。
- （3）Net為租賃IDC中所有網(wǎng)絡設備的每月折舊。
- （4）Idc為當月IDC中發(fā)生的所有成本，含機柜、電力、維護等。
- （5）Line為連接IDC間內(nèi)網(wǎng)專線線路的每月費用。
- （6）f_1是單臺服務器分攤函數(shù)，以算出除折舊外，單臺服務器的每月其他成本。
2、定價
B站的業(yè)務搭建在公有云和私有云上，想要各個業(yè)務了解成本，需要公有云和私有云都能計費和拆帳。將IT資源和對應的成本掛鉤。技術(shù)中臺想要和公有云一樣具備計費、出賬和對賬的能力，則需要統(tǒng)一設計和升級。各技術(shù)中臺需設計計費的SKU（即平臺售賣的產(chǎn)品），定好價格策略，然后統(tǒng)計各業(yè)務的資源用量，最終實現(xiàn)向內(nèi)部業(yè)務計費出賬。
SKU設計時即考慮和公有云平臺對齊，以便和公有云成本對比。又需要兼顧公司的實際業(yè)務場景需求。例如，容器平臺的一種CPU產(chǎn)品定價模型如下：
- （7）Cost_total是該類容器平臺SKU對應自有服務器的總成本，n為該SKU對應的所有服務器。
- （8）Price_cpu為CPU定價。
- （9）Ratio_cpu為CPU成本系數(shù)，用于折算服務器中CPU關(guān)聯(lián)的成本。
- （10）Cpu_total是對應所有機器的總邏輯核數(shù)。
- （11）loadfactor為利用率水位線，參考值為近期該SKU對應物理服務器的合理水位線。
- （12）(Cpu_total*loadfactor)就為理論上的總服務量。
對于其他技術(shù)中臺的SKU，基本適用以上“單價=SKU對應TCO/理論總服務量“的模式。由于技術(shù)中臺沒有盈利壓力，賬單只是為了合理的反應業(yè)務成本，推動業(yè)務提升使用資源的效率，所以平臺資源利用率的提升讓可售賣的資源更多了，降低了單個資源的單價，業(yè)務從成本上也能受益。
3、計費
成本=單價*用量。單價有了，接下來需要確定業(yè)務各SKU的計費用量了。我們大致將用量的統(tǒng)計方式分成了兩類，共享與獨占。還是以容器平臺的上述SKU為例：
- （13）t為資源使用時長。
- （14）Usage_shared為共享類資源用量統(tǒng)計方式，Limit是該服務申請容器的CPU資源限制。
- （15）Usage_exclusively為獨占類資源用量統(tǒng)計方式，Capacity為該服務所在pool的所在物理資源上限，loadfactor為該資源利用使用率上限。
在實際計算中，即使A（獨占類）、B（共享類）兩個服務實際消耗的CPU相同，A的計費用量也會高于B的。因為A所在資源池就算無服務運行，其獨占的特性也使其他服務無法調(diào)度進來，造成浪費。因此在成本量化上，按其資源池理論最大使用量進行收費。相對的，共享資源池內(nèi)的空閑節(jié)點可調(diào)度其他服務，按服務實際申請容器的limit進行收費。
通過區(qū)分獨占、共享用量統(tǒng)計邏輯，更多的業(yè)務方選擇收費更低的共享類資源，服務器資源的歸屬逐漸從業(yè)務方，轉(zhuǎn)向技術(shù)中臺，這使得中臺承擔更多的容量管理工作。原本在公司采購服務器流程中：預估業(yè)務目標->轉(zhuǎn)化機器數(shù)量->提出采購需求->中臺交付資源，技術(shù)中臺不會過多參與整機數(shù)量評估，業(yè)務需求采買多少服務器，中臺最終就交付、托管多少臺的服務。
而現(xiàn)在，整個流程改進為：預估業(yè)務目標->中臺轉(zhuǎn)化算力需求->評估全局算力缺口->提出采購需求。中臺會收集各業(yè)務需求，再結(jié)合自身存量資源，提出缺口算力對應的采購需求，從而減少資源采買。
4、賬單
“成本=單價*用量”，可以從折舊（Opex）的角度，客觀反映出平臺空閑與超賣情況，推動技術(shù)中臺和業(yè)務協(xié)同優(yōu)化，并量化成本收益。
- 技術(shù)中臺：角色轉(zhuǎn)變?yōu)閷蝺r負責，通過提升資源利用率、技術(shù)架構(gòu)升級，減少平臺底層資源采買，多供應商的議價能力，降低各類SKU的單價，各優(yōu)化項目可以明確的轉(zhuǎn)化為成本收益，讓技術(shù)中臺的成本更具競爭力。
- 業(yè)務方：通過治理應用實例的數(shù)量/存儲量、規(guī)模、使用時長、共享與獨占方式切換，降低SKU的用量。
雙方齊頭并進，合作共贏，優(yōu)化IT成本。
賬單生成好了，下個主要問題是讓業(yè)務負責人了解賬單并Review成本，從而確定后續(xù)優(yōu)化方向。賬單的確認流程由統(tǒng)一的出賬系統(tǒng)實現(xiàn)，具體成本分攤的規(guī)則、資源定價和出賬的流程都在系統(tǒng)里定義。系統(tǒng)里還有各類資源IT成本模型，能夠量化資源與成本關(guān)系，最終將每一種IT成本以統(tǒng)一的形式發(fā)送給業(yè)務方。
依托于出賬系統(tǒng)，公有云和私有云成本都能在統(tǒng)一的賬單里展示，業(yè)務查看賬單就能知道完整的IT成本構(gòu)成。每月各業(yè)務技術(shù)負責人在收到系統(tǒng)推送的賬單后，需完成對賬Review，并在系統(tǒng)中確認賬單。如對賬單細節(jié)有疑問可在系統(tǒng)中標注反饋，出賬平臺將修正賬單。
這里其實包含了很多的溝通成本，業(yè)務剛開始收到一份賬單，是很難看懂賬單的，需要有人"翻譯"一下。業(yè)務是業(yè)務視角，賬單是資源視角，一個業(yè)務或者一個功能對應到哪些資源上，各類資源的含義都需要解釋和說明。
對賬中最困難的其實是“資源歸屬業(yè)務”的準確性問題。挑戰(zhàn)來自公司組織架構(gòu)的各種調(diào)整，業(yè)務和資源的不斷變化，還有歷史包袱，有些歷史資源歸屬不清等等。
為確保歸屬的準確性，歸屬映射關(guān)系從服務樹（CMDB）同步。每一個微服務應用都有自身的APPID（Application Identification）。出賬系統(tǒng)通過APPID來進行應用的唯一定位與關(guān)聯(lián)相關(guān)資源的項目、部門和負責人等信息。基于CMDB的APPID（服務/應用粒度）=>項目=>組織架構(gòu)=>業(yè)務的關(guān)系，實現(xiàn)多維度的成本視角，應用視角，部門視角或者業(yè)務視角。
非服務樹（CMDB）支持的資源，則通過各平臺自身維護的歸屬映射，以實現(xiàn)多種方式的成本歸屬。例如大數(shù)據(jù)平臺基于工作空間的歸屬關(guān)系。
與此同時，成本數(shù)據(jù)的實時性也影響到成本監(jiān)測和優(yōu)化分析的有效性。日級別或者更加實時的賬單，能協(xié)助業(yè)務快速發(fā)現(xiàn)和定位成本問題，及時調(diào)整項目投入。提升實時性也是后續(xù)賬單系統(tǒng)的迭代方向。
總結(jié)一下，整個流程就是：**平臺出賬=>業(yè)務對賬=>賬單分析=>針對性優(yōu)化=>優(yōu)化效果反映到下一出賬周期的資源對賬，這樣一套閉環(huán)流程。**通過對賬，將IT成本及時同步給Finops中各類干系人，強化成本責任制，為IT成本優(yōu)化決策提供數(shù)據(jù)支撐。同時反映IT成本優(yōu)化效果、預算執(zhí)行情況等指標。
六、成本優(yōu)化思路——實操經(jīng)驗總結(jié)
成本賬單有了，效能大盤也有了，接下來該在哪些方向上推進成本優(yōu)化呢？如何有效推進成本優(yōu)化落地呢？
首先讓我們來分析一下成本數(shù)據(jù)。B站的主要業(yè)務是點播、直播、電商、游戲等，做為一個以視頻為主的網(wǎng)站，B站的每年IT成本花費中，帶寬占比最大，其次是硬件，最后是公有云&其他IT服務類成本。想要做到成本優(yōu)化的收益最大化，那么在各類成本資源項上都需要投入優(yōu)化。
從業(yè)務角度看，不同的資源需求有著不同的成本模型。
從資源角度看，不同的計費方式有著不同的優(yōu)化思路。
- 帶寬計費：一般云廠商為日95月平均，也有月95，即每5分鐘打點，取一個周期打點的95峰值。也有包端口的帶寬計費方式?？梢酝ㄟ^削峰填谷的方法優(yōu)化成本。
- 機柜計費：月租為主，也有電柜分離的計算方式，通過機柜電力合適的配比優(yōu)化成本。
- 服務器：一次性成本，通過維保增加從而減少攤銷成本。通過提升CPU利用率減少硬件采購。
- 配件：通過改配，打破硬件的瓶頸，提升硬件性能，節(jié)省成本。
- 云服務：按照用量計費，不同云服務的計費方式差異大，彈性是最大的優(yōu)勢。對彈性需求高的業(yè)務適用，例如游戲。
1、帶寬成本優(yōu)化
帶寬成本是成本的最大頭，從使用角度可以分為點播帶寬、直播帶寬、Web帶寬。其中Web帶寬又細分為動態(tài)帶寬和靜態(tài)帶寬。
- 點播帶寬：點播業(yè)務使用的流媒體帶寬。成本最高，優(yōu)化投入最大。
- 直播帶寬：直播業(yè)務使用的流媒體帶寬。成本僅次于點播帶寬，優(yōu)化方向區(qū)別于點播。
- Web動態(tài)帶寬：動態(tài)接口使用的帶寬，CDN回源率100%，不可緩存。
- Web靜態(tài)帶寬：圖片、js、apk等靜態(tài)文件使用的帶寬，可緩存。
（1）點播帶寬成本模型
下面以點播帶寬舉例，點播帶寬的成本模型如下：
點播帶寬成本 = 平均單次播放帶寬 點播播放次數(shù) 帶寬單價。
- 平均單次播放帶寬：是用來衡量單次播放的成本，這里的帶寬計算的是95計費值，所以不完全等于碼率，但是和碼率趨勢相同。碼率低則單次播放帶寬更低，碼率的優(yōu)化效果會體現(xiàn)在此指標上。編碼團隊通過窄帶高清轉(zhuǎn)碼系統(tǒng)，AV1等技術(shù)方案優(yōu)化15%的帶寬。
- 點播播放次數(shù)：和業(yè)務發(fā)展相關(guān)，難以準確預測，如超預期增長，則整體IT成本會有不小的增加，有超預算的風險。
- 帶寬單價：點播使用的帶寬資源多樣，既有云廠商提供的點播帶寬，又有自建CDN帶寬，還有PCDN、mCDN等廉價帶寬。不同資源單價不一樣，這些帶寬的占比影響了點播的綜合單價。
（2）點播帶寬優(yōu)化思路
從上述簡化的模型分析可以分析出點播帶寬的優(yōu)化主要是思路是降低碼率和降低單價，實際推進的優(yōu)化項目主要如下：
- 通過窄帶高清編碼系統(tǒng)，上線并擴大AV1覆蓋，進一步降低碼率
- 基于機器學習做優(yōu)化轉(zhuǎn)碼預測，提升優(yōu)化碼率的覆蓋
- 優(yōu)化視頻播放的清晰度策略
- 提升廉價帶寬PCDN、mCDN占比，降低帶寬平均單價
- 自建CDN專線互聯(lián)，降低回源成本
- 內(nèi)容分層，冷的內(nèi)容調(diào)度到聚邊資源，降低回源帶寬量
- 削峰填谷，和其他業(yè)務帶寬共峰復用
除了點播帶寬，上述的直播、Web動態(tài)、Web靜態(tài)都同步推進優(yōu)化，思路也是從成本模型數(shù)據(jù)分析出發(fā)，優(yōu)化前核算成本，優(yōu)化后驗證收益。
2、服務器成本優(yōu)化
服務器硬件優(yōu)化不同于帶寬，主要使用利用率來衡量優(yōu)化效果，同時采用TCO或者Opex來核算和評估技改優(yōu)化方案。
（1）服務器硬件迭代
- 英特爾CPU從Skylake => Cascadelake => Icelake =>Sapphire Rapids，每一代在功耗和單核性能上都有提升。
- AMD CPU從Rome => Milan => Genoa，每一代工藝和性能上都有提升。
- GPU從T4、V100、A10、A100到A800，工藝和性能也在變化。
- 網(wǎng)絡的架構(gòu)也從10Gbps，到25Gbps，再到100Gbps甚至200G。
硬件的迭代速度是飛速的，每一次的硬件迭代，也刷新了單位算力的成本的下限。既然新的硬件更有成本優(yōu)勢，那么應該盡量引導業(yè)務配合硬件升級，每個硬件代次的迭代成本優(yōu)化效果都是非常顯著的。
同時，硬件功耗的增長也是飛速的，機柜從3KW、4KW、8KW到10KW，機柜和電力成本優(yōu)化的收益也會非?？捎^。在IDC的布局和選擇上，可以選擇更加廉價的資源，將接入的POP點和IDC解耦，以達到性能和成本的最優(yōu)。
（2）服務器虛擬化和混部
基于K8S構(gòu)建的私有云容器平臺，是服務器成本優(yōu)化的主力。平臺也發(fā)表過多篇文章分享混部和VPA技術(shù)。讓我們來整體看下優(yōu)化思路，還記得前面講的效能模型嗎？容器平臺的優(yōu)化就是基于資源的效能模型。
提升容器總資源量：將服務器資源盡量都容器化，讓更多的業(yè)務都搭建在容器之上，不止業(yè)務應用，其他的技術(shù)中臺的應用也要盡量接入到容器平臺中。
提升池化率（可售賣的資源量/總資源量）：提高池化率主要是在有限的資源上，盡量增加可售賣的資源量，讓更多的資源都是通過統(tǒng)一的容器調(diào)度。
提升分配率（已售賣的資源量/可售賣的資源量）：不同分配率的資源池可以考慮合并，減少資源碎片和冗余。
提升利用率（使用資源量/已售賣的資源量）：利用率不足將造成資源的極度浪費，通過建立應用畫像，利用超賣、VPA、HPA等有效手段，資源利用率得到大幅提升。
除了以上的手段，混部也是提升利用率的一大利器。利用不同業(yè)務的潮汐效應，分時復用資源。轉(zhuǎn)碼做為算力密集型業(yè)務，最早嘗試混部。目前B站已經(jīng)對離線-離線，在線-離線間進行了混部，也有相關(guān)的技術(shù)分享文章。
當前在推進的主要是AI場景下的混部，也就是推廣搜業(yè)務的混部。AI業(yè)務不僅是計算密集型，訪存帶寬也非常高，會觸達硬件瓶頸，造成雪崩效應，因此混部策略需要更加謹慎。
3、公有云成本優(yōu)化
不同于服務器資源，公有云承擔彈性保障、降低延遲、海外部署等用途。而公有云的成本優(yōu)化，是為在支持業(yè)務正常發(fā)展的前提下，最大程度使用公有云資源即買即用的特性。
根據(jù)資源類型與其對應的計費方式，公有云上資源大致可分為網(wǎng)絡流量、云服務器等IaaS資源、云上SaaS服務等資源。不同資源，需對癥下藥。
（1）根據(jù)業(yè)務特性適配資源
云上項目根據(jù)業(yè)務特性，會產(chǎn)生波形截然不同的網(wǎng)絡流量，而云廠商提供的網(wǎng)絡流量產(chǎn)品也根據(jù)特點還有不同的計費方式。需同時考慮此二者關(guān)系，才能做到網(wǎng)絡成本最優(yōu)。
常見的網(wǎng)絡類產(chǎn)品計費模式有按帶寬計費和按流量計費：
- 按帶寬計費：適用于業(yè)務流量峰值在不同時間段分布平均，無明顯的流量波動場景
- 按流量計費：適用于業(yè)務流量波動較大，有突發(fā)的場景。
除計費模式外，網(wǎng)絡線路類型也有不同選擇，例如動態(tài)BGP、靜態(tài)BGP、三大運營商單線、公網(wǎng)或混合云專線等，會讓成本有較大差異，同樣需要根據(jù)業(yè)務的架構(gòu)方案及成本模型進行選擇。
- 對于帶寬、運營商占比穩(wěn)定、且技術(shù)方案可兜底單點故障的項目，優(yōu)先使用三大運營商單線。
- 對于帶寬波動大、三大運營商無法覆蓋、海外部署或流量較小的項目，優(yōu)先使用BGP。
- 而跨地域帶寬較高、回源量大的項目則考慮使用混合云專線。
在此基礎上還可考慮其他策略，例如將多個項目的網(wǎng)絡流量放進一個共享帶寬包，可實現(xiàn)帶寬的共峰收益。
（2）預先規(guī)劃與定期釋放
IaaS類資源多以實例*使用時長的形式計費，因此可在申請階段就控制新增資源量。大型項目的容量、實例組合和付費策略在申請時就要求有明確規(guī)劃。
申請方提交資源需求后，F(xiàn)inOps各方會基于業(yè)務特點、成本等考慮，確定供應商、地域、資源型號等事宜。
（3）自研or公有云
通常情況下，公有云的SaaS類服務擁有快速部署、簡易維護等優(yōu)勢，但相較自建乃至云上IaaS產(chǎn)品會有更高的定價。
同類自研產(chǎn)品在公司內(nèi)私有云已投入大量前期成本，擁有較為成熟的技術(shù)積累和專業(yè)運維團隊，在經(jīng)過一定的標準化改造，可滿足云上同類產(chǎn)品的功能需求。而對于自研暫無法替代或改造收益不高的產(chǎn)品，會通過調(diào)整使用場景、計費方式或?qū)ふ覂r格更優(yōu)的同類產(chǎn)品替代。
隨著B站自建機房節(jié)點與傳輸網(wǎng)絡建設程度提升，后續(xù)更多云上項目可復用基礎服務和基礎設施，做到常量私有云+公有云混合部署，突發(fā)公有云彈性兜底，實現(xiàn)此類服務的混合云方案?；谏鲜鰣?zhí)行辦法的實踐，B站的自研HTTPDNS域名解析、DSA動態(tài)加速等服務，已節(jié)省超過一半的成本。
4、小結(jié)
如下圖，IT成本除了帶寬、服務器、公有云，還有很多其他資源成本，各項成本FinOps都需要分析并推動優(yōu)化。在分析和推進的過程中，形成了一套完整的成本模型。隨著業(yè)務不斷的發(fā)展，成本模型和優(yōu)化方案也在不斷進步。
七、運營優(yōu)化——多方溝通協(xié)同
運營優(yōu)化是圍繞兩個方面開展的：
成本運營，依托于預算、成本賬單和成本模型，及時和各方同步成本情況和問題。
資源運營，依托于資源效能大盤數(shù)據(jù)，及時發(fā)現(xiàn)并制止資源浪費現(xiàn)象。
1、成本運營
預算控制：為了降本做到極致，達到成本最優(yōu)，預算控制需要更加嚴格。預算實際執(zhí)行采購的時間可能和預算規(guī)劃時間已經(jīng)間隔比較長了，內(nèi)部和外部都發(fā)生了變化，需要及時根據(jù)變化進行調(diào)整，盡量減少金額。
決算分析：每月基于賬單數(shù)據(jù)進行成本分析，將超預算或者其他有改進空間的成本項進行重點溝通，溝通范圍為業(yè)務研發(fā)負責人、基礎平臺負責人、財務、采購等FinOps各角色。對超預算的風險進行預警，共同商議改進措施和策略。
賬單分析：協(xié)助業(yè)務理解賬單，從業(yè)務角度觸發(fā)，分析單DAU成本，為業(yè)務降本提供指標和決策依據(jù)。
成本核算：對于技術(shù)改造的新方案或項目，構(gòu)建成本模型，決策出成本改進的最優(yōu)解。
成本決策：成本的模型搭建不難，難的是如何在追求成本更優(yōu)的情況下，兼顧穩(wěn)定性和效率。成本優(yōu)化通常伴隨著技術(shù)升級和技術(shù)改造，大量的人力投入會影響原來計劃的迭代效率，系統(tǒng)升級也常常會帶來不穩(wěn)定因素。追求廉價資源的使用，也會影響系統(tǒng)的質(zhì)量，需要系統(tǒng)設計上能考慮到容錯和兜底策略?？偟膩碚f，如果沒有強有力的管理層做成本決策，降本增效的效果將會大打折扣。
2、資源運營
公有云主機：結(jié)合利用率監(jiān)控、混合云平臺及供應商賬單數(shù)據(jù)，需要監(jiān)控資源效能情況，發(fā)現(xiàn)不合理的冗余容量、不再使用的資源，及時推進縮容、降配等操作。
公有云服務：資源巡檢過程中，若發(fā)現(xiàn)無人認領、未清退完全的資源，例如閑置未掛載的卻仍在計費的云硬盤，歷史悠久的快照等，會定期公示并清退。
IDC服務器：對于利用率極低的服務器，推進納入容器的資源池中，盡量容器化。
其他資源：各服務使用的合理性也需要運營同學關(guān)注，例如超長短信會拆成多條計費，合理設計短信模板，能節(jié)省大量成本。
總結(jié)與展望
B站通過對FinOps的實踐，實現(xiàn)了成本洞察=>成本優(yōu)化=>運營優(yōu)化的完整閉環(huán)。通過效能數(shù)據(jù)、成本賬單、持續(xù)優(yōu)化和運營等關(guān)鍵行動，達成了業(yè)務增長而IT成本金額不增長，為公司節(jié)省了數(shù)億成本。后續(xù)FinOps將繼續(xù)在實時數(shù)據(jù)驅(qū)動決策、成本預測等方向繼續(xù)探索，追求更加極致的IT成本，提升毛利率。
參考資料
- [1]《FinOps Foundation - What is FinOps?》： https://www.finops.org/introduction/what-is-finops/
- [2]《從量化到優(yōu)化，詳解有贊離線數(shù)據(jù)降本之路》： https://www.finops.org/introduction/what-is-finops/
作者丨葉翠、馬永智 來源丨公眾號：嗶哩嗶哩技術(shù)（ID：bilibili-TC）