运维人员非常勤奋好学，有非常广阔的技术视野和技能储备。但为何在技术生态中始终处于相对弱势、从属、被动的地位？我叫张冠石，目前在虎牙直播负责业务运维。先跟大家说说我个人对运维的三个思考。这里介绍一下：关于运维的三点思考。传统的运维困境。我们的运维一般是这样的：按计划准备软硬件资源，按需安装。起来，让业务快速上线，让服务器上的流程和业务正常，处理各种故障，响应各方需求。我们经常忙于处理这些工作，成为操作员、保姆、消防员。我们在运维方面也很努力，不想每次都被动救火。我们希望主动把控服务状态，体现我们的技术价值，做很多有成效的工作。运维人员非常勤奋好学，有非常广阔的技术视野和技能储备。但在技术生态中，它似乎始终处于相对弱势、从属、被动的地位。我也在不断思考和学习运维技术的深度和价值。几年前我也发现了我传统运维的局限性。并尝试深入业务，通过运维人员掌握更多的业务知识，了解技术架构，更深入地参与线上业务维护，提升价值。比如深入了解Nginx的运维知识和优化技术，MySQL的优化技术，PHP/Java的技术。这确实可以在一定程度上提高业务质量，但是在某些方面依赖于个人的主动性和深入的技术，并没有升级到像SRE那样高的方法论体系。可以说我们一直在实践中摸索，SRE帮我们梳理了方法，树立了标杆，指明了方向。DevOps和SREDevOps的关系是一种运维研发协作，甚至是整个业务链路上的敏捷协作。它是一种文化和运动，而SRE是DevOps的一种实践和方法论。SRE给我们最大的好处就是提供了一个方法论体系来指导我们的运维工作，同时也提供了一些具体的做法供我们参考。今天简单跟大家分享一下我们在SRE运维方面类似的经验。虎牙直播运维现状及挑战直播平台YY的挑战是秀场直播的先行者，虎牙直播是国内游戏直播的先行者。另外，虎牙直播是一家从YY中分离出来的公司，继承了YY的部分技术基因。现在做直播，有很多CDN厂商可以选择，但是我们刚开始做直播的时候，没有那么多厂商。很多技术都是我们自己研究实现的，所以我们很早就有了直播系统。大家都看到了这种直播技术的过程。首先，主播开始直播。有N种方式开始广播。那么推流的方式有很多种，推到某个线路，可能是我们自己的线路，也可能是CDN的线路，然后CDN会转发到多个地方，分发到整个网络CDN边缘，通过转码，转码到各个地区的运营商。***观众通过各种客户端连接到这些边缘节点的音视频流，观众可能并发***。整个过程很长，需要在几秒钟内完成。它不同于一般的Web类互联网服务，是我亲身体验过的最复杂的互联网应用。技术复杂度和运维重点对于YY来说，在做直播的时候，还是有一定的技术创新的。但是在这方面，我们的运维挑战比较大。从主播到观众看下面的架构图：一方面，虎牙直播目前是异构多云的架构。从整个链路的角度来看，任何一个观众都可以看到任何一条线上任何一个主播的情况，这是非常复杂的。另一方面，相对来说，R&D同学和各个团队会更加关注自己的方面。所以，我们引入多个CDN之后，不仅技术和管理的复杂度大大增加，而且在如此复杂的场景下，音视频运维还必须深入视频流路径，这就给我们带来了更多的挑战。运维质量和运维人员的技能水平。高要求。因此，由于直播平台不同于以往任何架构的特殊性，以及当时视频领域的技术有限，我们必须尽快找到运维的重点。后来我们整合了DevOps和我们这几年一直提倡的SRE来解决这个困境。接下来，我们将分享虎牙直播在这方面的一些实践经验。关于SRE概念SRE回顾SRE由三个词组成，我简单解释一下：第一个E。有两种理解：一种是Engineering工程师，一种是Engineering工程。在国内的很多分享文章中，讲的比较偏向于工程师的概念。我个人同意E是工程和工程。比如我们不叫SRE岗位，我们做的是“工程”，提高业务可靠性，甚至事情不是我们一个人做的，而是结合业务研发。第二R.Reliability，意为可靠性，从业务和工程上表达质量，对外终端用户理解为质量和价值。第三个S.Site/Service，即运维对象、网站服务、商业服务和各种在线服务。SRE概念从另一个角度看待SRE职位。Google招募软件工程师来培训他们成为SRE。在中国，我们传统的运维工程师如何转型，是一个值得思考的问题。我们目前传统Ops模型存在的主要问题是：过于关注如何解决那些常规问题、紧急问题，而不是找到根本原因和减少紧急事件的数量。每个人都不喜欢冒险，也不喜欢随时可能发生的意外失败，但失败往往是不请自来的，我们该怎么办？SRE给出的答案是：***，拥抱风险。并识别出风险，用SLI/SLO对其进行评价、衡量、量化，最终达到消除风险的目的。二是质量目标。一般可以认为没有故障是正常的，万事大吉。SRE需要明确定义SLI、SLO，对服务质量进行量化分析，而监控系统是SRE团队监控服务质量和可用性的主要手段。通过设置这样的指标，可以将质量量化，让我们有PK业务研发的力量，也可以和老板对话，获得更大的话语权。第三，减少家务。在SRE理念中，大约50%的时间用于工程研发，剩余50%的时间用于资源准备、变更、部署等日常运维，以及查看和处理监控、紧急事务处理、事后总结等应急处理工作。如果一个屏幕上有十几个窗口，各种屏幕滑动，但问题还不能彻底解决，那么就需要一种更好的方式——自动化的、系统的、工具的，甚至是自主的——来处理这些问题的“琐事”.这里对传统运维的思维也有一些挑战，因为我们在日常生活中做的最多的工作在SRE中被定义为低价值的琐事。运维不是运营。“运维”是一个工作内容。可以做。在谷歌，要求SRE能够开发自动化工具，对各种技术进行研究，使用自动化软件完成运维工作，使用软件制定和管理合理的SLI/SLO。四是工程研发。我个人理解的工程研发工作包括三个方面：推动产品研发改进架构，经常和研发讨论架构、集群、性能问题。引入新的运维技术，必须掌握基础组件，如TSDB、Bosun、Consul、Zipkin等。自研工程技术、平台、工具、系统、基础组件、框架。我们目前正在这些方面进行探索和改造，下面会详细介绍。虎牙直播的SRE践行质量指标SLI下面我们就来看看直播平台面临的风险和质量指标，以及我们是如何通过工程手段来提升质量的。流媒体直播技术指标有很多。内部大概有几百个指标，常用的就有十几个。以下是音视频中的一些场景：直播质量指标。观众端：无法进入直播，拉取视频失败，黑屏，花屏，卡顿，延时卡顿分析当我们把卡顿切出来单独分析时，会发现是平台等原因造成的，anchor,line,region,operator,受时间段、终端、时长、用户数、冻结率等多种因素制约。虽然冻结是平台中最常见也是最重要的质量指标，但是什么是冻结，什么是冻结率呢？目前业界没有统一的定义。下面根据虎牙的定义说说直播的SLI和SLO。SLI卡顿定义为以下四种类型的卡顿：延迟引起的卡顿。如果没有丢帧，但超过一定时间没有画面，则视为卡顿。（比如1和2是连续丢帧，2比预期的播放时间晚了几百ms，算是卡顿）丢帧导致的卡顿。如果连续丢帧超过1个，几百ms没有画面，就是卡顿。跳帧引起的卡顿。如果连续丢帧不止一个，则画面是连续的，但丢帧的播放时间要长于一定的时间。（即通过增加丢帧前一帧的播放时间，可以有效减少卡顿，但是后续接屏时，画面会跳动，一定时间后用户才能察觉到）的时间。）这是由视频源的低帧率引起的。暂停。可解码帧率低于10帧且丢帧率大于20%时会出现卡顿。（因为视频随机丢帧导致帧率下降，人眼很容易看出来。）卡顿率在SLI定义后，卡顿率怎么计算呢？业界没有统一的定义。有人统计了冻结用户的百分比和冻结时长，但是这些都太粗糙了，不能满足我们的要求。此外，许多维度分析无法很好地衡量质量和监控。冻结率其实有点复杂。下面是我们的一些计算方法。卡顿数据对于卡顿数据，我们有5秒和20秒的粒度去上报，上报的是多维度的信息。如何定义滞后率？卡顿率：卡住次数/用户数。我们稍微分析一下。从纵向上看，整个平台或者某一个流在某个时刻出现了卡顿率。这很容易理解。统计一下此时卡住的报告/报告样本的数量即可。从横向看，直播期间单条码流的卡顿率，如主播卡顿率，累计卡顿样本数/累计举报样本数；从整体来看，可以分为整个平台的每日冻结率。此外，我们还计算了线路卡顿率和其他维度的卡顿率。但是这里会有一个小问题：一个直播间有一小部分用户出现卡顿或者卡顿时间很短，卡顿率可能也是一样的，这显然是不公平的，所以我们多在定义了中等冻结率和严重冻结率。其中，当某一时刻冻结率在10%～40%之间时，属于中度冻结率，超过40%则属于重度冻结率。直播平台的带宽很猛，每年可能要交上亿的带宽费，给每个公司交是一笔不小的数目。老板很重视这个情况。如果没有这个摊档率，我们就很难向老板汇报质量，应该分到哪家公司。必须有数据可以作为决策的依据。全链路监控有了卡顿率之后，接下来就是怎么监控了。视频直播质量全链路监控我们围绕视频直播平台场景，构建了从主播视频源到观看直播的观众全链路的实时采集、展示、定位、报警系统。该系统可以帮助运维人员快速准确定位直播卡顿的现象和原因，也可以评估长期的整体质量。每个环节的研发往往对自己的节点感兴趣，运维负责整体，连在一起。这其中，多链路质量数据的整合体现了DevOps的理念；系统的建设体现了SRE的工程理念；从报告到监控、报警、评估闭环，再到系统落地能力，我们不依赖专家。相反，它解放了专家。有了全链路体系，我们也做了告警和事后问题分析总结的反馈闭环。故障处理和质量闭环这是我们做的质量故障处理和质量评价的闭环。首先，质量数据被收集、报告和存储，然后由监控系统进行监控。通过秒级监控，故障自动上报给运维和CDN厂商，厂商人员分析定位反馈，减少运维人工参与。从整个平台的这个监控数据中，我们也可以挖掘出一些数据，比如每天生成一些日卡，然后自动发给我们内部和厂家，厂家自己做一些回复，调查，总结,***反馈给我们。这样，我们通过对CDN质量的定期回顾，进行定期的总结和评估比较，然后以此为依据，看质量调整的情况和效果。同时，我们也会有一些评价方法，也是从这些数据中挖掘出来的，来推动CDN直播平台的发展和完善。二是建立更加开放的技术交流氛围，向CDN反馈优质数据，促进问题分析。过去，每个制造商都必须踩很多陷阱。现在我们对每个CDN、每个线路、每个区域、每个运营商的质量线路进行了剪裁、调度、调整，实现了对大部分主播的监控。覆盖。当然，我们也会集成一些运维能力，这个以后再说。质量指标SLI/SLO的效果这是我们把所有质量指标串起来后的效果：案例一：建立了直播音视频质量的全链路监控系统，实现了流-关卡秒级冻结，提高监控覆盖率，自动化、实时、可观察。通过建立质量模型，利用卡顿率和稳定性随时评估主机、平台、线路的质量，对质量进行回顾。与CDN供应商一起不断发现和优化质量。把能力推到前线值班。将能力推向执勤一线。过去，运维没有音视频oncall能力。只有经验丰富的音视频研发工程师才能处理问题。现在一线值班了，我们的业务运维也算是二线了，只处理一些比较重要的问题。案例二：点播成功率我们也对点播项目使用了质量指标，取得了不错的效果。目前，我们可以对供应商进行评估，只保留有用的；促进球员进步统计并优化自动报告；推动服务器研发加强故障统计，整体质量大幅提升。同时，我们还可以跨平台评估业务质量，生成相关数据报告给老板，让他了解项目当前的质量状况和质量变化。虎牙实践：带宽调度接下来介绍一个虎牙带宽调度的实践，将从调度的原因、方法和评估三个方面进行介绍。为什么要安排？原因有二：质量挑战。质量是我们最关心的，但是每条CDN线路和我们经常会出现故障等各种情况。这里我们需要一个调度能力。当某条线路或某些情况下出现质量问题时，我们可以及时将其调走。能力挑战。直播平台对带宽的消耗很大，但是每个CDN对可以承受的带宽都有一定的上限，必须做一定的调度，尤其是大型活动，防止某个CDN厂商彻底挂掉或部分条件。调度方式有：主播调度观众调度静态调度动态调度无缝切换能力调度主播调度就是把主播调度到某个线路上，我们或者某个CDN都可以做。主播的调度分为单CDN内智能调度和多CDN智能调度。我们会做一些默认的配置，提供动态的能力来实现无缝的流切换。观众端也实现了静态和动态的调度策略，优先使用平台内的台词，其质量将更有保障。此外，我们还提供了动态调度系统，让观众进入直播间时，可以自动调到某一行。在整个过程中，我们的运维人员都参与进来，提出我们的需求和目标。并且和研发一起，或者自己开发一部分，一个一个的形成工程化工作，极大的提升了业务的质量，将自身的能力落地到工程化体系中，实现运维价值的输出。SRE理念的一些实践除了上述实践之外，我们还有一些更接近SRE理念的实践。在这里和大家简单分享一下。如何作为SRE接手新业务，或者接手别人的旧项目；接手后如何处理与其他团队的关系，如何不断提升业务质量，这部分可以说是DevOps的实践，也有一些我整理出来的实践。具体有以下几点：了解产品，作为用户来了解，从开发者的角度来了解产品，了解网站结构，以及背后的技术原理和流程。阅读文档，获取开发文档，运维文档，设计文档，阅读WiKi等。掌握资源，作为内部人员了解部署和服务器，CMDB等资源，了解监控，管理后台。如果熟悉架构，请开发Leader从整体上介绍产品、架构、部署。获取故障，请制定并转发最新的bug邮件和故障邮件，了解近期发生的事故和事后总结。获取需求，近期重要需求和开发计划。运研关系，参与研发周会，积极配合，改变运维与研发的关系。了解期望，与产品开发负责人沟通，了解运维的核心问题和期望。梳理指标，核心业务指标，加监控。输出进度，召开运维研发周会，邀请研发主管参与，了解近期维护后出现的故障。推动改进，待大家关注后，提出改进要求和工程方案。产值并将核心指标提升为公司关注的指标。运维研发会运维研发会，我们试过了，效果很好。时间上是每周一次，有两级领导在场，包括研发团队的学生，具体业务研发的领导，以及上层的业务领导。内容包括以下几点：定期回顾性能指标、容量数据、可用性等的质量和趋势。紧急和非紧急警报。即将发生的生产环境变化。做出技术决定的事项。运维希望研发推动的东西，研发希望运维推动的东西。技术工作同步化。后续步骤和计划。事后报告事后总结和改进是SRE深入业务最直接的方式。这是我们的模板：其中，改善措施要有长效措施，而不是头疼就医头，脚疼就医脚。SRESRE与运维关系的转变传统运维如何改造SRE？正如我在第一部分中提到的，在谷歌内部，软件工程师被直接招聘为全职SRE。与传统商业公司不同，它具有第三地位。但我个人的理解是，SRE是一种工程活动，不一定是一份工作。研发可以转，运维也可以转。因此，运维人员必须互相认识。如何改造SRE从SRE工程活动的层面开始。在研发层面，SRE的运维并不一定要由我们自己来完成。我们可以提出需求、想法和计划，然后寻找发展资源去实现。这是工程师的维度。.另外，在逆向工程层面，深入理解技术架构，学会从更高的角度提升自己的架构思维和品质思维，留出时间进行工程相关的思考和学习。有必要明确一下运维的本质：它是人和机器共同完成的工程工作！
