DevOps四大能力模型与Google实践（下）

前言

Randy Shoup 曾协助领导 eBay 和 Google 的工程师团队，他是少数能将「建造高效产出 DevOps 与世界级可靠性系统需要怎样领导特质」描述清楚的人之一：

本文由 Gene Kim 根据对 Randy Shoup 的采访整理，深入讨论和讲解谷歌 DevOps 的提升之道，下面一起深入了解。本文系 OneAPM 联合高效运维社区编译整理。

Dr. Spear的模型有如下四大能力：

• 能力1：在问题发生时马上就能发现；

• 能力2：一旦发现问题立刻集群式解决（Swarming），并将此记录下来储备成新知识；

• 能力3：在整个公司范围内传播新知；

• 能力4：以开发为主导。

这也是采访 Randy Shoup 的基础，此次采访还揭示了一些在谷歌与 eBay 中未曾广泛讨论过的实践案例。

本文主要介绍其中的能力3和能力4，关于其他两大能力，请详见下文：DevOps四大能力模型与Google实践（上）

能力3：在整个公司里传播新知识。

Dr. Spear 写道：

高效率公司通过在全公司内部（不仅是发现者）传播知识，增加新知识的产出效果。他们不仅分享问题的结论，还分享发现问题的流程——学到了什么，怎么学到的。

尽管在大一些的系统中，他们的竞争对手在发现问题后，仍然让问题留在发现的地方，与解决方案放在一起。

但在高效率公司中，负责者会将发现的问题，在全公司进行传播。

也就是说人们在开始工作时，会吸收公司里其他人的经验。这样，我们会看到乘数效应的几个案例。

Q：问题发生时，知识如何传播？局部的发现如何转化为全球性质的进步？

其中一部分，尽管不是最大的那部分，是来自事后剖析会的文档。有这样的迹象：谷歌与其他公司一样频繁出现事故。在谷歌一旦有引人注目的停机事件，你可以肯定几乎公司里每个人都会读到事后剖析报告。

也许预防未来故障的最强大机制就是：全谷歌共同拥有的单一代码库。

不过更重要的是，由于可以搜索整个代码库，利用别人的经验就很简单。不管文件多正式多有一致性，更好的办法就是看看实践中人们的做法——「去看看代码」。

但是，也有消极的一面。一般来说，使用服务的第一个人可能会使用随机的配置，然后在公司里疯狂传播。突然间毫无理由，像「37」这样的随意设置传的到处都是。

只要你让知识变得容易传播又容易获得，它就会到处传播，并很有可能出现一些最优设置。

Q：除了单一的源代码库和无责的事后剖析，还有什么其他的机制可以从局部学习转化为全局改进吗？知识传播还有什么办法？

在谷歌源代码库中，最棒的事情之一就是你什么都能找到。所有问题最好的回答就是「看看代码」。

其次，还有只要搜索就能找到的优秀文档。

还有极好的内部小组。就像任何外部服务一样，写个「foo」就能列出一个叫做「foo-user」的邮件列表，然后你就可以向列表中的人问个问题。联络到开发者当然很好，不过大部分情况下会是用户给出回答。

顺带一提，这种做法，类似本行业大量成功的开源项目。

能力4：以开发为主导。

Dr. Spear 写道：

高效率公司的管理者确认：常规工作的一部分就是发布产品和服务，以及持续改进产品与服务发布的流程。他们教人们如何持续改进自己的那部分工作，并为他们提供充足的时间与资源。这样一来，公司在可靠性与高适应性方面都能够自我改进。

这是他们与失败的竞争对手最根本的不同。

高效率公司的管理者，并不负责通过一系列指标来命令、控制、斥责、威胁或者评估别人，而是确保公司在以下方面有所提高：自诊与自我改进、发现问题的技巧、解决问题、通过全公司传播解决方案来提高效率。

David Marquet 的名言（《Turn This Ship Around》的作者）：「真正的领导人的标志就是在他/她之下还有多少领导者。」这位潜艇前指挥官比历史上任何潜艇舰长带出过的领导者更多。

他要解决的主要问题是：一些领导者解决了问题，但一旦他们离开，问题又重新出现了。这是因为他们没能让系统在离开自己的情况下，继续正常运转。

Q：谷歌的领导层是怎么发展的？

谷歌已经实践了你能在任何一家健康运作公司中能找到的几乎所有办法。我们有两类职业道路：工程师道路与管理者道路。任何一个在职位上有「管理者」字样的人主要负责「让事情成为可能」，并鼓励他人进行领导。

我将自己的职责视为创造每个人都很重要的小团队。

每个团队都是一个交响乐团，与工厂截然相反：每个人都能独奏，但是更重要的是，他们都能彼此合作。我们都有过那样的糟糕体验：团队成员冲着彼此吼叫，或者谁也不听对方的。

在谷歌，我认为领导者最强大的影响在于，我们打造重要工程项目的文化愿景。大的文化规范之一，「每个人都写很棒的测试；我们不想成为一个写蹩脚测试的团队。」同样，有这样的文化「我们只雇参与者」——对我在情感上也很重要。

在谷歌，在评估与改进过程中，一些这样的东西被写进法典。这听起来很糟糕，因为那意味着，我们只管做好提升所需的那一份工作。

但是另一方面，评估过程赞誉很高，几乎公认是可观的：人们获得提升知识，因为他们作出了相应的贡献，并且很擅长他们所做的工作。我从未听过谁升职是因为他们「抱对了大腿，拍对了马屁」。

管理者和主管职位的主要标准就是领导力：也就是说，那个人是否作出了重大的影响，他的影响是否远超你工作的团队以及某个「只做自己事情的人」。

Google App Engine 服务是在7年前成立的，在集群管理组中有着一群令人惊讶的工程师，他们认为「嗨，我们拥有这些创造可扩展系统的技术。是不是可以编一个，让别人也能使用呢？」

「App Engine 创建工程师」的头衔被授予给那些倍受内部员工尊重的人，比如 Facebook 的创建者。

Q：新任管理者如何做事？如果领导者必须培养其他领导人，新任管理者或者一线管理者如何了解工作减轻的风险？

在谷歌，你只会得到「你已经在做」的那份工作，这与其他大多数公司都不相同，在别的公司都是做「希望你能做的工作」。

也就是说，如果你想要成为首席工程师，那么就做首席工程师的工作。在谷歌，就像很多大公司一样，有很多的培训资源。

但在大多情况下，如何完成工作的文化规范影响太大，可能确保文化规范延续就成了首要趋势。就像是一个自我选择的过程，增强文化规范与技术实践。

当然，这也跟公司高层的风格有关。谷歌是两个怪咖工程师创建的公司，在高层风格的影响下，这种文化也在不断增强。

如果你在一个命令与控制型的公司里，公司的领导者讨厌别人，那么这种不良信息也会传递并在公司里强化。

结论

再次重申，我从 Randy Shoup 那里学到的太多了，难以言喻。如果你对此有兴趣，想要了解更多并用于公司实践的话，不妨直接通过 LinkedIn 询问 Randy，他目前从事咨询工作。

关于其他两大能力，详见下文：

近期好文：

没看过瘾？

来 DevOpsDays 上海站吧！

来自 Google 的资深技术专家刘靖将带来精彩演讲

《 DevOps practice on Google Cloud Platform 》