很荣幸被邀请来Gdevops峰会作分享我叫张观石，目前在虎牙直播负责业务运维工作在正式开讲之前，先和大家谈谈我个人对运维的三点思考抛个引子：

我们运维一般是这樣的，把软硬件资源按计划准备好按需求***起来，让业务快速上线让服务器上进程和和业务正常，处理各种故障响应各方的需求。我们经常陷在处理这些工作上成为操作员、保姆、救火队员。

我们运维也都很努力也不想每次被动救火，希望能主动控制服务状态体现我们的技术价值，做了很多有效的工作运维人员是非常勤奋、爱学习的，具有非常广泛的技术视野和技能池但在技术生态中好潒总是处于一种较为弱势的、从属的、被动的地位。

2、运维技术深度和价值

我个人也是在不断思考和学习 几年前也发现自身传统运维的局限所在。尝试过深入业务通过运维人员掌握更多业务知识，了解技术架构更深度参与线上业务维护来提升价值。 比如我们深入掌握了Nginx的运维知识和优化技术，掌握了MySQL的优化技术掌握了PHP/Java的技术。这确实能一定程度提升业务质量不过靠的是个人的主动性和某方面技術的深入，没有提升为SRE这么高的一种方法论体系可以说我们一直在实践中进行摸索， 而SRE帮我们梳理了方法树立了标杆，指引了方向

DevOps 昰一种运维研发协作，甚至是整个业务链路上的敏捷协作是一种的文化和运动，而SRE是DevOps的一种实践、一种方法论SRE对我们最大收益是提供叻一种方法论体系，来指导我们运维工作也提供了一些具体的实践来供我们参考。

今天想简单跟大家分享下我们在运维上跟SRE比较类似的經验

YY是秀场直播的开创者，而虎牙直播则是国内游戏直播的先行者此外，虎牙直播是从YY里面分出来的一家公司承袭了YY的部分技术基洇。现在做直播有很多CDN厂商可以选择，但我们在开始做直播时还没有这么多厂商很多技术靠自己研究和实现，所以我们很早就有一套矗播体系

大家看到这个直播技术的流程，首先是主播开播这里有N种方式可以开播，然后有多种推流的方式将其推到某一条线路上，鈳能是我们自己的线路也可能是CDN的线路，而后CDN要转推到多家去还要在整个网络里分发到CDN边缘，通过转码转码到各种地区的运营商，朂后观众通过各种用户端连接到这些边缘节点的音视频流观众可能是并发百万级的。

整个过程路径很长需要在几秒之内完成，跟一般嘚Web类互联网业务是不同的是我个人经历过的最复杂的互联网应用。

2、技术复杂性和运维着力点

对YY来说在开始做直播的时候，还是有一萣的技术开创性但在这方面，我们运维的挑战比较大看到下面主播到观众遍布的这张架构图：

一方面，虎牙直播目前是异构多云的架構从整个链路看，任何观众都可以看到任何线路上任何主播的情况复杂度高。

另一方面相对来说，研发同学以及各个团队会比较关紸自己环节上的事情所以在我们引入了多CDN以后，不仅技术和管理复杂性大幅提高而且视频流路径在这么复杂的场景下，必须深入音视頻运维工作这对运维质量和运维人员技能提出了更高的要求。

因此由于直播平台不同以往任何架构的特殊性，以及当时视频板块技术嘚有限性促使我们必须尽快找到运维的着力点。后来我们接轨了近年来一直倡导的DevOps和SRE解决了这一困局，接下来便分享虎牙直播在这方媔上的一些实践经验

SRE由三个单词组成的：S、R、E，我先简单解释一下：

• 第一个E有两种理解：一则是Engineer工程师，一则是Engineering工程化在国内的很哆分享文章里，讲得更多是倾向于工程师这个概念我个人更认同E是工程和工程化，比如我们不叫SRE岗位但做的事情是提升业务可靠性的“工程”，甚至事情不是我们单独在做而是和业务研发联合来做。

• 第二个RReliability，意思是可靠性表达在业务上、工程上就是质量，理解为對外部最终用户的质量和价值

• 第三个S。Site/Service即运维对象、网站服务、业务服务和线上的各种服务。

从另外一个角度来看SRE岗位Google是招聘软件笁程师培养成为SRE的，而在国内我们传统运维工程师如何转型，是一个值得思考的问题目前我们在传统Ops模式上的主要问题是：过分关注洳何解决那些常规问题、紧急问题，而不是找到根本原因和减少紧急事件的数量大家都不喜欢风险，都不喜欢不期而遇、随时可能出现嘚故障可故障经常不请自来，怎么办SRE给出的***是：

第一，拥抱风险并且把风险识别出来，用SLI/SLO加以评估、度量、量化出来最终达箌消除风险的目的。

第二质量目标。一般可能认为没有故障就是正常万事大吉了。SRE要求明确定义SLI、SLO定量分析某项服务的质量，而监控系统是 SRE 团队监控服务质量和可用性的一个主要手段通过设立这样的指标，可量化质量使得我们有权力PK业务研发，也能跟老板对话取得更大的话语权。

第三减少琐事。SRE理念里讲究要花50%左右的时间在工程研发上剩余50%的时间用来做一些如资源准备、变更、部署的常规運维，以及查看和处理监控、应急事务处理、事后总结等应急处理工作如果一个屏幕上十几个窗口，各种刷屏但却不彻底解决问题，這时就需要用更好的方式——自动化、系统化、工具化的方式 ,甚至是自治的方式去处理这些“琐事”

这里对传统运维的思维也有一些挑戰，因为我们日常做得最多的工作在SRE中是被定义为价值不高的琐事运维不是操作，“运维”是个工作内容人工或是软件都可以做。在穀歌里会要求SRE有能力进行自动化工具研发，对各种技术进行研究 用自动化软件完成运维工作 ，并通过软件来制定、管理合理SLI/SLO

第四，笁程研发我个人理解的工程研发工作包括三个方面：

1. 推进产品研发改进架构，经常和研发探讨架构、集群、性能问题；

2. 自研工程技术、岼台、工具、系统、基础组件、框架

我们目前在这些方面都有一些开始在探索和转型，下面将展开详谈

我们来看看直播平台面对的风險和质量指标，以及我们是怎么样通过工程手段来提升质量的

直播流媒体技术中有很多指标，内部大概有上百个指标常用的也有十几個，下面是音视频方面的一些场景：

• 主播端：开播、采集、处理、推流失败、崩溃

• 观众端：进不了直播、拉视频失败、黑屏、花屏、卡顿、延迟

当我们把卡顿单独切出来进行分析会发现它是由比如平台、主播、线路、地区、运营商、时间段、端、时长、用户数量、卡顿率等多方面因素制约的。虽然卡顿是平台中最常见也是最重要的质量指标但什么是卡顿、什么是卡顿率？业界目前没有统一的定义下面峩们以虎牙的定义，来讲讲直播的SLI、SLO

• 第一种情况，由延时造成的卡顿

如果没有丢帧，但持续超过一定时间没有画面就算是卡顿（比洳1，2是连续的丢帧2比应该播放时刻晚数百ms算一个卡顿）

• 第二种情况，由丢帧造成的卡顿

如果连续丢帧大于1个，而且持续数百ms没有画面僦是产生了卡顿

• 第三种情况，由跳帧造成的卡顿

如果连续丢帧大于1个，有连续画面但丢掉的帧播放时长大于一定时间的情况。

（即通过增加丢掉的帧前面帧的播放时长可以有效减少卡顿，但后续画面接上去时会产生画面跳动感觉超过一定时间用户就能察觉。）

• 最後一种情况是由视频源帧率低造成的卡顿。

如果可解码帧帧率低于10帧以及丢帧率大于20%时会发生卡顿。（因为视频随机丢帧后导致帧率下降，容易被人眼看出来）

有了卡顿之后怎么把卡顿计算成卡顿率呢？业界没有统一的定义有人统计卡顿用户比例，卡顿时长方法但这些太粗了，都不能满足我们的要求而且很多的维度分析，都不能很好地衡量质量和做监控卡顿率这事其实有点小复杂，这里说說我们的一些计算方法

对于卡顿的数据，我们有5秒、20秒的粒度上报而且上报的是有多维度信息。那卡顿率怎么来定义

（2）卡顿率：鉲次数/用户数

我们稍稍分析下，从纵向看有全平台或某条流某个时刻的卡顿率，这个很好理解单单统计这个时刻的卡顿上报次数/上报樣本数即可。

从横向看单条流在直播时段内的卡顿率，比如一个主播的卡顿率卡顿样本次数累加/上报样本数累加；从全体来看，可以汾全平台每天的卡顿率此外，我们还有计算线路卡顿率以及其它多种维度的卡顿率

但这里会有一个小小的问题：一个直播间有小部分鼡户一直卡和在一小段时间内一直卡顿，卡顿率可能都是一样的这显然不公平，于是我们在这中间又多定义了中度卡顿率和重度卡顿率

其中，当某个时刻卡顿率区间范围为10%-40%属于中度卡顿率，超过40%的直播平台带宽是非常猛的，每年可能有几个亿的带宽费用要付出去洏付给每一家都是一个很大的量。老板很重视这个情况如果没有这个卡顿率，我们很难去跟老板上报质量如何应该分配多少量给哪一镓，得有数据可以作为决策的依据

有了卡顿率之后，接下来就是如何做监控这是我们直播视频质量全链路监控围绕视频直播平台的场景，我们构建了从主播视频源到观众端观看直播所有环节的点实时采集，展示、定位、告警系统这个系统能够帮助运维人员快速准确萣位到直播流卡顿的现象和原因，也能评估长期总体质量各个环节研发往往对自己的节点感兴趣，由运维对整体负责串起来。在这里媔整合多环节质量数据，体现了DevOps的理念；通过构建系统来做体现了SRE的工程化理念；从上报到监控，告警、评估闭环能力落地到系统，我们不是靠专家而是解放了专家。

有了全链路系统后我们还做了一个告警和事后问题分析总结的反馈闭环。

5、故障处理和质量闭环

這是我们做的一个质量故障处理和质量评估的闭环首先是质量数据的采集，上报存储然后由监控系统来监控，通过秒级监控自动报障到运维和CDN厂商，由厂商人员分析定位后反馈可以减少运维的人工参与。

从这个监控全平台的卡顿数据我们还可以再挖掘一些数据出來，比如每天生成一些卡顿日报然后自动发到我们内部和厂商两边，厂商会自己来做一些回复、调查和总结最后反馈回给我们，这样通过定期Review CDN的质量进行定期总结和评估对比，我们再以此为根据看看质量调整和效果的情况。

同时我们会有一些评估的手段也是从这些数据里面把它挖掘出来的，用来推动处理CDN直播平台的发展和完善

还有就是建立更开放的技术交流氛围，把质量数据反馈给各CDN推动分析问题。以往每家厂商过来都要踩很多坑现在我们对各家CDN、各条线路、各个地区和各个运营商的质量线路都进行了切量、调度、线路的調整，实现了大部分主播的监控覆盖当然，在这里面我们还会有一些运维能力在整合后面会再展开讲。

这是我们把这整个质量指标串起来之后实现的效果：

案例1：直播音视频质量

• 第一建立了全链路的监控系统，实现了秒级发现流级别的卡顿情况也提升了监控的覆盖率，同时是自动化、实时性、可观测的

• 第二，通过建立质量模型运用卡顿率和稳定性可以随时评估主播、平台、线路的质量，可以Review质量

• 第三，和CDN厂商一起持续发现和优化质量

• 第四，把能力推到一线值班把能力推到一线值班 ，以前运维是没有音视频Oncall能力的只有资罙的音视频研发工程师可以处理问题，现在一线值班我们业务运维可以当做二线，只处理一些更重要的问题

我们在点播项目上也用了質量指标的方式去做，也实现不错的效果目前我们可以实现评估供应商，仅保留好用的；推动播放器改进统计优化自动上报；推动服務端研发加强故障统计，整个质量有了大幅度的提升同时我们也可以把全平台评估业务质量，生成相关数据报告给老板去看让他了解箌项目目前的质量状况和质量变化情况。

7、虎牙实践：带宽调度

接下来介绍虎牙带宽调度的一个实践会从调度的原因、方法和评估三方媔进行介绍。

• 质量挑战质量是我们最在乎的事情，但每家CDN线路和我们都经常有故障等各类情况出现这里就需要有一个调度的能力，当某条线路或者某些情况下出现质量问题了可以及时把它调走。

• 容量挑战直播平台对带宽消耗是非常大的，可每家CDN可承受的带宽是有一萣上限的必须要做一定调度，特别是大型活动上要防止某家CDN厂商全部挂掉或者局部挂掉的情况。

调度方法有这样主播调度、观众调度、静态调度、动态调度、无缝切换能力几种

主播调度，就是把这个主播调度到某条线路上去我们或某家CDN的都可以。主播的调度又分为單CDN内的智能调度和多CDN的智能调度两种我们会做一些默认的配置，并提供动态的能力实现无缝的切流。观众端也是做了静态和动态的调喥策略优先使用平台里它的质量会应该是更有所保障的。此外我们也提供了动态调度系统，让它在观众进直播间时可以调到某一条线蕗上去

在这整个过程中，我们运维人员都参与其中提出我们的需求和目标。并跟研发一起或者自己开发其中的某些环节，形成一个個工程工作促使业务质量大幅提升，并且自己的能力落地到了工程系统中实现了运维价值的输出。

除了上述的我们还有一些其它比較接近SRE理念的实践，这里先和大家简单分享一下

1、以SRE的姿势接维

如何接维一个新的业务，或是从其他人手里接维老项目；接维后如何处悝和其他团队的关系如何持续改进业务质量，这部分可以说是DevOps的实践也是有我整理出来的一些实践，具体来说：

（1）了解产品作为鼡户区了解，以开发者视角去了解产品了解网站结构，以及背后的技术原理和流程；

（2）阅读文档获取开发文档、运维文档、设计文檔、阅读wiki等；

（3）掌握资源：作为内部人员去了解部署和服务器等资源、CMDB ，了解监控 、管理后台；

（4）熟悉架构：请研发leader 整体介绍产品、架构、部署；

（5）获取故障：请研发转发最近的bug邮件、故障邮件了解最近的事故和事后总结；

（6）获取需求：最近重要的需求和开发计劃；

（7）运研关系：参与研发周会，积极合作 改变运维与研发的关系；

（8）了解期望：和产品研发Leader沟通，了解核心问题和对运维的期望；

（9）梳理指标：核心业务指标加上监控；

（10）输出进展：举行运维研发周会，请研发上级领导参加了解最近接维后的故障；

（11）推進改进：大家都重视后，提出改进需求和工程计划；

（12）输出价值：把核心指标提升为公司级关注的指标

运维研发会议，我们试过了效果很不错。时间上来说是每周一次有两级的领导在场，包括研发团队的同学、具体业务研发的领导和上一级业务领导在场内容有这麼几点：

（1）定期Review性能指标、容量数据、可用性情况等质量、趋势；

（2）紧急的告警 、非紧急的告警；

（3）即将进行的生产环境变化；

（4）要进行技术决策的事宜；

（5）运维希望研发推进的事情、研发希望运维推进的事情；

（6）技术工作的同步；

（7）接下来待办事项及计划。

事后总结和改进是SRE切入深入业务的最直接的方式这是我们的模板：

其中，改进措施里面必须是要长效的措施而不能是头痛医头，脚痛医脚这种方式

1、SRE与运维的关系

那么，传统运维究竟如何转型SRE呢正如我第一部分讲到的，在谷歌内部是直接招聘软件工程师专职做SRE，跟传统的业务公司不一样它是有第三种岗位的。但我个人的理解是SRE是一个工程性的活动，不一定是一个岗位研发可以转过来，运維也可以转过来所以运维人员要有认识，这是可以互相抢饭碗的

从SRE的工程性活动这个层面出发，在研发层面运维做SRE，不一定是完全洎己做我们可以提出需求、设想和计划，然后找开发的资源实现这是工程师的维度。此外在反向工程的层面上，深入理解技术架构学会站在更高视角去完善自己的架构思维和质量思维，留出时间来用于工程相关的思考与学习要明确运维的本质：就是人与机器一起唍成的工程性的工作！