今天计划把剩下的主题全部写完，文章可能会比较长。
上线与发布
这部分具体不是很清楚，只是听前谷歌的人说过一些。Google内部会有release engineer，有点类似国内的运维工程师吧。搜索到了三本书，详细剖析Google的运维之道。链接如下：
https://landing.google.com/sre/books/
一本是《Building Secure & Reliable Systems》在线阅读地址为：
一本是《The Site Reliability Workbook》，介绍如下：
The Site Reliability Workbook is the hands-on companion to the bestselling Site Reliability Engineering book and uses concrete examples to show how to put SRE principles and practices to work.
This book contains practical examples from Google’s experiences and case studies from Google’s Cloud Platform customers. Evernote, The Home Depot, The New York Times, and other companies outline hard-won experiences of what worked for them and what didn’t.
在线阅读地址为：
https://landing.google.com/sre/workbook/toc/
另一本书是《Site Reliability Engineering》，书籍介绍如下：
Members of the SRE team explain how their engagement with the entire software lifecycle has enabled Google to build, deploy, monitor, and maintain some of the largest software systems in the world.
在线阅读地址如下：
https://landing.google.com/sre/sre-book/toc/index.html
由于这个话题不是很专业，上面的三本好书也还没来得及系统阅读，只能等后续阅读完毕再分享了。下面补充一些我听到的信息吧。
1，Google内部的部分工程师是需要作为Release Engineer的，也就是参与部署上线。听说是有特殊的奖励的，可能一个月几百块钱吧。
2，Google的基础架构很牛逼，运维部署系统也很专业，业界有不少开源的项目，都是Google放出来的,比如Kubernetes，项目地址为：https://kubernetes.io/
3，C++的一些编译工具，Google也开源了，比如bazel就是非常方便的C++工具，目前已经扩展到支持各种不同的语言了。项目网址为：https://bazel.build/
4，Google为了解决大规模的代码编译，还实现了一套很复杂的系统，包括
七八年前，百度的基础架构团队，有计划clone一套Google的代码编译系统，不过后来好像没有听到成功落地。当然，百度倒是借鉴Google的C++编码风格，弄了好几套百度内部的C++编码规范。
代码重构
一般工程师都参与过代码重构，但是不见得你的老板们会为你的重构工作买单。代码重构是必要的，就和房间需要经常打扫一样。现在我回想刚毕业那会写的很多代码，解决问题的算法和框架都已经很落后了。差不多10年的时候，我在一家搜索公司当研发，写了不少的代码去做网页的各种解析和质量分类等，之前很多都是依赖人来分析网页，从而编写规则，搞了一套套的专家系统，不过效果并不好。目前很多任务都使用深度学习来做了。
像我们做的语音合成，早期使用HTS，后来做拼接，再后来流行LSTM，目前基本主流的公司都切换到类Tacotron和 类WaveNet的系统了，否则根本没什么竞争力。
代码需要重构，我的理解里，主要是几个原因吧：
1，时代在进步，人也在进步，重构代码，可以让代码与时俱进。有时候旧瓶装新酒很困难，使用旧的代码框架，已经不再适合最新的思路和解决方案了。
2，人都是喜新厌旧的，尤其是聪明人，员工换岗，或者是离职，都会导致有新人来接手旧项目。而最好的接手方式，就是按照自己的理解重构下代码。
听说Google内部很多项目一两年就会整体重写一遍，他们内部也比较认可代码重构的价值，这可能是Google保持活力的原因之一吧。
说到重构，大部分人很少专门学习重构的技巧，可能也没有摸索过IDE工具里的重构能力和插件，建议没有这方面经验的人，找个时间尝试看看。代码重构领域，有一本书比较知名，这里推荐下英文原版：
我挺喜欢代码重构的，我曾经做过很多代码重构的工作。代码重构的乐趣，一定程度上类似的改写自己多年前的作文。随着审美的提高，多年前的文章，总觉得又臭又长。文章如此，代码也是这样。对文章而言，需要讲究谋篇布局，讲究简洁是美德，对代码也是一样，简洁，舒服，设计合理，用词精准等，都是很重要的原则。
OKR
Google内部讲OKR，国内大部分公司讲的还是KPI。目前国内推行OKR之风挺猛的，很多的OKR培训讲师冒出来。记得在之前的系列文章里提过前Google的一位朋友，上次没找到她课程的链接，后来问了下她，课程地址放在这里，有兴趣的朋友也可以听听看：
https://apphisefxvl7233.h5.xiaoeknow.com/v1/course/column/p\_5eb7d8e64c7af\_EEklDizt?type=3
国内目前字节跳动等公司都在大规模使用OKR，并且开发了很多内部工具，用于实现OKR的对齐，也就是你的目标，和上级等进行对齐，保证大家的重心不会有较大的偏离。我目前所在的公司，目前也在使用OKR，并且也开发了一些简单的工具，实现在企业微信内部编写OKR。同事之间可以使用企业微信，查看彼此的OKR。不过我认为我接触过的OKR实践并不算成功，这里就不详细展开了。
我说一下个人对OKR和KPI的区别理解。KPI有时候容易跑偏，导致围绕这目标，各种变形的动作出来，原因是大家对目标的理解有误解，或者是每个不同团队的目标，其实是不一致的。而为了达成一个不够全面的目标，各种手段都出来了，导致「为达目的不择手段」的事情时有发生，尤其是为了实现某个商业目标，往往会牺牲产品体验。
KPI往往是自上而下的，但是上层往往有更全局的视角和目标感知，但是目标传递到下面，往往就理解上带有偏离了。OKR更鼓励的是自下而上，倾向于发挥底层的创新力，让大家都想想自己的中长期目标是什么，而通过上下对齐，在保持底层活力和能动性的同时，又保证整体的力气是往一个大的共同方向使的，从而使得整体向心力较强。
OKR的落实难点，往往在于人员素质的难点。很少听说类似桥水等机构效率低下，因为人员很少的时候，人员的招聘和管理相对比较容易。人一多，招牌难度，管理难度都加大太多，所谓鱼龙混杂吧。招聘非常关键，招聘关把好了，找到的都是自我驱动力很强的人，想的都是怎么最大化自己的影响力，自然OKR的落实就会很容易。
20%自由时间
很多外企都会有20%时间的做法，在20%时间里，你可以根据自己的兴趣，做一些你感兴趣的项目。本系列第二篇文章里介绍的创新工场CTO，当时他在Google的时候，20%时间就经常参与Google涂鸦（doodle），玩转技术和艺术结合的乐趣。
在2004年Google发布的IPO letter中，创始人Larry Page和Sergey Brin在信中写道：
除了各组的常规项目之外，我们鼓励员工每周花20%的时间开发自己感兴趣、也可以促进谷歌发展的个人项目。
We encourage our employees, in addition to their regular projects, to spend 20% of their time working on what they think will most benefit Google.
那么有哪些知名的项目是20%自由时间里搞出来的呢？
2002年，Google News测试版发布
2003年，AdSense发布
2004年，Gmail测试版发布
2005年，Google Maps发布
不过从网上的信息看，目前Google的20%自由时间几乎已经名存实亡。
美团的王兴看起来也对Google的20%自由时间不以为然，看看他怎么说的：
这里我不打算加入口水战，说一下我个人的看法：
怎么激活员工的活力，是公司管理层，以及每一位管理者都需要想办法去做的重要事情。有些公司喜欢让员工时刻保持工作状态，认为有时候刷刷朋友圈，或者是饭点的时候看看视频都是不可接受的。他们恨不得员工时刻处于战斗状态。
我个人比较欣赏张弛有度的工作状态。忙碌的时候要进入打仗状态，但是也应该有休养生息的时刻，应该给予充电和学习的时间，没有学习和思考的时间，怎么才能做到厉兵秣马呢？
根据我的个人经验，花一定比例的时间在阅读和学习上，甚至在思考上，往往整体的效率更高。时刻花在特定问题的思考上，往往不容易有新的思路，因为很多时候「功夫在诗外」，其他方向，甚至其他专业的知识，也能对解决当前问题有所帮助。
绩效考核
gogole 的绩效考核机制，还是比较值得学习的，原因很简单，Google的创新活力依然不错。我没有专门做过人力资源，所以就找了下相关资料，找到了一份比较全面的资料：《Case Study: How Google does Performance Review》，链接地址如下：
https://worklogixblog.files.wordpress.com/2018/08/b3318-google.pdf
这份资料我看起来挺有价值的，值得一读，我自己也计划详细阅读。
基本上分为三个部分，个人自评，360度环评，校准。根据我呆过的两家Google系公司的经验（他们的绩效考核是否学到家我不清楚），对程序员而言，大概是这样的：
1，程序员准备下自己的评价，包括去年的主要工作，今年的规划，相关的代码链接， 个人打分等。
2，直接上级，工作上接触比较多的同事，会对你进行打分和评价。
3，管理层对员工个人打分进行校准。一般是兼顾公平原则吧。不过就我的经验而言，员工个人的打分没什么价值，一般是个人的工作总结比较重要，因为往往做绩效决策的人，并不熟悉所有人的工作情况。
TGIF
TGIF就是 Thanks God, It's Friday的意思。在Google，往往周五的时候，会举办公司活动，公司会准备一些零食水果或者酒水等，让员工在欢快的氛围中，听公司的老板分享一些信息。员工有什么问题，也可以随时提问。
在我呆过的两家公司里，除了老板分享公司的近况外，也会举办生日会，给当月的寿星们祝寿。此外，也会做一些内部产品发布，内部知识分享（比如技术分享，或者是产品分享，营销分享等）。
听说Google内部的CEO提问环节，挺open的，比较犀利的问题也可以去提问。Google对员工秉持的是信任原则，分享的一些信息，他们相信员工不会传播到外部去。我呆过的公司里，CEO提问环节中，员工也问过千奇八怪的问题，很多问题也是让CEO们抓破脑袋，不过再难回答的问题，确实也都直面问题，而不是直接就过滤掉问题，甚至不让提问。这可能就是Google文化对他们潜移默化的影响吧。
除了生日会，一般在TGIF上也会介绍一些重要角色的加入。比如，记得在李开复的自传里提及，李开复加入Google的时候，总部那边在TGIF上对他的欢迎仪式还蛮隆重的。
不过国内不少公司其实实行的是996，所以TGIF这个东西，多少有些变味。
谷歌的大佬们
本系列的文章里，提到了Google出的几本比较知名的书，也推荐了两三个Google工程师的公众号。这里写点儿工程师角色吧，重点是Google工程师双雄。
先来看看Google的技术级别：
Level 1 - I.T. Support Staff
Level 2 - Fresh out of college
Level 3 - Master’s Degrees
Level 4 - Several years of work or a Ph.D.
Level 5 - Most progression stops at level 5
Level 6 - The top 10%
Level 7 - Level 6s with a long track record
Level 8 - Associated with a major product or piece of infrastructure
Level 9 - Spoken of with reverance
Level 10 - A Google Fellow
Level 11 - Google Senior Fellows
在业界比较知名的谷歌技术大牛，恐怕是Jeff Dean和Sanjay了，他们也都是Google Senior Fellows，处于工程师金字塔的顶级。江湖上流传着很多他的传说。可以读一下这篇有关他和他的好基友的文章：《Jeff Dean的传奇人生：超级工程师们拯救谷歌》
先来看看Jeff Dean的介绍：
Dean joined Google in mid-1999, and is currently the head of its Artificial Intelligence division. While at Google, he designed and implemented large portions of the company's advertising, crawling, indexing and query serving systems, along with various pieces of the distributed computing infrastructure that underlies most of Google's products.[3] At various times, he has also worked on improving search quality, statistical machine translation, and various internal software development tools and has had significant involvement in the engineering hiring process.
The projects Dean has worked on include:
Spanner, a scalable, multi-version, globally distributed, and synchronously replicated database
Some of the production system design and statistical machine translation system for Google Translate
BigTable, a large-scale semi-structured storage system[3]
MapReduce, a system for large-scale data processing applications[3]
LevelDB, an open-source on-disk key-value store
DistBelief, a proprietary machine-learning system for deep neural networks that was eventually refactored into TensorFlow
TensorFlow, an open-source machine-learning software library[3]
He was an early member of Google Brain,[3] a team that studies large-scale artificial neural networks, and he has headed Artificial Intelligence efforts since they were split from Google Search.[10]
再来看看Sanjay的介绍：
Sanjay Ghemawat (born 1966 in West Lafayette, Indiana)[1] is an Indian American[2] computer scientist and software engineer. He is currently a Senior Fellow at Google in the Systems Infrastructure Group.[3][4] Ghemawat's work at Google, much of it in close collaboration with Jeff Dean,[5] has included big data processing model MapReduce, the Google File System, and databases Bigtable and Spanner. Wired have described him as one of the "most important software engineers of the internet age"
Jeff的一些论文和公开的PPT，我大概看了一些。而源代码的话，大概看过LevelDB的，Tensorflow大概使用过。Sanjay也参与过LevelDB，levelDB的项目地址为：
https://github.com/google/leveldb
作为比较迷你的知名key-value 数据库实现，这个项目的技术分析文章，甚至是源码解析，都随处可见，有兴趣的朋友可以找来读读。有时间的人，当然是读读代码更好。
而Sanjay还有一个项目是开源的，那就是性能剖析相关的gperftools, 项目地址为：
https://github.com/gperftools/gperftools
这个项目相当值得阅读，对内存分析，CPU分析和性能改进相当有帮助。强烈建议有时间的朋友们读一下代码，至少读一下相关的文档吧。
Sanjay参与的论文很少，除了Google三驾马车相关论文外，看起来就TensorFlow的论文了。被引用比较多的文章如下：
而Jeff Dean在AI时代，相对比较活跃。他目前是GoogleAI的掌舵人，在机器学习领域也多有参与。来看看他参与的被引用数靠前的文章：
当然，Google的牛人来来往往太多了，可能一本书都写不完。
