当前位置: 亚洲城ca88 > 计算机网络 > 正文

虎牙直播张观石【计算机网络】,虎牙直播的S

时间:2020-03-17 21:35来源:计算机网络
本文根据张观石老师在〖Gdevops2017全球敏捷运维峰会广州站〗现场演讲内容整理而成。 大家好,我叫张观石,来自虎牙直播,虎牙直播是弹幕式的游戏直播平台,我在公司负责业务运维

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

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

导读:本文是我在3月4日数人云北京站线下活动“当西方的SRE遇上东方的互联网”中的分享。

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

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

本文从SRE,Devops, PE间的关系开始,介绍企业该如何构建适合自己的运维组织架构并管理团队,讲解持续交付、监控、容量规划等具体运维场景实操,从工程实践的角度解读大规模复杂化的业务场景下运维指导思想的落地。

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

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

王超 / 京东金融企业PE团队负责人

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

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

目前在京东金融平台负责一个20人左右的应用运维团队(PE团队),也曾负责人人网PE团队。现阶段主要关注运维与业务的融合、业务可用性保障,运维平台建设和团队管理。

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

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

我是今天最后的演讲者,前面几位都是很知名的运维专家,对大家提到的很多运维痛点我都感同身受,谈到国内运维行业的发展,我没有在国外工作的经验,今天讲的经验都是我在国内不算美好的IT行业环境下的亲身实践和总结,其中也吸收了很多国内运维行业专家前辈的指点,希望对大家有借鉴的意义。

2、运维技术深度和价值

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

刚毕业时我在一家世界500强的传统行业公司信息中心做应用运维,后来换到人人网,再后来就是京东金融。从传统行业跳到人人网的时候,加入的是一个刚建立的技术运维团队,我从初期的运维工程师,成长为后来的运维主管。2014年到京东金融的时候,从0开始搭建起整个应用运维团队,从初期建设团队到一个比较稳定的状态,把公司的业务支撑好,这里面有很多经验可以和大家分享。

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

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

详解DevOps

3、DevOps和SRE的关系

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

DevOps 是传统瀑布流的交付方式中的Dev(开发)和Ops(运维)的关系。

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

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

开发和运维有一个矛盾点,开发的人觉得写好代码交给运维,就可以上线部署了,后面的事与我无关。代码像炸弹一样,上线后如果出了问题总是运维背锅。运维的人觉得开发的人总是找麻烦,总是不靠谱,于是把控变更的次数和审核流程,使开发的人不能申请更多的上线,比如一个星期只允许上线一次,就这样阻碍了业务的发展。DevOps解决了这个矛盾,协调了技术运营、QA还有开发三者间的关系。

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

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

DevOps误区

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

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

国内有很多错误的做法,比如写着招聘DevOps职位,但描述的工作职责跟传统的运维没有太多明显的变化,还是做发布和SA;有的团队把名字改成了DevOps,但是做的是运维开发的工作,要注意“运维开发”不是DevOps。DevOps是一个落实到团队里的文化理念和最佳实践,不只是运维团队做,也不只是开发团队做,而是大家一起做DevOps,甚至有可能单独设有有一些协调员去做发布、交付工作。所以,DevOps不只是一个团队的名称。

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

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

我在人人网的时候, DevOps的概念比较火,公司建了一个DevOps团队,后来在专家的指点下,我们把团队名称改成了PE团队。另外,DevOps并不是系统管理员加上自动化工具就够了,在部门里,SA做发布用了很多自动化的工具,但大家要知道,自动化只是一种手段和工具,要想好最终的目标解决的是怎样的问题。最后,DevOps也不是把root权限给了开发人员。开发的人员有root权限会引入很大的风险,DevOps需要控制这个风险。

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

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

DevOps技术目标DevOps的最终目标

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

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

DevOps的最终目标是建立一个流水线、准实时交互及时性的业务流程,快速把产品推上线,产生业务价值,最大化业务输出。做事一定要想公司的路线图是什么,公司要做什么样的事情。公司新发布一个产品,上线一个在社交网站上的新消息流功能,目标就应该是把这个功能推上线,服务更多的人,而不是简简单单的做一个工单的处理。目标不一样,结果也是不一样的。

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

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

从技术的角度或者是架构的角度来讲,DevOps需要快速部署的平台。这一点是大家都很认可的,很多现在DevOps培训都仅仅做技术上的快速部署平台,但是缺少对DevOps其他方面的培训。DevOps真正的价值是由业务的结果判断的。最大化输出业务,而不止是IT项目的范围或成果,就是对业务产生了多大的影响。

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

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

Facebook里有两个词说得特别多,一个是Vision(视野),另一个是Impact(影响力)。做事前想想这件事对公司是不是有正向的影响,影响力有多大?视野加上影响力很重要。举个例子,做一个架构的组件,可能短期内公司用不上,但是在明年也许会产生很大的效果,产生很大的改变,那就可以做。做完以后今年可能没有产生效果,但是明年可能对几十人、上百人的开发效率产生非常大的提升,这就是有意义的。所以要看最终的结果,而不只从一个项目的角度去考虑。

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

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

DevOps速度业务连续性

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

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

双峰挑战。系统基本上都可以分为这两类:是关注于快速上线的交互型系统,还是关注业务的连续性的记录型(SOR)系统。我们公司是做金融的,其中的交易系统就属于对业务连续性要求特别高的。有些产品则更关注于速度,比如web、app的开发,上线后如果有问题马上回退就好,对用户不会产生特别大的影响,这就是典型的交互型系统,这类系统也比较适合用DevOps。要区分系统是否适合DevOps,银行、证券的的核心系统要把控好,不够成熟就不要上DevOps。

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

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

DevOps风险安全

关于SRE理念1、SRE回顾

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

DevSecOps就是除了DevOps,还要注意安全。互联网公司对三点很关注,那就是速度、成本和质量。要快速的上线、快速的迭代,也要控制好成本。质量不能出问题,业务连续性不能断,如果经常丢数据,业务不能使用,公司的品牌会受到很大的影响。金融公司则更关注于安全,假如数据被窃取了,用户数据或交易纪录被篡改,是致命的。数据非常重要,所以DevOps里又加了一个DevSecOps 。

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

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

关注风险,但没有绝对的安全。DevOps的经典书籍《凤凰工程》里有一段情节,有个做审计的人总是特别郁闷,因为总觉得IT的人不按审计的要求去修复所有问题,会出非常大的问题。但是最终的结果是审计成功通过,因为公司里财务的人通过业务上的检查,解决了发现的安全问题,也就是说即使IT上存在一些问题,也可以通过业务的方式弥补,达到最终的安全。DevOps告诉我们,你要关注风险而不简单是安全,在避免风险的前提下,制度不应妨碍业务的发展和交互。另外,也要通过技术提升安全,简化流程,尽量实现自动化。设计流程很容易,很多公司里面都有特别多的工单,但是你要想你的工单是不是有作用?比如说是不是所有的项目的上线都需要安全的人审核,如果能自动判断没有风险的话,能否自动化流转?

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

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

DevSecOps和DevOps一样,也要加强人与人之间的沟通、协作,负责安全的人应该和开发、运维、测试人员一起防范风险。

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

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

浅谈SRE

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

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

谈谈SRE, SRE需要负责可用性、时延、性能、效率、变更管理、监控、应急响应和容量管理等相关的工作,包括工程研发、日常运维以及监控响应方向的工作。

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

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

深究PEPE起源

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

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

重点分享我正在做的PE是什么,先介绍一下PE的起源。大家比较认可的是从雅虎开始流行的,国内最大的团队就是阿里的PE团队,后来受阿里影响很多公司也设了PE职位。PE这个词有的叫产品运维工程师,有的叫业务运维工程师,也可以直接认为就是应用运维团队,简单来说就是负责业务或应用相关的一系列工程上的事务。

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

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

这是Facebook的招聘描述,PE既拥有软件也拥有系统方面知识的工程师,要保障Facebook 的服务平滑的运行,有足够的容量满足未来的规划。这也是刚才说的Facebook很强调两点:一个是视野,一个是影响力。技术人要有视野,能预见公司未来的业务发展,根据视野做设计。一方面要保证服务平滑运行,另一方面要满足未来的容量规划,以此设计基础组件,要有长久规划设计的能力。每个Facebook 产品,包括基础设施,都有PE的人。

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

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

听阿里毕玄老师说,阿里的PE团队打散到不同的BU业务单元里。大家要根据自身的情况考虑,Facebook 团队比较大,每个大团队都有两个PE的人跟进,他们有广阔的视野和经验,背景也比较好,从整个团队来看,既有新人也有老手,组成了多样化的团队。

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

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

除了写代码,PE也要会写文档。做运维的人一定不要抗拒写文档,不管在哪里,文档都很重要。好的文档能把事情描述清楚,给别人去看,传播给更多人,而不只是在自己的脑子里面。PE要做容量规划,像京东每年都有两次大促,618大促,双十一大促,PE要规划容量和性能能否够满足业务的发展。PE需要调试处理最困难的问题,所有运维都知道调试排查问题(Trouble Shooting),但是能做好的很难。很多公司做问题处理的时候,如果有乙方的支持,只要问题能解决,公司的人就不去想是问题的原因。

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

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

我们需要反思,再去自我提高,好的PE问题排查和总结范围的能力都很强,简单的问题也可以找到深层次的原因并做长期的提升改进。PE要加入到值班轮转里,在值班的时候处理问题。PE要做产品协调员,和工程师团队一同协作,这和SRE里相关的部分很像。

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

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

PE会和很多人打交道,这点对其他职业也是通用的。我很强调人与人之间的沟通协作,PE是一个协调员的角色,要和PM、产品经理、程序员、网工,或者SRE沟通,与各个组协调把事情做好。我招PE的时候,很注意软技能,如果软技能方面有问题,只想做技术,很多事情都很难处理,后面的风险会更大。对于个人,不管是运维还是其他职位,想更好的发展都应该提升软技能方面的能力,更多地与合作伙伴、同事共同协作,大家达成一致的目标,协作完成任务。

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

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

目标部分再说一下,管理者还要评估PE的绩效,保证业务正常运转,这也是管理者的一项重要工作。PE或应用运维工程师如何做发展计划?如果不转型,还是按PE方向发展,我觉得发展为架构师是很好的规划。

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

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

总结一下我对PE的定位。首先,PE应该是服务的第一响应者,有问题要马上处理。大家要有这个意识,有问题要能快速处理,这也要靠公司机制去保证,并不只是靠人。人不可能7*24小时处理问题,但是机制可以保证,包括轮班,一线二线的人分离任务,在保证核心的人不要太累的同时处理问题。性能分析师,利用有限资源承载更多的业务,京东每次大促前都要做全链路压测,做评估、扩容,先做性能分析,然后在进行容量规划。系统管理员是基本功,要懂操作系统,懂网络,也要能写Code,开发工具等等。开发工具并不要求是很大的平台,可以和专业开发人员一块去开发,解决问题就好。最后,产品工程协调员,加强人与人之间的沟通

直播质量指标

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

落地PE实践及心得如何结合组织架构设计技术架构

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

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

三个角色的定义都说完了,再说说如何结合组织架构设计技术架构,这里有很经典的康威定律原则——组织结构会影响技术架构,技术架构会影响到运维架构。康威定律很重要的一点是说,假如团队里有N个人,每个人都要跟N-1个人去沟通,团队越大沟通成本越高。

卡顿分析

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

如何设计结构降低沟通的成本?传统模式下很多公司都是职能型的团队,开发、运维、测试属于不同的职能团队,开发的人写好代码给运维的人上线就行了。在新的互联网公司中,除了传统的职能型团队以外,还有实施矩阵式管理,做单元化、BU化组织架构的,这样可以降低沟通协作的成本。

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

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

我之前在人人网带的团队有7、8个人,现在的团队比较大,有差不多20人。20人的团队怎么设计结构?我把业务线打散到两个不同的业务组里,这里也有一个2-pizza team的原则。假如两个pizza都喂不饱团队的时候,团队的沟通成本其实是很高的,管理也有难度。要把团队打散划分成更小的线,8人以内是比较合适的。

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

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

我也会设一些虚拟的小组,类似于矩阵式管理,有一些技术小组做大数据、分布式缓存,Docker、Nginx 等等,目的是什么?有点像Google SRE的50%原则,50%的时间做开发任务。但是我没有办法让他将50%的时间完全去写程序,因为有很多事情要去做,而且我们也有专门的开发团队,但我可以设一些技术的小组,分离业务和技术的事。每个人50%的时间去做跟技术相关的事情,这样他们自己也会觉得有意思一点,最终的目的不仅是做一个纯业务的运维,而是给PE们提升的空间。

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

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

SLM服务级别管理

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

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

下技术管理上的实践,即使是互联网公司,ITIL这样偏传统的管理方式也有很多可取的地方,我们现在也用得着,并不是抛弃掉所有传统的理念,要根据公司的需要,不管是ITIL还是SRE,还是其它方法都可以借鉴,以此设计你的组织结构。我会保留传统的东西,像SLM,在SRE里叫SLO。为什么叫SLO不叫SLA了?

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

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

因为SLA是服务协议,更多时候是甲方和乙方签协议。公司内部没有协议,而是设定一个目标,开发跟运维间达成一致,要有数据化的考量。SLA或SLO都不只是一个可用性的目标,还包括很多的方向,比如维护的时间是否可靠?包括性能、备份、问题解决的时间这些都是考量的指标,不只是数字。我们内部的SLA会分得很细,根据业务的类型,对不同业务的影响会有很细的评估。

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

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

变更管理

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

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

80%的故障都是变更引起。变更很频繁,互联网公司里面每天可能都几十次、上百次的变更,测试环境没有测试到业务的问题的可能性是很大的。变更管理的内容可以再看一下,比如CMDB,变更的时候还是要有基础库做记录的,有了基础库后面才能做很多事情。

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

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做多维度的分析,提供分析排障的东西。

琐事—50%时间去做开发或虚拟技术小组的事情,SRE说50%的时间做开发,但是我认为50%的时间不一定全做开发,开发的时候也可以做一些技术的事,只要是长远讲,对你的组、对公司有好的影响的事,我觉得就可以了,目的是一样的,多做自动化,促进大家提高能力。

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

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

自动化—减少重复性工作,减少手工操作带来的不确定性。很多公司做自动化的同时,导致风险也变多了,所以怎么样做正确的自动化?正确的自动化减少了重复性的工作,减少了错误,解放了人类,但是错误的自动化对应的只是把人类机械化了。以前手工做很多次的,现在变成一次就执行了,系统没有给你正确的反馈。这和DevOps说的一样,不仅能更快速迭代的发布,还要有反馈的信息,收到有反馈的异常信息以后能快速的回滚,这点很重要。

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

全链路修复和保障能力

很多的DevOps平台都只是做了自动化,但是风险是不是控制好了?系统能否有效反馈?发布失败的时候能不能停下来?要做好对应的信息反馈。错误的自动化对应的会给出错误的信息,导致决策失误,这是一定要注意的。比如金融证券行业,做了一定的自动化交易(量化分析),程序自动做投资、买卖股权、买卖股票,完全自动化。但是如果系统没有做好,就是灾难性的,风险还是很严重的。核心系统一定不要缺少人工干预,并不是完全自动化就不需要运维了,决策或者风险非常高的地方,还是需要人去做。

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

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

最后一点,理解构建的东西,设计任何一个系统一定要知道下面具体的实现。发布的时候告诉研发的人后面有什么风险,系统是怎么设计的,懂了原理之后才能规避更多的风险。

4、全链路监控

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

数据化运维

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

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

现在都说数据化运维,有点类似于运营,有些运维做得比较好的话还是可以往公司的运营方向转。很巧的是,运维和运营的英文的单词都是“operation”,都是偏运营的方向,目标也是一样的,做运维做得好的时候,应该有更多数据化的东西给公司做决策参考。尤其是监控跟线上处理相关的,对应的数据都是你的来源,这些来源都会做智能运维的数据采集,比如说网络监控,操作系统监控,DNS等服务监控,基础组件的监控。基础技术组件服务,像DB、缓存、消息等,架构的组件都需要做数据化的参考,没有这两部分数据的话,做应用级性能分析的时候就很难。

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

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

这些信息之间也会做一些联动,举个例子,比如某应用的接口访问慢了,到底是因为网络原因慢了,还是缓存慢了,还是DB慢了?要把这些信息做联动才能做更好的分析,如果做数据化运维就需要很多数据做分析。京东金融也做了分布式调用的跟踪,我们现在说的微服务,以前叫服务化,再往前是SOA,对应的都会涉及调用链的关系。一个请求下来可能后面有几十个、上百个应用,这时怎么发现是链条上的哪个请求变慢了?我们用的是自己开发的分布式调用跟踪系统,也可以使用日志监控,业务的解决方案,比如ELK、Splunk,日志易等。自己开发的系统能满足我们大规模高复杂度场景的需要,还能和我们的CMDB,统一告警中心等系统做深度的整合。

5、故障处理和质量闭环

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

下面两个是业务指标,比如,支付系统会有支付可用率的指标监控,也有对应每个银行分类的可用率,全局业务的监控大盘,这些都是业务方向的监控需求,方便进行快速的分析决策。所以,对业务连续性要求高的系统大多会设置一个监控中心或是作战指挥室,有很多监控的大屏,做数据化的运维,用数据做决策、分析。数据化运维今后的发展空间是很大的。

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

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

智能运维

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

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

采集大量的数据是基础,再发展的话,还会做事件汇总,打标签的数据积累。详细来讲,一方面做数据采集,一方面按事件分类。触发一次代码的变更上线,或者业务的机房间流量切换,或者一个网络的工单,都是不同的事件,什么样的事件导致了数据的波动,他们是有相关性的,要综合的分析找出根本问题。

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

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

再智能一点,像我们报警会做降级或者是升级,自动判断问题。报警问题对业务是否有影响?是不是重复报警?级别比较低,经常重复报又不需要人去处理的就降低级别。另外,智能预估和自动扩容,人工的规则向机器学习过渡,多打数据标签,做一些智能化的处理。智能运维是未来的方向,空间还是很大的。

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

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

END总结

6、质量指标SLI/SLO效果

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

从实践经验看,首先一定要明确公司团队的定位、发展方向,公司的使命、愿景和价值观是什么。让每个人都理解,才能产生比较好的团队作战能力,根据公司的情况去看组织结构,根据组织架构招到合适的人,设计系统、不断实践、持续迭代,分析、总结,长期规划。我们虽然做技术、管理,很多时候也要借鉴商业的模式,怎样更快速的做一个新的产业出来。

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

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

最后一点我说一下“带来变化”,不管在哪家公司,都应该尝试一些新的改变,而不是简单的做重复的事情。要有一些长远的规划,多做长期能带来更大影响的事情,多做推动个人,公司,社会进步的事情。

案例1:直播音视频质量

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

文章来自微信公众号:Charles杂谈

第一,建立了全链路的监控系统,实现了秒级发现流级别的卡顿情况,也提升了监控的覆盖率,同时是自动化、实时性、可观测的。第二,通过建立质量模型,运用卡顿率和稳定性可以随时评估主播、平台、线路的质量,可以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社群

编辑:计算机网络 本文来源:虎牙直播张观石【计算机网络】,虎牙直播的S

关键词: 亚洲城ca88