虎牙直播运维负责人张观石 | 解密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日在北京国家会议中心举行，张观石老师将作为大会讲师为大家带来《直播平台的运维保障实践》话题。

案例目标

相对于Web服务，直播音视频的运维更特殊，业界没有很好的参考的经验，刚接手时，这方面运维的挑战比较大。

（1）虎牙直播目前是异构多云的架构，从整个链路看，任何观众都可以看到任何线路上任何主播的情况，复杂度高； （2）研发人员以及各个团队会比较关注自己环节上的事情，所以在虎牙运维团队引入了多CDN以后，不仅技术和管理复杂性大幅提高，而且视频流路径在这么复杂的场景下，必须深入音视频运维工作，这对运维质量和运维人员技能提出了更高的要求。

成功（或教训）要点

直播音视频的传输质量评估体系，音视频质量数据的全链路监控，以及对于互联网服务可靠性系统工程的思考。

案例重点

运维效率的提升，直播质量的提升。

案例启示

由于直播平台不同以往任何架构的特殊性，以及当时视频板块技术的有限性，促使我们必须尽快找到运维的着力点。后来，我们接轨了近年来一直倡导的DevOps和SRE解决了这一困局。