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

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

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

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

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

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

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

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

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

歡迎大家投搞：lily.qi@cloudwise.com