业界前沿 B 站运维团队成长的血泪史

laofo · 发布于 2017年5月19日 · 最后由 laofo 回复于 2017年5月19日 · 116 次阅读
4

胡凯, 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 站的云用的多吗?
  • 答:内部相当于是私有云了,游戏业务用公有云多些。
共收到 1 条回复
4
laofo · #1 · 2017年5月19日
由于之前没有专门的运维部门, IT 系统的权限都在开发手上,出问题了以后运维总得跟在开发后面查原因,效率低不说,沟通往往容易出现问题。 **所以我们第 1 步做的就是:用 Ansible + Jenkins 搞定自动发布。 Ansible 是相对简单的批量管理工具,支持模板管理等高级功能。搞定了自动发布,开发的服务器需求已经明显下降,只要把代码提交到 Git 主干,就会自动触发发布。 **

这个方法也许对于某些团队就很不错。

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册