写点什么

我所理解的 SRE、PE 和应用运维(上)

  • 2020-03-17
  • 本文字数:4514 字

    阅读完需:约 15 分钟

我所理解的SRE、PE和应用运维(上)

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的论文。

  • 容量管理,能够提前判断系统容量,避免因为容量不足导致的系统故障


通过以上的分析,这些系统大都是以稳定为导向和目标,同时带动了日常运维效率的大幅度提升,有了监控和全链路这样的问题发现和定位手段,也大大的提升了我们对于故障处理和问题定位的效率,容量管理,不仅仅可以保障容量充足,还能够最大程度保障资源分配的合理性,尽可能减少浪费,对于成本管控也大有好处。所以,围绕着稳定性这个核心目标,不仅达到了稳定的目的,还获得了高效的运维效率。Google SRE 的牛逼之处我觉得有两个地方:


  • SRE 的理念通过稳定这个核心点讲整个运维体系要做的事情非常系统紧密的整合了起来,而不是一个个孤立的运维系统。所以,SRE 是一个岗位,但更是一种运维理念。(关于雅虎 PE 的岗位的历史和发展我没能找到对应的资料,所以从这一点上看,在理念的宣导上 Google 是做的最出色的)

  • Google 具备超强的技术实力和超前的发展眼光,把在外界看来很苦逼的运维,做成了世界上最高端的技术工种之一,引领了运维的趋势,给业界提供了一种做运维的方法论。


也正是 Google 如此重视基础设施、架构和人才能力上的建设,才能让 Google 的业务能够如此高速的发展。我之前不止一次的听到很多从 Google 出来的工程师,再加入到另一家公司后,对 Google 基础设施之完善的赞叹,即使他们加入的是 Twitter、FB 等公司。不过经过这几年的发展和硅谷人才的流动,Twitter 和 FB 在基础设施方面的发展也取得了惊人的进步,大家知道的 Twitter 的 Mesos,FB 的 Area 404 硬件实验室,并且开源了 FB 内部的部分硬件架构设计,这些都侧面反映了大公司对基础设施的建设。国内可以看到阿里和百度都有类似的动作。


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


原文链接:https://mp.weixin.qq.com/s/D2bCidBP-yFLOq_5KTMlUw


2020-03-17 22:111872

评论

发布
暂无评论
发现更多内容

让程序员欲罢不能的职场工具合集

伤感汤姆布利柏

基于飞桨框架实现PCA的人脸识别算法

百度Geek说

人脸识别 百度飞桨

python Socket无限发送接收数据方式

我再BUG界嘎嘎乱杀

Python 编程 后端 socket 开发语言

如何使用 Higress 快速构建 AI 应用?

阿里巴巴云原生

阿里云 云原生 Higress

2025第二十四届杭州国际智能楼宇展览会

AIOTE智博会

智能楼宇展 智能楼宇展会 智能楼宇展览会

上线一天销售额超15亿!《黑神话:悟空》火爆全网的技术秘诀!

可信AI进展

人工智能

2024年最受欢迎的轻量级项目管理软件推荐

爱吃小舅的鱼

项目管理 轻量项目管理

成本效益分析:观测云投资的回报

可观测技术

成本优化

推三返一消费全返模式系统开发指南教程/步骤详细/功能逻辑/源码程序

V\TG【ch3nguang】

ReidsTemplate序列化器

李爽

5款在线PPT工具,一键生成精美的PPT幻灯片!

职场工具箱

效率工具 职场 PPT 办公软件 AI生成PPT

Python多进程日志以及分布式日志的实现方式

我再BUG界嘎嘎乱杀

Python 编程 多线程 日志 分布式日志

动态化-鸿蒙跨端方案介绍

京东科技开发者

一文了解电商大促系统的高可用保障思路-献给技术伙伴们

京东科技开发者

短剧开发丨短剧系统开发模式讲解丨短剧现成源码

V\TG【ch3nguang】

短剧系统开发

关于Arrays.asList返回List无法新增和删除?

EquatorCoco

数据结构 后端

七牛云 CDN 视频瘦身,为视频分发「减负增效」

七牛云

CDN CDN带宽

快手主站前端工程化探索:Gundam 脚手架在新春除夕项目中的实践与展望

快手技术

前段

创新驱动:观测云如何帮助企业在竞争中保持领先

可观测技术

数据分析

一对一语音视频聊天APP系统开发玩法设计/步骤指南/案例源码

V\TG【ch3nguang】

云手机如何保障TikTok多账号安全运营

Ogcloud

云手机 海外云手机 tiktok云手机 手机群控 tiktok矩阵

数据安全审计必备攻略:一文掌握6大核心审计要点(附下载)

极盾科技

IPQ5018 motherboard: QCN6102-QCN6122 Multi-band integration -DIY customization

wifi6-yiyi

wifi ipq5018 WIFI6E

AIGC应用实战营-毕业总结

王琨琨

微软发布 Phi-3.5 系列模型,涵盖端侧、多模态、MOE;字节 Seed-ASR:自动识别多语言丨 RTE 开发者日报

声网

Python开发中,SQLAlchemy 的同步操作和异步操作封装,以及常规CRUD的处理。

不在线第一只蜗牛

Python 数据库 oracle

未来展望:观测云技术的发展与企业业务的融合

可观测技术

业务监控

Java 流式编程的七个必学技巧

高端章鱼哥

解锁未来财富密码:AI自动化副业创收班——终身财富加速器

测吧(北京)科技有限公司

测试

为什么要用云手机进行海外社交营销

Ogcloud

云手机 海外云手机 云手机海外版 海外社媒营销

我所理解的SRE、PE和应用运维(上)_软件工程_成哥的世界_InfoQ精选文章