我们离Google SRE还有多远?

devopsec 等级 371 0 0

经过几年的挣扎和讨论(确切说应该是3年),老板在钉钉群以通告的方式正式告别伴随我们多年的职业Title --- PE,改名为SRE。(后续以A SRE区别Google SRE)

我们离Google SRE还有多远?

BigDataSRE

暂且不提名称变化背后的含义,对于新的称谓的意义很明显,SRE源于Google“网站可靠性工程师”的缩写,这个职位在Google内部有着“崇高”的地位,他们参与产品的设计(高扩展性、高可靠性),他们决定产品是否可以上线,他们研发面向海量任务、服务器、其他人员的管理系统、基础服务、规划系统等等。一时之间,SRE就是“高逼格”职业的代名词,更让人惊喜的是,这些工作都是运维的范畴。多年来成为苦逼代名词的运维岗喜极而泣!原本压抑在内心的信条 --- “运维是最牛逼的职业” 终于得到正名。

谁都不是傻子,很快SRE带来全新的、革命性的运维方式表面上让运维这个行业变得光明起来,可背后涌动的“暗流”却是我内心反复锤问 --- “运维工程师可以转型成SRE吗?”,不要忘了,SRE的出生是研发工程师。

“我们常说要转型,要做DevOps,要做SRE。可几年来,你才发现,这只不过是一个骗局,真正需要转型的是Dev,他们把Ops的活干了,而Ops只能另谋出路,DevOps对Ops来说就是一个笑话。”

虽然我不完全同意我同事的这番言论,但至少他把我们心里不愿承认的,不愿回答的问题给出了他的答案。

作为一个运维老兵,也希望可以找到自己问题的答案,好在一书的上市,全面且细致的介绍了SRE工作,让我可以近距离的了解和思考未来。

我们离Google SRE还有多远?

 一、土壤:基础设施 

1.1 硬件故障

2010年,记得刚加入A云的我,每周耗费一个工作日例行到机房处理各种硬件故障,那时候我们还只有一个数据中心,运行的服务器不过寥寥几千台,那时的我心里有一个疑问:“以后怎么办?”,为此后续的一年,我从事两项相关的工作:

  1. 把维修自动化,主要是磁盘和内存的维修自动化,当厂商把损坏的硬件替换到服务器上之后,后面的维修动作就是一键触发,自动修复并上线。
  2. 故障预判,其实说预判有些牵强,大部分的故障我们无法做到预判,多数情况是在小时级别后发现硬件故障。

这能在非线性的物理服务器增长中,让同事从繁琐的维修工作中解脱出来,但事实上,2部分的工作带来很多的质疑:

“为什么机器/硬盘Hang住了,你的检测程序却无动于衷?”

质疑多了不同的团队自己就要抡开膀子自己干,造成了一些不必要的PK,这些PK渐渐的让这些相关团队认识到硬件是不可靠的,而不是天真的认为“一切硬件故障可以被甄别,并可以快速隔离”。重复造了轮子,明白了一个道理。

可我并没有在一书中找到SRE是否经历这样的阶段,因为一书中提到和硬件相关内容甚少,不过在相关资料中,能找到类似的经历。

文章的作者之一,Jimmy Clidaras,他从04年开始从事Google Datacenter Engineering的工作,是第一个Senior Director of Google’s Platforms Infrastructure Engineering Team。

文章提到了非常有趣观点 --- 为了提到维修的效率,以下两项工作非常关键:

  1. "每天打扫一次"数据中心里需要维修的硬件。(而非时刻都在)
  2. 需要一份精确的硬件损坏和分析报告,报告来自 Google System Health

最后,他同样提到应对的观点:(N+?理论,该论点也反复在SRE一书中提到)

TOLERATING FAULTS, NOT HIDING THEM.

我们离Google SRE还有多远?

Google System Health

我可以得出这样的结论,Google的基础设施团队,他们做了大量的工作(包括科研性的工作),这一切SRE团队并非参与者,而是“维护者”,甚至是“享用者”。(理想情况下,他们不需要再关心硬件故障或者之类,但我相信现实情况下,他们对硬件故障也耳熟能详了。)

幸运的是(还是不幸?:)),硬件故障等问题经验至今仍然是A云SRE值得“分享”的一大类目。

** A SRE 1:0 G SRE **

1.2 硬件选型

Google的信条是:

并不会用专门的物理服务器运行专门的软件服务器

所以,G SRE不会碰到硬件选型的烦恼。所以他们不会碰到如以下的对话:

: "混合存储是什么机型?啊?为什么是X块SSD硬盘呢?我的业务场景需要Y块!"
:"B、C等其他业务都统一了,为了节省采购成本,请做应用的优化来适配这一款混合存储机型。"

A SRE他们有足够的话语权。这并不是说他们可以自主研发某一款机型,他们的背后还有基础系统研发团队,通常基础研发团队会拿出多款搭配的试验机型供SRE来决策。一方面A SRE在这些机型之上“折中”出四不象来,看起来让每个业务都不饿,但也都喂不饱。另一方面,A SRE开始游说业务研发的Leader们开始做应用改造和适配,否则就会面临到货周期、财务等一系列的挑战。

因为没有一个统一的资源调度系统(说起来很轻松),业务还是天然的区分了几种不同类型的物理服务器:

| 机型 | 业务场景
|--------|
| A | CPU、MEM密集型、少量存储
| B | CPU密集型、大量存储
| C | CPU密集型、磁盘响应延迟低

每年A SRE(包括基础系统、网络团队)因此需要做物理服务器在数据中心之间繁重的搬迁工作。

同时,针对机型的定制化改造也变得臃肿不堪,为了对机型做某些妥协的业务通过RAID,软RAID的方式来最小化他们应用的改造成本,而这些行为都被记录在A SRE提供的“应用模板”之中,它是系统装机之后必须经过的步骤,以确保机型被正确的配置了。

机型规划、有效缩减是A SRE必备的课题,由于缺乏长期看得见的举措,A SRE用短期“自动化”的手段补位,相信这也是A SRE值得分享的心路历程。

** A SRE 2:0 G SRE **

1.3 基础软件系统

1.3.1 Borg

Borg并不是SRE团队研发的产品,无论是资料还是John Wilkes 15年的分享(其实我早知道:))。可为什么每次提起Brog,就会让人联想到G SRE? 就像每次提及双11,就会让人联想到阿里巴巴技术保障部。我觉得这种错觉是相似的 --- 当你既是这款产品的使用者,又是这款产品的维护者,那你最适合做这款产品的代言人。

Borg让G SRE进化,G SRE让Borg进化。看看书中G SRE进化的例子吧

最初的自动化包括简单的Python脚本,执行如下的操作。

  • 服务管理:保障服务运行(例如,在段错误后重新启动) --- borg
  • 跟踪 那些服务应该运行在那些机器上。 --- Borg
  • 日志消息解析:SSH进入每一台机器,用正则表达式过滤日志。 --- gRPC。

我做了标注部分,书中是这样解释的。

“最初的自动化努力给我们争取了足够的时间,把集群管理转化为自治系统,而不是自动化系统。”
“机器的损坏和生命周期的管理已经不需要任何操作了。成千上万的机器加入系统,或者出现问题,被修复,这一切都不需要SRE的任何操作。”

很有意思,G SRE并没有觉得自己曾经的工作被替代(更别提被“别人”拯救)我想唯一的可能是G SRE有极大的参与感和主导权。

A SRE在地球的另一端,仍用着“最初的自动化脚本”执行着去完成那些操作。宣称不久将“替代”A SRE这些脚本的DevOps团队,从1.0演进到2.0再到现在3.0,多年来风风雨雨,你来我往,既没有兑现当年的承诺,也没有留下“战友”般的友谊。干活累的时候,相互喷一嘴解解乏。

** A SRE 2:1 G SRE **

1.3.2 BorgMon

** A SRE 2:2 G SRE **

1.3.3 Jupiter&BwE

Google Jupiter和BwE(带宽控制器),实现了一个巨大的可供管理的虚拟网络,在一个数据中心里,几百台自研的交换机以Clos方式连接为一体,拥有几W个虚拟端口,提供1.3Pb/s交叉带宽。

网络也并不由A SRE直接维护,但A SRE在数据中心网络问题的排查中往往会起到决定性的作用,而相比较G SRE的BwE,A SRE更有办法能够找那个“坏小子”应用,人肉充当带宽控制器的角色,当然前提是时间允许的情况下。

** A SRE 2:3 G SRE **

1.3.4 存储系统

我们离Google SRE还有多远?

D Service

A云的存储系统和G司类似,除了D服务。A云并没有D服务,底层磁盘是直接由分布式文件系统盘古直接管理,在盘古之上也衍生出很多数据库服务,如MaxCompute、OTS、OSS等。

或许没有D服务,盘古仅能按照集群来管理不同类型的磁盘,还无法做到数据中心级别。

** A SRE 2.5:4 G SRE **

1.3.5 分布式锁服务

和存储类似,相比较可以提供多个数据中心服务的Chubby,A云的分布式锁服务仅能按照集群级别管理。

** A SRE 3:5 G SRE **

1.3.6 GSLB

** A SRE 3:6 G SRE **

1.3.7 结束

我相信G SRE的成功之一源于G基础软件服务成功,正如蒸汽火车和磁悬浮列车最高时速的差距并不在于“司机”的操作技巧。

我们离Google SRE还有多远?

 二、能力:SRE研发的产品 

本节只能依据书中明确提到由SRE团队研发产品来横向的比较。书中提到大部分Google内部幕后的软件工程实践都是来自SRE部门,而此类现象在A云并不多见,相反,在A云多数源于SRE部门的idea,而往往实践落到了研发部门,我们称之为“收编”。

2.1 Auxon

容量规划是两个SRE都要直面的问题,而且两者都意识到了传统容量规划的方法带来的巨大开销和不确定性。

G SRE和技术项目经理研发了Auxon,一款基于“意图”的容量规划工具。A SRE虽然表现上已经告别了表格的方式,但容量规划的系统是财务主导,由研发团队支撑,和SRE并没有太大的关系。而A SRE更多的专注在研发如何“高效”的提供让人信服的业务数据和趋势分析的平台。

从书上可以了解到,G司拥有不止一套容量规划的模型和工具,用于满足数据样本和规划模型之间的差异化,G SRE也意识到Auxon也无法满足所有项目。但书中没有提到的是大型分布式系统的容量规划,这背后不是简单一个或几个技术指标的分析与运算,容量规划背后那些KPI的目标,不同部门相互交织,视角和理解数据的方式完全不同,A SRE要面临的挑战或许要大的多。

** A SRE 0:1 G SRE **

2.2 Layer-3 Load Balancer

对于这款产品,书中提及的篇幅不多,我翻阅了一下参考资料<Maglev: A Fast and Reliable Software Network Load Balancer>,文章的作者大多数来是Google的资深软件研发工程师。

G SRE源自对网站的可靠性维护,自然的对负载均衡器有非常深的理解,从19、20章的描述可以感受到LB是那种根植于SRE技能条里必备技能。根据我个人的以往工作经历,曾经几乎一整年的工作就是和商业负载均衡器打交道,反而到了A云接触的少了。

** A SRE 0:2 G SRE **

2.3 Sisyphus

我们离Google SRE还有多远?

Tesla

通用的自动化发布框架,和G SRE类似的,A SRE团队已经实现了支持自动化发布的复杂部署、升级流程,这个平台叫Tesla。同时,它也具备负责记录每个步骤执行过程和异常通知,提供Python扩展包,唯一让我觉得遗憾的是,Sisyphus和构建工具打通,做到代码构建到上线快速发布。我相信任何的线上发布除了系统之间互通之外,也需要研发团队、发布团队和SRE团队之间的互通。而Tesla目前虽然还未和构建平台有任何的交互,但在团队直接的协同通知上,已经研发出了一套面向工程师的“发布申请流程”。

Tesla平台已经在内部运行了几年,是由A SRE主导研发的智能运维平台,除了自动化发布框架,它还整合了其他很多SRE主导研发的产品。

** A SRE 1:3 G SRE **

2.4 其他

Google Cron&Google WorkFlow,书中有专门的章节提及,但并未直言这两个产品是由SRE团队研发,我想列出来的原因是本是大型分布式系统应该依赖的基础软件,G SRE可以明白的阐述其软件设计思路和实现,而A云,早在几年前也有类似的产品服务整个数据中心,但由于组织架构的调整,这些服务慢慢的变成“无人区”,更别提有业务应用敢使用,作为A SRE的一员,未免令人唏嘘不已。

** A SRE 1:4 G SRE **

我们离Google SRE还有多远?

 三、思想:方法论 

3.1 培训新人

很不幸,我不得不承认A SRE团队目前就是这种“浴火重生”的学习方式,幸运的话,有能力的工程师最后能够从这种大坑里爬出来(所以我们招人异常困难),但更常见的是,多数有能力的工程师都无法在这种环境里成长。我们意识的问题的现状,却仍然没有腾出手来改变。

虽然说,我们的初衷和G SRE相同,培养工程师个人的能力,与其让他们传授知识,不如自己动手(感觉我有点厚颜无耻),可与G SRE 提供明确的系统性培训目标以及不同领域的SRE专家和研发联系人不同是,A SRE知识体系仍然在口口相传。

相比较G SRE在生产系统做故障演练和破坏性学习,大多数A SRE会从测试环境成长起来,测试环境的配置问题和软件标准化远远比生产环境糟糕的多,虽然A SRE可以在测试环境做一些破坏性的试验加深对系统的理解,但相比较生产系统,这可以说是完全不同的世界。

缺少有效的事后总结和文档能力,A SRE每周的不定期的知识技能分享也面临无法维继的风险。

** A SRE 0:1 G SRE **

3.2 接手一项服务/产品

在A云只有部分服务是一开始就是SRE负责运维的。但和G SRE不同的是,A SRE开始刚接手服务/产品往往都是一个“烂摊子”。

为了提高该服务的可靠性,A SRE往往会参与产品的设计和下个迭代版本的构建:

  • 系统的结构体系,从下自上的高可用优化方案。
  • 监控,提供更加丰富和标准的监控接口。(很多产品接手时,没有任何监控,研发团队甚至不清楚有什么监控平台。)
  • 选择指标,度量服务可用性的关键指标。
  • 紧急事件的处理机制和升级路线。
  • 服务日志分析。
  • 通过Tesla的平台扩展产品自我快速迭代的能力。

并且往往在A SRE还未完全验收好相关改进和方案,产品就要开门“接客”了。

  • 文档,A SRE决定了一个产品运维文档的撰写能力
  • 咨询,“飞机”已经起飞,始料未及的“Bug”需要研发团队和A SRE在线找到办法修复/临时绕过,等待下一个迭代版本。(在这里,原本应该提供的运维改进版本又Delay了。)

A SRE周围充满了人情和感性,业务产品那个不是从水深火热之中爬出来,而我们又如何能够袖手旁观呢?

G SRE PRR模型是非常值得借鉴的一种接管服务的方式,G SRE的这套方法论更坚定了A SRE的未来改进的方向。

** A SRE 1:2 G SRE **

3.2 团队构成

G SRE A SRE
/ 传统Ops
Tech Lead Tech Lead
SRM Tech Lead
PM/TPM /
/ PD
/ 数据分析/运营

SRE团队构成多样化,有些成员喜欢责任职责被明确的定义(仅作研发效率相关的工作),据此可以迅速安全的做出范围内的决策,另一些成员在一个更为动态的环境中工作,随时切换责任。

A SRE相比G SRE是一个更为动态的团队,团队内部比较来说,只有数据分析/运营的职责(技能)的SRE技能切换不太频繁。

A SRE技术负责人承担了不仅负责团队技术方向,还有绩效管理和横向团队协作等(其他一切其他人不能处理的事情),所剩的工作时间很少能够review团队成员的代码,更多方通过在团队中推进共识的建立来引领团队。

** A SRE 2:3 G SRE **

我们离Google SRE还有多远?

 四、结束语 

通读全书,不禁赞叹!

No A SRE G SRE
SRE的土壤 3 6
SRE的能力 1 4
SRE的思想 2 3

一千个人眼中有一千个哈姆雷特,在意识到差距的同时更不必妄自菲薄,更重要的是思考这些差距的所欠缺是努力还是思想,是再次驱动我翻开这本书细细再品的动力。

更让我收获的是,书中那些活生生的案例。

  1. 一项不稳定的服务,Bigtable稳定性造成报警过多,降低SLO减少报警,重点提升Bigtable的软件性能。
  1. Gmail的手工干预哲学:是短期麻木于SRE的提供的工具减少影响还是长期找到根因,并解决。
  2. 迁移Mysql到Brog,Brog不是万能,至少离开SRE在业务上做的优化,这项工作无法得以完成。

这些案例书中有的给出的答案,有的没有,给我最大的几点共鸣

  1. “世界上没有捷径”,我们经历着的也是G SRE经历过的。
  2. 没有一种答案可以解决所有问题,试图回答文章之初的问题变得可笑,SRE是一个积累的命题,寻找总开关想一劳永逸注定是徒劳无益。
  3. 只有非比寻常的努力,才配的上不寻常的Idea。
收藏
评论区

相关推荐

30分钟带你了解Web工程师必知的Docker知识
前言 笔者之前和朋友一直在讨论web技术方向的话题,也一直想了解web运维方面的知识,所以特意请教了一下我的朋友老胡,他对web运维和后端技术有非常多的实战经验,所以在本
头条研发-SRE运维研发实习生视频面试(一, 二面)
(about:blank%E4%B8%80%E9%9D%A230min "一面 (30min)")一面 (30min) 江湖规矩自我介绍, 很罕见的没有用算法题起手, 直接就问很具体的问题, 点个赞 <3 (htt
《Google SRE》读后感
注:从我的知乎搬移过来,方便管理,link:《Google SRE》读后感(https://link.jianshu.com/?thttps://zhuanlan.zhihu.com/p/22912741?group_id815131133242134528) (https://imghelloworld.osscnbeijing.a
我们离Google SRE还有多远?
经过几年的挣扎和讨论(确切说应该是3年),老板在钉钉群以通告的方式正式告别伴随我们多年的职业Title PE,改名为SRE。(后续以A SRE区别Google SRE) (https://imghelloworld.osscnbeijing.aliyuncs.com/188fb7b287badee91332a9f90c3af347.p
运维监控系统——Zabbix简介
前言对于运维人员来说,监控是非常重要的,因为如果想要保证线上业务整体能够稳定运行,那么我们则需要实时关注与其相关的各项指标是否正常,而一个业务系统的背后,往往存在着很多的服务器、网络设备等硬件资源,如果我们想要能够更加方便的、集中的监
运维安全-信息安全
本文转自 ,如有侵权,请联系删除。
运维,关于监控的那些事,你有必要了解一下
作者 | 乔克 来源 | 运维开发故事监控是整个运维以及产品整个生命周期最重要的一环,它旨在事前能够及时预警发现故障,事中能够结合监控数据定位问题,事后能够提供数据用于分析问题。一、监控的目的监控贯穿应用的整个生命周期。即从程序设计、开发、部署、下线。其主要的服务对象有: 技术 业务 技术通过监控系统可以了解技术的环
谷歌SRE理论读书札记:SLI、SLO与SLA
趁着这被人扫地出门,无地可去的日子,多学习学习别人的理论知识。 书籍名 《Site Reliability Engineering》网络运维工程,编者Betsy Beyer, Chris Jones, Jennifer Petoff, Niall Richard Murphy第二部分 规则(Principles)
数据库运维做些什么?
一. 数据库生命周期 结合软件生命周期、项目的开展,数据库的生命周期大致可分为这么几个阶段。 (https://imghelloworld.osscnbeijing.aliyuncs.com/8552b8c2942bb8ce23
DevOps简介
DevOps 是一个完整的面向IT运维的工作流,以 IT 自动化以及持续集成(CI)、持续部署(CD)为基础,来优化程式开发、测试、系统运维等所有环节。DevOps的概念DevOps一词的来自于Development和Operations的组合,突出重视软件开发人员和运维人员的沟通合作,通过自动化流程来使得软件构建、测试、发布更加快捷、频繁和可靠。
DevOps概述
DevOps概述DevOps(Development和Operations的组合词)是一组过程、方法与系统的统称,用于促进开发(应用程序/软件工程)、技术运营(运维)、质量保障(测试)(QA)部门之间的沟通、协作与整合。随着业务复杂化和人员的增加,开发人员和运维人员逐渐演化成两个独立的部门,他们工作地点分离,工具链不同,业务目标也有差异,这使
DevOps与CICD的区别 及 docker、k8s的CICD思路
1\. DevOps简介DevOps 就是开发(Development)、测试(QA)、运维(Operations)这三个领域的合并。image.png为什么要合并这三个领域?主要是开发和运维的脱节。DevOps是一种思想、一组最佳实践、以及一种文化。DevOps落地实施,从组织架构、设计人员、流程、人员分工、人员技能到工具,变化
SRE和DevOps值得关注的十大开源项目
构建可扩展且高度可靠的软件系统是每个SRE的最终目标。在SRE/DevOps领域中,有大量出色的开源项目,每个项目都有新颖而激动人心的解决方案。在本文中,我们将会介绍一些在监视,部署和维护领域最受欢迎的开源项目。 1\. Cloudprober可以主动跟踪和监视应用程序,并帮助你提前发现故障。它使用“活动(active)”监视模型来检查你的组件是否按预
一份DevOps工程师职责清单,待你查阅
如果一个组织的开发人员和运维人员是独立工作的模式,实施DevOps就需要对组织进行大的调整。因为,只有具备合适的组织人员,文化和工具来才能成功实施DevOps。根据显示,实施DevOps的最常见的障碍之一是员工缺乏技能。什么是DevOps工程师?DevOps工程师是一位IT专家,应该对开发和运维工作都有广泛的了解,包括编码,基础
运维大佬嘲笑我,这个你都不知道?
大家好,我是阿沐,一个喜欢分享技术而且爱好写散文的程序员。今天来给大家介绍一下info命令查看redis具体的详细信息讲解!起因是:前几年我在老家郑州实习面试(那个时候还没有毕业)的时候遇到面试官提问;面试官来于百度总部的工程师6年java开发经验+3年多的PHP开发经验,我在他的面前基本就是弟弟中的弟弟,虽然勉强通过入职了,但是却被运维无情地嘲笑,就因为组