注：因为评论功能尚未开通，所以欢迎大家公众号留言讨论，因为后面还会有个番外篇，专门有一部分用来回答问题，如果大家有什么疑问可以公众号留言，我会选择一些典型的问题和答复放在文章中，感谢大家支持！
上篇介绍了关于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是否可以很好的起到上面的作用，直接决定了系统的稳定，我想这也是为什么在各大公司对这个角色越来越重视的原因。分享个阿里技术保障部的文章，可能会更好理解一些，我就不啰嗦了。
推荐阅读，主要看前半部分就好了：《阿里技术保障部：阿里云的幕后英雄》https://lingyun.aliyun.com/4/viewhero.html
小结
通过两篇文章的分析，我们可以有以下几个结论：
Google定义的SRE的角色，我们可以通过团队组织的方式来完成，单兵作战能力达不到，就通过团队协作来达成，这也是基本除了Google之外的互联网公司所采取的一种运维模式。
SRE所涵盖的工作内容和职责，其实在国内外的互联网公司也都在做，比如自动化、持续集成和发布、监控等等，对于标准、规范和流程上，每个公司也都有自己的一套适合自己公司业务和技术特点的体系。比如阿里，其实整个SRE体系就是非常完善的，在我看来是绝对不逊于Google的。所以，这么来看，SRE貌似也没有这么神秘，但是要清楚的看到技术能力上的差距，仍然是我们努力的方向。
最后，两篇文章把我对SRE的理解做了一个分享，抛砖引玉，欢迎大家来讨论。本来还想写一写通过我的观察，国内外SRE或运维发展的趋势和对运维同学的一些发展建议，但是我想暂时先放一下，主要是想看看大家有没有自己的一些感受和感想，或者你认为发展趋势是怎么样的，我们应该做好哪些方面的准备等等。或者大家有什么问题，直接在我公众号后台留言，后面准备再来个番外篇吧。
本文分享自微信公众号 - 成哥的世界（forrest_thinking）。
如有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。
来源：oschina
链接：https://my.oschina.net/u/4596703/blog/4446846