e-works数字化企业网  »  文章频道  »  基础信息化  »  运维管理

传统运维不迷茫,究竟如何转型SRE?

2018/2/14    来源:DBAplus社群    作者:张观石      
关键字:运维技术  SRE  
运维人员是非常勤奋、爱学习的,具有非常广泛的技术视野和技能池。但在技术生态中为何总是处于一种较为弱势的、从属的、被动的地位?
    运维人员是非常勤奋、爱学习的,具有非常广泛的技术视野和技能池。但在技术生态中为何总是处于一种较为弱势的、从属的、被动的地位?本文先和大家谈谈我个人对运维的三点思考。
 
传统运维不迷茫,究竟如何转型SRE?
 
    对运维的三个思考
 
    传统运维窘境
 
    我们运维一般是这样的:把软硬件资源按计划准备好,按需求安装起来,让业务快速上线,让服务器上进程和和业务正常,处理各种故障,响应各方的需求。我们经常陷在处理这些工作上,成为操作员、保姆、救火队员。
 
    我们运维也都很努力,也不想每次被动救火,希望能主动控制服务状态,体现我们的技术价值,做了很多有效的工作。
 
    运维人员是非常勤奋、爱学习的,具有非常广泛的技术视野和技能池。但在技术生态中好像总是处于一种较为弱势的、从属的、被动的地位。
 
    运维技术深度和价值
 
    我个人也是在不断思考和学习, 几年前也发现自身传统运维的局限所在。并尝试过深入业务,通过运维人员掌握更多业务知识,了解技术架构,更深度参与线上业务维护来提升价值。
 
    比如,我们深入掌握了 Nginx 的运维知识和优化技术,掌握了 MySQL 的优化技术,掌握了 PHP/Java 的技术。
 
    这确实能一定程度提升业务质量,不过靠的是个人的主动性和某方面技术的深入,没有提升为 SRE 这么高的一种方法论体系。
 
    可以说我们一直在实践中进行摸索, 而 SRE 帮我们梳理了方法,树立了标杆,指引了方向。
 
    DevOps 和 SRE 的关系
 
    DevOps 是一种运维研发协作,甚至是整个业务链路上的敏捷协作,是一种文化和运动,而 SRE 是 DevOps 的一种实践、一种方法论。
 
    SRE 对我们最大收益是提供了一种方法论体系,来指导我们运维工作,也提供了一些具体的实践来供我们参考。
 
    今天想简单跟大家分享下我们在运维上跟 SRE 比较类似的经验。
 
    虎牙直播运维现状与挑战
 
    直播平台的挑战
 
    YY 是秀场直播的开创者,而虎牙直播则是国内游戏直播的先行者,此外,虎牙直播是从 YY 里面分出来的一家公司,承袭了 YY 的部分技术基因。
 
    现在做直播,有很多 CDN 厂商可以选择,但我们在开始做直播时还没有这么多厂商,很多技术靠自己研究和实现,所以我们很早就有一套直播体系。
 
传统运维不迷茫,究竟如何转型SRE?
 
    大家看到这个直播技术的流程,首先是主播开播,这里有 N 种方式可以开播。
 
    然后有多种推流的方式,将其推到某一条线路上,可能是我们自己的线路,也可能是 CDN 的线路,而后 CDN 要转推到多家去,还要在整个网络里分发到 CDN 边缘,通过转码,转码到各种地区的运营商。
 
    最后观众通过各种用户端连接到这些边缘节点的音视频流,观众可能是并发百万级的。
 
    整个过程路径很长,需要在几秒之内完成,跟一般的 Web 类互联网业务是不同的,是我个人经历过的最复杂的互联网应用。
 
    技术复杂性和运维着力点
 
    对 YY 来说,在开始做直播的时候,还是有一定的技术开创性。但在这方面,我们运维的挑战比较大。看到下面主播到观众遍布的这张架构图:
 
传统运维不迷茫,究竟如何转型SRE?
 
    一方面,虎牙直播目前是异构多云的架构,从整个链路看,任何观众都可以看到任何线路上任何主播的情况,复杂度高。
 
    另一方面,相对来说,研发同学以及各个团队会比较关注自己环节上的事情。
 
    所以在我们引入了多 CDN 以后,不仅技术和管理复杂性大幅提高,而且视频流路径在这么复杂的场景下,必须深入音视频运维工作,这对运维质量和运维人员技能提出了更高的要求。
 
    因此,由于直播平台不同以往任何架构的特殊性,以及当时视频板块技术的有限性,促使我们必须尽快找到运维的着力点。
 
    后来,我们接轨了近年来一直倡导的 DevOps 和 SRE 解决了这一困局,接下来便分享虎牙直播在这方面上的一些实践经验。
 
    关于 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。

责任编辑:李欢
本文为授权转载文章,任何人未经原授权方同意,不得复制、转载、摘编等任何方式进行使用,e-works不承担由此而产生的任何法律责任! 如有异议请及时告之,以便进行及时处理。联系方式:editor@e-works.net.cn tel:027-87592219/20/21。
e-works
官方微信
掌上
信息化
编辑推荐
新闻推荐
博客推荐
视频推荐