摘要：胡凱，運維負責人，曾經(jīng)就職于金山軟件金山網(wǎng)絡獵豹移動，負責運維相關工作。胡凱在去年加入站剛剛成立的運維部，人少事多，遇到了很多坑。

胡凱，bilibili運維負責人，曾經(jīng)就職于金山軟件、金山網(wǎng)絡、獵豹移動，負責運維相關工作。Bilibili是國內最大的年輕人潮流文化娛樂社區(qū)，銀河系知名彈幕視頻分享UGC平臺。
95后二次元新人類的追捧，讓以視頻彈幕、UP主聞名于世的bilibili（以下簡稱B站）愈發(fā)火爆，無數(shù)年輕人通過電腦、手機、電視等終端設備在B站上追番、看彈幕，特別是新番上線時的訪問壓力是非常大的，這就給B站的IT運維團隊帶來了巨大壓力。胡凱在去年加入B站剛剛成立的運維部，人少事多，遇到了很多坑。
本文根據(jù)作者在“監(jiān)控與性能分享群”中的分享內容整理。
B站運維痛點主要有3個：人手不足、故障多、運維系統(tǒng)跟不上，針對這三個痛點，B站采用了三種方式進行破冰。

1、解放勞動力
目前B站的CDN主要是自建的，TB級帶寬，視頻存儲也已達到N個PB，運維壓力非常大。招人確實可以解決問題，但在上海這座魔都招聘合適的運維人員非一朝一夕能夠完成的，人手不足怎么辦？那就想辦法把勞動力從繁雜的日常運維工作中釋放出來。
由于之前沒有專門的運維部門，IT系統(tǒng)的權限都在開發(fā)手上，出問題了以后運維總得跟在開發(fā)后面查原因，效率低不說，溝通往往容易出現(xiàn)問題。
所以我們第1步做的就是：用Ansible + Jenkins搞定自動發(fā)布。Ansible是相對簡單的批量管理工具，支持模板管理等高級功能。搞定了自動發(fā)布，開發(fā)的服務器需求已經(jīng)明顯下降，只要把代碼提交到 Git主干，就會自動觸發(fā)發(fā)布。

Git使用的是 GitLab，同時為了安全我們做了一層LDAP代理，效果相當于“將軍令”，操作機、Git和Jenkins用 OpenLDAP 做統(tǒng)一認證，后續(xù)用到的Redmine、Grafana、Zabbix 等都接入了OpenLDAP認證，每個人都有個動態(tài)口令，每次驗證都需要用到。
2、一棒子監(jiān)控告警系統(tǒng)
由于原始的監(jiān)控不滿足快速增長的業(yè)務，我們部署了開源監(jiān)控系統(tǒng) Zabbix，雖然運維同事能夠很好的使用Zabbix，但其他部門同事總覺得易用性不高、而且很多定制化監(jiān)控實現(xiàn)起來很麻煩。

然后，我們開始折騰監(jiān)控系統(tǒng)——“一棒子監(jiān)控”，為什么這么說呢，因為要把監(jiān)控細化，不是一兩天的事情。而B站的幾乎所有請求都要經(jīng)過CDN，入口在手上，出問題想知道還難嗎？于是，我們在入口處做了監(jiān)控，所有 5xx 的錯誤都打到ELK，那么無論是什么業(yè)務出問題了都會及時告警，讓相關人員來處理，后續(xù)再細化。
另外，要把精力投入到最重要的事情上。我們可以花很長的時間去搞好Zabbix、Open-Falcon，但結果可能是 從80分 到 90分這種并不顯著的效果，而很多監(jiān)控并不是 Zabbix、Open-Falcon擅長的，不如打個差異戰(zhàn)。
上圖中有個 StatsD推薦給大家，StatsD可以非常靈活的嵌入到代碼里進行監(jiān)控（Shell都可以），因為使用UDP協(xié)議，所以服務端性能和故障不會影響到調用的程序，可以實現(xiàn)業(yè)務級的 QPS、響應時間等統(tǒng)計類監(jiān)控。
其中一個報警最終的效果如下：

B站是自建CDN的，在國內有覆蓋全國的好幾百個CDN節(jié)點，CDN的監(jiān)控一直是個難點，當某1個鏈路出現(xiàn)問題，用傳統(tǒng)的Zabbix、Open-Falcon監(jiān)控很難發(fā)現(xiàn)問題。雖然我們自研了Http-monitor監(jiān)控，可用于網(wǎng)站的可用性監(jiān)控告警，但考慮到獨立資源和數(shù)據(jù)可靠性，還有用戶端網(wǎng)絡質量的檢測，還是同時使用了第三方監(jiān)控寶的服務。監(jiān)控寶使用簡單，功能實用，監(jiān)控點多，分布式監(jiān)控可以及時發(fā)現(xiàn)網(wǎng)絡上出現(xiàn)的問題，提供的快照功能可以快速定位問題和查看詳細信息。而且監(jiān)控寶屬于第三方獨立的，還能出具網(wǎng)站的SLA證書，作為B站內部工作考核的依據(jù)。

3、開源系統(tǒng)的愛與恨

B站技術氛圍濃厚，愛開源、愛新技術，所以使用了大量的開源組件，包括SheepDog（丟過數(shù)據(jù)）和GlusterFS（卡成翔），其中最大的坑是 SD卡 + Ceph存儲。Ceph本身的設計非常好，但是姿勢不對也會死很慘。比如B站的某套服務器集群用 SD卡來跑系統(tǒng)，結果 SD卡跪了導致系統(tǒng)也跪了，所有虛擬機的磁盤io都卡頓甚至死機，經(jīng)過不斷調優(yōu)終于還是穩(wěn)定了。Ceph給我最大的安慰是：它沒有丟數(shù)據(jù)，沒有丟！
此外，Redis3.0、Codis、Twemproxy等開源系統(tǒng)都在B站得到了使用，最后我們自研了 BiliTW（已開源），主要原因是 Codis現(xiàn)在沒更新了，Twemproxy的性能比較差，特別是后端Redis多的情況下（而且它和Redis一樣、只吃單核）。BiliTW最大的改進是支持多核，增加了一些易于運維的功能。
最后總結一下B站運維團隊的成長過程：
由于人手不足，所以事情得挑著做；由于故障多，得先抓入口、抓大的；由于運維系統(tǒng)跟不上，得先拿開源的頂著；由于用了大量開源系統(tǒng)，所以踩了很多坑。

問：請問動態(tài)口令是怎么做的，自己開發(fā)還是開源auth？
答：用的是谷歌動態(tài)口令，開源的Google身份驗證器。
問：Ceph部署到線上需要什么特別的處理嗎？都遇到什么問題了？
答：Ceph要注意版本，一定要用穩(wěn)定版，要用大廠用過的版本。另外 Ceph非常耗資源，B站全部用的SSD，Ceph的內部交換是獨立的萬兆網(wǎng)絡。Ceph遇到最大的問題就是感覺Ceph成了分布式單點存儲，都是幾個節(jié)點、幾個副本，大的kvm塊存儲集群有64節(jié)點的集群，數(shù)據(jù)3副本，解決起來很復雜，需要有愛研究，能看懂代碼的人。
問：B站運維團隊多少人？
答：去年是從0開始，目前20多人，包含應用、研發(fā)、安全、信息等。
問：GlusterFS這個存儲用起來卡嗎？
答：GlusterFS 我認為只適合做大文件的冷存儲。
問：為什么不用Docker而用kvm
答：我們也用Docker，Docker一直有關注，但實際用的人不多，能用起來的都是投了很多資源進去的大公司。在 Docker 1.9.0 開始，我們把核心SLB跑在Docker上了，用Host方式。今年下半年，我們的一個大目標就是Docker接入其它線上業(yè)務。目前使用的Mesos Macvlan方式已經(jīng)在踩水過程中。
問：Hadoop 相關的運維需要做嗎
答：大數(shù)據(jù)也做，暫無專職人員。技術研究這塊由于缺少專人，我都是給每個應用運維分任務。大數(shù)據(jù)就分給了一個應用運維在搞，和開發(fā)一起學習。
問：你們服務器網(wǎng)卡做綁定了嗎？
答：我們全部做了雙網(wǎng)卡的綁定，萬兆bond0。
問：故障多，這種麻煩如何快速解決？
答：這個很難，一方面需要了解業(yè)務，二方面需要有數(shù)據(jù)和手段。剛開始我們查問題非常慢，后來逐步改進，比如完善監(jiān)控，加故障錨點，故障總結。最近在做 Drapper 鏈接追蹤，好多公司也都有做，實際上就是在請求的鏈接各個環(huán)節(jié)加標記，然后選擇性做實時分析。Drapper最終實現(xiàn)的效果就像瀏覽器的審查元素一樣，哪里慢一下就看到了。
問：mode0模式的話總帶寬還是一個網(wǎng)卡的吧？我在測試mode=4，結合交換機的動態(tài)聚合，遇到的問題是服務器相互傳輸?shù)脑?，帶寬是一個網(wǎng)卡的速度。
答：Mode 0 最好在交換機上做下配置，帶寬是跑2張網(wǎng)卡的，既能冗余，也能上量。我們自建CDN帶寬很高，單臺機器帶寬就按20G準備。在獵豹用的是Mode4，也挺好的，Mode6不需要特殊配置，但有一個方向不均衡。之前測試Mode4效果最好，但公司最后用了Mode6，因為易維護。
關于帶寬的問題，必須2個客戶端向一個服務端同時傳輸才能達到雙網(wǎng)卡帶寬，以前測試mode0的時候遇到過跑不滿的現(xiàn)象，后來就用了mode6。不過是好多年前的事情了，當時應該是CentOS5或6，現(xiàn)在B站用的是 Debian 8，Mode 0 并沒有發(fā)現(xiàn)問題。
問：你們的Redis集群3.0穩(wěn)定嗎？
答：Redis 3.0 挺穩(wěn)定的，它的 Java客戶端會好些，其它語言可能得自己開發(fā)。這邊語言很多，有些業(yè)務還是用 Proxy的方式在跑。我們正在開發(fā)一個Cache管理系統(tǒng)，最終會兼容各種方式，未來會開源。
問：BiliTW是?https://github.com/anewhuahua...?嗎？
答：不是，這個是前同事做的，是基于Twemproxy 改的多進程版本。未來會重構一個新的，放在?https://github.com/bilibili?下面。
問：B站的云用的多嗎？
答：內部相當于是私有云了，游戲業(yè)務用公有云多些。

歡迎大家投搞：[email protected]