我所理解的SRE、PE和应用运维(下)

注:因为评论功能尚未开通,所以欢迎大家公众号留言讨论,因为后面还会有个番外篇,专门有一部分用来回答问题,如果大家有什么疑问可以公众号留言,我会选择一些典型的问题和答复放在文章中,感谢大家支持!


上篇介绍了关于SRE、PE和应用运维的一些理解和业界部分公司的玩法,这一篇写一下应用运维在具体做的一些事情和组织方式,看看为什么这个岗位越来越受到重要,越来越受到重视,他的价值到底体现在哪里。然后分析下应用运维这个职业方向的发展趋势,希望对于当前正置身于这个行当的同学能有一些帮助和启发。

关于SRE的定位

首先抛个结论出来,SRE的目标不是Operation,而是Engineering,是一个是“通过软件工程的方式开发自动化系统来替代重复和手工操作”的岗位,为了保证达成这个目标,Google强制约定了50%的工作法则,SRE至少保证50%的时间是在做自动化开发的工作上,实际这个比例可能会更高,所以SRE运维的工作内容是低于50%的。书中相关的描述如下:

Common to all SREs is the belief in and aptitude for developing software systems to solve complex problems. 所有的SRE团队成员都必须非常愿意,也非常相信用软件工程方法可以解决复杂的运维问题。

这里我个人觉得更准确的理解应该是,Google压根就没把SRE定义为运维(Operation)的岗位,运维(Operation)这个岗位或工作内容更多的指的是原来传统运维模式下SA的职责描述。书中第一章就分析了从SA和SRE两个不同的视角来看待Google线上系统的区别,正是因为SA模式下遇到了很多无法解决的问题,才引入了SRE这样的软件工程岗位,而引入这个岗位的目标就是为了消除掉原来SA运维模式下的问题、矛盾和冲突。

也正是Google换了一个思路,从另外一个维度来解决运维的问题,才把运维做到了另一个境界。下面是文中的几个关于SRE的描述,大家可以一起理解下看看。

By design, it is crucial that SRE teams are focused on engineering. SRE模型成功的关键在于对工程的关注 SRE is what happens when you ask a software engineer to design an operations team. SRE就是让软件工程师来设计一个新型运维团队的结果

另外,还有一个很有意思的地方,就是整本书中提到Operation(运维)的地方其实并不多,而且大多以Operation load、Operation overload、Traditional/Manual/Toil/Repetitive operation works等词汇出现,理解一下,是不是跟上面的推断也很契合。

上面又花了些篇幅谈对SRE的理解,主要还是把SRE的定位分析清楚,然后再看对我们自己有什么启发。好了,下面进入分析环节。

SRE的团队组成

我们上篇提到过,Google的SRE必须具备很强的SWE能力,所以有很多的自动化和稳定性的东西就自己做了,但是这种人才很稀缺,对于一般的公司很难招到这样的人或者组成这样的一支团队,所以按照Google的模式基本是玩不转的,那应该怎么办呢?答案就是:依靠团队的力量:单个人搞不定的事情,我们可以靠团队中具备不同能力的人协作,共同达成SRE的职责和目标。这种方式实际也是大多数公司采用的一种方式,至少现在我了解下来的FB、Linkedin,国内的绝大多数公司也是这种团队模式。目前对于运维团队的基本组成模式:

  • 系统运维:SA、网络工程师和IDC工程师
  • 应用运维:国内大多叫应用运维,国外大多都定义为SRE或PE(国内也有,如阿里叫PE,滴滴、小米、美团等叫SRE)
  • 技术支持:主要是问题跟踪和一些流程组织及闭关跟踪的事情,如故障复盘、改进Action执行跟踪等,国内了解到的阿里有这样一个部门,其它很多公司可能QA会承担一部分这样的职责,国外叫NOC,这个部门虽然不直接解决问题,但是对于问题的推进,特别是对于线上运维规范性的监督作用非常大。
  • 工具&平台开发:自动化、监控、持续集成&发布和稳定性平台开发
  • 数据库DBA:DBA,有可能也会是独立团队
  • 运维安全:对线上网络、系统和应用安全负责,大多是独立团队,但是即使独立,跟运维团队都是紧密协作的

还是以阿里为例,阿里之前的技术保障部简称就叫SRE,是PE应用运维、工具开发、技术支持、DBA、安全、系统运维的组合起来的一个大的部门,非常典型的SRE团队作战的优秀实践。但是从今年开始,运作模式也发生了很大的变化,特别是应用运维PE这个岗位,后面会详细讲到。同时,后面我们再提到SRE就不是一个单独的岗位了,而是一个团队或者一种能力,那接下来重点说一下应用运维和工具平台开发的岗位。

SRE应用运维

目前在国内,我们的应用运维岗位还是多以线上的部署、发布、监控和问题的处理为主,其中有很多都还是以手工操作的方式为主,按照之前我们的分析,SRE的目标不是做这些事情的,或者说不应该是以这些事情为主才对,所以大家可以想一下我们的应用运维在实际日常工作中,是不是以这些事情为主?甚至把这些事情当做了常态?如果是这样,按照SRE的标准就不是合格的SRE。那正确的姿势应该怎么样的呢,说起来并不难,建议如下:

  • 意识转变,第一点一定是先转变意识,不能再陷于人工、重复和反锁的运维操作中,我们的目标是消除这种事情,尽可能的自动化
  • 产品分析能力,将日常人工、重复和繁琐的事情进行总结、分解和提炼,要能够将这些事情通过技术的手段做成脚本,提炼成需求,让工具平台的同学去开发,这里就要求要有产品需求分析和设计能力
  • 标准和规范制定能力,上篇我们介绍到,SRE是要能够制定服务质量指标(SLI、SLA、SLO)、应用运行标准、容量标准、发布规范、监控规范、On-Call规范、故障应急响应规范、事故复盘规范等等一系列的标准和规范。标准这部分,要求对线上实际业务和应用非常熟悉和了解才可以,这个只有应用运维最合适,换其他任何一个岗位都做不来,关于规范这块,特别是On-Call、复盘、应急响应这块技术支持可以更多的参与进来一起制定,但是根本上还是得应用运维发力才可以
  • 标准和规范执行能力,这个是上述两点的延续,标准规范定好了,产品需求提炼出来了,标准规范和需求功能固化到软件平台上了,应用运维的同学要能够把共同打造出来的产品强力推行下去, 所有的产品很应用都必须要能够按照这套体系来运作并且接入才可,比如必须接入发布系统、接入监控系统、出现故障必须按照既定的流程执行等等,不允许再有游离之外的应用和业务
  • 软性的能力,上面是专业能力的建议,软能力就是要求应用运维要注意锻炼和提升自己的沟通协作能力,因为很关键的一点,我们制定的标准和规范,是否是跟业务开发同学一起沟通制定的,开发同学是否可以接受,这样做会带来什么好处,不这样做会有什么问题,这些是我们要能够用嘴巴和文字表达出来的。再就是我们要将我们的需求转化成产品层面的需求,甚至是能设计出产品文档的,这就需要我们工具平台的同学能够很好的协作起来,最终,我们是否可以把我们的需求准确的描述和表达出来,工具平台的同学是否能够准确的理解我们的需求,决定着我们的工具平台是否可以推广起来,也决定着我们SRE的口碑如何。

关于上面这一部分,我在另外的文章中详细写过,大家有兴趣可以参考。(我发现公众号文章对超链接还有限制,所以麻烦大家在公众号历史文章列表看吧)

  • 论运维自动化(上):运维系统须具备五个维度,全面自动化应分步实现
  • 论运维自动化(下):先克服难点完成自动化,再连通业务实现技术运营
工具平台(运维开发)

这个角色,实际就是SRE中SWE的能力职责了,要能够准确的理解应用运维同学的需求,是否能够开发出满足实际运维场景的平台,直接依赖于工具平台同学的能力。还是有几个建议:

  • 产品设计和理解能力,这里建议工具平台的同学要多往一线应用运维同学这里靠一下,主动去了解需求和痛点,因为不理解应用运维是不可能做好运维产品的,甚至条件允许的情况最好能轮岗体验一下一线运维。
  • 产品整合能力,因为我们做了很多的工具、平台或产品,如果这些产品都是一个个孤立的部分,那我们的SRE的能力是很难发挥出来的,这里需要工具平台的同学具备根据场景来整合和设计产品的能力,让使用者能够很方便的使用我们的产品
  • 运维能力提升,从目前看很多的工具平台开发同学都是SWE背景,如果是一直从事运维开发的工作,可能很少有机会能接触到系统、网络和应用运维的一些技能锻炼,还有一些运维意识上的关联,比如操作规范性、问题响应应急等等,这里建议还是轮岗。提这一条的原因是,工具平台的同学通过这块能力的提升,实际是转向真正的Google标准SRE的很好的后备人选。
技术支持

这个岗位也是非常重要的一个岗位,在阿里有一个很牛的名字,叫全球运营指挥中心,简称GOC,负责日常和重大活动的技术支持、应急、指挥和调度,而指挥和调度的角色,最主要的就是应用运维和业务开发,规则和规范就是前面提到的制定的一系列的内容。限于我个人的了解有限,这里就不多介绍了。

SRE应用运维的价值

把上面说的总结下来,SRE应该要能够制定和执行各种稳定性的标准和规范,能够将人工和重复的工作提炼成需求,并把这些需求能够转化成产品设计文档,准确的传递到工具平台团队,确保各方理解一致,从而能够使得各种自动化的工具平台落地。

以上我觉得就是SRE应用运维的价值了,SRE是否可以很好的起到上面的作用,直接决定了系统的稳定,我想这也是为什么在各大公司对这个角色越来越重视的原因。分享个阿里技术保障部的文章,可能会更好理解一些,我就不啰嗦了。 推荐阅读,主要看前半部分就好了:《阿里技术保障部:阿里云的幕后英雄》https://lingyun.aliyun.com/4/viewhero.html

小结

通过两篇文章的分析,我们可以有以下几个结论:

  • Google定义的SRE的角色,我们可以通过团队组织的方式来完成,单兵作战能力达不到,就通过团队协作来达成,这也是基本除了Google之外的互联网公司所采取的一种运维模式。
  • SRE所涵盖的工作内容和职责,其实在国内外的互联网公司也都在做,比如自动化、持续集成和发布、监控等等,对于标准、规范和流程上,每个公司也都有自己的一套适合自己公司业务和技术特点的体系。比如阿里,其实整个SRE体系就是非常完善的,在我看来是绝对不逊于Google的。所以,这么来看,SRE貌似也没有这么神秘,但是要清楚的看到技术能力上的差距,仍然是我们努力的方向。

最后,两篇文章把我对SRE的理解做了一个分享,抛砖引玉,欢迎大家来讨论。本来还想写一写通过我的观察,国内外SRE或运维发展的趋势和对运维同学的一些发展建议,但是我想暂时先放一下,主要是想看看大家有没有自己的一些感受和感想,或者你认为发展趋势是怎么样的,我们应该做好哪些方面的准备等等。或者大家有什么问题,直接在我公众号后台留言,后面准备再来个番外篇吧。

本文分享自微信公众号 - Forrest随想录(forrest_thinking)

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2016-12-12

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏Ken的杂谈

【系统设置】CentOS 修改机器名

18030
来自专栏haifeiWu与他朋友们的专栏

复杂业务下向Mysql导入30万条数据代码优化的踩坑记录

从毕业到现在第一次接触到超过30万条数据导入MySQL的场景(有点low),就是在顺丰公司接入我司EMM产品时需要将AD中的员工数据导入MySQL中,因此楼主负...

29740
来自专栏FSociety

SQL中GROUP BY用法示例

GROUP BY我们可以先从字面上来理解,GROUP表示分组,BY后面写字段名,就表示根据哪个字段进行分组,如果有用Excel比较多的话,GROUP BY比较类...

5.2K20
来自专栏非著名程序员

「我真的没有改需求」

11910
来自专栏非著名程序员

这是对付产品经理的一副毒药,程序员慎入

程序员和产品经理的日常就像是一对天生的冤家,为了需求的实现,几乎天天在争吵。这不,就在昨天各大技术和产品群里一个程序员暴打产品经理的视频火了,被广泛传播。

12520
来自专栏前端桃园

知识体系解决迷茫的你

最近在星球里群里都有小伙伴说道自己对未来的路比较迷茫,一旦闲下来就不知道自己改干啥,今天我这篇文章就是让你觉得一天给你 25 个小时你都不够用,觉得睡觉都是浪费...

21640
来自专栏腾讯大讲堂的专栏

白底黑字or黑底白字,眼睛更喜欢哪一个?

12310
来自专栏微信公众号:小白课代表

不只是软件,在线也可以免费下载百度文库了。

不管是学生,还是职场员工,下载各种文档几乎是不可避免的,各种XXX.docx,XXX.pptx更是家常便饭,人们最常用的就是百度文库,豆丁文库,道客巴巴这些下载...

44630
来自专栏腾讯NEXT学位

今天我就说三句话

11620
来自专栏web前端教室

你可以从面试中学到什么?

讲一下我对面试的一些。。。“偏见”,哈哈,熟悉我的同学们一定要批判的读接下来的内容哈。

12200

扫码关注云+社区

领取腾讯云代金券

年度创作总结 领取年终奖励