什么是SRE运维？和传统运维有什么区别？

China中间件 2020-06-30

12038

首先，SRE是指Site Reliability Engineer (网站可靠性工程师)。他是软件工程师和系统管理员的结合，一个SRE工程师基本上需要掌握很多知识：算法，数据结构，编程能力，网络编程，分布式系统，可扩展架构，故障排除，可靠性管理。

其次，SRE起源于国外大型互联网公司，如google,直接掌管着互联网公司的机器和服务，保证网站不宕机是他们的使命。

SRE基本是从软件研发工程师转型，有很强的编程算法能力，同时具备系统管理员的技能，熟悉网络架构等，是一个要求非常高的职业。

大部分人理解SRE等于传统运维工程师(OP)或者系统管理员(SA)，实则不然，这两类角色离一名合格的SRE还有太大的差距，完全无法匹配得上这个称号。

最后，其实干运维时间长了，基本都会知道，无论做什么运维，运维工程师最基本的职责都是负责服务的稳定性，连续性，可用性和可靠性，确保服务可以7*24H不间断地为用户提供服务。在此之上运维工程师的主要工作职责如下：

1、质量：保障并不断提升服务的可用性，确保用户数据安全，提升用户体验。

2、效率：用自动化的工具/平台提升软件在研发生命周期中的工程效率。

3、成本：通过技术手段优化服务架构、性能调优；通过资源优化组合降低系统成本、提升ROI。

那么SRE到底是怎么样一个角色呢？我认为，SRE，一般是高级开发工程师转到运维的，这样既有很强的开发能力，也有一定的系统运维的能力。其实很像是DEVOPS的升级版，DEVOP是牛人的话，SRE就是真正的大牛，是开发技能和运维技能结合的于一身的大牛。

以下是引述自一大牛（赵成）的总结：

关于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、网络工程师和IDC工程师
应用运维：国内大多叫应用运维，国外大多都定义为SRE或PE（国内也有，如阿里叫PE，滴滴、小米、美团等叫SRE）
技术支持：主要是问题跟踪和一些流程组织及闭关跟踪的事情，如故障复盘、改进Action执行跟踪等，国内了解到的阿里有这样一个部门，其它很多公司可能QA会承担一部分这样的职责，国外叫NOC，这个部门虽然不直接解决问题，但是对于问题的推进，特别是对于线上运维规范性的监督作用非常大。
工具&平台开发：自动化、监控、持续集成&发布和稳定性平台开发
数据库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应该要能够制定和执行各种稳定性的标准和规范，能够将人工和重复的工作提炼成需求，并把这些需求能够转化成产品设计文档，准确的传递到工具平台团队，确保各方理解一致，从而能够使得各种自动化的工具平台落地。

小结

Google定义的SRE的角色，我们可以通过团队组织的方式来完成，单兵作战能力达不到，就通过团队协作来达成，这也是基本除了Google之外的互联网公司所采取的一种运维模式。
SRE所涵盖的工作内容和职责，其实在国内外的互联网公司也都在做，比如自动化、持续集成和发布、监控等等，对于标准、规范和流程上，每个公司也都有自己的一套适合自己公司业务和技术特点的体系。比如阿里，其实整个SRE体系就是非常完善的，在我看来是绝对不逊于Google的。所以，这么来看，SRE貌似也没有这么神秘，但是要清楚的看到技术能力上的差距，仍然是我们努力的方向。

数据库

文章转载自China中间件，如果涉嫌侵权，请发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。