Site Reliability Engineering
@ wgjak47 | 星期二,一月 19 日,2021 年 | 5 分钟阅读 | 更新于 星期二,一月 19 日,2021 年

Google SRE读后感

我很少写读后感,但是去年断断续续读完了google sre之后,总感觉要写一下。先说我的第一感觉:羡慕,相当羡慕

SRE到底是指的什么

SRE这个概念被Google分享给业界之后,确实挂起了一股旋风,影响深远。有的公司根据Google的理念,结合自己的实际,产生了自己的经验,有的嘛,给传统的运维工程师更换了一个头衔,该干啥干啥。SRE是翻译过来是网站可靠性工程师,但是靠什么手段来保障网站的可靠性,我认为是区分SRE和普通运维的区别之一。SRE到底是什么呢,给我个人的感觉来看,SRE更像是将各种运维工作流作为SASS提供给developer。根据书中的描述,SRE有很多职责:维护监控系统、进行容量规划、负载均衡、线上救火、上线新服务等等。但是这些工作很多时候并不是某个SRE亲自实施,而是SRE把工作标准化,流程化,通过一个sass服务提供给用户的。

一个例子:Auxon

我之前有幸参与过一个管理服务器交付流程的系统,包含采购和备机池功能,SRE的工作流主要分为一下几种:

  • 项目上线前采购机器

  • 项目快速增长,从备机池采购机器

  • 项目增长乏力,从线上下线机器到备机池节约成本

这个项目上线后,极大的加快了服务器的交付流程。但是相比于Google的Auxon,我发现我太缺乏想象力。 我们的流程都是由业务的SRE提具体的硬件需求,多少台机器,什么型号的CPU,带不带GPU等等,但是google的Auxon不同,它要求业务SRE/开发者提供更加抽象的需求:某服务需要在某写地区满足将要到来的业务增长,并实现某种程度的冗余度。 Auxon会根据服务的依赖关系(使用了google那些基础资源,是否需要对基础资源扩容?),服务本身的监控数据(以往线上的监控数据和新版本的压力测试数据)以及服务的优先级(受限于成本,偶尔还是会有牺牲)这三个方面预估出需要的服务器资源。这里带来的好处十分明显:完全交给业务SRE预估资源,会受限于SRE自身对项目的了解程度和SRE自己的经验。而通过Auxon,极大的提升了预测结果的稳定性,不会因为某个新接手某项目的SRE因为经验不足,导致预估不足,进而影响业务增长,同时也将SRE从各种excel报表统计工作中解放出来,可以投入精力到其它方面。

SRE的50%时间

google SRE书中提到了另一个有意思的东西:google SRE会至少留出50%的时间用于平台开发工作,SRE内部似乎不存在专门的全职开发者,他们内部平台的开发这往往也是这些平台的使用者。这样从某种程度上省去了SRE和developer的沟通成本。google的书中,SRE的招聘要求往往看起来知识要求更广,除了对操作系统和各种基础设施的维护技能和知识,也要求一定的软件开发技能。不知道随着软件开发越来月负载,google是否还能坚持这一原则,或者把某些大型设施交付给基础架构团队?

我个人的经验,开发和运维分离的缺点

不过就我的职业经历而言,google的这套做法确实有一定的好处。我本人在我的第一家公司先是干了两年的SRE,负责一线业务的可靠性,而后一半是兴趣,一般是处于对原有的运维设施(cmdb)不满,内部转岗到了开发团队。一开始我两年的sre运维经验确实起到了积极的作用。但是随着时间的流逝,我脱离了一线运维之后,缺少有效的手段去跟踪业务的变化,于是我也接到不少抱怨。之后处于职业规划原因来到了一家新的公司,继续从事相关的开发工作,结果昨天开会,用户也反映说目前的平台使用不方便,流程不顺畅。这个其实就是用户和开发这常见的问题了,需求分析并不一定准确,而且中间耗费的沟通成本很高。但是随着互联网行业的如日中天,各种技术也越来越复杂,很难想想一个SDN专家或者一个linux内核专家有足够的经历去学习react + gin从而进行相应的管理平台开发。

一个反向实践的例子

这是一个非常大的问题,风控、大盘都有责任,本以为会让每个系统都接风控、全盘核查 API、重构代码等,从技术角度来解决类似问题,但拼多多的操作实在让我惊呆了。

过年后,风控组开始7*24小时值班,每个技术岗必须值班,早班7-19点,晚班19-7点。虽然说不怎么合理,但也算是个临时的办法吧。

数日后,技术全员开始7*24小时值班,多强调几遍,技术全员!技术全员!技术全员!

这段内容是在某厂的员工自述,我写这篇文章的不久前,该厂残酷的工作环境成了社会的热点问题。我看到这篇自述的时候,正好也收尾google SRE这本书。看到上面的描述,不禁感叹,Google SRE整本的实践一直是在通过开发各种服务,优化流程,总结经验,提升单位人员的产出,以应对日益复杂的线上环境。某厂反其道行之,不采取技术手段应对(不确定,也许做了,原文没提),不从流程上避免问题的发生,反而寄希望于员工的本分和奉献,靠无脑堆人力,不但可能会再次发生,而且会促使优秀员工离职。毕竟比起更明智的,试图提升你的工作体验来提升总产出的公司,这种不断用无聊的琐事来PUA你的屑公司有啥留的必要呢?

SRE
保存为图片