NBA直播,足球直播,篮球直播,欧洲杯直播,lol直播,英雄联盟直播,dota2直播,dnf直播,cf直播,绝地求生直播,王者荣耀直播,游戏直播,赛事直播,YY直播,美女直播,视频直播,足球直播文根据张观石老师在〖Gdevops 2017全球敏捷运维峰会广州站〗现场演讲内容整理而成。

　　张观石，虎牙直播业务运维负责人，《运维前线》联合作者。拥有多年互联网业务运维经验。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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