SRE这个概念我个人印象中应该14年下半年左右听到的,当时只知道是Google对运维岗位定义,巨牛逼的一个岗位,在网上查到SRE是叫网站稳定工程师,只要是保障稳定为主,其他就没有更深的意识了。15年开始逐渐有更多在Google工作或接触过这个岗位的专家在介绍这个概念,大家有了更进一步的认识,但是很多的细节,大家仍然是不了解的。今年年初,Google SRE这本书的英文电子版引入到了国内,再后来9月份有了中文版译本,SRE在今年彻底火爆。
我今年年初拿到电子版之后,就把内容啃了一遍,懵懵懂懂,后来有幸跟部分海外从事SRE工作的工程师有了一些交流,然后再回来回顾了一遍内容,加上我本身对互联网运维的经历,对SRE有了更深的理解。整理了一下思路,把我的一些理解分享出来。
这个是第一篇,主要谈一下自己对Google SRE的理解,第二篇,打算写一下我了解到的大部分公司SRE的组织方式,对我们的启发是什么。再就是应用运维为什么对于技术团队来说如此重要,到底有哪些价值。
对于SRE,书中没有直接的定义,而是给了一个职责描述,我觉也可以很好的来理解这个概念了。
In general, an SRE team is responsible for the availability, latency, performance, efficiency, change management, monitoring, emergency response, and capacity planning of their service(s). SRE需要负责可用性、时延、性能、效率、变更管理、监控、应急响应和容量管理等相关的工作。(这里先不做过多的解读,后面详细描述。)
接下来,我们再看下对于SRE的岗位,Google的招聘标准:
50–60% are Google Software Engineers, or more precisely, people who have been hired via the standard procedure for Google Software Engineers. The other 40–50% are candidates who were very close to the Google Software Engineering qualifications (i.e., 85–99% of the skill set required), and who in addition had a set of technical skills that is useful to SRE but is rare for most software engineers. By far, UNIX system internals and networking (Layer 1 to Layer 3) expertise are the two most common types of alternate technical skills we seek. Google SRE 人力技能模型大致分为两类,50-60%为SWE,也就是软件工程师,另外的40-50%除了软件开发技能之外,还要至少对Unix内核和底层网络(1-3层)非常精通才可以。从这里也可以大致推断出,Google SRE的技能要求是非常高的,SWE只是基础条件。从技能模型上,按照Google的标准,原来传统的SA或NE这样运维角色根本无法胜任Google SRE的岗位,势必要进行非常艰难的转型。
这样看SRE的门槛实在是太高了,别说是传统的运维,就算是优秀的SWE可能也很被Google选中。所以按照这种模式来组建SRE或者向SRE借鉴什么经验的话,我们基本是玩不转的,因为具备这种技术能力的人太少,实在是太少,而且具备了技术能力,还需要有一定的产品sense、良好的沟通协作能力、良好的规范标准制定意识,这些偏软性的东西又可能是很多技术神人所不擅长的。
回到现实中来,是不是这种优秀的模式我们就学习不来了。答案是否定的,让我先来看看在硅谷和国内大型互联网企业又是怎么来运作应用运维这个岗位的呢,根据我了解到的一些信息(不一定精确),先大致介绍一下:
OK,先介绍这么多,后面可能会捎带介绍其它几个公司的运维情况。说到这里,我们可以大致得出以下两个结论:
以上是结论,我想我们应该还有个共同的疑问:
接下来,我说下我的理解和分析,首先上结论:
SRE,直译过来是网站稳定性工程师,表面看是做稳定的,但是我觉得更好的一种理解方式是,以稳定为目的,围绕着稳定这个核心,负责可用性、时延、性能、效率、变更管理、监控、应急响应和容量管理等相关的工作。继续分解,这里就有主要两方面的事情要做,我们分为管理和技术来看:
可以看到技术上的平台和系统是用来支撑管理手段的,其实Google的运维并没有单独去提自动化、发布、监控这些,而是通过稳定这个核心目标,把这些事情全部的串联在了一起,同时又得到了效率上的提升。我们挑几个主要的系统看看,比如:
通过以上的分析,这些系统大都是以稳定为导向和目标,同时带动了日常运维效率的大幅度提升,有了监控和全链路这样的问题发现和定位手段,也大大的提升了我们对于故障处理和问题定位的效率,容量管理,不仅仅可以保障容量充足,还能够最大程度保障资源分配的合理性,尽可能减少浪费,对于成本管控也大有好处。所以,围绕着稳定性这个核心目标,不仅达到了稳定的目的,还获得了高效的运维效率。Google SRE的牛逼之处我觉得有两个地方:
也正是Google如此重视基础设施、架构和人才能力上的建设,才能让Google的业务能够如此高速的发展。我之前不止一次的听到很多从Google出来的工程师,再加入到另一家公司后,对Google基础设施之完善的赞叹,即使他们加入的是Twitter、FB等公司。不过经过这几年的发展和硅谷人才的流动,Twitter和FB在基础设施方面的发展也取得了惊人的进步,大家知道的Twitter的Mesos,FB的Area 404硬件实验室,并且开源了FB内部的部分硬件架构设计,这些都侧面反映了大公司对基础设施的建设。国内可以看到阿里和百度都有类似的动作。
OK,上篇就写到这里吧,相信对于SRE我们应该有一个共同的认识了。