当前位置:澳门贵宾厅 > www.vip8888.com > 对运维的思考1、www.vip8888.com传统运维窘境,我今天要分享的是运维技术如何驱动直播平台整体技术稳定性
对运维的思考1、www.vip8888.com传统运维窘境,我今天要分享的是运维技术如何驱动直播平台整体技术稳定性
2020-03-31

本文根据张观石老师在〖Gdevops 2017全球敏捷运维峰会广州站〗现场演讲内容整理而成。

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

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

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

对运维的思考1、传统运维窘境

首先会介绍下直播技术的总体架构和挑战;然后给大家分享下我提炼的可靠性工程、稳定性保障工作的一个能力框架;接着讲下在直播音视频的稳定性保障中的应用。包括几个核心指标和评估体系,如何度量直播的稳定性;接下来会介绍如何提升可靠性的感知能力,可靠性下降了,故障来了,如何快速感知到,这包括了监控、告警、响应以及一些技术点;再然后会讲下我对能力框架中的快速修复和保障能力的认识。快速修复能力、恢复能力是运维能力的体现,是缩短故障时长的关键点;最后会再次总结下我对可靠性工程的能力框架和几点思考。1.直播音视频传输的总体技术架构

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

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

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

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

2、运维技术深度和价值

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

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

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

对运维的思考1、www.vip8888.com传统运维窘境,我今天要分享的是运维技术如何驱动直播平台整体技术稳定性。3、DevOps和SRE的关系

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

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

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

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

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

我们的运维现状与挑战1、直播平台的挑战

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

关于SRE理念1、SRE回顾

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

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

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

第一个E。有两种理解:一则是Engineer工程师,一则是Engineering工程化。在国内的很多分享文章里,讲得更多是倾向于工程师这个概念。我个人更认同E是工程和工程化,比如我们不叫SRE岗位,但做的事情是提升业务可靠性的“工程”,甚至事情不是我们单独在做,而是和业务研发联合来做。第二个R。Reliability,意思是可靠性,表达在业务上、工程上就是质量,理解为对外部最终用户的质量和价值。第三个S。Site/Service,即运维对象、网站服务、业务服务和线上的各种服务。2、SRE理念

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

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

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

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

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

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

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

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

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

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

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

第四,工程研发。我个人理解的工程研发工作包括三个方面:

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

推进产品研发改进架构,经常和研发探讨架构、集群、性能问题;引入新的运维技术,基础组件要hold住,比如TSDB、Bosun、Consul、Zipkin等;自研工程技术、平台、工具、系统、基础组件、框架。

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

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

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

虎牙直播的SRE实践1、质量指标SLI

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

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

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

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

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

直播质量指标

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

主播端:开播、采集、处理、推流失败、崩溃观众端:进不了直播、拉视频失败、黑屏、花屏、卡顿、延迟

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

卡顿分析

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

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

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

2、SLI卡顿定义第一种情况,由延时造成的卡顿。

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

如果没有丢帧,但持续超过一定时间没有画面就算是卡顿。

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

第二种情况,由丢帧造成的卡顿。

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

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

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

第三种情况,由跳帧造成的卡顿。

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

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

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

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

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

如果可解码帧帧率低于10帧,以及丢帧率大于20%时会发生卡顿。

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

3、卡顿率SLI定义

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

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

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

卡顿数据

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

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

我们用了一个ClickHouse的存储,这是俄罗斯人开发的。日均写入数据达到3000亿,效果都挺好的。讲一下感知能力,感知能力不等于我们的监控告警,监控告警只是一环,我们的目标是从发生到感知有两分钟,这个从技术上来讲有一定的要求,秒级采集,20s上报,触发告警要在1分钟执行一次,要准确地定位这个问题,而且要发给准确的人。现在我们要求准确发到一线,发到GOC,而且要对告警做足够的收敛。我们要感知这个问题不是说告警就够了,而是要确定问题所在,监控覆盖必须要全,这就要求业务去做上报,主播端、观众端等等各种端都要做上报,要采集运维的数据,而且这么大的数据要进行实时地的计算,我们不能一条一条发出来,要做一些聚合和关联,聚合要比较准确才能告诉你业务出现问题,指标也要变成。

卡顿率:卡次数/用户数

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

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

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

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

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

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

全链路修复和保障能力

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

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

4、全链路监控

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

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

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

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

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

5、故障处理和质量闭环

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

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

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

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

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

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

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

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

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

6、质量指标SLI/SLO效果

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

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

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

案例1:直播音视频质量

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

第一,建立了全链路的监控系统,实现了秒级发现流级别的卡顿情况,也提升了监控的覆盖率,同时是自动化、实时性、可观测的。第二,通过建立质量模型,运用卡顿率和稳定性可以随时评估主播、平台、线路的质量,可以Review质量。第三,和CDN厂商一起持续发现和优化质量。第四,把能力推到一线值班。把能力推到一线值班 ,以前运维是没有音视频Oncall能力的,只有资深的音视频研发工程师可以处理问题,现在一线值班,我们业务运维可以当做二线,只处理一些更重要的问题。

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

案例2:点播成功率

第一,设计与分析:深入业务、分析架构;就像军队的战略部、参谋部,事前宏观规划、战略部署、摆阵形。第二,感知能力。感知、发现、监控、告警、响应,类似情报工作,类似卫星、侦察机、间谍、电子对抗,发现真相。诊断能力,性能的监测,嵌入SDK,APM,日志服务等。目的是提升发现和定位能力,减少耗时。第三,修复能力。快速恢复、止损能力,类似军队快速打击能力,火箭军,讲求精准打击,精准修复。第四,反脆弱能力。稳定性从弱到强排序应该是:脆弱健壮反脆弱。 脆弱的对立面不是健壮,而是反脆弱。预计、量化脆弱性,故障预测与健康管理,经常做体检。通过混沌工程,主动注入故障、发现脆弱点,提升环境适应性、抗抖动能力,弹性能力。例如允许丢包10%而不影响业务。第五,保障能力。总后勤装备部、战略支援军、稳定性保障团队如何保障人、机器、工具、技术及时准确到位。保障能力是基础性的,支撑性的。包括资源保障、人员训练保障,甚至是操作手册等。第六,可靠性管理能力。确定性保障管理能力,做好连接者,应急、协同、复盘、改进。司令部、政治部。

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

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

7、虎牙实践:带宽调度

画了一个架构图,上面是我们的业务,中间是我们稳定性保障的一些打法:故障预防、防范、感知、响应、定位、恢复的过程。下面会定位一些不同的阶段做一些事情,事情防范要做哪些事情,响应要做智能监控等等。不同的阶段做不同的事情实现我们“235目标”。以上是我分享的全部内容,希望对大家的稳定性保障工作有一点点帮助,谢谢大家!

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

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

为什么要调度

质量挑战。质量是我们最在乎的事情,但每家CDN线路和我们都经常有故障等各类情况出现,这里就需要有一个调度的能力,当某条线路或者某些情况下出现质量问题了,可以及时把它调走。容量挑战。直播平台对带宽消耗是非常大的,可每家CDN可承受的带宽是有一定上限的,必须要做一定调度,特别是大型活动上,要防止某家CDN厂商全部挂掉或者局部挂掉的情况。

调度方法

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

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

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

SRE理念的一些实践

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

1、以SRE的姿势接维

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

了解产品,作为用户区了解,以开发者视角去了解产品,了解网站结构,以及背后的技术原理和流程;

阅读文档,获取开发文档、运维文档、设计文档、阅读wiki等;

掌握资源:作为内部人员去了解部署和服务器等资源、CMDB ,了解监控 、管理后台;

熟悉架构:请研发leader 整体介绍产品、架构、部署;

获取故障:请研发转发最近的bug邮件、故障邮件,了解最近的事故和事后总结;

获取需求:最近重要的需求和开发计划;

运研关系:参与研发周会,积极合作 ,改变运维与研发的关系;

了解期望:和产品研发Leader沟通,了解核心问题和对运维的期望;

梳理指标:核心业务指标,加上监控;

输出进展:举行运维研发周会,请研发上级领导参加,了解最近接维后的故障;

推进改进:大家都重视后,提出改进需求和工程计划;

输出价值:把核心指标提升为公司级关注的指标。

2、运维研发会议

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

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

紧急的告警 、非紧急的告警;

即将进行的生产环境变化;

要进行技术决策的事宜;

运维希望研发推进的事情、研发希望运维推进的事情;

技术工作的同步;

接下来待办事项及计划。

3、事后报告

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

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

转型SRE1、SRE与运维的关系

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

2、如何转型SRE

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

作者:

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

原文来自微信公众号:DBAplus社群

上一篇:没有了
下一篇:没有了