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

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

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

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

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

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

本文主要介绍其中的能力1和能力2，关于其他两大能力，请详见后续文章。

能力1：在问题发生时立刻就能发现

Dr. Spear 写道：

高效率公司会针对已有知识库，制定详细规则并设计捕获问题的方法，使用内置测试以发现问题。

无论个体还是团队工作，无论是否有设备，高效率公司不愿意接受模棱两可。他们提前对以下内容进行详细说明：

·         预期产出；

·         谁负责什么工作，顺序如何；

·         产品、服务与信息如何从上一步的负责人手上，递交到下一步的负责人手中；

·         完成每一部分工作的方法。

在 DevOps 领域，特别是在自动化测试领域，Google 应该是典范之一。我们看看Google 面临的挑战（数据截止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 等等），常见的谷歌基础设施服务是各个团队独立运作的，而且通常是一个令人惊讶的小团队：

1.    他们不仅要编写代码，还要负责运营。

2.    等这些组件成熟了，他们不仅要向使用者提供相应服务，还得为他们提供客户端文件库，使得服务更加便捷。使用现有的客户端文件库，他们可以为客户端测试模拟后台服务，并注入各种失败场景，比如：

你可以使用 BigTable 生产程序库，再加上一个模拟器，就会跟实际生产平台的表现一样。你想在写入和ACK 阶段注入失败场景？直接做就成了！

我怀疑这些原则和实践是来自”艰苦的磨练”，从那些你一直问”怎么避免停机”这样的紧急情况中磨练出来的。

随着时间过去，最终规则被完善，得到了一个坚挺的架构。

能力2：一发现问题集群式解决，并记录下来，成为新知识。

Dr. Spear 写道：高效率公司擅长在系统里第一时间发现问题并找到问题。他们同样擅长：

1.    在问题扩散之前找到它；

2.    找出并解决发生问题的原因，让问题不再发生。

这样一来，他们在如何管理解决实际工作问题系统方面，构建了更深层次的知识，将前期难以避免的疏漏转化为知识。

在GK（本文原作者）的研究中，最令人惊讶的集群式解决问题的例子有两个：

1.    丰田的 Andon 拉绳，负责在工作偏离已知模式时让它停下。有记录表明，一个典型的丰田工厂，平均一天需要拉下 Andon 拉绳3500 次。

2.    Alcoa CEO 为了降低工作场所事故发生，制定了相关政策：任何在工作场所发生的事故必须在24小时内通知他。谁需要负责报告？业务部门总经理。

Q：谷歌的远程文化与那些支持集群行为（Swarming Behaviors）的文化类似吗，比如丰田安灯拉绳与 Alcoa CEO 对工作场所事故的向他通知的要求？

完全一致，两者都能引起我的共鸣。

在 Ebay 和谷歌，都有事后剖析免责文化（blame-free PostMortems，或称 blameless post-mortem）。

事后剖析免责是一条非常重要的规定，只要有一个客户受停机影响，我们都会举行一个事后剖析会议。

就像 John Allspaw 和其它人员广泛描述的那样，事后剖析的目标并不是为了追责，而是创造学习的机会和跨公司的广泛交流。

我发现，如果公司文化中事后剖析不会引发什么责任性后果，那么会产生惊人的动力，工程师互相“攀比”，看谁捅出过更大的娄子。比如：

「嗨，我们发现从没测过的备份恢复程序」，或者「然后我们发现，我们没有主动复制。」

也许对很多工程师来说，这一幕十分熟悉：「我希望没停过机，不过现在我们终于有机会修复那个已经被抱怨了好几个月的破系统了！」

这将产生大规模的公司性学习，并且正如 Dr. Steven Spear 所描述的：这样的做法使得我们在灾难性后果发生之前，可以不断找到并解决问题。

我认为其有效原因在于，我们内心里都是工程师，都喜欢建立并改善系统，而让问题暴露出来的公司环境，造就了激动人心和令人满意的工作环境。

问：事后剖析产生了什么结果？不能仅仅写成文档，然后丢进垃圾桶，对不对？

你可能觉得难以置信，但是我相信最重要的部分就是组织事后剖析会议本身。

我们知道，DevOps 中最为重要的部分就是文化，能组织会议，即便没有产出，都能对组织有系统性的提高。

它会成为我们日常规定的一部分，并证明我们的价值以及如何区分工作优先级。

当然，事后剖析之后，几乎都是列出一大堆清单，写着正常运转和出故障的内容，然后你就有了一张待办事项，需要安插到工作队列中去（比如：backlog——所需功能列表；增强功能——改进文档等。）

当你发现需要做新改进时，最终得在某些地方做些修改：有时候是文档、流程、代码、环境或者其他什么。

不过即便没有这些，只是单纯的记录下，这种事后剖析文档也会有巨大的价值。你可以想象一下，在谷歌，什么都搜得到，所有谷歌人都能看到每一个事后剖析文档。

将来在类似事故发生时，事后剖析文档永远是第一个会被读到的。

有趣的是，事后剖析文档还起到一个作用。谷歌有一个长期传统，所有新服务需要开发人员自行管理至少六个月。

服务团队在要求「毕业」时（也就是需要一个专门的 SRE 团队，或者运营工程师来维护），他们基本上都会与 SRE 协商。他们请求 SRE 接管应用提交的相关职责（关于 Google SRE，可以参见高效运维微信公众号之前的文章—编者注）。

SRE 会进行审查文档、部署机制、监控概况等等工作。

当然，SRE 往往首先会检查事后剖析文档，这一步占很大比重，决定他们是否能让一个应用「毕业」。

Q：你在谷歌有看到过类似 Alcoa CEO 那样的要求吗？是否有通过改进措施不断减少问题的例子？

Dr. Spear 描述了 Paul O’Neill（Alcoa CEO） 在美铝公司，如何带领团队减少制铝厂车间的受伤情况的（太惊人了，里面都是高热、高压与腐蚀性的化学制剂），将事故率从每年2%降低到0.07%，使公司成为行业内最安全的公司。

令人惊讶的是，在车间事故率降低到一定数值时，O’Neill 让员工在可能有差错发生时通知他。

确实有。当然，在工作场地发生事故相当于我们影响到用户的停机事件。相信我，在出现影响客户的大故障时，他们会收到通知。在事故发生时，会发生两件事情：

1.    你需要动员一切恢复服务所需的人员，他们要持续工作，直到问题解决（当然，这是标准流程）。

2.    我们也会举行管理层的每周事故会议（在我的 App Engine 团队里，需要出席的有工程技术部主管——共两人，我是其中之一；我们的老板、我们团队的领导、还有支持团队和产品经理）。我们回顾在事后剖析会中所学的东西，检查下一步所需行动，并确认已经妥当的解决了问题。如果必要的话，决定我们是否需要做一个面向客户的事后剖析或者发个博客。

有时候我们没什么要说的。不过一旦情况处于控制之下，团队总是希望同级审查时出现的问题更少，并且更希望提高。

比如一个「不会影响客户」的问题，我们会将它称为「影响团队」的问题。

大多数人都体验过「差点出事」（near misses）的情况吧？布置了六重保护措施，全都是为了防止用户受失败影响所设置，结果全挂了，幸好还剩一个能用。

在我的团队里（Google App Engine），我们可能每年会有一个大众都知道的影响用户的停机事件。当然，每一个这样的情况背后都有几个「差点出事」。

这就是我们为什么会有灾难性恢复（Disaster Recovery）。

尽管谷歌做得不错，我们学到了很多（这就是为什么我们要有三个生产备份），我们认为亚马逊做得要更好，他们的工作比其他人要提前五年。

Q：在美铝公司，工作场地事故需要在24小时之内报告给 CEO。在谷歌是否有类似的垂直升级机制？

在 Google App Engine，我们有很小的团队（全球100个工程师），里面只有两级：做事的工程师和管理者。

在发生了影响客户的事故时，我们也曾在午夜把大家叫醒。每一个这样的事故，有十分之一会升级到公司领导层。

Q：你对Swarming（集群式解决问题的行为）如何发生怎么描述？

像丰田工厂，并非出现所有问题时都能确保人人到位解决问题。但在文化上，我们的确会优先考虑优先级为0的那些问题的可靠性和质量。

在很多方面都有这种情况，其中一些不算太明显，比停机要微妙一些。

在你检查打断测试的代码时，在修复之不会有其他工作，也不会发现还有打断更多测试的问题急待解决。

与此相似，如果有人也出现了类似的问题需要帮助时，也会希望你放下一切提供帮助。为什么呢？这是我们安排优先度的方式——就像「黄金法则」。我们希望帮助每个人推动工作，从而也帮助到了所有人。

当然，在你需要帮助时，他们也会这样对你。

从系统的角度来看，我认为它就像棘齿或者过山车的中间齿轮——让我们不会滑下去。

这不是流程中的正式规则，不过每个人都知道，如果有类似影响用户的明显不正常操作出现，我们会发出警报，发一些邮件等等。

信息通常是「嗨，大家好，我需要你们的帮助」，然后我们就去帮忙啦。

我认为它总是奏效的原因在于，即便没有正式说明或列出规则，大家都知道我们的工作不只是「写代码」，而是「运行服务」。

甚至全球性的依赖（比如负载均衡器、全球基础架构配置错误）都能在几秒内修复，事故会在5到10分钟内解决。

关于其他两大能力，我们将在下一篇继续和大家分享，就在下周，敬请期待。

（王鹏、高浩淼原创）

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

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

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

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

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

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

本文主要介绍其中的能力1和能力2，关于其他两大能力，请详见后续文章。

能力1：在问题发生时立刻就能发现

Dr. Spear 写道：

高效率公司会针对已有知识库，制定详细规则并设计捕获问题的方法，使用内置测试以发现问题。

无论个体还是团队工作，无论是否有设备，高效率公司不愿意接受模棱两可。他们提前对以下内容进行详细说明：

·         预期产出；

·         谁负责什么工作，顺序如何；

·         产品、服务与信息如何从上一步的负责人手上，递交到下一步的负责人手中；

·         完成每一部分工作的方法。

在 DevOps 领域，特别是在自动化测试领域，Google 应该是典范之一。我们看看Google 面临的挑战（数据截止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 等等），常见的谷歌基础设施服务是各个团队独立运作的，而且通常是一个令人惊讶的小团队：

1.    他们不仅要编写代码，还要负责运营。

2.    等这些组件成熟了，他们不仅要向使用者提供相应服务，还得为他们提供客户端文件库，使得服务更加便捷。使用现有的客户端文件库，他们可以为客户端测试模拟后台服务，并注入各种失败场景，比如：

你可以使用 BigTable 生产程序库，再加上一个模拟器，就会跟实际生产平台的表现一样。你想在写入和ACK 阶段注入失败场景？直接做就成了！

我怀疑这些原则和实践是来自”艰苦的磨练”，从那些你一直问”怎么避免停机”这样的紧急情况中磨练出来的。

随着时间过去，最终规则被完善，得到了一个坚挺的架构。

能力2：一发现问题集群式解决，并记录下来，成为新知识。

Dr. Spear 写道：高效率公司擅长在系统里第一时间发现问题并找到问题。他们同样擅长：

1.    在问题扩散之前找到它；

2.    找出并解决发生问题的原因，让问题不再发生。

这样一来，他们在如何管理解决实际工作问题系统方面，构建了更深层次的知识，将前期难以避免的疏漏转化为知识。

在GK（本文原作者）的研究中，最令人惊讶的集群式解决问题的例子有两个：

1.    丰田的 Andon 拉绳，负责在工作偏离已知模式时让它停下。有记录表明，一个典型的丰田工厂，平均一天需要拉下 Andon 拉绳3500 次。

2.    Alcoa CEO 为了降低工作场所事故发生，制定了相关政策：任何在工作场所发生的事故必须在24小时内通知他。谁需要负责报告？业务部门总经理。

Q：谷歌的远程文化与那些支持集群行为（Swarming Behaviors）的文化类似吗，比如丰田安灯拉绳与 Alcoa CEO 对工作场所事故的向他通知的要求？

完全一致，两者都能引起我的共鸣。

在 Ebay 和谷歌，都有事后剖析免责文化（blame-free PostMortems，或称 blameless post-mortem）。

事后剖析免责是一条非常重要的规定，只要有一个客户受停机影响，我们都会举行一个事后剖析会议。

就像 John Allspaw 和其它人员广泛描述的那样，事后剖析的目标并不是为了追责，而是创造学习的机会和跨公司的广泛交流。

我发现，如果公司文化中事后剖析不会引发什么责任性后果，那么会产生惊人的动力，工程师互相“攀比”，看谁捅出过更大的娄子。比如：

「嗨，我们发现从没测过的备份恢复程序」，或者「然后我们发现，我们没有主动复制。」

也许对很多工程师来说，这一幕十分熟悉：「我希望没停过机，不过现在我们终于有机会修复那个已经被抱怨了好几个月的破系统了！」

这将产生大规模的公司性学习，并且正如 Dr. Steven Spear 所描述的：这样的做法使得我们在灾难性后果发生之前，可以不断找到并解决问题。

我认为其有效原因在于，我们内心里都是工程师，都喜欢建立并改善系统，而让问题暴露出来的公司环境，造就了激动人心和令人满意的工作环境。

问：事后剖析产生了什么结果？不能仅仅写成文档，然后丢进垃圾桶，对不对？

你可能觉得难以置信，但是我相信最重要的部分就是组织事后剖析会议本身。

我们知道，DevOps 中最为重要的部分就是文化，能组织会议，即便没有产出，都能对组织有系统性的提高。

它会成为我们日常规定的一部分，并证明我们的价值以及如何区分工作优先级。

当然，事后剖析之后，几乎都是列出一大堆清单，写着正常运转和出故障的内容，然后你就有了一张待办事项，需要安插到工作队列中去（比如：backlog——所需功能列表；增强功能——改进文档等。）

当你发现需要做新改进时，最终得在某些地方做些修改：有时候是文档、流程、代码、环境或者其他什么。

不过即便没有这些，只是单纯的记录下，这种事后剖析文档也会有巨大的价值。你可以想象一下，在谷歌，什么都搜得到，所有谷歌人都能看到每一个事后剖析文档。

将来在类似事故发生时，事后剖析文档永远是第一个会被读到的。

有趣的是，事后剖析文档还起到一个作用。谷歌有一个长期传统，所有新服务需要开发人员自行管理至少六个月。

服务团队在要求「毕业」时（也就是需要一个专门的 SRE 团队，或者运营工程师来维护），他们基本上都会与 SRE 协商。他们请求 SRE 接管应用提交的相关职责（关于 Google SRE，可以参见高效运维微信公众号之前的文章—编者注）。

SRE 会进行审查文档、部署机制、监控概况等等工作。

当然，SRE 往往首先会检查事后剖析文档，这一步占很大比重，决定他们是否能让一个应用「毕业」。

Q：你在谷歌有看到过类似 Alcoa CEO 那样的要求吗？是否有通过改进措施不断减少问题的例子？

Dr. Spear 描述了 Paul O’Neill（Alcoa CEO） 在美铝公司，如何带领团队减少制铝厂车间的受伤情况的（太惊人了，里面都是高热、高压与腐蚀性的化学制剂），将事故率从每年2%降低到0.07%，使公司成为行业内最安全的公司。

令人惊讶的是，在车间事故率降低到一定数值时，O’Neill 让员工在可能有差错发生时通知他。

确实有。当然，在工作场地发生事故相当于我们影响到用户的停机事件。相信我，在出现影响客户的大故障时，他们会收到通知。在事故发生时，会发生两件事情：

1.    你需要动员一切恢复服务所需的人员，他们要持续工作，直到问题解决（当然，这是标准流程）。

2.    我们也会举行管理层的每周事故会议（在我的 App Engine 团队里，需要出席的有工程技术部主管——共两人，我是其中之一；我们的老板、我们团队的领导、还有支持团队和产品经理）。我们回顾在事后剖析会中所学的东西，检查下一步所需行动，并确认已经妥当的解决了问题。如果必要的话，决定我们是否需要做一个面向客户的事后剖析或者发个博客。

有时候我们没什么要说的。不过一旦情况处于控制之下，团队总是希望同级审查时出现的问题更少，并且更希望提高。

比如一个「不会影响客户」的问题，我们会将它称为「影响团队」的问题。

大多数人都体验过「差点出事」（near misses）的情况吧？布置了六重保护措施，全都是为了防止用户受失败影响所设置，结果全挂了，幸好还剩一个能用。

在我的团队里（Google App Engine），我们可能每年会有一个大众都知道的影响用户的停机事件。当然，每一个这样的情况背后都有几个「差点出事」。

这就是我们为什么会有灾难性恢复（Disaster Recovery）。

尽管谷歌做得不错，我们学到了很多（这就是为什么我们要有三个生产备份），我们认为亚马逊做得要更好，他们的工作比其他人要提前五年。

Q：在美铝公司，工作场地事故需要在24小时之内报告给 CEO。在谷歌是否有类似的垂直升级机制？

在 Google App Engine，我们有很小的团队（全球100个工程师），里面只有两级：做事的工程师和管理者。

在发生了影响客户的事故时，我们也曾在午夜把大家叫醒。每一个这样的事故，有十分之一会升级到公司领导层。

Q：你对Swarming（集群式解决问题的行为）如何发生怎么描述？

像丰田工厂，并非出现所有问题时都能确保人人到位解决问题。但在文化上，我们的确会优先考虑优先级为0的那些问题的可靠性和质量。

在很多方面都有这种情况，其中一些不算太明显，比停机要微妙一些。

在你检查打断测试的代码时，在修复之不会有其他工作，也不会发现还有打断更多测试的问题急待解决。

与此相似，如果有人也出现了类似的问题需要帮助时，也会希望你放下一切提供帮助。为什么呢？这是我们安排优先度的方式——就像「黄金法则」。我们希望帮助每个人推动工作，从而也帮助到了所有人。

当然，在你需要帮助时，他们也会这样对你。

从系统的角度来看，我认为它就像棘齿或者过山车的中间齿轮——让我们不会滑下去。

这不是流程中的正式规则，不过每个人都知道，如果有类似影响用户的明显不正常操作出现，我们会发出警报，发一些邮件等等。

信息通常是「嗨，大家好，我需要你们的帮助」，然后我们就去帮忙啦。

我认为它总是奏效的原因在于，即便没有正式说明或列出规则，大家都知道我们的工作不只是「写代码」，而是「运行服务」。

甚至全球性的依赖（比如负载均衡器、全球基础架构配置错误）都能在几秒内修复，事故会在5到10分钟内解决。

关于其他两大能力，我们将在下一篇继续和大家分享，就在下周，敬请期待。

（王鹏、高浩淼原创）