DevOps案例研究:庖丁解牛,剖析Google持续交付之道

内容来源:DevOps案例深度研究 –Google持续交付实践战队(本文只展示部分PPT及研究成果,更多细节请关注案例分享会,及本公众号。)

本案例内容贡献者:姚元庆 (Topic Leader) 、任跃兵、王红阳、王晓敏、张彪

本次案例解读:许舟平

640?wx_fmt=png

解读者说:作为起源于硅谷的跨国科技公司,谷歌的业务涵盖互联网搜索、广告、云计算、AI等众多领域,开发并运营了大量基于互联网的产品与服务。本文将从谷歌的价值观、发展历程、企业文化、持续交付工程实践、SRE团队等多个方面来剖析谷歌独特的持续交付之道。

(注:Google,中文称谷歌,本文会混用google与谷歌的名称)

引子

640?wx_fmt=png

To organize the world's information and make it universally accessible and useful (整合全球信息,供大众使用,使人人受益)

—Google Slogan

由拉里·佩奇和谢尔盖·布林于1998年9月4日成立的Google,被公认为全球最大的搜索引擎公司,其主域名google.com是全世界访问量最高的网站。

Google不仅提供其核心的网络搜索业务,还在全世界提供丰富的线上服务,如Gmail电子邮件、Google Map、Google Calendar、YouTube等。

Google的产品同时也以应用软件的形式进入用户桌面,例如Google Chrome网页浏览器、Picasa图片整理与编辑软件、Google Hangouts即时通讯工具等。

另外,Google还开发了用于移动设备的Android操作系统以及Google Chrome OS操作系统。

相比于“整合全球信息,供大众使用,使人人受益”的官方Slogan,Google的非正式口号“Don't be evil”(不作恶)更是广为流传。

为了支持如此众多的线上业务,Google在分布于全世界的数据中心内运营着上百万台服务器,每天处理数以亿计的各种请求。谷歌是如何做到7*24支持业务上线部署和系统持续交付的呢?让我们在本次DevOps案例研究中一探究竟。

Google的发展历程

640?wx_fmt=png

640?wx_fmt=png

Google的发展概况

  • 1996年1月,加州斯坦福大学的两位博士生——拉里·佩奇和谢尔盖·布林开始研究一项区别于传统搜索“根据关键字在页面中出现次数来进行结果排序”的方法,两人开发了一个对网站之间的关系做精确分析的搜寻引擎。

  • 1997年9月15日,拉里·佩奇和谢尔盖·布林两人注册了Google域名。

  • 1998年9月4日,在加州门洛帕克的一间车库里,佩奇和布林创建了Google,克雷格·西尔弗斯坦(Craig Silverstein)成为公司的首位雇员。

  • 2004年7月13日,Google收购照片整理与编辑软件Picasa,同年10月又吞并了Keyhole公司。一年后,Google将Keyhole公司的Earth Viewer服务改名为Google地球。

  • 2004年8月19日,Google完成首次公开募股,当初总股本27182万股(2.718281828和数学常数e有关,常数e又被称为欧拉数,为自然对数函数的底数,值约为2.71828)。

  • 2005年,成立仅22个月的高科技企业Android被Google收购,成为Google麾下的移动设备操作系统。

  • 2010年3月23日,谷歌宣布关闭在中国大陆市场的搜索服务,保留研发和市场团队。

  • 2011年5月,Google的月独立访客数量首次超过十亿,与一年前同期的9亿3100万相比增长8.4%,成为全世界首个获取该数据里程碑的网站。

  • 2015年8月10日,Google宣布对企业架构进行调整,并创办了一家名为Alphabet的控股公司,Google成为Alphabet旗下子公司。

640?wx_fmt=png

Google的企业文化

640?wx_fmt=png

不同的视角,不同的认识:

  • 对于用户来说,Google是一家有品质的互联网企业。

  • 对于硅谷的技术人员来说,Google是一个创新天堂。

  • 对于华尔街来说,Google是一家有别于传统的另类企业。

  • 对于Google员工来说,自由畅快的企业文化造就了它无穷的创造力,在这里,工作就是一种生活。

640?wx_fmt=png

以用户利益为准则

Google坚持为客户带来更多的体验,因此建立了很多网上服务,而且它的搜索操作简单实用,广告跟正常搜索结果明显分开。

不作恶也能盈利

Google不会因为任何原因操纵搜索排名位置,以满足付了大量资金的合作伙伴排在搜索结果前列的要求。制定执行“不作恶”的标准,就是要避免做任何损伤谷歌用户使用体验的事情,“哪怕是以牺牲公司的收入为代价”,如不做烟草广告以及烈性酒广告。

行善的Google

Google基于“不作恶”原则对广告商挑三拣四,但却给两百多家健康卫生、教育和非政府组织做免费广告。

640?wx_fmt=png

人才观:让员工很快乐

1)给员工20%的自由支配时间

Google给每位工程师20%的自由时间用来做自己感兴趣的项目。这表现出公司对员工个人的极大信任,员工对自己工作时间的分配拥有了更大的自由裁量权。这样的20%不是一刀切的,员工可以自己衡量当前工作进度,然后决定要不要将20%的个人时间用到自身项目上。

兴趣驱动的工作中,员工可以获得愉悦和满足感,从而释放创造力,许多员工为了这样的项目甘心额外付出时间和精力。基于这种方式,Google员工的自我管理水平不断提高,既能够保障完成公司所分配布置的工作,又能够不断推出新创意,这也是Google众多重磅产品的来源。

640?wx_fmt=png

2)创新无处不在

在Google的企业文化中,工作可以和生活一样是轻松欢愉的,这种舒适感可以赋予员工充分的创造力。每个员工的办公区都各具特色,员工在上班前会得到一笔资金用来装扮自己的办公区。除了需要保密的项目或者部门,公司内极少有单人办公室或封闭式办公室,不同员工在开放的工作区域上保持亲近,方便随时沟通。

Google为每位员工配备了笔记本电脑,供他们随时随地进行编程、收发邮件或记录突如其来的灵感。公司设有各种风味的餐厅,各楼层的茶水间摆放了各种零食和饮料。员工如果不喜欢被分派到的项目工作,他可以申请转换项目。另外,在Google从事非技术工作的员工也会得到同样的尊敬和重视。

3)避免惟命是从,自由的最大化

在Google的管理层中管理者不存在对下属的绝对支配权力,难以做出是否雇佣、是否解雇、是否重用及加薪等决策。在Google,管理者没有直接的决定权,决定权赋予独立的委员会或小组,这样的委员会或者小组可以是临时任命的,能够保证其独立性和客观性,确保作出的决策能够有利于公司的长远利益,而不是屈从于某一管理者的个人意志。

在Google的企业文化中,坚信每个员工都是好的,员工会为个人利益和公司利益而奋斗,这样的主人翁意识决定了员工不是机器,而是企业进步的最大推动力。

4)不惧失败

在现代企业经营中,企业对失败的承受力大大降低,一次简单的失误就能使一家大型企业在激烈的市场竞争中归于破产。不同于其他企业,Google的企业文化中表现出对失败的极大包容性,允许员工在不断尝试中失误,认同失误的价值,认为其中蕴含了成功的机会。在Google的众多项目中,对失败的包容,往往促成了更好的创新,许多成功的项目得以脱颖而出。这也正是Google公司强大创新力的重要来源,员工的失败不会简单地归于个人的失职,而是作为有意义的经历,失误的经验教训被吸取,众多的失误中蕴含着成功的机遇。

Google持续交付的工程实践

640?wx_fmt=png

谷歌产品研发及运维团队的角色组成:

  • Engineering Manager

  • Software Engineer(SWE)

  • Research Scientist

  • Site Reliabilty Engineer(SRE)

  • Product Manager

  • Program Manager /Technical Program Manager

Google Site Reliability Engineer实践

640?wx_fmt=png

作为谷歌DevOps实践中具有代表性的SRE,其工作的主要职责不仅仅是从事Operation方面的工作,更多是保障整个Google服务的稳定性,包括但不限于:

1)确保长期关注研发工作

Google将SRE团队的运维工作限制在50%以下,SRE团队应该将剩余时间花在研发项目上。在实践中,SRE管理人员应该经常度量团队成员的时间配比,如果有必要的话,可以采取一些暂时性措施将过多的运维压力转移回开发团队处理。

例如,将生产环境中发现的Bug和产生的工单转给研发管理人员去分配,将开发团队成员加入到轮值on-call体系中共同承担轮值压力等。这些暂时性措施应该一直持续到运维团队的运维工作压力降低到50%以下。在DevOps实践中,这种措施实际形成了一个良性循环,激励研发团队设计、构建出不需要人工干预、可以自主运行的系统。

2)在保障服务等级目标 SLO (Service Level Objective) 的前提下,最大化迭代速度。

产品研发部门和SRE之间可以通过消除组织架构冲突来构建良好的合作关系。在企业中,最主要的矛盾就是迭代创新的速度与产品稳定程度之间的矛盾。

3)监控

监控系统是SRE团队监控服务质量和可用性的一个主要手段。在Google有一个规则:没有不需要采取行动的警报。如果你遇到一个自己认为不需要执行操作的警报,你需要采用自动化的手段来修复该警报,监控不做任何事情在Google是不会存在的。一般来说,Google的SRE监控系统会有三种有效的监控输出:警报、工单、日志。

4)紧急事件处理

可靠性是MTTF(平均失败时间)和MTTR(平均恢复时间)的结合结果。评价一个团队将系统恢复到正常情况的最有效指标,就是MTTR。

5)变更管理

大概70%的生产事故由某种部署的变更而触发。变更管理的最佳实践可使用自动化来完成以下几个项目:采用渐进式发布机制;迅速而准确地检测到问题的发生;当出现问题时,安全迅速地回退改动。

6)需求预测和容量规划

需求预测和容量规划简单来说就是保障一个业务有足够的容量和冗余度去服务预测中的未来需求。

7)配置

资源的部署与配置是变更管理与容量规划的结合物。如何自动化地实现资源部署和资源调度,是SRE需要考虑的内容。

8)效率和性能

高效地利用各种资源是任何营利性服务都要关心的,因此SRE必须也承担起任何有关利用率的讨论及改进,确保在高可靠性、快速迭代的情况下效率和性能提升。

640?wx_fmt=png

在日常工作中,当SRE需要接手某个服务前,对server的性能和稳定性都有一定的要求,比如server出现报警的次数不能超过一定的频率,server对CPU、内存的消耗不能超过预设的指标。只有server完全满足SRE的要求以后,SRE才会接手这个server。

当server出现问题时,SRE会先紧急修复,恢复服务,然后SRE会和SWE沟通,最终SWE来彻底修复server的bug。同时,对server的重大更新,SWE都要提前通知SRE,做好各种准备工作,才能发布新的版本。

为了能让SRE能接手server,SWE要根据SRE的要求对server做大量的调优。首先SRE会给出各种性能指标,比如服务响应延迟、资源使用量等等;其次SRE会要求SWE给出一些server评测结果,诸如压力测试结果、端到端测试结果等等;同时,SRE也会帮助SWE做一些性能问题排查。

640?wx_fmt=png

基于Google Cloud Platform的持续集成与持续交付工具

与AWS、Azure、阿里云等其他云服务商不同,谷歌云的起家是从PaaS开始,Google App Engine在2008年4月发布第一个测试版本,用户只需使用GAE提供的资源就可以开发自己的应用程序或网站,并且可以方便地托管到Google来进行运维。后来,谷歌才逐步增加和丰富了谷歌云的IaaS服务能力,在2012年6月28日的Google I/O大会上提供Google Compute Engine的预览版,这自然使得GCP的特性和功能受到了广大开发人员的欢迎,特别是那些希望使用DevOps工具和开源方案的开发者。

640?wx_fmt=png

许多中小型创业公司被Google的创新性和开放性所吸引,从而使用GCP。依照独立IT研究与咨询服务公司Gartner的说法:

Google对于那些云原生和想要‘如Google一样运行’的公司最具吸引力。

对于云原生和容器,Google通过开源自身的容器管理平台Kubernetes,以及对云原生开源社区进行的技术输出,使得GCP在云原生、微服务和DevOps上的能力持续加强,可以帮助GCP的使用者专注于应用开发、大数据分析和机器学习等应用领域。

640?wx_fmt=png

2018年,Google更是推出了一款全新的持续集成和持续交付(CI/CD)工具 - Google Cloud Build。

谷歌对Google Cloud Build的定位是:“全面管理的持续集成与持续交付平台,能用来快速且大规模构建、测试和部署软件。”因此,Google Cloud Build可应用于各种架构,如虚拟机、无服务器(Serverless)、Kubernetes或者Firebase架构。

Google Cloud Build的用户可以使用触发程序来部署应用,当达到一定条件,可以自动触发更新,另外也有本地部署跟云端部署两种方式供选择。Google Cloud Build可帮助使用者跨语言构建项目,通过和类似GitHub等配置管理工具的集成,可以在Google Cloud Build中设置持续构建流水线,自动执行构建和测试工作。

640?wx_fmt=png

如果Google Cloud Build发现持续集成中出现问题,可以提供分析和建议,用户还可以通过历史错误、警告和过滤器来识别将阻碍程序构建与部署的问题。

另外,在监控方面,Google Cloud Monitoring服务提供从Google App Engine、Compute Engine以及Cloud SQL收集的数据来对运行的应用性能、容量和正常运行状态进行监控。

640?wx_fmt=png

小结

640?wx_fmt=png

尼采说过:“你有你的路。我有我的路。至于适当的路、正确的路和唯一的路,这样的路并不存在。”对于每一位DevOps实践者而言,走自己的路才会达到自己想要去的那个地方。更为重要的是,一定要拥有追随自己内心与直觉的勇气,你可以在DevOps案例深度研究的团队里,勇敢踏出DevOps实践的第一步。

参考资料

  • Fergus Henderson,“Software Engineering at Google”, Jan 2017

  • Rachel Potvin and Josh Levenberg,“Why Google Stores Billions of Lines of Code in a Single Repository”, July 2016

  • Betsy Beyer, Chris Jones, Jennifer Petoff, Niall Richard Murphy编著,孙宇聪 译《SRE: Google 运维解密》

案例研究者

640?wx_fmt=png

拓展阅读:DevOps案例研究:知人善任——Google敏捷核心文化

DevOps案例研究:进取到让自己毛骨悚然,Netflix公司的简介和文化

DevOps案例研究|史上最能“拜客户教”的公司,是如何做到持续交付的?(第1趴)

640?wx_fmt=gif

DevOps黑客马拉松 

9月7-8日 北京

专业大咖陪你一起进化

欢迎企业组队PK,企业团队报名有特惠

目前已经有两家企业组队!!

赶紧报名吧~⬇️⬇️⬇️

640?wx_fmt=jpeg


本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.mzph.cn/news/314674.shtml

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

架构杂谈《八》Docker 架构

Docker 架构 一、Docker 引擎的三大组件1)Docker 后台服务(Docker Daemon):是长时间运行在后台的守护进程,是Docker的核心服务,可以通过命令dockerd与它进行交互通信。2)REST 接口(R…

P3723 [AH2017/HNOI2017]礼物 FFT + 式子化简

传送门 文章目录题意:思路:题意: 思路: 首先可以知道,我们对某个数组加上一个正数数的操作可以转换成对一个数组加上一个任意数,所以我们设变化量为xxx。 对于∑i1n(ai−bi)2\sum_{i1}^n(a_i-b_i)^2i1∑n​…

.net core 基于 IHostedService 实现定时任务

.net core 基于 IHostedService 实现定时任务Intro从 .net core 2.0 开始,开始引入 IHostedService,可以通过 IHostedService 来实现后台任务,但是只能在 WebHost 的基础上使用。从 .net core 2.1 开始微软引入通用主机( GenericHost)&#x…

nowcoder 清楚姐姐的翅膀们 F 一般图的最大匹配

传送门 文章目录题意思路:题意 思路: 这个题很容易就会掉到二分图匹配的坑里。。 但实际上这个是一个一般图匹配。 考虑将妹子拆点,一个入点一个出点,入点出点都连蝴蝶结。 我们看看最终会有三种匹配情况: (1)(1)(1)妹…

HDU - 7072 Boring data structure problem 双端队列 + 思维

传送门 文章目录题意:思路:题意: 你需要实现如下四个操作 q≤1e7q\le1e7q≤1e7 思路: 做的时候想了个链表的思路让队友写了,懒。 看了题解感觉题解还是很妙的。 你需要快速插入一个数在前后两端,还需要…

C#中谁最快:结构还是类?

前言在内存当道的日子里,无论什么时候都要考虑这些代码是否会影响程序性能呢?在现在的世界里,几乎不会去考虑用了几百毫秒,可是在特别的场景了,往往这几百毫米确影响了整个项目的快慢。通过了解这两者之间的性能差异&a…

阅读nopcommerce startup源码

创建一个asp.net core项目,可以到到startup类有两个方法// This method gets called by the runtime. Use this method to add services to the container.public void ConfigureServices(IServiceCollection services)public void Configure(IApplicationBuilder a…

HDU - 7073 Integers Have Friends 2.0 随机化 + 质因子

传送门 文章目录题意:思路:题意: 给你一个序列aaa,找一个最大的集合,集合中所有元素模mmm相等。 思路: 之前做过一道连续的,直接尺取就好,这个不连续加大了难度。 考虑最简单的…

一份关于.NET Core云原生采用情况调查

调查背景Kubernetes 越来越多地在生产环境中使用,围绕 Kubernetes 的整个生态系统在不断演进,新的工具和解决方案也在持续发布。云原生计算的发展驱动着各个企业转向遵循云原生原则(启动速度快、内存占用低)的平台, .N…

KPI在小型产品团队中的实践

最近公司决定对所有技术人员实行KPI考核,曾经一度非常反感KPI的我也被要求制定产品团队的KPI指标。为什么要实行KPI考核,因为在项目团队和产品团队的管理中出现了问题:不同项目团队的开发人员的工作量饱和度问题,阶段性会出现有的…

历久弥新 - 微软万亿市值背后的文化支撑(上)|DevOps案例研究

内容来源:DevOps案例深度研究-Microsoft文化支撑研究战队(本文只展示部分PPT研究成果,更多细节请关注案例分享会,及本公众号。)本案例内容贡献者:陈飞(Topic Leader)、陈雨卿、郭子奇…

ASP.NET Core on K8S深入学习(1)K8S基础知识与集群搭建

在上一个小系列文章《ASP.NET Core on K8S学习初探》中,通过在Windows上通过Docker for Windows搭建了一个单节点的K8S环境,并初步尝试将ASP.NET Core WebAPI项目部署到了K8S,把玩了一下快速部署和实例伸缩。这个系列开始,会继续学…

我眼中的 NCC,WTM 寻亲之旅

峥嵘岁月如谢花流水,三朝五帝如散雾云海。开发语言更迭如此。我们所坚持的,只是那最初的感动,那“只是在人群中多看了你一眼”的惊艳。三十年河东,三十年河西,不忘初心,方得始终!嗯,…

Codeforces Round #594 (Div. 2) C. Ivan the Fool and the Probability Theory 思维 + dp

文章目录题意:思路题意: 思路 一开始找规律,表都打好了,没找出来。。 找规律还是适合让队友来。 先考虑第一行,我们先计算第一行的方案数,设f[i][j]f[i][j]f[i][j]表示到了iii位,第iii位的颜色…

Wtm携手LayUI -- .netcore 开源生态我们是认真的!

经过WTM团队和LayUI团队多次深入协商,双方于2019年7月29日在北京中国国际展览中心正式达成战略合作意向,双方签署了战略合作框架协议,LayUI团队承诺使用WTM框架的任何项目都可以免费使用其收费版的后台模板,WTM团队则从受捐助款项…

Codeforces Round #305 (Div. 1) D. Mike and Fish 欧拉回路

传送门 文章目录题意:思路:题意: 思路: 欧拉回路经典题。 将其转换成图上问题,对于横纵坐标我们将其分开,对于(x,y)(x,y)(x,y)我们将其横纵坐标连一个无向边,现在问题就转换成了我们需要对每条…

高性能动态编译库Natasha发布1.0版本!

一、 前言对于开源贡献者,Emit和表达式树不是陌生的字眼,IL的动态特性为封装工作带来了极大的方便,会Emit的开发者可以说驾驭了大部分的高性能、高动态的编程技巧。纵观ef、dapper、json.net等第三方常用库,哪个能脱离emit而独善其…

Codeforces Round #245 (Div. 1) E. Points and Segments 欧拉回路 + 建模

传送门 文章目录题意:思路:题意: 思路: 考虑对于线段,如何建模。 我们考虑先将线段转换成左闭右开的形式,将左右点连起来。 再考虑每个点,将所有离散化后的点拿出来,每个点都有一个…

微软.Net Core 3.0 预览版7发布:大幅减少 SDK 空间大小

据悉,这个预览版是 .Net Core 3 中重要的版本,可以视为原计划在 7 月发布的 RC 版本 (引自微软 .NET Core 首席 Program Manager Richard 先生原话),故可在生产环境进行开发和部署。Windows, macOS 和 Linux 版本的Download .NET …

5门可能衰落的编程语言

专注于为北美地区的科技专业人士提供行业见解和分析,以及提供求职消息的技术职业消息服务网站 Dice Insights 近日发表了一篇题为《5 Programming Languages That Are Probably Doomed》的文章。作者主要根据 TIOBE 和 RedMonk 这两个编程语言排行榜,以及…