B站運維團隊成長的血淚史

胡凱，bilibili運維負責人，曾經就任於金山軟件、金山網絡、獵豹移動，負責運維相關工做。Bilibili是國內最大的年輕人潮流文化娛樂社區，銀河系知名彈幕視頻分享UGC平臺。

 

95後二次元新人類的追捧，讓以視頻彈幕、UP主聞名於世的bilibili（如下簡稱B站）愈發火爆，無數年輕人經過電腦、手機、電視等終端設備在B站上追番、看彈幕，特別是新番上線時的訪問壓力是很是大的，這就給B站的IT運維團隊帶來了巨大壓力。胡凱在去年加入B站剛剛成立的運維部，人少事多，遇到了不少坑。

本文根據做者在「監控與性能分享羣」中的分享內容整理。

 

B站運維痛點主要有3個：人手不足、故障多、運維繫統跟不上，針對這三個痛點，B站採用了三種方式進行破冰。

 

一、解放勞動力

目前B站的CDN主要是自建的，TB級帶寬，視頻存儲也已達到N個PB，運維壓力很是大。招人確實能夠解決問題，但在上海這座魔都招聘合適的運維人員非一朝一夕可以完成的，人手不足怎麼辦？那就想辦法把勞動力從繁雜的平常運維工做中釋放出來。

因爲以前沒有專門的運維部門，IT系統的權限都在開發手上，出問題了之後運維總得跟在開發後面查緣由，效率低不說，溝通每每容易出現問題。
因此咱們第1步作的就是：用Ansible + Jenkins搞定自動發佈。Ansible是相對簡單的批量管理工具，支持模板管理等高級功能。搞定了自動發佈，開發的服務器需求已經明顯降低，只要把代碼提交到 Git主幹，就會自動觸發發佈。

 

Git使用的是 GitLab，同時爲了安全咱們作了一層LDAP代理，效果至關於「將軍令」，操做機、Git和Jenkins用 OpenLDAP 作統一認證，後續用到的Redmine、Grafana、Zabbix 等都接入了OpenLDAP認證，每一個人都有個動態口令，每次驗證都須要用到。

二、一棒子監控告警系統

因爲原始的監控不知足快速增加的業務，咱們部署了開源監控系統 Zabbix，雖然運維同事可以很好的使用Zabbix，但其餘部門同事總以爲易用性不高、並且不少定製化監控實現起來很麻煩。

 

而後，咱們開始折騰監控系統——「一棒子監控」，爲何這麼說呢，由於要把監控細化，不是一兩天的事情。而B站的幾乎全部請求都要通過CDN，入口在手上，出問題想知道還難嗎？因而，咱們在入口處作了監控，全部 5xx 的錯誤都打到ELK，那麼不管是什麼業務出問題了都會及時告警，讓相關人員來處理，後續再細化。

另外，要把精力投入到最重要的事情上。咱們能夠花很長的時間去搞好Zabbix、Open-Falcon，但結果多是 從80分 到 90分這種並不顯著的效果，而不少監控並非 Zabbix、Open-Falcon擅長的，不如打個差別戰。

上圖中有個 StatsD推薦給你們，StatsD能夠很是靈活的嵌入到代碼裏進行監控（Shell均可以），由於使用UDP協議，因此服務端性能和故障不會影響到調用的程序，能夠實現業務級的 QPS、響應時間等統計類監控。

其中一個報警最終的效果以下：

 

 

B站是自建CDN的，在國內有覆蓋全國的好幾百個CDN節點，CDN的監控一直是個難點，當某1個鏈路出現問題，用傳統的Zabbix、Open-Falcon監控很難發現問題。雖然咱們自研了Http-monitor監控，可用於網站的可用性監控告警，但考慮到獨立資源和數據可靠性，還有用戶端網絡質量的檢測，仍是同時使用了第三方監控寶的服務。監控寶使用簡單，功能實用，監控點多，分佈式監控能夠及時發現網絡上出現的問題，提供的快照功能能夠快速定位問題和查看詳細信息。並且監控寶屬於第三方獨立的，還能出具網站的SLA證書，做爲B站內部工做考覈的依據。

 

 

三、開源系統的愛與恨

 

B站技術氛圍濃厚，愛開源、愛新技術，因此使用了大量的開源組件，包括SheepDog（丟過數據）和GlusterFS（卡成翔），其中最大的坑是 SD卡 + Ceph存儲。Ceph自己的設計很是好，可是姿式不對也會死很慘。好比B站的某套服務器集羣用 SD卡來跑系統，結果 SD卡跪了致使系統也跪了，全部虛擬機的磁盤io都卡頓甚至死機，通過不斷調優終於仍是穩定了。Ceph給我最大的安慰是：它沒有丟數據，沒有丟！

此外，Redis3.0、Codis、Twemproxy等開源系統都在B站獲得了使用，最後咱們自研了 BiliTW（已開源），主要緣由是 Codis如今沒更新了，Twemproxy的性能比較差，特別是後端Redis多的狀況下（並且它和Redis同樣、只吃單核）。BiliTW最大的改進是支持多核，增長了一些易於運維的功能。

最後總結一下B站運維團隊的成長過程：
因爲人手不足，因此事情得挑着作；因爲故障多，得先抓入口、抓大的；因爲運維繫統跟不上，得先拿開源的頂着；因爲用了大量開源系統，因此踩了不少坑。

 

 

問：請問動態口令是怎麼作的，本身開發仍是開源auth？

答：用的是谷歌動態口令，開源的Google身份驗證器。

問：Ceph部署到線上須要什麼特別的處理嗎？都遇到什麼問題了？

答：Ceph要注意版本，必定要用穩定版，要用大廠用過的版本。另外 Ceph很是耗資源，B站所有用的SSD，Ceph的內部交換是獨立的萬兆網絡。Ceph遇到最大的問題就是感受Ceph成了分佈式單點存儲，都是幾個節點、幾個副本，大的kvm塊存儲集羣有64節點的集羣，數據3副本，解決起來很複雜，須要有愛研究，能看懂代碼的人。

問：B站運維團隊多少人？

答：去年是從0開始，目前20多人，包含應用、研發、安全、信息等。

問：GlusterFS這個存儲用起來卡嗎？

答：GlusterFS 我認爲只適合作大文件的冷存儲。

問：爲何不用Docker而用kvm

答：咱們也用Docker，Docker一直有關注，但實際用的人很少，能用起來的都是投了不少資源進去的大公司。在 Docker 1.9.0 開始，咱們把核心SLB跑在Docker上了，用Host方式。今年下半年，咱們的一個大目標就是Docker接入其它線上業務。目前使用的Mesos Macvlan方式已經在踩水過程當中。

問：Hadoop 相關的運維須要作嗎

答：大數據也作，暫無專職人員。技術研究這塊因爲缺乏專人，我都是給每一個應用運維分任務。大數據就分給了一個應用運維在搞，和開發一塊兒學習。

問：大家服務器網卡作綁定了嗎？

答：咱們所有作了雙網卡的綁定，萬兆bond0。

問：故障多，這種麻煩如何快速解決？
答：這個很難，一方面須要瞭解業務，二方面須要有數據和手段。剛開始咱們查問題很是慢，後來逐步改進，好比完善監控，加故障錨點，故障總結。最近在作 Drapper 連接追蹤，好多公司也都有作，實際上就是在請求的連接各個環節加標記，而後選擇性作實時分析。Drapper最終實現的效果就像瀏覽器的審查元素同樣，哪裏慢一下就看到了。

問：mode0模式的話總帶寬仍是一個網卡的吧？我在測試mode=4，結合交換機的動態聚合，遇到的問題是服務器相互傳輸的話，帶寬是一個網卡的速度。

答：Mode 0 最好在交換機上作下配置，帶寬是跑2張網卡的，既能冗餘，也能上量。咱們自建CDN帶寬很高，單臺機器帶寬就按20G準備。在獵豹用的是Mode4，也挺好的，Mode6不須要特殊配置，但有一個方向不均衡。以前測試Mode4效果最好，但公司最後用了Mode6，由於易維護。

關於帶寬的問題，必須2個客戶端向一個服務端同時傳輸才能達到雙網卡帶寬，之前測試mode0的時候遇到過跑不滿的現象，後來就用了mode6。不過是好多年前的事情了，當時應該是CentOS5或6，如今B站用的是 Debian 8，Mode 0 並無發現問題。

問：大家的Redis集羣3.0穩定嗎？

答：Redis 3.0 挺穩定的，它的 Java客戶端會好些，其它語言可能得本身開發。這邊語言不少，有些業務仍是用 Proxy的方式在跑。咱們正在開發一個Cache管理系統，最終會兼容各類方式，將來會開源。

問：BiliTW是 https://github.com/anewhuahua/bilitw 嗎？

答：不是，這個是前同事作的，是基於Twemproxy 改的多進程版本。將來會重構一個新的，放在 https://github.com/bilibili 下面。

問：B站的雲用的多嗎？

答：內部至關因而私有云了，遊戲業務用公有云多些。

 

歡迎你們投搞：lily.qi@cloudwise.com