Google公司的软件工程之道

原文：Software Engineering at Google, by Fergus Henderson, 31 Jan 2017

编译：徐文锦、杨晓慧、朱少民

Google（谷歌）已经是一个非常成功的公司，除了谷歌搜索和AdWords的成功之外，谷歌还向我们提供许多优秀的产品，如谷歌地图、翻译、语音识别、Chrome和Android等。谷歌还通过兼并小公司，拥有像阿尔法狗、YouTube等产品，并展示了一些尚未推出的惊人产品，例如自动驾驶汽车等。

第1部分 Google软件开发之道

1. 如何管理源代码？（）

大部分的代码都用统一的源代码库（repository）来管理，允许所有Google的软件工程师访问。同时也有以下几种值得注意的例外情况，如：

像大型开源项目Chrome和Android使用了独立的开源代码库

一些高价值的或高安全性的代码，则设定了严格的读取权限

但是大多数的程序依然是共享同一个代码库。截止到2015年1月，这个86TB的代码库已经存有10亿多个文件，其中有900多万源代码文件，其代码行数高达20亿，并包含了3500万代码提交（commits／check in）记录，每天还以4万次提交在增长（译者注： 谷歌有超过3万开发人员）。对代码库的写权限是被限定的：只有列出的每个库subtree（译者注：Git 的术语）的所有者（Owner，译者注：本来也可以不翻译）有权批准对subtree的修改。但一般来说，任意一位工程师都可以访问任何代码,可以检出（check out）所需代码并进行构建,也可以在本地对其修改、测试,并且经代码的所有者复审（review）通过后提交（check in）新修改的代码。谷歌的企业文化鼓励工程师跨越项目边界去修复他们认为受到破坏并知道如何修复的任何缺陷。这给了工程师更多授权，并促使达到高质量的基础设施,以更好地满足其使用需求。

几乎所有的开发均发生在代码库的“head”上（译者注：git中的head，即要merge到master之前的分支）,而不是在subtree上。这有助于尽早识别出集成问题并最小化所需的合并工作量。同时也使得安全补丁能够更容易和更快的上线。

更多的Google源代码存储库详见[17、18、21]，关于另一个大公司又是如何处理同样挑战的,可参见[19]。

2. 构建系统（The Build System）

谷歌使用一个被称为Blaze的分布式构建系统,此系统负责软件编译、链接及其测试。它提供了用来构建和测试软件的标准命令,并适用于整个代码库。这些标准命令和高度优化的工具意味着任何Google工程师构建版本和测试软件通常是非常简单和快速的。这种一致性在帮助工程师能够跨越项目边界进行修改起着关键作用。

程序员需要为Blaze编写如何完成版本构建的“BUILD”文件。诸如库、程序和测试这些构建实体，均由高级的声明式构建规范（declarative build specifications，DBS）进行声明，描述具体的每一个实体，如实体的名称、源文件、相关的库文件或所依赖的其它实体。这些DBS是由被称为“构建规则”的声明来组成，每个声明均用来指定如“一个拥有依赖于其他库的一系列源文件构成的C++库” 这样的高层次概念，并取决于构建系统将每项构建规则和一系列的构建步骤映射起来，例如为每个源文件进行编译的步骤、链接的步骤，以及确定使用哪个编译器和编译标志。

在某些情况下，特别是Go程序，因为BUILD文件中的依赖性信息 (通常)是源文件依赖信息的抽象，所以构建文件是可以自动生成 (和更新) 的。尽管如此，这些文件也要被检入到代码库中。这就确保了构建系统通过分析构建文件而不是源文件来快速地确定依赖关系，并以此避免了构建系统和编译器或者用于支撑其他编程语言的分析工具之间的过度耦合。

构建系统使用谷歌的分布式计算设施进行实现。通常每个构建的工作是分布在成百上千台机器中穿插进行的。这使得快速构建超大型程序或并行运行成千上万的测试成为可能。

个人构建步骤必须是“密封”的：只取决于其已声明过的输入。

所有依赖项都必须被正确的声明，这是分布式构建的必然诉求：只有已声明的输入信息会被发送到正在运行构建步骤的机器。因此, 可以依据构建系统来获取真实的依赖关系，即使构建系统的某个编译器被视为一种输入。

个人构建步骤是确定的。因此构建系统可以缓存构建结果。软件工程师可以同步其workspace回到原来的变更 码再进行重新构建，以得到完全相同的二进制版本。此外，这个缓存可以在不同的用户之间安全地共享。(为了使它正常工作,我们必须消除构建所调用的工具中的非确定性，例如通过洗掉所生成的输出文件中的时间戳)。

构建系统是可靠的。构建系统跟踪构建规则本身变更上的依赖性，这样如果某操作导致规则变化时依旧知道如何重新构建目标，即使输入对操作是不可知的，例如只有编译器选项发生改变时。同时，也能够妥善处理构建某部分被中断或在构建中修改源文件等情形：在这种情况下,你只需要重新运行构建命令，但从来不需要运行“make clean”这类命令。

构建结果缓存在“在云中”，还包括中间结果。如果另一个构建请求需要相同的结果,构建系统将自动复用而不是进行重建，即使此请求来自于不同的用户。

快速的增量构建。构建系统一直驻留在内存中，因此可以仅仅针对上次构建之后修改过的文件来进行增量分析来完成新的构建。

Presubmit检查。针对启动代码审查和/或准备提交变更到存储库时，谷歌有工具自动运行一组测试。每个库subtree都可以包含一个配置文件，以确定要运行哪些测试,以及是否在代码评审时进行测试，或在提交之前即刻运行测试，或者都要。测试可以是同步的，例如在发送变更给审查之前运行，和/或在提交变更到代码库中之前运行(有利于快速测试)。测试也可以是异步的，即通过邮件将结果发送到评审讨论线程（thread）。[评审线程正是代码审查活动发生的电子邮件线程,所有线程的信息也会在基于web的代码复查工具中呈现出来。]

3.代码评审（Code review）

除了主库部分，“实验性”的代码库部分就没有强制要求执行常规的代码评审。然而，在产品线上运行的代码必须存储在主库中，而且鼓励工程师一开始就在主库的管理下开发代码，而不是先在实验库中研发之后再将其移动到主库中。因为在刚写完代码后就进行代码审查是最有效的，而不是彻底完成代码开发工作之后再进行代码评审。实践中，有些工程师甚至会在实验阶段就请求进行代码评审了。

对于30～99行的添加/删除/删除等类型的变更，标注为 “medium-size”；

对于300行以上的变更，根据其程度进行标注，如(300～999)为 “large”， (1000 ～1999)为“freakin huge”等等。

(然而，在常见的Google方式中，为了让工作有趣，每年会有几天，如“像海盗一样说话”的那天，会使用风趣少见的描述来代替这些熟悉的描述方式)

4 测试（Testing）

集成测试和回归测试也得到了广泛的应用。

Google也有自动化工具来度量测试覆盖率，其结果作为可选层（an optional layer），与源代码浏览器（窗口）集成在一起。

在Google，部署之前的压力测试也是必备礼仪（de rigueur），要求团队通过图表显示在各种输入请求（负载压力）下系统的关键指标，如延迟和错误率。

[ 译者注：欲全面了解Google的软件测试，请参考James Whittaker 等《Google软件测试之道》]

5 缺陷跟踪（Bug tracking）

在Google的团队中定期扫描各个组件中未关闭的Bug是十分常见的（虽然不很普遍）,优先关注这些Bug并合理地将它们分配给相应的工程师。有些团队会有一个特定的人员来负责Bug分配（triage，译者注：有些bug处理有争议，需要特定的处理，就像微软早期的“”三国会议），而有些团队则在定期团队会议上进行做Bug分配。Google的很多团队均依据Bug上的标识（译者注：Bug状态标记）来判断此Bug是否已经被分配、每个Bug需要在哪个版本发布前被修复

6 编程语言（）

Google极力鼓励软件工程师去使用官方认可的四种编程语言C++、Java、Python或Go中的一种进行编程。不同的编程语言使用数量达到最低，从而减少代码复用和程序员合作上的障碍。

除了上述四种编程语言，也有许多专业的领域特定语言（Domain-Specific Languages，DSL）是用于特殊用途的（如BUILD语言是用于指定构建目标及其依赖关系的）。

这些不同的编程语言之间的互操作主要是通过使用协议缓冲（ProtocolBuffers）来实现的。协议缓冲是对结构化数据编码的一种有效的、可扩展的方法，它包括一种用于说明结构化数据的DSL，连同一个可以解析这样的描述并生成C++、Java、Python代码的编译器, 完成这些对象的构造、访问、序列化和反序列化。Google版本的协议缓冲是与Google的RPC库相集成的，允许简单的跨语言RPC实现，并对RPC框架自动处理的请求与响应进行序列化和反序列化。

7 调试和分析工具（Debugging and Profiling tools）

Google服务器与为正在运行的服务器进行调试的工具库是联系在一起的。一旦服务器崩溃，一个信 处理程序将堆栈跟踪信息自动存储到日志文件中，并保存其core文件。如果由于堆内存耗尽导致服务器崩溃的，服务器将保存一个堆对象的样本子集所在的那些站点的堆栈跟踪信息。也提供了Web的调试接口，允许检查传入和传出的RPC（包括时间、错误率、速率限制等）、改变命令行标志值（例如为特定模块增加日志冗长度）、资源消耗、分析等等。

这些工具大大增加整体调试的容易度，因此也很少启动像gdb那样的传统调试器。

8 发布工程（Release engineering）

在Google，只有很少的几个团队有专职的的发布工程师，但大多数团队，其发布工程的工作是由非专职的软件工程师来完成的。

大多数软件发布频繁；每周或每两周发布一个版本是普遍的，甚至有些团队做到每日发布。可以这样做，是因为大部分常规的版本发布实现了自动化。频繁发布新版本有助于保持工程师的士气（如果几个月或几年才发布一个新版本，那么他们是很难保持兴奋的），并通过更快的迭代来提高了整体的开发效率，而且在给定的时间内有更多的机会获得用户的反馈和对反馈做出响应。

版本的发布通常开始于一个崭新的workspace，通过同步最新的“绿色”版本(即最后一个通过所有自动测试的版本)的变更 并创建一个版本分支。发布工程师可以选择额外的变化作为“择优挑选（cherry-picked）”，即将主分支合并到新版本分支。然后软件会从头重新构建并执行响应的测试。如果测试失败，则会添加新的变更来修复失败，这“择优选取”的变更会再次合并到新版本分支，再重新构建和重新测试。直到测试全部通过后，将构建好的可执行文件和数据文件一起打包。所有这些步骤都是自动执行的，因此发布工程师只需要运行一些简单的命令，甚至只需要在菜单驱动的UI上选择相关项，选择哪些变更（如果有）作为“择优挑选”。

一旦候选版本已经完成打包，则通常部署到staging（译者注Beta 服务器或准产品线环境）服务器上，由少量用户（有时只是开发团队）进一步完成集成测试。

一个有用的技术，涉及到从产品线上发送一份请求的copy（或子集）到staging服务器，同时也发送同样的请求到当前真正的产品服务器以进行实际的处理。从staging服务器获得的响应已被丢弃，而从真实的产品服务器所获得的响应会送回给用户。这有助于确保在新版本真正上线之任何有可能会导致严重后果的问题（如服务器崩溃）能被检测出来。

下一步通常是推出一个或多个canary服务器，用于处理产品线流量的一个子集（subset of the live production traffic）。与staging服务器不同，它是处理和应对真实用户的。

最后发布就可以推广到所有数据中心的服务器上了。一些非常高流量、高可靠性的服务是需要几天时间、逐步推出，以减少由于未被之前的检测步骤所发现的、新引入的缺陷而造成任何停机／服务中断（outages）的影响。

更多的Google发布工程信息，请参阅SRE一书的第8章[7]，或参考[15]。

9 产品启动审批（Launch approval）

验收过程的设定也是为了确保在发布重大新产品或者新特性时能通知到公司内部相关的人。

关于验收审批的更多信息，请参阅SRE一书的第27章[7]。

10 事后分析 告（Post-mortems）

每当生产系统有重大的outage或类似的事故发生时，所涉及到的人员都被要求写一份事后分析 告。该文档描述了这一事故，包括标题、摘要、影响、时间表、事故根源、做对／错了什么（what worked/what didn’t）以及行动计划。分析重点在于问题本身以及未来该如何避免再次发生，而不是谁出的问题或该问题由谁负责。

影响部分试图量化意外事件带来的影响，如停机多少时间、丢失了多少查询（或失败的RPC等）和损失了多少营业额等。

时间表部分可以完整给出从停机开始到诊断、纠正问题这样一个过程。

做对／错了什么：总结教训——哪些做法有助于快速检测并解决问题、哪些做错了、采取了哪些具体行动（最好是 成Bug再分配给特定的人）以此在将来减少发生此类问题的可能性和/或类似问题的严重性。

关于Google事后调查文化的更多信息,请参阅第SRE书[7]的15章。

11 频繁重写（Frequent rewrites）

Google大多数的软件每隔几年就会被重写一次。

这么做的成本之高，往往会是令人惊讶。事实上它也的确消耗了Google很大一部分的资源。但它仍然带来一些非常良好的收益，正是这些优点对Google敏捷性和长期成功起着关键的作用。近几年来，随着软件环境和其他技术的变化，产品的快速变化成为了一项典型的需求，随着技术或市场的变化也进一步影响用户的需求、渴望和期望。多年前发布的软件是围绕一组旧的设计要求来设计的，通常不适合当前的需求。此外，它通常会积累了大量的复杂性。重写代码削减掉所有不必要的复杂性，例如过去强调的需求在今天不再那么重要了。另外，重写代码也是将知识和归属感传递给新的团队成员的一种方式。这种归属感是生产力的关键——工程师们自然而然地会把更多的精力投入到开发并修复那些他们觉得是属于自己代码中的缺陷。频繁的重写也鼓励不同项目之间的工程师流动，以推进思想的交融。频繁的重写也有助于确保代码总是使用最新的技术和方法来写的。

第2部分Google项目管理之道1.20%时间

允许工程师将高达20%的时间花在他们选择的任何项目上，而且无需事先得到经理或其他人的批准。对工程师的这种信任是非常有价值的，原因有很多。

1）这能够让有好点子的人，即使其他人无法立即发现这个想法值得去做，他也有足够的时间去开发一个原型、演示内容或演示文稿，用于展示他们的想法有何价值。

2)它让那些可能隐藏起来的活动变得可见以便管理。在其他没有“允许20%时间”这种官方政策的公司中，工程师有时会参加那种不成形管理机制（informing management）的“特别任务小组（译者注：skunkwork类似于taskforce，为特定任务而设立的团队）”项目。如果工程师能公开这些项目，在 告日常工作状态时也描述这些项目上的工作，就会好得多，即使管理者不认同当前项目的价值也是如此。公司层面支撑这些的官方政策和文化使这成为可能。

3) 通过允许工程师将一小部分工作花在有趣的事情上，可以让工程师保持激情和兴奋，防止他们心力交瘁，当他们感觉不得不花100%的时间来处理繁琐的任务时，很容易陷入疲惫。工作上十分投入的、有激情的工程师，与筋疲力尽的工程师相比，在生产效率上的差异远远不止20%。

4) 这鼓励了创新文化，看到其他工程师做有趣的实验性20%项目，会鼓励其他人也这么做。

2.目标和关键结果

Google的每个员工和组织都被要求明确记录下他们的目标，并评估目标实现的进展情况。团队会设定季度和年度目标，每个目标带有可度量的关键结果（OKR），用于展现目标实现的进展。公司的每个层级都这样做，从各个角度定义公司的整体目标。个人和小团队的目标，需要对齐他们所属的更广泛团队的、更高层级的目标，也要对齐公司的整体目标。每个季度末，记录OKR的进展，并对每个目标给出0.0（没有进展）到1.0（100%完成）的评分。OKR及其评分通常在公司内公开可见（对于高度机密的项目等特别敏感的信息，偶尔会有例外），但不直接用于个人绩效评估。

OKR应该设高一点：预期目标的整体平均得分是65%，意味着鼓励团队设置一个比实际能完成的多约50%任务的目标。如果一个团队的得分显著高于这个水平，那就鼓励他们在下个季度设置更高的目标（相反，如果团队的得分显著低于这个水平，则鼓励他们下个季度设定一个审慎一些的目标）。

OKR提供了一种沟通公司各部门工作的关键的机制，并通过 会性的激励（social incentives）来鼓励员工有良好的表现——工程师知道他们的团队将会有一个OKR评分的会议，并且自然而然地想要得到一个好分数，即使OKR对绩效评估或薪酬没有直接影响。

定义客观的、可度量的关键结果有助于确信：人们被引导去做一些对实现共同目标有真实、具体、可衡量的影响的工作，以取得好的绩效。

3.项目批准

尽管有一个明确定义的启动批准的流程（译者注：第1部分已介绍），Google并没有明确的项目批准或取消的流程。尽管我自己已经在Google待了差不多10年，并且现在已经成为一名经理，我仍未完全理解这种决定是怎么做的，部分原因是批准方法在公司内并未统一。各级经理们对他们团队的项目负责并承担责任，同时行使他们认为合适的自由裁定权。一些情况下，这意味着决策的方式是自底向上的，工程师们在团队范围内，有选择为哪个项目工作的自由。在另一些情况下，这些决策更多的是自顶向下的方式，主管或经理们决定哪个项目继续进行，哪个将获得额外的资源，而哪个会取消。

4.团队重组

偶尔，当一个主管决定取消一个大项目的时候，就会有许多之前在这个项目工作的工程师，需要到一个新的团队找一个新的项目来做。同样的，偶尔也会有一些“碎片整理（译者注：defragmentation也可翻译“重组”，但这样翻译更生动）”工作，将跨区域的、分离的项目进行整合以减少地域数量。为达到这个目的，某些区域的工程师就会被调整团队和/或项目。这种情况下，工程师们通常在他们本地区可获得的职位内，可以自由选择新的团队和角色。重组时，他们也可以选择换地区以待在原来的团队和项目中。

除此以外，其他种类的团队重组，例如整合或拆分团队、变更 告关系等似乎经常发生，尽管我不知道Google和其他大公司相比如何。在一个大型的、技术驱动的组织中，为了避免技术和需求变化导致的组织效率低下，略微频繁的重组可能是必要的。

第3部分Google人员管理之道1.角色

下面将会详细介绍，Google设立了工程和管理的不同的职业发展通道（阶梯），将技术管理角色从管理者中分离出来，将研究嵌入到工程中，以及支持工程师工作的产品经理、项目经理和 站可靠性工程师（site reliability engineers，SRE）等角色。看起来至少有部分实践对于维持由Google开创的创新文化是很重要的。

Google在工程类别下还设立了少量不同的角色，每种角色都有职业发展的可能，有一系列级别和晋升通道（与薪酬的提升相关，例如工资），用来认可进入更高级别的认可。

主要角色如下：

1）工程经理（译者注：，类似部门经理）

这是本列表中唯一的管理者角色，其他角色中的个体可能会管人，而工程经理一定会管人。工程经理通常做过软件工程师，并且总是具备相当可观的技术专长，以及人员管理技巧。

技术上的领导力与人员管理是有区别的。

工程经理不一定领导项目；项目由技术主管领导，他有可能是工程经理，但更多的时候是软件工程师。一个项目的技术主管对这个项目的技术决策有最终的发言权。

经理们对技术主管的选择，以及他们团队的表现负有责任。他们负责辅导和协助职业发展，做绩效评估（以同行反馈作为输入，见下），并负责薪酬中的某些方面。他们还负责一部分招聘流程中的工作。

工程经理通常可以直接管理3~30人，最常见的是8~12人。

2）软件工程师（Software Engineer ，SWE）

从事软件开发的大部分人都是这个角色，Google的软件工程师招聘门槛非常高，通过只雇佣特别优秀的软件工程师，避免或尽量减少困扰其他组织的许多软件问题。

针对工程人员和管理人员，Google有各自独立的职业发展序列（译者注：美国科技公司基本类似）。尽管软件工程师进行人员管理，或者转换为工程经理角色是可能的，但人员管理并非晋升所必须，即使在很高的级别上也是如此。在更高的级别上，需要展现领导力，但是可以有多种形式的体现。例如，创建有巨大影响力的、或有大量工程师使用的重要软件，这就足够了。这（译者注：指各自独立的职业发展通道）很重要，因为这意味着有很强技术能力，但缺乏人员管理意愿和技巧的人，仍有很好的职业发展路径，而他们无需走管理通道。这避免了一些组织中存在的问题——人们因为职业晋升的原因最终踏入管理岗位，但却忽视了团队中真正的人员管理。

3）研究科学家（ResearchScientist）

4） 站可靠性工程师（SRE）

对运行系统（译者注：产品线上正在运行的系统）的维护是由软件工程师团队来实施的，而不是传统的系统管理员团队，但是SRE职位招聘软件工程师要求，略低于SWE职位的招聘要求。SRE角色的性质和目的在SRE手册[7]中已经详细介绍，这里不再进一步讨论。

(译者注：[7] https://landing.google.com/sre/book.html)

5）产品经理（）

产品经理对产品的管理负责，作为产品用户的支持者，他们协调软件工程师的工作，传递对这些用户很重要的功能特性，与其他团队合作，跟踪缺陷和计划，确信所需的一切都就绪，以开发出高质量的产品。产品经理通常不亲自写代码，但会与软件工程师一起工作，以确保他们写出正确的代码。

6）项目经理/技术项目经理（译者注：直译为“程序经理/技术程序经理”或“流程经理/技术流程经理”，以前微软也要类似角色，但“项目经理”一词更接近该角色的职责）

项目经理是一个与产品经理大致相似的角色，只不过不是管理产品，他们管理项目、流程或操作（如数据收集）。技术项目经理也类似，但需要与工作相关的特定专业技术知识，例如用于处理语音数据的语言学。

软件工程师与产品经理和项目经理的比例，在不同的组织内是不同的，不过一般都很高，例如在4:1到30:1之间。

2.设施

Google以其有趣的设施而闻名，像滑梯、海洋球和游戏室之类的。这有助于吸引和留住优秀人才。Google有很棒的咖啡馆，对员工免费，其作用也是一样的，而且这也巧妙的鼓励Google员工留在办公室，肚子饿从来都不是离开办公室的理由。四处放置的“微厨房”让员工可以拿到零食和饮料，这也提供了同样的功能，但它也充当了非正式观点交流的重要资源（译者注：应当理解为“非正式观点交流的重要平台”），因为许多对话都是从这里开始的。健身房、运动和现场按摩帮助员工保持苗条、健康和心情愉快，提升了生产率和保留率。

在Google座位是开放式的，而且往往坐的很密。虽然有争议[20]，但这鼓励了沟通，虽然有时付出了个人专注度的代价，但很经济（译者注：敏捷开发也提倡开放式的座位，有利有弊——沟通方便了，但写代码的效率降低了，*总是*“付出了个人专注度的代价”）。

每个员工都会被分配一个单独的座位，但座位的调整是相当频繁的（例如每6~12个月，通常是组织扩张的结果），经理通过座位的选择鼓励沟通并为沟通提供方便，这比较容易发生在相邻或接近相邻的个体之间。

Google的所有会议室都配备了最先进的的视频（state-of-the-art video）会议设施（译者注：可以参考），在那里，只要点一下屏幕就可以马上连通事先日程安排所邀请的人员。

3.培训

Google在许多方面鼓励员工教育：

Google新员工（“Noogler”）有一个强制性的初始培训课程（译者注：可以参考My First Day at Google – And the Beginning of Something Special）。

技术人员（软件工程师和研究科学家）从做“Codelabs”开始：带有编码练习的个人技术短期在线培训课程。

Google为员工提供各种在线和面对面培训课程。

Google还为在外部机构学习提供支持。

此外，通常会为每个Noogler指定一个正式的“导师”和一个单独的“伙伴”，以帮助他们跟上进度。通过与经理的例会、团队会议、代码审查、设计审查和非正式流程，也会进行非正式的指导。（译者注：基本没什么特别，美国公司大多数是这样的）。

4.转部门

在公司的不同部门间调换是被鼓励的。这有助于知识和技术在组织间的传播，并且促进了跨团队交流。在一个位置上工作12个月以上且信誉良好的员工，允许在项目和/或办公地间调换。也鼓励软件工程师在组织的其他部门承担临时任务，例如在SRE（ 站可靠性工程师）岗位上为期六个月的“轮换”（(临时任务）。

5.绩效考核和奖励

在Google十分鼓励反馈。工程师可以通过“同行奖励（peer bonuses）”和“荣誉（kudos）”给与彼此明确的正面反馈。所有员工都可以提名任意其他员工获得“同行奖励”——每年最多两次，每次现金奖励$100——以奖励超出职责范围的工作，只需要填一张web表格说明情况就行。获得同行奖励时，通常会通知队友。对员工还可以给予“荣誉”，一种正式的赞美之词，这是对良好的工作给与了明确的 会认同，但没有物质奖励；给与“荣誉”并不要求工作超出正常的职责范围，也没有授予次数的限制。

经理也可以给与包括现场奖励在内的奖金，例如在项目完成时现场奖励。而且，与其他公司一样，Google的员工根据其绩效也会获得年度绩效奖金和股权奖励。

Google有一个非常审慎、详细的晋升过程，包括：自荐或由经理提名、自我回顾、同行评审、经理评估；然后由促进委员会（译者注：应该是评估员工任职能力的专家团队）基于这些输入做出实际的决定，决定的结果可以提交给促进上诉委员会（译者注：应该是由技术专家和人力资源共同组成的，最终决策和处理上诉的团队）进一步审查。确保正确的人得到晋升对于保持对员工的正确激励至关重要。

另一方面，绩效不佳则由经理反馈处理，如果有必要还会制定绩效改进计划，计划包括设定非常明确具体的绩效目标，并评估目标达成的进展。如果这样做没有效果，解雇业绩不佳的员工是有可能发生的，但现实中，这在Google非常罕见。

经理的绩效通过反馈调查来进行评估，每个员工都被要求填写一份针对他们经理的业绩表现调查表，每年调查两次，调查结果是匿名的，并在汇总以后提供给管理者。这种自下向上的反馈对于维护和提高整个组织的管理质量非常重要。

[译者注：参考文献大家点击“阅读原文”查看]