技术驱动娱乐，直播平台运维保障实践

大家好，我叫张观石，来自虎牙直播，虎牙直播是弹幕式的游戏直播平台，我在公司负责业务运维相关工作。看直播已经成为一种重要的娱乐方式，技术驱动娱乐是虎牙的slogan，我今天要分享的是运维技术如何驱动直播平台整体技术稳定性。

今天我会分享的几块内容。

• 首先会介绍下直播技术的总体架构和挑战；

• 然后给大家分享下我提炼的可靠性工程、稳定性保障工作的一个能力框架；

• 接着讲下在直播音视频的稳定性保障中的应用。包括几个核心指标和评估体系，如何度量直播的稳定性；

• 接下来会介绍如何提升可靠性的感知能力，可靠性下降了，故障来了，如何快速感知到，这包括了监控、告警、响应以及一些技术点；

• 再然后会讲下我对能力框架中的快速修复和保障能力的认识。快速修复能力、恢复能力是运维能力的体现，是缩短故障时长的关键点；

• 最后会再次总结下我对可靠性工程的能力框架和几点思考。

1.直播音视频传输的总体技术架构

首先讲下直播音视频技术的总体架构和挑战。

大家都看直播，简单来讲直播就是主播开播，观众看直播。

技术流程是主播设备安装直播软件，进行采集、编码、封装成为RTMP流，然后推流，为了看多个码率档位清晰度的需求要转码、如果有P2P还得进行切片，为了政策风险要截图鉴黄录制，要经过内容分发网络传输到离用户最近的节点，然后观众通过直播软件连接到边缘节点，把流拉下来，进行解码，渲染，这就看到直播的内容了。

虎牙很早就实现了混合云/多云的架构。虎牙直播有自己的传输网络，也有多家CDN音视频传输网络。

主播和观众的大概架构是这样的：一个主播可能上行推流到任何一条线路，观众可以通过任何线路去看这个主播的节目。这个架构就有点小复杂，组合很多。当然后台是可以调度的。作为运维的任务是如何在这种复杂场景下保证实时可靠性。

我们看一下单个主播直播的情况。

一个主播会推到一个CDN，然后在多云里面互相转推，在每家云里面有不同的运营商、不同的省市区域，这里面的链路比较长，整个过程是实时的。任何一个节点出现问题，都会影响全局或部分的观众。在实时、海量的情况下，怎么保障直播质量是有一定挑战的工作。

比如直播质量中最常见的卡顿，卡顿有很多种的原因，有可能是网络延时，有可能是丢帧或主播端就卡了。上面说的那些其实每家直播平台都是这样的，那么直播真正的技术挑战是在哪里？

直播平台技术栈中开播有10+种开播方式，推流方式4,5种，推流转推情况较复杂，各种码率音视频处理技术，比如H264,H265,各种音视频协议，各种码率档位等，采集设备效果不一，移动端版本迭代难等，CDN音视频技术不完全统一，当然国内看直播的观众，网络情况运营商情况，地区情况也是参差不齐，作为平台方要解决等。

直播与WEB服务有一些差别。WEB的服务都是打开浏览器来访问服务端，这是浏览器到服务端，浏览器是标准化的东西，很多时候失败可以重试。

直播是主播端到后台再到观众端上，链路长很多，而且是实时的。对网络的要求不太一样，网络是飘忽不定的。第三，主播端、观众端软硬件情况复杂，也很多，安卓软件很复杂，甚至有安卓TV的很老的版本。

直播界也有双十一—英雄联盟全球总决赛，去年是S8，今年是S9，去年中国得了冠军以后非常火爆。4个最高：最高荣誉、最高含金量、最高竞技水平、最高知名度的比赛，每次观看的人比较多，对带宽的要求也比较多。

5G时代来了，5G时代来了之后对我们整个运维、互联网应用和生态都会带来很大的变化。

在4G时代，我们看直播还不错，但是5G普及的时候整个互联网会发生更大的变化，直播技术会从娱乐转向工业生产、日常生活。

不管是做直播或者娱乐的，什么AR、VR，今天这么多互联网的直播，将来在5G的时代直播的效果可能会更好，可能会有一种全新的直播。

5G对基础设施的影响是巨大的，会出现真正意义的边缘计算。对网络的吞吐、网络延时都是不可同日而已。5G有一个很大的特点：高带宽、低延时，在一平方公里支持百万级的连接。应用场景也会更多，5G+AIoT可能是未来的互联形态。将来的连接终端数量会比现在高几个数量级，整个的网络会更复杂。

我认为直播技术是比较接近5G未来技术和应用形态的一种，将来直播平台会更大。所以今天讲直播的保障，也是对未来的一种探索，对我们也是一种机会。

当然更重要的是5G可能会产生完全不一样的应用生态。直播可能是最简单的，技术以及体验会大幅升级。对运维可靠性将会有更大挑战，当然也说明有更大机会。包括AIoT，可能会真的爆发，那时的网络应用是一个爆炸性的增长。如何保障可靠性是个新问题。

2.稳定性保障能力概述&设计与分析能力

接下来讲一下稳定性思考的一个能力框架。我们今年重点要做稳定性保障的工作，我们提了一个“235工程”，是指从故障发生到发现2分钟，从故障到响应到定位定界出来3分钟，从定位到处理（执行快速恢复的手段）5分钟，“2+3+5就是10分钟”，10分钟的要求是否高？其实挺高的，每个故障从发现问题到处理问题10分钟，但是距离要求特别高吗？不算特别高，10分钟的故障，如果经常出现这样的故障要10分钟处理，整个平台也是受不了的。

我们怎么样来保障稳定性呢？是不是像达摩克里斯之剑，马尾巴毛断了剑就掉下来，这个人就挂了，我们头上可能是根网线，光纤一断、服务就挂了。靠佛祖的保佑去保障临时的稳定性？还是靠我们的努力，7X24，不眠不休，高度压力抗住？

当然现在也有很多新的运维方法和新的理念出来，AIOps、DevOps、SRE、混沌工程等等，我们很多人都在钻研。这些绝招怎么保证业务是稳定的呢？天龙八部里面有一个角色我很喜欢—鸠摩智，为什么呢？不是因为他很坏，而是他很像技术人员的成长过程，他偷学各大门派的功夫绝招，不惜代价勤学苦练。

我们也在学习这些绝招，可是学会了就能解决稳定性的问题吗？我们的稳定性就会好了吗？其实有可能像鸠摩智一样学了很多形似而神不同、走火入魔。但是鸠摩智最后的结果还是比较好的，他的结局是什么？走火入魔之后武功尽失，但最后终于觉悟成为一代高僧。

我们也先放下所有的武功，来看看稳定性可靠性的本质。

接下来讲下我的一些思考，我认为可靠性/稳性工程就是与故障做斗争，这是一个工程学科，不是普通的运维操作。当做一门学科来看的话，就要研究产品故障发生发展规律，进而预防、纠正、解决故障的，使故障尽量不发生或少发生的，发生之后有能力快速应对。

左边这张图是通过几个能力与故障做斗争的过程。在设计阶段就能预防各种故障，风险和脆弱性。在故障可能出现，或已经出现的时候，快速去发现感知到；感知到之后快速修复；修复后要验证，可能是推动研发改进设计。这样的一个闭环是跟故障做斗争的整个过程。

整个过程需要很多的武功，能力。我总结出六种能力，我认为这六种能力都达到一定水平后，我们的稳定性一定会提高。

右边是我对可靠性工程的总结的一个体系，分享给大家，稳定性保障的六种能力。包括可靠性设计与分析能力、感知能力等六大能力。

第一，设计与分析能力。 设计能力是指怎么样去设计与分析业务架构，业务架构包括研发的技术架构、也包括我们的运维架构、系统架构、基础设施架构、部署架构。业务技术架构是业务研发来做的，其他几个我们运维同学也能设计。

第二，感知能力。 可靠性退化了，需要快速感知到，对互联网服务来说就是上报、监控、告警、响应、协同。我理解AIOps主要是感知层的工作。比如无阈值告警是提升我们告警配置的覆盖度，提升告警阈值的准确性。异常检测、根因分析是解决海量监控指标曲线的分析效率和准确性的问题。

我们分析架构去识别的风险点，甚至反向驱动改进我们的设计，分析质量指标（成功失败的数据），分析过往的故障，提出可靠性的目标（SLI或者SLO）。 有了SLI、SLO之后怎么做监控、响应、警告等等，我们把这一块定位为感知能力。SLI、SLO去做监控、定位等等都是感知能力。 

第三，修复能力。 出现故障之后要修复，怎么去修?靠人登录服务器里面或者跑到系统点”一键修复”？修有很多的学问，这个系统能不能修，怎么去修？比如说容量不够怎么去扩容，是否有隔离，是否有 工具 等。 如何去修复，靠人，靠工具，靠系统，靠自愈？

第四，保障能力。 保障能力拿一个类比来说就是后勤装备部或者战略支援军的综合保障能力。这里的保障能力是指我们的人员训练保障、工具系统的保障、基础设施快速交付的能力等。 

第五，反脆弱能力 。我们的业务总是很脆弱，网络很脆弱，业务发展总是面临很多脆弱的环境。 所有公司所有业务都有一个稳定性的提升过程，在这过程中面临无数脆弱的风险点。作为稳定性保障的负责团队，如何在脆弱的环境中让迅速反向提升稳定性，提升我们的反脆弱性。互联网应用的随机性无处不在无时不发生。网络中断，机器死机，负载高，误操作，发布变更等，挖断光纤，爆炸、断电，割接等。

常说的混沌工程、Chaos Monkey是指的反脆弱能力，对现有环境实施一定的应用，负荷，主动产生可能发生的故障，我们再去感知到对可靠性的影响。虎牙也是这样，从S4到S8，每年都会多多少少出现故障，出现问题之后是怎么样去修复的，或者出现了问题改进设计。反脆弱能力是指不只是能扛住这个业务量，不止是加强健壮性，而是能在故障处理过程、在业务的发展过中提供主动反脆弱的能力，稳定性也在增长。

最后，管理能力。 我们的业务是极其复杂的，业务服务、功能、服务器之多，可靠性数据之多，涉及人员之多，没有好的管理，协同，故障管理，质量管理，应急协同等是不可能做好的。我们的业务涉及很多很多的服务器、架构、变更，包括故障，怎么把这些串联起来就是管理能力。

为了研究故障规律，我们先来看下故障生命周期：发现故障、定位故障、解决故障。放大细分一点可以分为十几个阶段，不同的阶段可以做不同的事情。稳定性保障在这些阶段做不同的事情。

六种能力里面的设计分析能力，我不知道大家做运维会不会参与到架构设计里面，或者对研发团队是否有一些影响的能力。

在我们团队，我会要求大家首先要知道业务的架构、熟悉业务的架构（画出业务架构图），这个业务架构图就是我们的同学画的，对于业务架构比较熟悉了解之后才能熟悉里面的风险，才能够知道里面的问题，比如说做系统架构、部署保障的时候才能够有的放矢，才知道问题在哪里，甚至我们会参与业务的架构设计。

做设计的时候有五个“错”，首先叫知错，大家是否有能力去知道它造成哪些问题，设计的时候要避错，容错、能够查错、改错。有些架构是我们自己来设计的，右边是直播流的一个高可用的保障，由我们来设计的。对应google SRE种说的拥抱风险、度量风险、评估风险容忍能力。

3.全链路监控感知能力&直播质量指标

前面讲到识别风险、设计和分析能力首先要有质量指标，质量指标对应谷歌SRE就是SLI以和SLO，这些指标对于定量分析质量确实很重要。我们一起分析过往的数据，未来的目标是什么？定一个或多个指标去量化质量现状、确定新的目标，朝着指标去做六种能力：感知能力、修复能力等等。

有了这些质量数据以后，还有有维度信息。运维数据=数据+维度+度量，比如直播平台的质量，有了卡顿、黑屏、秒开的数据，其实还会带很多的维度信息，比如说主播的、观众的，数据来源也有很多，我们自己的服务器断了，CDN的或者事件的各种各样的数据，我们会与端上做打通。端上在早期上报的数据比较少，后来我们一起来做这件事情，大家尽量把数据一报上来，我们来做同样的分析。

有了这些数据就能感知到质量的变化，出问题也能快速知道。很多同学可能觉得运维数据就是运维日志那些东西，日志多了会带来我们的磁盘填满这些问题就直接删除了，其实运维数据对于我们来说是非常重要的资产，对于业务来讲也是非常重要的资产，能够把数据利用好，这是对运维在整个团队里面的地位会有很大不一样的地方。

简单讲下我们的一个上报架构，如图，有各种数据的上报报告，有端上的上报，有Agent的上报。

我们用了一个ClickHouse的存储，这是俄罗斯人开发的。日均写入数据达到3000亿，效果都挺好的。

讲一下感知能力，感知能力不等于我们的监控告警，监控告警只是一环，我们的目标是从发生到感知有两分钟，这个从技术上来讲有一定的要求，秒级采集，20s上报，触发告警要在1分钟执行一次，要准确地定位这个问题，而且要发给准确的人。

现在我们要求准确发到一线，发到GOC，而且要对告警做足够的收敛。我们要感知这个问题不是说告警就够了，而是要确定问题所在，监控覆盖必须要全，这就要求业务去做上报，主播端、观众端等等各种端都要做上报，要采集运维的数据，而且这么大的数据要进行实时地的计算，我们不能一条一条发出来，要做一些聚合和关联，聚合要比较准确才能告诉你业务出现问题，指标也要变成。

这里面也会用到AIOPS的一些东西，因为要求阈值要合理，告警不能被淹没掉了，不能几百条没有人看，一线告警要升级到上级，一级领导要在更大范围去协同这件事情。感知能力的一些方法，我们会用一些CK、Flink、Hive这些。

一屏排障，通过业务运维去打开页面，要求所有的业务都做多一屏排障，我们做了一屏排障，拉很多的数据进来。我们团队很多人用Hive来做分析，这是一线的分析，长期的分析，我们用CK 和CK SQL来做分析，我们有很多灵活的页面。大家可以通 SQL 做多维度的分析，提供分析排障的东西。

感知能力确实有很好的考核指标，一个故障出现了，有多少是通过告警首先响应的，这是我们的一个指标。有告警出来了被淹没了，不是我们先看到或者不是我们先响应，这个也不算首发。这个要求也比较高，这是我们每人一天只收到5条告警，我们有很多环节的质量数据，一出问题就知道定位是某一个，越靠近主播源头可能更多就是他的原因。定位在此之后，我们要做修复和保障。

全链路修复和保障能力

下面讲一下快速恢复的能力，故障出现之后，我们要求做到5分钟去修复，首先要对研发架构、运维架构非常熟悉，要识别里面的风险，要开发出针对的保障工具。比如说我们对主播往主播网上行推流出现问题，怎么办？ CDN对观众的覆盖有问题怎么办？我们怎么发现整个问题、去定位，定位之后怎么去解决，解决的办法是换节点，换CDN的节点或者上行，或者私有的一些协议调度，这些调度要求线上与后台做互通或者决策的互通。

为了提高效率，可以做到智能线路的切换，对接到上行的问题或者链路的问题可以自动切换到其他的链路，我们还有其他的一些快恢工具，比如说接入机房可以做到快速上下线，一线值班就能快速修复。不少公司可能还是这样的，出现故障要登陆服务器去处理，这叫人肉处理，或者通过工具平台一键诊断，这就需要做平台、做工具、写脚本，下一步做稳定性保障平台，针对核心服务的运维场景的建立一些快恢工具，在平台上不断丰富场景和工具，越来越多的场景提供快速恢复的能力。

要做到故障修复从手工到智能就是数据的智能，数据其实是运维很重要的资产，也是智能运维的基础，大家把数据用得好可以帮助我们做很多的事情。比如说右边这个图看得清楚，正常情况下的业务流程，两个跑的数据没有问题就正常去跑了，一旦出现红线表示的问题或者异常的数据会触发我们一些控制的算法，然后会做一些操作的指令，这样去恢复我们的故障。

这是控制论的一个架构图，我们有些做的工具，有些无上行的推流会经常出现故障，有些一键切换的可能会切换十万次，如果十万次用人工是根本操作不了的。

这是整个商业切换的一个简单的示意图，正常说它会介入CDN，同时数据会上报到TSDB、ClickHouse这些监控系统，监控能够看到监控大屏或者告警，一线的运维和感知，一旦有问题就做调度，主播可能就到了新的链路，可以正常直播了。

我们建立了GOC团队，保障能力下放到一线值班，一线处理率达到90%以上，成功影响了整个运维组织和工作方式，很大程度解放了音视频研发同学和业务运维同学工作，并使我们的音视频运维能力达到业界领先水平。推动开发音视频调度能力和平台建设，调度能力放到一线，提升处理效率。

一线值班能处理94%音视频卡顿问题，问题一般在10分钟内都能解决恢复，时效性较高，并解放研发专家，除非特殊问需要研发参与，自动监控告警、分析、定位、一线值班可简单操作调度，并形成内外部协作的故障处理闭环。

2.可靠性工程-管理能力

再回顾下可靠性保障的一些思考。稳定性、可靠性其实是一个工程工作，是一个系统工程，不光是靠我们运维来做的。技术架构设计要跟业务研发团队打交道，做监控分析应该与监控团队、大数据团队打交道，做保障要跟基础运维团队、运维开发团队合作，要和做一线值班团队、管理团队互相协同才能把事情做好。

运维/运营是一个连接者的角色，把很多团队联结在一起大家整合起来形成一个闭环。同时稳定性工程其实是一把手工程，老板要很重视稳定性工作才能够真正做好，要不然协调不动的。

可靠性管理能力包括可靠性管理、故障管理等很多工作，比如说一个故障出来之前怎么做SLI、SLO，故障出来时怎么做应急响应，故障处理之后，怎么去记录和复盘的，复盘能力也很考验团队的协同能力。

整改或者后期的验证整个的过程，整改的是很重要的环节，通过整改或者验证之后才能说这个故障是真正完结了。我们要求已经发现的故障必须要整改，要进行核验证，在里面要发现我们的性能脆弱点，从而去发现我们的问题。

再来回顾下可靠性工程的能力框架和思考。可靠性是指在规定条件规定时间完成规定功能的能力。总结起来包括六种能力：

• 第一，设计与分析：深入业务、分析架构；就像军队的战略部、参谋部，事前宏观规划、战略部署、摆阵形。

• 第二，感知能力。感知、发现、监控、告警、响应，类似情报工作，类似卫星、侦察机、间谍、电子对抗，发现真相。诊断能力，性能的监测，嵌入SDK,APM，日志服务等。目的是提升发现和定位能力，减少耗时。

• 第三，修复能力。快速恢复、止损能力，类似军队快速打击能力，火箭军，讲求精准打击，精准修复。

• 第四，反脆弱能力。稳定性从弱到强 排序 应该是：脆弱<健壮<反脆弱。 脆弱的对立面不是健壮，而是反脆弱。预计、量化脆弱性，故障预测与健康管理，经常做体检。通过混沌工程，主动注入故障、发现脆弱点，提升环境适应性、抗抖动能力，弹性能力。例如允许丢包10%而不影响业务。

• 第五，保障能力。总后勤装备部、战略支援军、稳定性保障团队如何保障人、机器、工具、技术及时准确到位。保障能力是基础性的，支撑性的。包括资源保障、人员训练保障，甚至是操作手册等。

• 第六，可靠性管理能力。确定性保障管理能力，做好连接者，应急、协同、复盘、改进。司令部、政治部。

这是我们的“235工程”，故障发生到开始定位要2分钟，定位到响应3分钟，快速处理到快恢要5分钟，这个挑战挺大的。我们只能在部分的服务里面做好，但是不要紧，我们只需要在更多的场景做覆盖，业务组织会趋向于稳定的。

画了一个架构图，上面是我们的业务，中间是我们稳定性保障的一些打法：故障预防、防范、感知、响应、定位、恢复的过程。下面会定位一些不同的阶段做一些事情，事情防范要做哪些事情，响应要做智能监控等等。不同的阶段做不同的事情实现我们“235目标”。

以上是我分享的全部内容，希望对大家的稳定性保障工作有一点点帮助，谢谢大家！

说明：本文为虎牙直播运维总监张观石在 GOPS 2019 · 深圳站的演讲。

2019年夏天，关于 DevOps 全领域技术大会即将于北京举行，DevOps 2019 · 北京站，我们在北京等您~

文末大福利，首届 DevOps 国际峰会现场实录，互联网、金融、通信、传统行业，80个国内外大厂DevOps 落地案例，限量放送~

更多精彩，请点击阅读原文