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

上篇介绍了关于 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、网络工程师和 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 应该要能够制定和执行各种稳定性的标准和规范，能够将人工和重复的工作提炼成需求，并把这些需求能够转化成产品设计文档，准确的传递到工具平台团队，确保各方理解一致，从而能够使得各种自动化的工具平台落地。

以上我觉得就是 SRE 应用运维的价值了，SRE 是否可以很好的起到上面的作用，直接决定了系统的稳定，我想这也是为什么在各大公司对这个角色越来越重视的原因。分享个阿里技术保障部的文章，可能会更好理解一些，我就不啰嗦了。

推荐阅读，主要看前半部分就好了：《阿里技术保障部：阿里云的幕后英雄》

小结

通过两篇文章的分析，我们可以有以下几个结论：

• Google 定义的 SRE 的角色，我们可以通过团队组织的方式来完成，单兵作战能力达不到，就通过团队协作来达成，这也是基本除了 Google 之外的互联网公司所采取的一种运维模式。

• SRE 所涵盖的工作内容和职责，其实在国内外的互联网公司也都在做，比如自动化、持续集成和发布、监控等等，对于标准、规范和流程上，每个公司也都有自己的一套适合自己公司业务和技术特点的体系。比如阿里，其实整个 SRE 体系就是非常完善的，在我看来是绝对不逊于 Google 的。所以，这么来看，SRE 貌似也没有这么神秘，但是要清楚的看到技术能力上的差距，仍然是我们努力的方向。

最后，两篇文章把我对 SRE 的理解做了一个分享，抛砖引玉，欢迎大家来讨论。本来还想写一写通过我的观察，国内外 SRE 或运维发展的趋势和对运维同学的一些发展建议，但是我想暂时先放一下，主要是想看看大家有没有自己的一些感受和感想，或者你认为发展趋势是怎么样的，我们应该做好哪些方面的准备等等。或者大家有什么问题，直接在我公众号后台留言，后面准备再来个番外篇吧。

本文转载自成哥的世界公众号。

原文链接：https://mp.weixin.qq.com/s/H3_ajw4AeXSnnAyy7ZxbCA