我所理解的SRE、PE和应用运维（上）

SRE这个概念我个人印象中应该14年下半年左右听到的，当时只知道是Google对运维岗位定义，巨牛逼的一个岗位，在网上查到SRE是叫网站稳定工程师，只要是保障稳定为主，其他就没有更深的意识了。15年开始逐渐有更多在Google工作或接触过这个岗位的专家在介绍这个概念，大家有了更进一步的认识，但是很多的细节，大家仍然是不了解的。今年年初，Google SRE这本书的英文电子版引入到了国内，再后来9月份有了中文版译本，SRE在今年彻底火爆。

我今年年初拿到电子版之后，就把内容啃了一遍，懵懵懂懂，后来有幸跟部分海外从事SRE工作的工程师有了一些交流，然后再回来回顾了一遍内容，加上我本身对互联网运维的经历，对SRE有了更深的理解。整理了一下思路，把我的一些理解分享出来。

这个是第一篇，主要谈一下自己对Google SRE的理解，第二篇，打算写一下我了解到的大部分公司SRE的组织方式，对我们的启发是什么。再就是应用运维为什么对于技术团队来说如此重要，到底有哪些价值。

关于Google 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、良好的沟通协作能力、良好的规范标准制定意识，这些偏软性的东西又可能是很多技术神人所不擅长的。

国内外对于应用运维的定义

回到现实中来，是不是这种优秀的模式我们就学习不来了。答案是否定的，让我先来看看在硅谷和国内大型互联网企业又是怎么来运作应用运维这个岗位的呢，根据我了解到的一些信息（不一定精确），先大致介绍一下：

• 雅虎，作为互联网业界的鼻祖，技术也是互联网行业的翘楚，硅谷很多优秀的技术经验都是从源自雅虎，后面还会提到。在雅虎，有个运维的岗位叫PE（Product Engineer），早期能够走上这个岗位的工程师都是在开发团队承担业务架构师或资深SWE这样的角色，因为一个应用或业务上线后，对应用最熟悉的就是这批人，他们能够很好的跟产品人员协作起来，传递应用在线上运行的状况，同样，产品人员如果发现什么问题跟PE交流起来也是最顺畅的，交流完还可以直接改代码上线。这种模式运作下来，产品、开发、运维协作起来是最高效的，所以这种模式就一直延续下来。所以可以看到，PE的岗位职能和角色与SRE是基本相同的。
• 阿里，这里提到阿里的主要原因还是因为雅虎。2005年，阿里收购了雅虎中国以后，雅虎中国的工程师也被合并进来，这个团队对于阿里后续技术的促进和贡献是非常大的，我们所熟知的前淘宝搜索负责人鬼脚七，就属于雅虎中国。回到正题上来，熟悉阿里的同学都知道，阿里应用运维岗位也叫PE，这个岗位就是传承着雅虎的运维文化和模式而来，据说是现在阿里合伙人之一刘振飞09年当时在创建技术保障部时成立了PE的团队。但是，这支PE团队更多的就是偏应用运维了，绝大部分人是不具备SWE能力的，这一点也是受限于当时国内整个技术能力的水平，不可能一下招到这么多的原来雅虎的那种PE工程师，不过这个不是大问题，至于为什么，后面会分析到。
• Facebook，我们再回到硅谷的公司，熟悉FB的同学可能也不陌生，FB的应用运维岗位也叫PE，至于师承何处这个我没有找到第一手资料，不过应该大概差不多可能也是从雅虎继承而来，前段时间跟FB的一个工程师交流，了解下来，FB的PE做的事情跟上面阿里的模式差不多更偏应用运维一些。
• Linkedin，很有幸在12.2日的ArchSummit大会上我们的专题邀请到了Linkedin的一名SRE团队主管，并在会议期间做了很深入的关于SRE团队的组建和分工职责等方面的讨论。在Linkedin，SRE的职责跟前面讲到的阿里PE和FB PE的职责相似，以应用运维为主。关于这块我再下篇中会展开讲一下。

OK，先介绍这么多，后面可能会捎带介绍其它几个公司的运维情况。说到这里，我们可以大致得出以下两个结论：

• 第一，不仅在国内，即使在硅谷的公司里，类似Google定义的SRE的人才也是极度稀缺的，或者说，也许只有Google这样的平台上可能才能成长出这样牛逼的人才。（大家可以想一下，身边是否存在这样的牛人，我身边是有的，但是真的很少）。
• 第二，随着互联网业务的高速发展，到目前为止已经诞生出太多的大大小小的互联网公司，各个公司都越来越需要SRE或PE（应用运维）这样的角色。例如， 与FB的工程师沟通过程中了解下来，FB对于PE对开发的比例目标是 1:30，可能很多公司还达不到这个比例，大多可能还在1：100，甚至更低，当然FB现在也达不到这个比例，但是从这个趋势上，可以说明应用运维这个岗位的重要性越来越大，同时也越来越受到重视，对于做运维的小伙伴无疑是个很好的信号。至于为什么，下面会分析到。

以上是结论，我想我们应该还有个共同的疑问：

• 按照前面的介绍，感觉除了Google和之前的雅虎，其它公司的SRE这个角色貌似跟国内的应用运维角色差别不大，SWE的技能相对都是偏弱的，那这样的SRE是否还是Google定义的那个真正意义上的SRE呢？

我对SRE的理解

接下来，我说下我的理解和分析，首先上结论：

• SRE的能力模型，不仅仅是技术上的，还有产品设计、标准规范制定、事后复盘总结归纳、沟通协作等等这些非技术方面的能力要求
• 依靠团队的力量：单个人搞不定的事情，就发挥团队的力量，单个团队搞不定的事情，就跨团队协调资源搞定。所以，SRE岗位的要求很高，但是我们可以靠团队中具备不同能力的人协作，共同达成SRE的职责和目标。

SRE，直译过来是网站稳定性工程师，表面看是做稳定的，但是我觉得更好的一种理解方式是，以稳定为目的，围绕着稳定这个核心，负责可用性、时延、性能、效率、变更管理、监控、应急响应和容量管理等相关的工作。继续分解，这里就有主要两方面的事情要做，我们分为管理和技术来看：

• 管理体系上，涉及服务质量指标（SLI、SLA、SLO）、发布规则、变更规则、应急响应机制、On-Call事后复盘机制等一系列配套的管理规范和标准的制定等
• 技术体系上，以支持和实现上述标准和规范为目标，涉及自动化、发布、监控、问题定位、容量定位，最终以电子流程串联各个环节，做到事件的闭环

可以看到技术上的平台和系统是用来支撑管理手段的，其实Google的运维并没有单独去提自动化、发布、监控这些，而是通过稳定这个核心目标，把这些事情全部的串联在了一起，同时又得到了效率上的提升。我们挑几个主要的系统看看，比如：

• 自动化，是为了减少SRE人为的、频繁的、重复的线上操作，这样可以大大减少人为的失误造成的故障，同时效率提升，比如Google内部大名鼎鼎的Borg系统。
• 发布，Google内部也强调持续集成和发布，因为发布这个动作设计产品代码和配置的变更，迭代周期短，发布频繁，特别是在复杂的分布式系统中，非常容易因为一次发布的问题导致故障，所以发布工程的目标就是能够做到平稳快速的发布，发现问题能够快速回滚。（这种情况靠人是完全无法完成的）
• 监控，更不用说了，就是为了能够快速发现问题，快速定位问题，同时快速解决问题，稳定性保障的基石
• 问题定位，这块跟监控相关但是又有不同，我看到Google SRE这本书中并没有提到太多的Tracing的内容，更多的是讲监控和问题管理层面的跟踪机制。其实，关于问题定位，Google的Dapper大名鼎鼎，国内外很多的跟踪系统和思路都是参考了Dapper的理论，很强大。这块也是为了能够快速定位问题，保障稳定而产生的，国内大多在分享的关于全链路跟踪和分析、限流降级、开关&预案系统、强弱依赖等等都属于这个范畴，这块我认为更准确的定义应该算是分布式服务治理相关的内容。大家有兴趣可以看下Dapper的论文，http://research.google.com/pubs/pub36356.html
• 容量管理，能够提前判断系统容量，避免因为容量不足导致的系统故障
• 。。。。。。。。。。。。

通过以上的分析，这些系统大都是以稳定为导向和目标，同时带动了日常运维效率的大幅度提升，有了监控和全链路这样的问题发现和定位手段，也大大的提升了我们对于故障处理和问题定位的效率，容量管理，不仅仅可以保障容量充足，还能够最大程度保障资源分配的合理性，尽可能减少浪费，对于成本管控也大有好处。所以，围绕着稳定性这个核心目标，不仅达到了稳定的目的，还获得了高效的运维效率。Google SRE的牛逼之处我觉得有两个地方：

• SRE的理念通过稳定这个核心点讲整个运维体系要做的事情非常系统紧密的整合了起来，而不是一个个孤立的运维系统。所以，SRE是一个岗位，但更是一种运维理念。（关于雅虎PE的岗位的历史和发展我没能找到对应的资料，所以从这一点上看，在理念的宣导上Google是做的最出色的）
• Google具备超强的技术实力和超前的发展眼光，把在外界看来很苦逼的运维，做成了世界上最高端的技术工种之一，引领了运维的趋势，给业界提供了一种做运维的方法论。

也正是Google如此重视基础设施、架构和人才能力上的建设，才能让Google的业务能够如此高速的发展。我之前不止一次的听到很多从Google出来的工程师，再加入到另一家公司后，对Google基础设施之完善的赞叹，即使他们加入的是Twitter、FB等公司。不过经过这几年的发展和硅谷人才的流动，Twitter和FB在基础设施方面的发展也取得了惊人的进步，大家知道的Twitter的Mesos，FB的Area 404硬件实验室，并且开源了FB内部的部分硬件架构设计，这些都侧面反映了大公司对基础设施的建设。国内可以看到阿里和百度都有类似的动作。

OK，上篇就写到这里吧，相信对于SRE我们应该有一个共同的认识了。