这是一个创建于 3030 天前的主题，其中的信息可能已经有所发展或是发生改变。
胡凯， bilibili 运维负责人，曾经就职于金山软件、金山网络、猎豹移动，负责运维相关工作。 Bilibili 是国内最大的年轻人潮流文化娱乐社区，银河系知名弹幕视频分享 UGC 平台。
95 后二次元新人类的追捧，让以视频弹幕、 UP 主闻名于世的 bilibili （以下简称 B 站）愈发火爆，无数年轻人通过电脑、手机、电视等终端设备在 B 站上追番、看弹幕，特别是新番上线时的访问压力是非常大的，这就给 B 站的 IT 运维团队带来了巨大压力。胡凯在去年加入 B 站刚刚成立的运维部，人少事多，遇到了很多坑。
本文根据作者在“监控与性能分享群”中的分享内容整理。
B 站运维痛点主要有 3 个：人手不足、故障多、运维系统跟不上，针对这三个痛点， B 站采用了三种方式进行破冰。
1 、解放劳动力
目前 B 站的 CDN 主要是自建的， TB 级带宽，视频存储也已达到 N 个 PB ，运维压力非常大。招人确实可以解决问题，但在上海这座魔都招聘合适的运维人员非一朝一夕能够完成的，人手不足怎么办？那就想办法把劳动力从繁杂的日常运维工作中释放出来。
由于之前没有专门的运维部门， IT 系统的权限都在开发手上，出问题了以后运维总得跟在开发后面查原因，效率低不说，沟通往往容易出现问题。
所以我们第 1 步做的就是：用 Ansible + Jenkins 搞定自动发布。 Ansible 是相对简单的批量管理工具，支持模板管理等高级功能。搞定了自动发布，开发的服务器需求已经明显下降，只要把代码提交到 Git 主干，就会自动触发发布。
Git 使用的是 GitLab ，同时为了安全我们做了一层 LDAP 代理，效果相当于“将军令”，操作机、 Git 和 Jenkins 用 OpenLDAP 做统一认证，后续用到的 Redmine 、 Grafana 、 Zabbix 等都接入了 OpenLDAP 认证，每个人都有个动态口令，每次验证都需要用到。
2 、一棒子监控告警系统
由于原始的监控不满足快速增长的业务，我们部署了开源监控系统 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 站内部工作考核的依据。
3 、开源系统的爱与恨
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 站的云用的多吗？
答：内部相当于是私有云了，游戏业务用公有云多些。
欢迎大家投搞： [email protected]
95 后二次元新人类的追捧，让以视频弹幕、 UP 主闻名于世的 bilibili （以下简称 B 站）愈发火爆，无数年轻人通过电脑、手机、电视等终端设备在 B 站上追番、看弹幕，特别是新番上线时的访问压力是非常大的，这就给 B 站的 IT 运维团队带来了巨大压力。胡凯在去年加入 B 站刚刚成立的运维部，人少事多，遇到了很多坑。
本文根据作者在“监控与性能分享群”中的分享内容整理。
B 站运维痛点主要有 3 个：人手不足、故障多、运维系统跟不上，针对这三个痛点， B 站采用了三种方式进行破冰。
1 、解放劳动力
目前 B 站的 CDN 主要是自建的， TB 级带宽，视频存储也已达到 N 个 PB ，运维压力非常大。招人确实可以解决问题，但在上海这座魔都招聘合适的运维人员非一朝一夕能够完成的，人手不足怎么办？那就想办法把劳动力从繁杂的日常运维工作中释放出来。
由于之前没有专门的运维部门， IT 系统的权限都在开发手上，出问题了以后运维总得跟在开发后面查原因，效率低不说，沟通往往容易出现问题。
所以我们第 1 步做的就是：用 Ansible + Jenkins 搞定自动发布。 Ansible 是相对简单的批量管理工具，支持模板管理等高级功能。搞定了自动发布，开发的服务器需求已经明显下降，只要把代码提交到 Git 主干，就会自动触发发布。
Git 使用的是 GitLab ，同时为了安全我们做了一层 LDAP 代理，效果相当于“将军令”，操作机、 Git 和 Jenkins 用 OpenLDAP 做统一认证，后续用到的 Redmine 、 Grafana 、 Zabbix 等都接入了 OpenLDAP 认证，每个人都有个动态口令，每次验证都需要用到。
2 、一棒子监控告警系统
由于原始的监控不满足快速增长的业务，我们部署了开源监控系统 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 站内部工作考核的依据。
3 、开源系统的爱与恨
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 站的云用的多吗？
答：内部相当于是私有云了，游戏业务用公有云多些。
欢迎大家投搞： [email protected]
 |
1
solonF 2016-09-05 18:00:48 +08:00
那个，我希望 B 站能有视频加速功能（抱歉这条回复没有帮助
|
 |
2
lovejoy 2016-09-05 18:13:29 +08:00  1
我不明白为啥发在监控宝的节点下，所以是软文咯？也太硬了吧。
|
 |
3
lizeqiangd 2016-09-05 19:30:47 +08:00
sd 卡问题不是今年初就差不多换完了么?
|
 |
4
ClassicOldSong 2016-09-05 19:30:49 +08:00 via Android
欢迎大家投搞🌚👍
|
 |
5
plqws 2016-09-05 19:43:50 +08:00 1
B 站的稳定性一直都蛮烂的，各种 502 小电视，果然是折腾出来的锅
|
 |
6
R18 2016-09-05 19:46:11 +08:00 via Android
啥时候快进能用？啥时候冷门视频可以看？
|
 |
7
ihacku 2016-09-05 20:21:53 +08:00 via Android
挺好的，能分享下自建 cdn 的经验么
|
 |
8
DoraJDJ 2016-09-05 20:58:00 +08:00 via Android
个人感觉，逸站无论是用户群体还是网络方面，都不怎么样。
|
 |
9
pixstone 2016-09-05 21:02:42 +08:00 via iPhone
围观
|
|
10
pixstone 2016-09-05 21:04:03 +08:00 via iPhone
用 docker 做 slb 有多少的消耗么 相对 原生系统走。延迟，吞吐量方面
|
 |
11
immjun 2016-09-05 21:47:06 +08:00
B 站的 HTML5 播放器什么时候支持超清？
|
 |
12
lrvy 2016-09-05 21:54:09 +08:00 via Android
(^o^)好棒 报了好多料
|
|
13
lizeqiangd 2016-09-05 21:58:48 +08:00 via iPhone
@lizeqiangd 更正下。 sd 卡问题依旧 并没有换完
|
 |
14
zjb861107 2016-09-05 22:46:30 +08:00
B 站不稳定？那你看看现在的 A 站。。。。
|
|
15
zjb861107 2016-09-05 22:47:33 +08:00
不了解 B 站的工作氛围怎么样，但是 B 站的内容我是一直喜欢的
|
 |
16
ctrlaltdeletel 2016-09-05 23:20:41 +08:00
不错
|
 |
17
falcon05 2016-09-05 23:54:30 +08:00 via iPhone
恕我直言， B 站在我这连经常卡成翔，深圳联通
|
 |
18
ixinshang 2016-09-06 00:28:22 +08:00 via Android
竟然和 b 站有合作
|
 |
19
qa 2016-09-06 00:42:16 +08:00 via iPhone
b 站开始播放前几秒卡一下，这问题很久了吧，很多视频都有这个问题。
|
 |
20
Radiums 2016-09-06 00:55:25 +08:00
据说 b 站人手不够的最大原因是钱给的不够？
|
 |
21
est 2016-09-06 08:36:07 +08:00
比预想的 6666 很多。
|
 |
22
pango 2016-09-06 08:39:46 +08:00
满满的都是干货，赞！
|
 |
23
quericy 2016-09-06 09:04:59 +08:00
直播呢?b 站的直播为啥老是炸......
|
 |
24
halfbloodrock 2016-09-06 09:25:45 +08:00
2010 年时候的项目用了 mode4 模式，配合堆叠交换机上 LACP 有点问题。。。最后放弃 bonding 。
|
 |
25
sayyesorno 2016-09-06 09:49:06 +08:00
exciting~
|
 |
26
Jasmine2016 2016-09-06 11:12:15 +08:00
山东用户路过，看到那一坨嫩绿了。。。
|
 |
27
techmoe 2016-09-06 11:53:00 +08:00 via Android
SD 卡跑系统。。原来之前听某位前辈说的是真的。。跪了
好奇是多大的 SD 卡？ |
 |
28
walkman660 2016-09-06 14:52:02 +08:00
内容挺不错，支持一个
|
 |
29
sunsan05 2016-09-06 19:07:18 +08:00
自从金山入住 B 站以后，各种往脸上贴金啊，但是实际上做的东西还不如原团队的 1/10 性能，呵呵呵呵。
|
 |
30
buseni 2017-09-22 18:38:46 +08:00
学习下
|
Select Language