https://www.cnblogs.com/zhangxinglong/p/14756366.html
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内部的部分硬件架构设计，这些都侧面反映了大公司对基础设施的建设。国内可以看到阿里和百度都有类似的动作。
上篇介绍了关于SRE、PE和应用运维的一些理解和业界部分公司的玩法，这一篇写一下应用运维在具体做的一些事情和组织方式，看看为什么这个岗位越来越受到重要，越来越受到重视，他的价值到底体现在哪里。然后分析下应用运维这个职业方向的发展趋势，希望对于当前正置身于这个行当的同学能有一些帮助和启发。
首先抛个结论出来，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的定位分析清楚，然后再看对我们自己有什么启发。好了，下面进入分析环节。
我们上篇提到过，Google的SRE必须具备很强的SWE能力，所以有很多的自动化和稳定性的东西就自己做了，但是这种人才很稀缺，对于一般的公司很难招到这样的人或者组成这样的一支团队，所以按照Google的模式基本是玩不转的，那应该怎么办呢？答案就是：依靠团队的力量：单个人搞不定的事情，我们可以靠团队中具备不同能力的人协作，共同达成SRE的职责和目标。这种方式实际也是大多数公司采用的一种方式，至少现在我了解下来的FB、Linkedin，国内的绝大多数公司也是这种团队模式。目前对于运维团队的基本组成模式：
还是以阿里为例，阿里之前的技术保障部简称就叫SRE，是PE应用运维、工具开发、技术支持、DBA、安全、系统运维的组合起来的一个大的部门，非常典型的SRE团队作战的优秀实践。但是从今年开始，运作模式也发生了很大的变化，特别是应用运维PE这个岗位，后面会详细讲到。同时，后面我们再提到SRE就不是一个单独的岗位了，而是一个团队或者一种能力，那接下来重点说一下应用运维和工具平台开发的岗位。
目前在国内，我们的应用运维岗位还是多以线上的部署、发布、监控和问题的处理为主，其中有很多都还是以手工操作的方式为主，按照之前我们的分析，SRE的目标不是做这些事情的，或者说不应该是以这些事情为主才对，所以大家可以想一下我们的应用运维在实际日常工作中，是不是以这些事情为主？甚至把这些事情当做了常态？如果是这样，按照SRE的标准就不是合格的SRE。那正确的姿势应该怎么样的呢，说起来并不难，建议如下：
这个角色，实际就是SRE中SWE的能力职责了，要能够准确的理解应用运维同学的需求，是否能够开发出满足实际运维场景的平台，直接依赖于工具平台同学的能力。还是有几个建议：
这个岗位也是非常重要的一个岗位，在阿里有一个很牛的名字，叫全球运营指挥中心，简称GOC，负责日常和重大活动的技术支持、应急、指挥和调度，而指挥和调度的角色，最主要的就是应用运维和业务开发，规则和规范就是前面提到的制定的一系列的内容。限于我个人的了解有限，这里就不多介绍了。
把上面说的总结下来，SRE应该要能够制定和执行各种稳定性的标准和规范，能够将人工和重复的工作提炼成需求，并把这些需求能够转化成产品设计文档，准确的传递到工具平台团队，确保各方理解一致，从而能够使得各种自动化的工具平台落地。
以上我觉得就是SRE应用运维的价值了，SRE是否可以很好的起到上面的作用，直接决定了系统的稳定，我想这也是为什么在各大公司对这个角色越来越重视的原因。分享个阿里技术保障部的文章，可能会更好理解一些，我就不啰嗦了。 推荐阅读，主要看前半部分就好了：《阿里技术保障部：阿里云的幕后英雄》https://lingyun.aliyun.com/4/viewhero.html
通过两篇文章的分析，我们可以有以下几个结论：
最后，两篇文章把我对SRE的理解做了一个分享，抛砖引玉，欢迎大家来讨论。本来还想写一写通过我的观察，国内外SRE或运维发展的趋势和对运维同学的一些发展建议，但是我想暂时先放一下，主要是想看看大家有没有自己的一些感受和感想，或者你认为发展趋势是怎么样的，我们应该做好哪些方面的准备等等。或者大家有什么问题，直接在我公众号后台留言，后面准备再来个番外篇吧。