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