解谜谷歌 DevOps：什么特质可以打造世界级可靠系统？
【编者按】本文是 Gene Kim 总结自对 Randy Shoup 两个小时的采访，主要关注谷歌 DevOps 的提升之道。本文系 OneAPM 联合高效运维编译整理。
Randy Shoup 曾协助领导 eBay 和 Google 的工程师团队，他是笔者见过少数能将「建造高效产出 DevOps 与世界级可靠性系统需要怎样领导特质」描述清楚的人之一。其两个演讲（2013 Flowcon 演讲、2000s 早期他在转化 eBay 架构时惊人的工作）深受笔者喜爱。
本文由 Gene Kim 根据对 Randy Shoup 的采访整理，深入讨论和讲解谷歌 DevOps 的提升之道，下面一起深入了解。本文系 OneAPM 联合高效运维编译整理。
Dr. Spear的模型有如下四大能力：
- 能力1：在问题发生时马上就能发现；
- 能力2：一旦发现问题立刻集群式解决（Swarming），并将此记录下来储备成新知识；
- 能力3：在整个公司范围内传播新知；
- 能力4：以开发为主导。
这也是采访 Randy Shoup 的基础，此次采访还揭示了一些在谷歌与 eBay 中未曾广泛讨论过的实践案例。
（笔者从 Randy Shoup 那里学到了太多东西，难以言喻。如果想了解更多信息，并用于公司实践的话，不妨通过 Randy LinkedIn 的个人主页联系他，他目前正从事咨询工作）。
能力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%的工程师致力于开发工具
这里有一份2010年 Ashish Kumar 做的 QConSF PPT，在这里你可以查看到更多关于 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：你可能觉得难以置信，但是我相信最重要的部分就是组织事后剖析会本身。我们知道，DevOps 中最为重要的部分就是文化，能组织会议，即便没有产出，都能对系统有所提高。
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，他做了这个演讲 QCon 2009，主题是亚马逊的故障管理。）
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，他目前从事咨询工作。访问 Randy 的 LinkIn 页面以获得更多联系方式。
原文链接：Uncovering The DevOps Improvement Principles At Google (Randy Shoup Interview)
本文系 OneAPM 工程师编译整理。OneAPM 是应用性能管理领域的新兴领军企业，能帮助企业用户和开发者轻松实现：缓慢的程序代码和 SQL 语句的实时抓取。想阅读更多技术文章，请访问 OneAPM 官方博客。
