2018.11.08 丨 msup

虎牙直播运维负责人张观石 | 解密SRE的六种能力及虎牙运维实践

2018.11.08 丨 msup

虎牙直播运维负责人张观石


本文是根据虎牙直播运维负责人张观石10月20日在msup携手魅族、Flyme、百度云主办的第十三期魅族开放日《虎牙直播平台SRE实践》演讲中的分享内容整理而成。


张观石,拥有10余年网站开发、架构、运维经验;目前关注互联网服务可靠性系统工程、运维平台的规划建设、网站高可用架构等方面;在音视频传输质量评估、微服务运维方面积累了丰富的经验。


目录

一、 直播平台的架构及运维挑战 

(一) 音视频传输流程及挑战 

(二) 一个直播间的流程 

(三) 直播平台的运维挑战 

二、 我们的思考和运维实践 

(一) Google SRE介绍 

  • SRE是什么 

  • Google SRE方法论

(二) 我们的思考:运维的六种能力 

(三) 我们的运维实践 

  1. 运维可靠性管理 

  2. 感知能力 

  3. 修复能力   

  4. 反脆弱能力 

  5. 保障能力 

  6. 安全能力 


虎牙直播介绍


虎牙直播是以游戏为主要内容,涵盖娱乐、综艺、教育、户外、体育等多种内容的直播平台,2018年5月在纽交所上市。

虎牙算是整个直播行业比较重视技术的一家公司,大家可以对比下几家平台观看体验,我们应该是最好的一家了。英雄联盟S8 是全球最大的电子竞技赛事,目前正在如火如荼进行,从今天开始进入了总决赛的淘汰赛阶段了。这会正在进行的是IG对KT队,IG是中国的队伍,今年共有3只中国对进入了8强,是历年最好的成绩,比赛很精彩,如果不来今天的分享,我可能在家看比赛,或是去公司值班了。欢迎大家到虎牙直播平台观看直播,为LPL加油!(发布此稿时,中国队IG已经获得了总决赛冠军,虎牙平台观众数也突破了历史新高,直播过程无较大故障发生)。


今天的分享正好会讲到关于这次赛事的运维保障的技术。

一般网站比如电商类网站用户是卖家+买家, 卖家先编辑商品信息,发布后买家刷新后再看到,是异步的,卖家可以慢慢改,错了可以慢慢调。直播平台上,一个主播开播出现在摄像头面前,可能有成千上万的人同时观看,主播不能有任何小动作,不能离开,重新开播代价太大了,10分钟不能播观众就跑了。要是互动不流畅,土豪也就不想看你了。主播更不可能停播配合我们运维人员做一些技术上的调整。如此看来,直播平台相对于传统网站还是有区别的。所以,这对运维的挑战就更大。

直播平台技术是比较复杂的,首先是音视频处理本身有很多高深的技术,其实是大规模的观众和主播,还要对实时性要求特别高。

今年英雄联盟总决赛S8是从韩国现场传送回国,传输路径也比较复杂。



直播平台的架构及运维挑战


(一)音视频传输流程及挑战


音频流程是指平台从开播到观看一系列的流程。

①开播主播多

同时开播的主播数量非常多。

②上行选择多

图中,中间蓝色部分的线是可以支持上行的线路,每一个主播都可以到任何一条线路上,虎牙有自动调度,运维人员也可以进行调度,主播上行哪里。

③ 转推路径多 

确定一条上行线路后,还要互相转推到其他线路上,观众可以在任何一条线路看到主播的直播。

④观众线路多 

观众有很大的选择权,比如选择不同的清晰度、不同的线路,包括H5技术等,播放技术和观众选择不一样。

⑤转码档位多

⑥实时要求高


今年,虎牙运维研究团队又做了P2P技术,架构又比以前复杂了很多。


(二)一个直播间的流程



上图是一个虎牙主播直播的流程。首先,主播可以选择一个开播方式(进程开播、桌面直播、摄像头开播、手游投屏、手游桌面、OBS、导播系统、VR直播、第三方推流等)进行直播,经过4种推流方式(HUYA、UDP、 YY、 RTMP、CDN),直推到某条线路上,转推多家CDN,从CDN边缘到中心,然后再选择转码率,最后分发到不同省、市的运营商,之后就到观众的客户端。


(三)直播平台的运维挑战


因为音视频本身的复杂度,加上业务的实时性,对运维造成很大的挑战。传统的运维可以对开源组件做部署、配置、优化、高可用部署等。而音视频技术变化很快,自成一个体系,主播端和观众端的逻辑性强,由于中间传输路线多,运维人员很难参与其中,所以我们必须换一种工作方式。

google的SRE 给了我们很大的启发,我们在SRE的方法论指导下,比较深入地参与到了音视频传输业务中,虽然我们不叫SRE,还是叫业务运维,不过做法吸收了SRE的很多思路。今天要分享的也是这方面的内容,希望对大家有些启发。


我们的思考和运维实践


(一)Google SRE介绍


• SRE是什么

S是Site/Service/Software,运维的对象,网站业务服务线上的服务

R是reliability,关注可靠性,质量,理解为对外部最终用户的质量和价值

E是Engineer工程师、Engineering工程化。

运维的本质是人和机器参与的一项系统性工程,这种工程跟软件工程不太一样的是,我们是负责业务上线后稳定运营,可靠性、质量、成本等。有人比喻业务研发和运维的关系就像是:生孩子与养孩子,哪个更难哪个更容易呢?


• Google SRE方法论:

•关注研发工作,减少琐事

•保障SLO&度量风险

•做好监控及黄金指标

•应急事件处理

•变更管理

•需求预测和容量规划

•资源部署

•效率与性能


(二)我们的思考:运维的六种能力


常有人问我们运维是做什么的,我们说是做质量、效率、成本 ,具体怎么做,要怎么做呢,几句话很难讲清楚。《SRE Google运维解密》这本书强调实践方法论,能落地,但不够体系,可能是由不同的人写不同的章节。我有机会顺着可靠性这条路径,找到了传统行业的可靠性研究,发现了另外一片世界。大家都以为SRE是google提出来的,其实传统行业的SRE已经存在了几十年了,已经成为了一门学科。我个人研究之后,认为这门学科讲得更体系更完整,于是希望能套到互联网的服务中来。我参照照传统行业一些可靠性的理论、对框架做了一些迁移,将自己的思考转化成了一个运维的思考框架,叫做运维的六种能力,将其分为以下6点:



SER眼中的可靠性:规定条件规定时间内完成规定功能

可靠性的两个故事:

二战时某次美军近半飞机无法起飞,发现是某些电子管不可靠引起的。朝鲜战争中美军电子设备不可靠,维修成本比制造成本高了几倍。从而诞生了可靠性这门学科。


①可靠性管理

首先要分析目标业务的可靠性模型,然后画出可靠性逻辑框图,评估每个环节和总体的可靠性性,进行度量和评价,可以是定性的,也可以是定量的。

②感知能力

在业务上线、建立连接之后,学会如何感知其状态、变化及问题。

③修复能力

当可靠性在设计阶段不够完善时,修复能力可以帮助我们在用户没有感知的状态下修复故障。

④反脆弱能力

业务运行在一定内部或外部环境里,寻找脆弱点和风险点,然后对它的脆弱点进行分析,并设计出反脆弱的能力,最终推动业务研发修改技术架构。

⑤保障能力

很多业务需要具备保障能力,建立保障性的设计,实现快速交付资源和快速能力到位。

⑥安全能力

如何保证我们业务安全、数据安全。


(三)我们的运维实践


我们主要关注所负责业务的核心服务的核心指标,我们将每一条端到端链路都看做是一个服务,那么服务指标可以是成功率、延迟或其他,将指标能达到某个程度作为目标;研发和运维团队会对这个服务画出部署构架图、可靠性逻辑框图(见下图);建立业务的可靠性模型,同时还会做一些FMECA;分析失败模式及其带来的影响,以及讨论设计解决方案;对一些关键的服务,要把故障树画出来,度量风险,选择优先风险,推动解决;可靠性是管理出来,是运维出来的,但首先是设计出来的,可靠性设计的方法包括避错、改错、容错等。


下图是我们负责运维的同学画的P2P技术架构流程图。


 下图是主播上行经过的环节,这对运维人员做监控时有指导意义。逻辑框图越画越细,每个点都会分析、统计它的可靠性。


1.可靠性管理的要点

①如何识别风险

可以从几个方面判断:

复杂度;技术成熟度;重要程度;环境严酷程度

②如何验证可靠性水平

开发阶段前性能测试;上线压测;容量模型;改进测试;模拟故障测试等

③实践

建立可靠性指标大盘;黄金指标&SLO;主播上行APM;全链路的可靠性;多维度的析评估体系;日报,月报,实时可靠性等。


2.感知能力

什么是感知力,包括但不限于监控的覆盖度,告警的实时性,准确性,触达率,问题定位能力,趋势预测能力 。

①监控、状态感知能力

以监控数据作为基础,提高人工感知能力和机器感知能力,监控是感知的基础,监控指标多了,不能说就有了感知力,这远远不够。

②故障感知能力

帮助运维人员感知业务的状态、变化和其他问题

③AIOps大多是加强运维感知能力

大数据;智能告警

自动化测试、压力测试

拨测、APM

日志trace可阅读,可分析



3.修复能力  

SRE是与故障做斗争的系统工程。程序写得再好,也很难达到完全不出故障。

衡量修复能力-MTTR:

对于大部分的故障,都应该知道它的故障模式,根据故障模式就可以制定故障预案(规定条件规定时间规定人进行修复),根据预案做出一些修复工具,即人工修复或智能自愈。当发生一些考虑不到的情况出现时,需要维修和技术保养,进行扩容或者优化。根据平均修复时间和最大修复时间进行修复评价。

虎牙的一些实践:

主播上行切换:从早期主播重新开播修复上行问题,到后台手工切换,到主播端自动切换。修复时间(MTTR)从半个小时缩短到5分钟,到秒级。

观众调度系统:基于主播端,观众端调度,小运营商调度、无缝切换,按协议调度等,机房一键上下线。

故障修复更高一级是自愈,这也是故障修复能力转化为软件架构设计的高度


4.反脆弱能力

反脆弱的设计:

保证服务在脆弱条件下的保持容忍范围内的健壮性。

软件总是在不同环境运行、不同条件下运行,这个条件就是可靠性中“规定的条件”。环境总是有很多脆弱点,要做脆弱性分析、反脆弱设计,最后评估评审。互联网常见的脆弱性因素,有机房、运营商、网络、单机故障,业务突发事件负载高、流量大,也可能微服务请求超时。健壮性设计,容灾性设计、高可用的设计、资源冗余等。这也是google SRE种说的拥抱风险、度量风险、评估风险容忍能力。


S8源流的反脆弱性设计


5.保障能力 

软件架构设计特性和计划的保障资源,能快速满足使用要求的能力。


可靠性保障的设计,要做到无状态,可切换,可调度,可重试等,比如说我们怎么样实现替换一台故障机器,且要求在10分钟内提供业务服务。

做可靠性保障要做一个闭环,分析目标、风险、脆弱性;设计SLO-感知还有保障、修复、演练。感知SLI的变化以及相关的子SLI的变化,尽快修复SLI退化情况,在设计时尽量考虑到各种脆弱条件,做出反脆弱的保障方案。


我们的一些实践:

•带宽资源保障:

 能分钟级实现带宽调度,能1分钟内实现切流

•服务器保障:

3分钟能拿到多个机房服务器

3分钟能把核心服务部署起来

保障能力需要架构设计、接口的设计

我们在直播间的做了一些特殊设计

保障能力是多方面能力的综合体现:

•考验的是自动化的程度,要有支撑系统的保障,要有自动化工具的保障

•要做人力和人员的规划,考验故障时人员到位时间

•要做硬件、软件资源的供应保障

•是对软件架构的要求,是否支持平滑扩容

•要有演练,确保能执行

6.安全能力

安全是最基本的能力,也是最大的风险之一。

数据安全:层出不穷的数据泄露事件,用户信息涉密事件。

业务安全:优惠券被刷,支付漏洞,主播言行、登录风控等。

用户安全:比如滴滴的安全事件。


以上内容来自张观石老师的分享。



由msup主办的第七届TOP100全球软件案例研究峰会将于11月30日至12月3日在北京国家会议中心举行,张观石老师将作为大会讲师为大家带来《直播平台的运维保障实践》话题。

识别图中二维码,即可查看更多运维案例!


媒体联系

票务咨询:赵丹丹 15802217295

赞助咨询:郭艳慧 13043218801

媒体支持:景    怡 13920859305