您所在的位置： &
如何通过DevOps解决团队配合问题
如何通过DevOps解决团队配合问题
不同的技术团队一般隶属不同的部门，分散在公司不同的办公区域，团队内部的沟通相对多一些，但团队之间的沟通较少。DevOps是2010年从欧洲传过来的概念，实际是给各个团队之间搭桥，让他们不仅仅是依靠上线申请单这样的鸿雁传书工具进行沟通，而且经常离开自己的孤岛，走到别人的岛上去，了解别人，并提供自己的想法，帮助对方。
一、技术团队细分及配合问题
在IT企业里产品从创意到交付给用户，从整体上看是由技术部门负责，但如果深入到技术部门，会发现由不同的技术团队负责不同的部分或者阶段。一般会分产品团队、开发团队、测试团队以及运维团队，在互联网公司里，运维团队一般还分基础运维和产品运维两个团队，基础运维负责基础设施(包括机架、网络、硬件)和操作系统的安装，为整体公司的所有产品提供基础设施的运维服务。而产品运维负责线上产品的问题处理、代码的布署和跟开发的接口等。
不同的技术团队一般隶属不同的部门，分散在公司不同的办公区域，团队内部的沟通相对多一些，但团队之间的沟通较少。不同团队都会形成自己的办事习惯、节奏，都有自己的关注点，一般只是知道与之接口的团队的总体职责，但是不知道对方可能面临的困难与工作中的挑战点。另外，如果公司够大，每个团队内部又会分为许更细的小团队，如基础运维一般有系统团队、网络团队和IDC团队等，这样更加重了团队之间沟通难度。
从产品策划到上线，一般是以下边的顺序经过各个团队：
开发团队收集产品的需求，定下时间表并进行开发
开发完后，交由测试或质量团队进行测试
然后交给运维团队布署新产品或新版本
运维团队将运维过程中发现的代码缺陷反馈给开发团队进行修复
在上面的每个阶段，对应的团队都是各做各的，一般是在最后才会把球踢给下一个团队，如果下一个团队发现问题又会把球踢回原来的团队。如果你深入到不同的团队中去，或听到不同的抱怨声音。
基础运维团队经常抱怨：
产品开发一点计划都没有，突然要上线机器，让我们措手不及。
每个产品都急着上线，谁催得急就上谁的，谁能说一下，到底那个重要？
动不动就要重装系统，坏了一块盘就着急去修，刚从机房回来，又要过去。
上线太突然了，没有交换机，没有机架，还需要搬别的机器腾地方。
那个地方有机架和交换机端口，但没有四层设备，他们又要放在四层后边，真的没有办法了。
刚跟他们上线到一个机房，他们又说要换到另一个机房，尽折腾。
他们怎么能那么用设备，把上连端口带宽都跑满了。
产品运维团队会说：
真没办法，上个线不是说没机架，就是没有交换机，还有就是说没有四层设备。
从来不告诉我们什么时候能设备能上线交付给我们，不派专人催着这事，一点谱都没有。
本来没有想好怎么用这些设备，先提前一个月申请上线，得我们想清楚了，他们却说又得换机房。
网络怎么老是出问题，他们怎么规划的。
开发的代码太不靠谱，一上线就引发用户投诉，只能回滚到老版本。
开发人员的技术能力不行，写不出能用的版本。
开发要求有一个跟生产环境一样的测试环境，这不可能有的。
而开发团队却说：
他们又不让我们碰线上的系统，生产环境是什么样，我们都不知道，没法开发代码。
我们辛苦开发几个月，上线出问题又直接回滚了，心情很不好受。
代码在测试环境或我的机器跑的好好的呀，怎么一上线就出问题呢。
测试怎么测的，那么多问题发现不了。
我们希望产品运维同事帮忙搭一个跟线上一模一样的测试环境。
另外，测试团队的人也许会说：
开发人员不写规定写单元测试代码。
想着能用一个自动的集成测试环境，因为开发的原因，老是实现不了。
测试环境跟生产环境不一样，好多问题才发现
还有那么多的bug没有解决，产品就催着上线。
二、技术团队之间配合不好的影响
上面看到的团队之间的冲突和抱怨问题虽然都不一样，产生的影响确是类似的：
产品上线的进度延误，整个团队很难正常交付新版本。
产品上线后问题很多，影响用户的访问。
团队的士气很差。
最近又发生了运维团队与开发团队之间的配合不好的问题，影响及原因如下：
新产品上线延误了两个星期，正常情况下一天就可以上线。原因是开发考虑不周，测试环境中没有发现，到上线前才发现部署到多台机器上后，按开发原先计划的方式多台机器无法协作完成任务。还有就是在设计阶段没有考虑生产环境的状况，在上线的过程中需要做出对应的代码调整。
上线后质量不稳定，出现多次紧急修复。原因同上。
临时增加硬件投入。新产品中有个组件采用全新的技术方案，跟原来的LAMP体系不兼容，所以需要新增机器，单独部署。
除低了服务可用性标准，并产生了遗留问题。因为临时需要增加硬件，而恰好又只有一台，这样就形成了单点，如果该机器出现故障，服务将全部中断。另外，由于开发前设计上考虑不周，跟别的组件集成时产生别的单点。所以这些降低了服务的可用性，以后还得想办法解决。除此之外，组件采有新的软件，安装、服务起停以及软件配置的管理都是纯手工打造，以后还得找时间纳入到自动配置管理中。
影响了团队士气。在上线过程中开发、测试和运维都觉得不舒服，相互之间产生了抱怨。如果不处理好，会影响以后的配合。
虽然，有些问题确实需要靠某些团队提高自身的人员技能才能解决好，但这些团队能够形成一股合力的话，同样的人员组合肯定会产生更好的效果。
三、过去解决团队配合问题的方法
第一次碰到团队之间的配合问题时，我们还没来得及解决的时候，公司战略调整，整个开发和系统运营团队转给了另一个大部门。但我们在别的地方重新梳理技术团队时，后来又没有出现这种问题，回想起来，我们的做法是：
部分开发人员有生产环境中服务器的帐号，可以观察代码的运转情况，少数核心开发人员还有sudo权限，当然他们也不会随便修改服务器的设置
开发时一开始就会跟系统运维团队沟通，在代码中增加数据收集的接口和监控接口，这样上线后，很容易收集产品的性能数据，并能方便地对运行状态进行监控与报警
生产环境中也有沙箱与beta环境，这样大的版本从测试中过渡到生产环境前，先在沙箱环境中适应一段时间，这样能相对平稳过渡到生产环境
部分开发人员临时转到系统运维团队工作一到二个季度，跟系统运维同事一起上线产品，解决产品在运行中发生的问题，这样更好地了解代码如何在生产环境中运行，回去之后能更好地运维同事沟通，开发出来的代码更容易在生产环境中运行
这样，不同团队之间虽然有职责上的明确分工，但在中间的配合的部分做了不少柔性处理。另外，开发、运维与测试等团队中的核心人员之间本身就有认同感，大家一开始的目标就是奔着公司能成功来的，这是没有出配合问题的根本原因。这一点其实跟DevOps的核心点类似，既然如此，何不重新审视一下DevOps，并参考着解决团队之间的配合问题呢。
四、DevOps
DevOps是2010年从欧洲传过来的概念，最先是由一群有着跨学科技能的工程师提出来的，为了解决下面的问题：
推出新功能和解决老问题的周期过长
新产品或新版本上线充满风险，代码能否在生产环境中稳定运行，没有人有信心，只能艰难地推上去，再看是不是有问题
不同团队相互隔离，配合差。如开发人员收到问题后，第一反应是&在我的机器上工作得好好的呀&
我认为DevOps的核心是不管你是开发者、测试人员、管理者、DBA、网络工程师还是系统管理员，大家都是一起的，只有一起努力给客户提供稳定而高质量的软件服务，实现公司的商业利益才会有别的，包括自己的工作机会。
所以，DevOps实际是给各个团队之间搭桥，让他们不仅仅是依靠上线申请单这样的鸿雁传书工具进行沟通，而且经常离开自己的孤岛，走到别人的岛上去，了解别人，并提供自己的想法，帮助对方。
DevOps更象是一种运动，每家公司都需要根椐自身的特点进行借鉴，推动团队之间的协作与合作。需要在三个方面努力：
一方面对现有人员进行培训，鼓励他们了解别的团队的工作、面临的挑战等，让他们用自己的特长去审视和帮助别的团队，另一方面也想办法招一些全面的技术人才，在不同团队之间搭出一些适用的桥来。
在研发的前期，让系统运维同事参与起来，一起搭建测试环境，验证想法，或者也可以在一些项目团队中直接配有系统、开发和测试以及产品人员，一起为产品的上线努力。出现问题的时候，一起想方法找到问题的真正根源，避免相互推托，将解决方案落实在以后的研发过程中。从绩效考核流程上也需要考虑协作因素。
说实在的，大家针对DevOps在工具方面其实讨论得更多，这里面跟敏捷有些类似之处。快速的系统部署和自动化产品代码发布方面的工具显得尤为重要了。
为了避免校弯过正，走向另一个极端，也需要避免下面的对DevOps的常见误解：
DevOps意味着要给开发者root权限
可以给开发者加sudo权限，运行指定的命令，比如重启web服务。让开发者更多地了解生产环境和产品的运行状况，但并不意味着让开发者象管理员一样的去管理机器。
所有系统管理员需要写代码，所有开发者需要上架机器
在系统管理和开发者各个领域仍然需要各自的专家，如存储、网络、安装、javascript等专门的人才，DevOps并不意味着让大家不做自己专长的事情。
你一定要用某个工具，不然就不是DevOps
一些技术和自动化的工具对推动各个团队之间协作很有帮助，但是还是需要聚焦于要解决的问题，根椐问题和组织的特点选择合适的工具。
我们需要招聘DevOps
DevOps不是一个新的岗位
五、结合DevOps，解决团队配合问题
管理人员关注团队之间的沟通机制及氛围：
以新版能在生产环境中可靠稳定运行为目标，形成协作的氛围。
在项目的早期，立项之间，运维、开发与测试就进行沟通，可能的话坐在一起，面对面沟通。
在项目上线前，除了测试功能，还要关注部署、备份、监控、安全以及配置管理，在早期发现的问题越多，越能尽少后期的问题并避免影响用户体验。
建立各个团队的核心成员定期沟通机制。
团队之间的协作纳入绩效考核过程中去。
让开发人员了解运维工作、关注点及挑战，并从开发视角帮助运维：
开发人员参与运维团队的内部培训，了解线上的系统。
了解运维如何定位并解决故障、如何监控系统的运转情况等。
少数开发人员可以跟运维一样发版本到生产环境中，让开发人员关注并了解自己代码的运行情况。
从运维的视角修改代码，方便运维人员进行日常的变更与调整，监控与报警。
帮助运维人员修改puppet配置模板。
帮助运维人员编写与修改产品的发布脚本，提高自动化水平。
让运维人员了解开发过程的关注点及挑战，并从运维角度改善开发过程：
运维为开发在公司搭建基于虚拟机的测试环境，虚拟机的安装、配置管理以及代码的发布采用跟生产环境一样的方式。
开发人员与测试人员象运维一样发布版本到测试环境中。
鼓励开发与测试人员修改puppet配置与模板，管理自己的虚拟机。
在生产环境中建立了beta环境，开发人员可以直接发版本上去，让代码在最终上线前多一层缓冲。
运维去了解代码的模块结构，从运维的角度修改代码，让产品上线后更方便运维与适应生产环境的特点。
运维参与到持续的集成测试中，用自己的自动化知识帮助实现自动的集成测试等。
【编辑推荐】
【责任编辑： TEL：（010）】
关于的更多文章
转眼十一月份了，天气逐渐变冷了。又到了起床靠毅力，洗澡靠勇气
北京时间10月18日，Ubuntu 13.10（代号为Saucy Salama
回顾PC漫长的发展史，如果让你想一个关键词，我相信很
日晚7点整，微软公司如约发布了Windows 8
本书是作者深入研究SQL Server 2005数据库体系结构和内部机制的经验总结。
全书不拘泥于具体的管理操作，而是通过对存储的数据
51CTO旗下网站酷勤网 C 程序员的那点事！
当前位置： >
浏览次数：次
【编者按】本文是 Gene Kim 总结自对 Randy Shoup 两个小时的采访，主要关注谷歌 DevOps 的提升之道。本文系联合高效运维编译整理。
Randy Shoup 曾协助领导 eBay 和 Google 的工程师团队，他是笔者见过少数能将「建造高效产出 DevOps 与世界级可靠性系统需要怎样领导特质」描述清楚的人之一。其两个演讲（2013 Flowcon 演讲、2000s 早期他在转化 eBay 架构时惊人的工作）深受笔者喜爱。
本文由 Gene Kim 根据对 Randy Shoup 的采访整理，深入讨论和讲解谷歌 DevOps 的提升之道，下面一起深入了解。本文系联合高效运维编译整理。
Dr. Spear的模型有如下四大能力：
能力1：在问题发生时马上就能发现；
能力2：一旦发现问题立刻集群式解决（Swarming），并将此记录下来储备成新知识；
能力3：在整个公司范围内传播新知；
能力4：以开发为主导。
这也是采访 Randy Shoup 的基础，此次采访还揭示了一些在谷歌与 eBay 中未曾广泛讨论过的实践案例。
（笔者从 Randy Shoup 那里学到了太多东西，难以言喻。如果想了解更多信息，并用于公司实践的话，不妨通过的个人主页联系他，他目前正从事咨询工作）。
能力1：在问题发生时立刻就能发现
Dr. Spear 写道：
高速率的公司会针对已有知识库制定详细规则和设计捕获问题，并使用内置测试以发现问题。 无论个体还是团队工作，无论是否有设备，高速率公司不愿意接受模棱两可。他们提前对以下内容进行详细说明： （a）预期产出；（b）谁负责什么工作，顺序如何；（c）产品、服务与信息如何从上一步的负责人手上递交到下一步的负责人手中；（d）完成每一部分工作的方法。
GK（作者）：在 DevOps 领域，谷歌应该是典范之一，特别是在自动化测试领域。
Google SCM 团队 Eran Messeri 在2013年的 GOTOcon Aarhus 大会的某环节上表示：「在成千上万名工程师分享同一个持续构建时，出现了什么问题？」（演讲笔记可以查看）
他列出了一些值得注意的统计资料（截止到2013年），并介绍了他们是如何创建在能力范围内最迅速、最及时且成本最低的反馈机制：
1.5万程序员（包括开发与运维）
4000个同时进行的项目
在同一个库里 check 所有的源代码（数十亿文件！）
5500次代码提交 via 1.5万程序员
自动测试日运行7500万次
0.5%的工程师致力于开发工具
这里有一份，在这里你可以查看到更多关于 Google 开发团队所实现的惊人数字。
Q：谷歌可能是自动化测试的典范了，大家都想更多地了解你在那里的工作经验。
A：的确如此，谷歌做了大量的自动化测试&&超过我工作过的其他所有典范。「一切」都需要测试&&不仅要测试 getter/setter 功能，还要测试一切可能出问题的地方。
对所有人来说，设计测试通常是极具挑战的。也不会有人花时间去写测试来检查自己认为会正常运作的功能，相反通常是去测试那些可能出错的、有难度的地方。
实际中，这代表着团队需要进行可靠性测试。通常希望单独测试某个组件，其他部分使用模拟组件，从而在一个半真实的世界中测试自己的组件，但更重要地是可以在模拟测试中注入故障（inject failures）。
这样一来通过不断地进行测试，可以找出组件不运作的地方。在每天实际进行的测试中，也许有百万分之一、千万分之一的几率这些组件运行不了（比如，服务器有两个副本宕机了；在准备与提交阶段之间有什么东西出错了；或者大半夜整个服务器宕掉了）。
所有这些都令促使需要在日常工作中构建恢复性测试，并一直运行这些测试，工作量巨大。
Q：谷歌现有的自动测试规则是怎么来的？
A：我不知道谷歌公司的相关规则是怎么演化出来的，我去的时候就已经有了。确实十分惊人，这个大规模分布式系统中的所有组件都用这些复杂的方法持续不断地测试。
作为新人，我并不想写出些没经过足够测试的蹩脚玩意儿。作为负责人，我特别想给团队树立一个坏榜样。
下面是个具体案例，展示了一些这样团队的优点。大家在著名的论文中可能都读到过（Google File System，BigTable，Megastore 等等），常见的谷歌基础设施服务是各个团队独立运作的&&通常是一个令人惊讶的小团队。
他们不仅要编写代码，还要负责运营。等这些组件成熟了，他们不仅要向使用者提供相应服务，还得为他们提供客户端文件库，使得服务更加便捷。使用现有的客户端文件库，他们可以为客户端测试模拟后台服务，并注入各种失败场景。比如：你可以使用 BigTable 生产程序库，再加上一个模拟器，就会跟实际生产平台的表现一样。你想在写入与 ack 阶段注入失败？直接做就成了！
我怀疑这些原则和实践是来自「艰苦的磨练」，从那些你一直问「怎么避免停机」这样的紧急情况中磨练出来的。
随着时间过去，最终规则被完善，得到了一个坚挺的架构。
能力2：一发现问题集群式解决，并记录下来，成为新知识。
Dr. Spear 写道：
「高速率公司擅长在系统里第一时间发现问题并找到问题。他们同样擅长：（1）在问题扩散之前找到它（2）找出并解决发生问题的原因，让问题不再发生。这样一来，他们在如何管理解决实际工作问题系统方面构建了更深层次的知识，将前期难以避免的疏漏转化为知识。」
GK：在我的研究中，最令人惊讶的集群式解决问题的例子有两个：
A：丰田的 Andon 拉绳，负责在工作偏离已知模式时让它停下。有记录，一个典型的丰田工厂，平均一天需要拉下 Andon 拉绳3500次。
Alcoa 的 CEO，受人尊敬的 Paul O&Neill，为了降低工作场所事故发生，制定了相关政策：任何在工作场所发生的事故必须在24小时内通知他。谁需要负责报告？业务部门总经理。
Q：谷歌的远程文化与那些支持集群行为（Swarming Behaviors）的文化类似吗，比如丰田安灯拉绳与 AlcoaCEO 对工作场所事故的向他通知的要求？
A：完全一致，两者都能引起我的共鸣。在 Ebay 和谷歌，都有事后剖析免责文化（blame-free PostMortems）。（GK：John Allspaw 又称它为 blameless post-mortem。）
事后剖析免责是一条非常重要的规定，只要有一个客户受停机影响，我们都会举行一个事后剖析会。就像 John Allspaw 还有其他人广泛描述的那样，事后剖析的目标并不是为了追责，而是创造学习的机会和跨公司的广泛交流。
我发现，如果公司文化中事后剖析不会引发什么后果会产生惊人的动力：工程师互相攀比，看谁捅出过更大的娄子。比如：「嗨，我们发现从没测过的备份恢复程序」，或者「然后我们发现，我们没有主动复制。」也许对很多工程师来说，这一幕十分熟悉：「我希望没停过机，不过现在我们终于有机会修复那个已经被抱怨了好几个月的破系统了！」
这将产生大规模的公司性学习，并且正如 Dr. Steven Spear 所描述的：这样的做法使得我们在灾难性后果发生之前可以不断找到并解决问题。
我认为其有效原因在于，我们内心里都是工程师，都喜欢建立并改善系统，而让问题暴露出来的环境造就了激动人心和令人满意的工作环境。
问：事后剖析产生了什么结果？不能仅仅写成文档，然后丢进垃圾桶，对不对？
Q：你可能觉得难以置信，但是我相信最重要的部分就是组织事后剖析会本身。我们知道，中最为重要的部分就是文化，能组织会议，即便没有产出，都能对系统有所提高。
A：它会成为一种 kata&&成为我们日常规定的一部分，证明我们的价值以及如何区分工作优先级。
当然，事后剖析之后，几乎都是列出一大堆清单，写着正常运转和出故障的内容，然后你就有了一张待办事项，需要安插到工作队列中去（比如：backlog&&所需功能列表；增强功能&&改进文档等。）
当你发现需要做新改进时，最终得在什么地方做些修改。有时候是文档、流程、代码、环境或者其他什么。
不过即便没有这些，只是单纯的记录下事后剖析文档也会有巨大的价值，你可以想象一下，在谷歌，什么都搜得到，所有谷歌人都能看到每一个事后剖析文档。
将来在类似事故发生时，事后剖析文档永远是第一个会被读到的。
有趣的是，事后剖析文档还起到一个作用。谷歌有一个长期传统，所有的新服务需要开发人员自行管理至少六个月。服务团队在要求「毕业」时（也就是需要一个专门的 SRE 团队，或者运营工程师来维护），他们基本上都会与 SRE 协商。他们请求 SRE 接管应用提交的相关职责。
（Gene：点击查看视频，Tom Limoncelli 将其称为的流程，SRE 会进行审查文档、部署机制、监控概况等等工作。视频非常棒！） SRE 往往首先会检查事后剖析文档，这一步占很大比重，决定他们是否能让一个应用「毕业」。
Q：你在谷歌有看到过类似 Paul O&neill 和他的团队在 Alcoa 那样的要求吗？是否有通知/升级门槛怎样不断减少的例子？
A：GK：Dr. Spear 描述了 Paul O&Neill 在美铝公司如何带领团队减少制铝厂车间的受伤情况的（太惊人了，里面都是高热、高压与腐蚀性的化学制剂），将事故率从每年2%降低到0.07%，使公司成为行业内最安全的公司。令人惊讶的是，在车间事故率降低到一定数值时，O&Neill 让员工在可能有差错发生时通知他。
确实有。当然，在工作场地发生事故相当于我们影响到用户的停机事件。相信我，在出现影响客户的大故障时，他们会收到通知。在事故发生时，会发生两件事情：
你需要动员一切恢复服务所需的人员，他们要持续工作，直接问题解决（当然，这是标准流程）。
我们也会举行管理层的每周事故会议（在我的 App Engine 团队里，需要出席的有工程技术部主管&&共两人，我是其中之一；我们的老板、我们团队的领导、还有支持团队和产品经理）。我们回顾在事后剖析会中所学的东西，检查下一步所需行动，并确认已经妥当的解决了问题。如果必要的话，决定我们是否需要做一个面向客户的事后剖析或者发个博客。
有时候我们没什么要说的。不过一旦情况处于控制之下，团队总是希望同级审查时出现的问题更少，并且更希望提高。 比如一个「不会影响客户」的问题，我们会将它称为「影响团队」的问题。
大多数人都体验过「差点出事」（near misses），布置了六重保护措施，全都是为了防止用户受失败影响所设置，结果全挂了，就剩一个能用。
在我的团队里（Google App Engine），我们可能每年会有一个大众都知道的影响用户的停机事件，不过想当然，每一个这样的情况背后都有几个「差点出事」。
这就是我们为什么会有灾难性恢复（Disaster Recovery），Kripa Krishnan 曾在这里讨论过。
尽管谷歌做得不错，我们学到了很多（这就是为什么我们要有三个生产备份），这里亚马逊做得要更好，他们的工作比其他人要提前五年。（Jason McHugh 是亚马逊 S3 的架构师，现在去了 Facebook，他做了这个演讲，主题是亚马逊的故障管理。）
Q：在美铝公司，工作场地事故需要在24小时之内报告给 CEO。在谷歌是否有类似的向上升级（即问题升级到领导层）的时间线？
A：在 Google App Engine，我们有很小的团队（全球100个工程师），里面只有两级：做事的工程师和管理者。在发生了影响客户的事故时，我们曾在午夜把大家叫醒。每一个这样的事故，有十分之一会升级到公司领导层。
Q：你对Swarming如何发生怎么描述？
A：像丰田工厂，并非出现所有问题时都能确保人人到位解决问题。但在文化上，我们的确会优先考虑优先级为0的那些问题的可靠性和质量。
在很多方面都有这种情况，其中一些不算太明显，比停机要微妙一些。
在你检查打断测试的代码时，在修复之不会有其他工作，也不会发现还有打断更多测试的问题急待解决。
与此相似，如果有人也出现了类似的问题需要帮助时，也会希望你放下一切提供帮助。为什么呢？这是我们安排优先度的方式&&就像「黄金法则」。我们希望帮助每个人推动工作，从而也帮助到了所有人。
当然，在你需要帮助时他们也会这样对你。
从系统的角度来看，我认为它就像棘齿或者过山车的中间齿轮&&让我们不会滑下去。
这不是流程中的正式规则，不过每个人都知道，如果有类似影响用户的明显不正常操作出现，我们会发出警报，发一些邮件等等。
信息通常是「嗨，大家好，我需要你们的帮助」，然后我们就去帮忙啦。
我认为它总是奏效的原因在于，即便没有正式说明或列出规则，大家都知道我们的工作不只是「写代码」，而是「运行服务」。
甚至全球性的依赖（比如负载均衡器、全球基础架构配置错误）都能在几秒内修复，事故会在5到10分钟内解决。
能力3：在整个公司里传播新知识。
Dr. Spear 写道：
高速率公司通过在全公司内部（不仅是发现者）传播知识，增加新知识的习得率。他们不仅分享问题的结论，还分享发现问题的流程&&学到了什么，怎么学到的。尽管在大一些的系统中，他们的竞争对手在发现问题后仍然让问题留在发现的地方，与解决方案放在一起，但在高速率公司中，负责者会将问题与发现进行全公司的传播。也就是说人们在开始工作时，会吸收公司里其他人的经验。我们会看到乘数效应的几个案例。
Q：问题发生时，知识如何传播？局部的发现如何转化为全球性质的进步？
A：其中一部分，尽管不是最大的那部分，是来自事后剖析会的文档。有这样的迹象：谷歌与其他公司一样频繁出现事故。在谷歌一旦有引人注目的停机事件，你可以肯定几乎公司里每个人都会读到事后剖析报告。
也许预防未来故障的最强大机制就是全谷歌共同拥有的单一代码库。不过更重要的是，由于可以搜索整个代码库，利用别人的经验就很简单。不管文件多正式多有一致性，更好的办法就是看看实践中人们的做法&&「去看看代码」。
但是，也有消极的一面。一般来说，使用服务的第一个人可能会使用随机的配置，然后在公司里疯狂传播。突然间毫无理由，像「37」这样的随意设置传的到处都是。
只要你让知识变得容易传播又容易获得，它就会到处传播，并很有可能出现一些最优设置。
Q：除了单一的源代码库和无责的事后剖析，还有什么其他的机制可以从局部学习转化为全局改进吗？知识传播还有什么办法？
A：在谷歌源代码库中，最棒的事情之一就是你什么都能找到。所有问题最好的回答就是「看看代码」。
其次，还有只要搜索就能找到的优秀文档。还有极好的内部小组。就像任何外部服务一样，写个「foo」就能列出一个叫做「foo-user」的邮件列表。你向列表中的人问个问题。联络到开发者当然很好，不过大部分情况下会是用户给出回答。顺带一提，就像本行业大量成功的开源项目。
能力4：以开发为主导。
Dr. Spear 写道：
高速率公司的管理者确认：常规工作的一部分就是发布产品和服务，以及持续改进产品与服务发布的流程。他们教人们如何持续改进自己的那部分工作，并为他们提供充足的时间与资源。这样一来，公司在可靠性与高适应性方面都能够自我改进。这是他们与失败的竞争对手最根本的不同。高速率公司的管理者并不负责通过一系列指标来命令、控制、斥责、威胁或者评估别人，而是确保公司在以下方面有所提高：自诊与自我改进、发现问题的技巧、解决问题、通过全公司传播解决方案来提高效率。
GK：我也很喜欢 David Marquet 的名言（《Turn This Ship Around》的作者）：「真正的领导人的标志就是在他/她之下还有多少领导者。」这位潜艇前指挥官比历史上任何潜艇舰长带出过的领导者更多。
他工作的要点是：一些领导者解决了问题，但一旦他们离开，问题又重新出现了，这是因为他们没能让系统在离开自己的情况下继续正常运转。
Q：谷歌的领导层是怎么发展的？
A：谷歌已经实践了你能在任何一家健康运作公司中能找到的几乎所有办法。我们有两类职业道路：工程师道路与管理者道路。任何一个在职位上有「管理者」字样的人主要负责「让事情成为可能」，并鼓励他人进行领导。
我将自己的职责视为创造每个人都很重要的小团队。每个团队都是一个交响乐团，与工厂截然相反&&每个人都能独奏，但是更重要的是，他们都能彼此合作。我们都有过那样的糟糕体验：团队成员冲着彼此吼叫，或者谁也不听对方的。
在谷歌，我认为领导者最强大的影响在于我们打造重要工程项目的文化愿景。大的文化规范之一，「每个人都写很棒的测试；我们不想成为一个写蹩脚测试的团队。」同样，有这样的文化「我们只雇参与者」&&对我在情感上也很重要。
在谷歌，在评估与改进过程中一些这样的东西被写进法典&&听起来很糟糕，因为那意味着，我们只管做好提升所需的那一份工作。但是另一方面，评估过程赞誉很高，几乎公认是可观的&&人们获得提升知识因为他们作出了相应的贡献，并且很擅长他们所做的工作。我从未听过谁升职是因为他们「抱对了大腿，拍对了马屁」。
管理者和主管职位的主要标准就是领导力&&也就是说，那个人是否作出了重大的影响，他的影响是否远超你工作的团队以及某个「只做自己事情的人」。
Google App Engine服务是在7年前成立的，在集群管理组中有着一群令人惊讶的工程师，他们认为「嗨，我们拥有这些创造可扩展系统的技术。是不是可以编一个，让别人也能使用呢？」
「App Engine 创建工程师」的头衔被授予给那些倍受内部员工尊重的人，比如 Facebook 的创建者。
Q：新任管理者如何做事？如果领导者必须培养其他领导人，新任管理者或者一线管理者如何了解工作减轻的风险？
A：在谷歌，你只会得到「你已经在做」的那份工作，这与其他大多数公司都不相同，在别的公司都是做「希望你能做的工作」。
也就是说，如果你想要成为首席工程师，那么就做首席工程师的工作。在谷歌，就像很多大公司一样，有很多的培训资源。
但在大多情况下，如何完成工作的文化规范影响太大，可能确保文化规范延续就成了首要趋势。就像是一个自我选择的过程，增强文化规范与技术实践。
当然，这也跟公司高层的风格有关。谷歌是两个怪咖工程师创建的公司，在高层风格的影响下，这种文化也在不断增强。
如果你在一个命令与控制型的公司里，公司的领导者讨厌别人，那么这种不良信息也会传递并在公司里强化。
再次重申，我从 Randy Shoup 那里学到的太多了，难以言喻。如果你对此有兴趣，想要了解更多并用于公司实践的话，不妨直接通过 LinkedIn 询问 Randy，他目前从事咨询工作。访问以获得更多联系方式。
& 相关主题：