我所理解的SRE、PE、DBA、SA运维
我所理解的SRE、PE、DBA、SA运维
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内部的部分硬件架构设计，这些都侧面反映了大公司对基础设施的建设。国内可以看到阿里和百度都有类似的动作。
上篇介绍了关于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）：数据中心、网络、服务器、操作系统工程师
- 应用运维（PE）：国内大多叫应用运维，国外大多都定义为SRE或PE（国内也有，如阿里叫PE，滴滴、小米、美团等叫SRE）
- 技术支持（QA）：主要是问题跟踪和一些流程组织及闭关跟踪的事情，如故障复盘、改进Action执行跟踪等，国内了解到的阿里有这样一个部门，其它很多公司可能QA会承担一部分这样的职责，国外叫NOC，这个部门虽然不直接解决问题，但是对于问题的推进，特别是对于线上运维规范性的监督作用非常大。
- 平台开发（SRE）：自动化、监控、持续集成&发布和稳定性平台开发
- 数据库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或运维发展的趋势和对运维同学的一些发展建议，但是我想暂时先放一下，主要是想看看大家有没有自己的一些感受和感想，或者你认为发展趋势是怎么样的，我们应该做好哪些方面的准备等等。或者大家有什么问题，直接在我公众号后台留言，后面准备再来个番外篇吧。
