內容來源：DevOps案例深度研究第4期 – B站 DevOps實踐研究戰隊（本文只展示部分PPT及研究成果，全程視頻請移步文末）轉載請註明出處。
本案例內容貢獻者：曹坤良，董沙莎，過佳昱，廖定，李晶晶，李思源，歐美玲，任廣印，Ruth，姚丹，張楠
IDCF指導老師：徐磊、姚冬、王立傑、許舟平
原文首發於「老廣的印記」
Bilibili簡稱B站，是中國年輕人聚集的文化社區
月活躍用戶量 1.28億人
18-35歲用戶佔總用戶數78%
一、文化和歷史
B站，被粉絲暱稱為“小破站”，為中國年輕一代高度聚集的文化社區和視頻平臺，深受年輕用戶的喜愛。經過十年多的發展，圍繞用戶、創作者和內容，構建了一個源源不斷產生優質內容的生態系統 ，B站已經成長為一個涵蓋7000多個興趣圈層的多元文化社區。
B站原名叫：Mikufans彈幕網。最早的雛形是“初音未來”的粉絲交流社區。於2010年1月改為提供視頻資源的網站，並正式改名為Bilibili。
嗶哩嗶哩的名字來源於《某科學的超電磁炮》，創始人徐逸是這部動漫的狂熱粉絲，女主角御坂美琴用硬幣打出電氣系技能超電磁炮發出的聲音像Bilibili，徐逸覺得這個名字好聽又好記，所以將Mikufans改名為Bilibili。而御坂美琴發射電磁炮的硬幣，也成為B站現在的通用貨幣。
- 徐逸：創始人，意見領袖，重度動漫迷。曾任執行董事。2019年卸任法人代表和執行董事，目前負責社區運營。
- 陳睿：董事長兼CEO。曾任中國最早的互聯網軟件企業之一金山軟件聯合創始人。2011年，陳睿以天使投資人的身份加入B站；2014年，正式加入B站擔任董事長。
- 李旎：首席運營官。
B站企業文化關鍵詞：社區優先，正直誠信，合作共贏，極致執行
我們可以看到，B站企業文化關鍵詞第一位的是社區優先，董事長陳睿曾經說過，B站在社區文化建設中的兩個初心：
- 為用戶構建好的社區。
- 為創作者搭建施展才華的舞臺。
二、社區運營生態
B站2019年的跨年晚會非常成功，收穫了非常多的讚譽，在豆瓣的評分高達9.2，截止二月底累計播放量9075萬次，彈幕總數294萬，最高在線人數8000萬，被稱為最懂年輕人的晚會。
B站跨年晚會成功的背後 - “B站對於不同年齡的用戶畫像的深刻理解和把握”。
B站的用戶群體大部分是年輕人，可以看這張統計圖，24歲以下的使用人群超過B站用戶的的38%。
B站還是中國最大的音樂創作平臺之一，中國增長最快的 vlog 社區，中國最大的在線自學平臺等等。
這背後最大的原因，就在於B站對於不同年齡段用戶的用戶畫像的深刻理解和把握。
B站最典型用戶畫像-Z世代。
報告顯示，目前，全球Z世代有24億人，佔全球人口的32%，而在中國，Z世代的用戶約佔20%。
針對這樣的一群金主，B站是如何做的呢?
形成了以 " 原創內容 + 用戶 + 彈幕 " 的交互方式所構築的強粘性社區生態環境， 以及由 “UP 主 - 內容 - 社區用戶”所組成的循環生態。
這個生態是一個不斷自增長的閉環。隨著UP主群體的不斷擴大，社區內容也向多元化發展，同時又吸引了更多的用戶。
B站的這種以內容即社交的“打開方式”，正是B站在年輕人中受到歡迎的主要原因。
三、用戶價值為導向的需求管理
下面我們來介紹B站以用戶價值為導向的需求管理，前面已經介紹了B站以用戶價值為核心的企業文化和運營生態，如何通過產品研發和系統實現呢？首先介紹用戶價值為導向的需求管理。
B站的用戶價值以業務需求為載體，通過需求分析的篩選，快速地流入到研發並投產上線，並通過上線後的運營和用戶來持續優化產品，實現整個業務價值的閉環。遵循DevOps的核心思想，持續快速的迭代反饋，特別是在用戶需求的收集分析管理和用戶反饋上，凸顯出對用戶價值的關注。接下來我們重點分析。
首先是用戶分析，我們看看B站核心用戶畫像。
- 二次元用戶（核心目標用戶）：可以追番劇，瞭解二次元文化，希望能認識更多同好。
- UGC創作者（核心目標用戶）：希望有一個大平臺可以讓自己作品被看到，收到大家認同。
- 直播愛好者：希望有平臺能展示自己的才能。
- 非二次元用戶：只是單純地希望能找到有序的視頻，或跟隨喜歡的UP主或主播而來。
有了清晰的用戶畫像，可以分析出B站的需求主要分為視頻內容、用戶體驗、社區文化和氛圍環境四類。
- 視頻內容主要包括番劇、原創視頻及UP主自制類視頻功能，加上以用戶為中心的頁面佈局、交互等用戶體驗設計，這兩類需求針對核心用戶佔比會比較大，也呼應了前面的注重核心用戶價值和體驗。
- 社區文化類主要包括會員管理及支撐圈層的需求；氛圍環境類包括彈幕和交流環境以及相關審核的需求，這兩塊為共同愛好者持續的交流分享營造一個良好的氛圍，為核心功能提供支撐，這是B站重點響應的部分。
需求的收集主要從兩個方面：
- 一方面通過全面分析商業價值、用戶價值、分解轉換為具體實現的需求；
- 另一方面在快速響應需求上線以後，收集用戶反饋來持續完善產品的需求。
對於需求的優先級排序，B站有自己管理方法。
- 首先它是基於用戶及商業價值的分析，基於核心用戶的訴求和用戶畫像，優先考慮需求的迫切程度，通過良好的用戶體驗既維持老用戶的粘度。對於系統運行穩定的一些非功能性的需求，也作為重點的排序考慮。
- 另外基於商業價值考量，針對付費用戶，用付費情況來衡量需求價值，更量化且與商業接軌。
- 考慮用戶與商業價值分析的同時，B站也會使用四象限法來進行需求的篩選和排序，通過需求的用戶範圍、發生頻率和成本、效益，進行綜合分析排序，確保用戶價值價值較高的需求能夠優先、快速地進入迭代循環，快速地上線並得到用戶的反饋。
B站採用多種方式來收集用戶的反饋，不僅包括了線下渠道的主動收集，而且還通過日誌採集、設置埋點等多種手段，線上自動採集運營數據。對於線上的採集，採取了收集用戶行為和用戶數據的方式，首先與業務方一起繪製需採集業務場景涉及的系統鏈路，然後系統分佈分別在客戶端和服務端設置埋點，採集用戶行為數據，記錄日誌。通過新功能灰度上線後目標用戶數據採集和分析，形成對需求的快速反饋，持續打磨完善產品。
通過以線上與線下相結合的用戶反饋收集機制，從用戶畫像分析、需求篩選排序到持續迭代反饋，用戶的價值在DevOps循環中快速流動持續交付，B站實現了以用戶價值為導向的需求管理的閉環。
四、高性能微服務實踐
一開始B站的技術以PHP為主，那時的代碼大家喜歡稱之為“KFC全家桶”，一套代碼包含了所有的東西，包括CDN的管理、轉碼、多媒體視頻的處理等等，都是通過PHP來完成的，當時就是這樣一套系統支撐著B站的業務運行。
這麼大的一個系統面臨著很多問題：
1）代碼維護難度大
- 文檔缺失，上手難度大。
- 理解業務邏輯很耗時。
2）基礎架構難以擴展
- 基於織夢CMS，一個開源的內容管理系統。
- 系統做了深度定製，底層邏輯沒幾個人能搞定。
- 業務聚合在一起，不易被擴展和拆分。
- 運行環境基本上只能通過創始人來擴展。
3）運維複雜
- 線上配置很複雜，代碼層面沒有設計路由系統。
- 運維已經不堪重負，已經禁止添加重寫規則。
B站成立的基礎是一個天才型選手，以前在那套系統加入了一些黑科技的東西，但同時也就限制了公司團隊的發展，基於這樣的一些重點問題，隨著業務的發展和團隊的不停增長，解決B站目前面臨的這些問題勢在必行。
4.1 服務化/微服務化
1）優勢
- 各個服務獨立開發。
- 分工明確，各自迭代。
- 單獨模塊獨立部署。
- 可獨立進行測試。
2）挑戰
- 依賴鏈條長，測試常常遇阻，影響測試結果。
- 各服務的一致性難以保證。
- 運維成本高，錯誤難定位。
- 基礎設施，網絡等要求都比較高。
針對業務邏輯進行垂直劃分切割，將一個巨大的服務體系，按業務邏輯切割成單元相對獨立的服務，如：評論、硬幣、稿件、收藏、feed等，服務間依賴標準採用RPC調用。
（微服務架構）
4.2 RPC框架
B站一開始是以PHP為主流開發語言，後來為了快速支撐業務的發展，Node、Java、Python等開發語言也相繼出現，導致B站的核心技術棧無法統一，對於微服務的落地，是兼容所有的語言基於現有架構改造，還是選擇統一的技術棧進行重寫？B站選擇了後者。
歸根結底，重寫後臺工程（主要是賬號相關的業務）是嗶哩嗶哩統一技術棧的一次嘗試，至於最後為啥選擇了用Go來實現RPC，在2017全球架構師峰會上，毛劍解釋很簡單：“主要就是我比較喜歡Go”，看似簡單的一句回答，其實支撐其選擇的原因還在於Go的諸多優勢：
- 強大的標準庫，解決了B站在視頻方面的問題。
- 和Docker容器化良好的支持。
- 二進制發佈，優秀的執行效率和開發效率。
- 易學易用上手快。
- 背靠Google大廠，豐富的開發者生態。
- 支持幾乎所有主流的框架。
又或者說，選擇Go非要有個原因麼？為什麼不能是Go呢？
1）B站的RPC框架
- 基於Go原生的網絡庫“net/rpc”。
- Gob進行struct的序列化，不需要拷貝額外的代碼，使用較為方便。
- 方法級的超時控制。
- 上下文context的支持。
2）服務註冊與發現Discovery
- 及時同步服務上下線事件。
- 服務發現節點自我發現。
- CP模式：依賴ZK的心跳進行廣播（ZK心跳遇到抖動時候，容易出現全服務下線 ，所以B站會根據服務節點變化數進行判斷是否放棄本次變更，進行容錯）。
- AP模式：polling + ping（優先保證高可用，犧牲部分一致性，但最終達到一致）。
3）配置中心
- 利用mysql做存儲管理相關配置信息。
- 通過http long polling來檢查配置變更確保及時生效。
- 獲取服務ip和版本，記錄meta信息，實現服務發現的功能。
4.3 高性能
微服務化以後，曾經的本地調用變成了遠程調用，曾經的多節點對等變成了分佈式的多節點，部署越來越複雜，調用鏈條越來越長，跨機房、跨網絡、跨機架等都可能造成性能損失。
1）鏈路加速（客戶端&服務端）
- 慢、流量貴（移動端）。
- HTTP DNS & Server List。
- 多CDN加速（規避風險）。
- 協議優化（壓縮、聚合、根據網速選擇資源等）。
2）網關優化（go自研，靈活可控）
- 動態配置
- 協議裝載
- 業務攔截
- 限流保護
- 緩存加速
- 鑑權
- 反作弊
- 業務服務
- 統計&監控
3）優化服務部署架構
多個組，小集群方式部署，每個組依賴更少的節點，這樣依賴資源有多套，相互之間也達到了隔離的作用。
（一旦某個服務出現問題，全體受影響）
（小集群，多個組，相互隔離，互不影響）
4.4 可用性
1）隔離
- 服務隔離：壓力分流，穩定性高，物理隔離。
- 輕重隔離：核心穩定，快慢分離，流量遷移。
- 物理隔離：進程隔離，集群隔離，機房隔離。e.g. 機器隔離，容器隔離
2）超時
- 設置超時：連接超時，讀取超時，寫入超時。e.g. 避免擠壓，防止雪崩
- 合理超時：避免過短，避免過長，動態設置。
3）限流
- 流量限流：accept，connection，thread。
- 資源限流：連接池，線程池。
- 請求限流：總數，時間窗口，平滑限流。
- 分佈式限流：redis + lua，nginx + lua。
- 接入層限流：nginx limit_req，nginx limit_conn
4)容錯
- 重試容錯：簡單重試，主備重試，成功率重試，快速失敗。
- 熔斷容錯：動態剔除，異常恢復。
5）降級
- 調用鏈路：UI降級，UI異步請求降級，功能降級，讀/寫降級，接入層降級，應用層降級。
- 自動降級：超時降級，統計失敗降級，服務故障降級，限流降級。
- 手動降級：功能開關，只讀緩存，寫異步化降級。
每個服務自身擁有比較健壯的服務能力，基本每個對外服務在代碼層都能兼顧到降級、限流、容錯、熔斷、安全、健康檢測。
通過鏈路追蹤保證，對錯誤能快速定位和精準定位，降低感知時間和修復時間。
6）Playbook 運維操作手冊
- 依賴的接口，必須加上熔斷。
- 當接口出現故障，自動熔斷，普羅米修斯出熔斷數據曲線圖，並且報警。
- 當超過N分鐘，服務仍然不恢復，可以使用配置中心的推送功能，打開強制熔斷，不再依賴接口。
- 當依賴方告知服務恢復，重新關閉熔斷開關，變成自動熔斷狀態。
7）運維層面，定期故障演練，確保流程可被正確可靠執行。
4.5 一致性
1）存儲一致性
- MySQL本地事務
- 本地事務+消息隊列
- Binlog
2）服務一致性
- 消息隊列
- 冪等
- 努力送達
- 事務補償
4.6 微服務部署發佈
1）灰度發佈 - 染色
- 在PaaS平臺上選擇灰度發佈-染色，定義染色標籤。
- 在IaaS平臺上開啟“環境代理”虛擬機。
- 鏡像選擇環境代理hasson-base最小配置即可。
- 在hasson的虛擬機錄入染色標籤，按需配置測試接口。
- DNS指向hasson IP，即可開始測試。
RPC meta info & context
serviceA(Red) -> serviceB -> serviceC(Red)
2）灰度發佈 - feature flag
- 儘早的進入主幹，可以跟灰度發佈結合使用（金絲雀發佈），需要使用統一的flag機制。
- 需要清理不再需要的flags，需要開發者養成良好習慣，正確使用flags，否則容易顯得很亂。
4.7 代碼管理
- 隨著業務發展，基礎庫變更頻繁，推進困難。
- 雖然重視代碼質量，但流程不夠自動化，完全靠自覺。
- 測試都積壓在發版前，質量難保證，發版風險大。
- 版本管理非常複雜，代碼複用率低下，維護成本高。
通過比對分散式管理方式和集中式管理方式，顯而易見，大倉庫的優勢在於統一版本依賴、增強協作、最大化複用代碼以及減少版本不一致所引發的各種線上運營風險。
1）大倉庫管理代碼帶來的好處：
- 統一版本控制
- 廣泛的代碼共享和重用
- 簡化依賴管理，避免菱形依賴
- 原子修改
- 大規模重構
- 跨團隊協作
- 靈活的團隊邊界和代碼所有權
- 代碼可見性以及清晰的樹形結構提供了隱含的團隊命名空間
(引自：Google為什麼要把數十億行代碼放到一個庫中？)
同時，大倉庫所帶來的的挑戰也很明顯，如何保證安全性，如何防止誤操作，如何減少每次checkout代碼的時間和編譯的時間，B站進行了如下的應對。
1）目錄級權限管理
2）統一的構建系統Bazel
- 支持多種開發語言。
- 依賴分析增量編譯。
- 可按需進行擴展。
3）更高的代碼質量要求
- 統一的代碼規範，便於協作。
- 單元測試覆蓋率，高質量傳承。
4）注重CodeReview，鼓勵溝通
- 保證業務邏輯代碼質量。
- 信息傳遞，擴充人員備份。
- buildup competence，提升集體戰鬥力。
- Ownership機制，責任到人。
五、數據運營
數據產生價值，該部分內容主要介紹B站日誌平臺、監控平臺和數據平臺。
5.1 日誌平臺
基於go自研日誌平臺Billions，主要由採集、傳輸、切分和檢索四部分構成。該系統打破各個業務研發日誌壁壘、規範日誌格式、收斂日誌接入方式，並統一傳輸、解析和存儲，整個系統高吞吐、低時延、高可用、高可運維性。
日誌採集agent同時支持服務鏈路日誌採集，隨著微服務化，一個請求聯動多個微服務，當出現問題時，根據日誌裡記錄的traceId，可快速檢索出相關服務調用信息、定位故障。
5.2 監控平臺
結束多個監控系統並存局面，基於prometheus搭建統一監控平臺，覆蓋業務層、應用層、中間件、基礎設施層全面監控。開源prometheus存在單點、存儲本地受限、配置維護難三個問題，B站基於聯邦方式部署prometheus，並將採集到的指標遠端存儲至influxdb中，關聯cmdb獲取監控對象，界面化配置告警規則，集中處理告警事件，形成高可用、擴展強、易用監控平臺。
5.3 數據平臺
讓監控、日誌數據產生更大價值，使用AI技術對用戶行為日誌分析生成用戶畫像，實現精準推薦；根據流量數據實時計算結果，及時調整渠道投放以達到最優效果等。
B站實時數據平臺-saber，解決實時計算開發門檻高、作業管理難、無統一告警及工程開發師和算法工程師之間明確分工問題。saber平臺支持BSQL和DAG拖拽式編程，約束輸入源schema，規範輸出源格式，降低flink開發門檻；同時解決流式Join、維表Join和實時特徵等數據處理過程中狀態、Timer、sql擴展等難點，讓工程無縫對接AI平臺。
六、結尾
B站十年的風雨路程，是伴隨著這一代人一起見證的。B站這十年，也是同這一代人一起成長的。B站的這些用戶，既是傳播內容的目的地，傳播效果的反饋源，更是傳播渠道的探尋者，傳播動力的新引擎。這類人為B站的內容生態，社區生態乃至產品生態提供了源源不斷的動力！
B站堅持的品質導向和價值觀優先原則為其平臺創造了較高的用戶壁壘，以其對用戶畫像的精準分析，準確把握了用戶的訴求，通過以用戶及商業價值為導向的需求分析和管理方式，以及日漸完善的監控反饋機制，將用戶最關心，最迫切的需求通過最敏捷的技術實現呈現在用戶面前，不斷迭代不斷創新。
雖然B站目前還未盈利，但他展現出來的良性生態循環，未來展現的價值還有更大的想象空間，畢竟：
“一代人終將老去，但總有人正在年輕。”
本文部分配圖來源於網絡，內容來源於網絡和B站分享內容。
本文以案例分析為目的，沒有任何商業意圖，案例產出文章轉載需獲得IDCF授權，並註明出處。
本文來源於DevOps案例深度研究第4期 – B站 DevOps實踐研究戰隊。
第4期DevOps案例深度研究交付包括《青春不老-B站持續交付案例分析》、《中國速度-火神山雷神山建設》、《“京”益敏捷-京東案例分析研究》、《自由的樂章-Spotify協奏曲》。
＋“CH050791”回“案例研究”，可獲得全部視頻~
閱讀更多 國際DevOps教練聯合會 的文章
