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

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

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

本次案例解读：许舟平

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

（注：Google，中文称谷歌，本文会混用google与谷歌的名称）

引子

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的发展历程

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旗下子公司。

Google的企业文化

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

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

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

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

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

以用户利益为准则

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

不作恶也能盈利

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

行善的Google

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

人才观：让员工很快乐

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

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

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

2）创新无处不在

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

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

3）避免惟命是从，自由的最大化

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

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

4）不惧失败

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

Google持续交付的工程实践

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

• Engineering Manager

• Software Engineer(SWE)

• Research Scientist

• Site Reliabilty Engineer(SRE)

• Product Manager

• Program Manager /Technical Program Manager

Google Site Reliability Engineer实践

作为谷歌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必须也承担起任何有关利用率的讨论及改进，确保在高可靠性、快速迭代的情况下效率和性能提升。

在日常工作中，当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做一些性能问题排查。

基于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工具和开源方案的开发者。

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

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

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

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中设置持续构建流水线，自动执行构建和测试工作。

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

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

小结

尼采说过：“你有你的路。我有我的路。至于适当的路、正确的路和唯一的路，这样的路并不存在。”对于每一位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 运维解密》

案例研究者

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

DevOps黑客马拉松 

9月7-8日 北京

专业大咖陪你一起进化

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

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

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