在这篇博文中，我们采访了Chris Jones，他在Google App Engine工作了3年半，在Google工作了近9年，是一名网站可靠性工程师。克里斯也是网站可靠性工程的编辑之一：谷歌如何运行生产系统，由O'Reilly出版，今天可以使用。

谷歌应用引擎每天服务超过1000亿个请求。您可能听说过我们的站点可靠性工程师（SREs）是如何做到这一点的。这有点神奇，但主要是将计算机科学和工程的原理应用到计算系统的设计和开发中——通常是非常大的分布式系统。

站点可靠性工程是一套工程技术方法，可以让我们或任何人运行更好的生产系统。它继续向更广泛的It社区宣传DevOps的概念。这很有趣，因为这是一种相对简单的方法来提高性能和可靠性在行星规模，但可以同样有用的任何公司，比如说，推出Windows桌面。做得好，SRE技术可以提高运行任何计算服务的效率。

问：Chris，告诉我们有多少SRE运行appengine，规模是多少？

CJ:我们在App Engine上有数以百万计的应用程序，每天服务超过1000亿个请求，由数十个SRE支持。

Q:这么少的人，我们如何做到这一点？

CJ:SRE是一种操作大规模分布式计算服务的工程方法。使系统高度标准化至关重要。这意味着所有系统都以相似的方式工作，这意味着操作它们所需的人员更少，因为需要理解和处理的复杂性更少。

自动化也很重要：我们构建新容量或扩展负载平衡的启动过程是自动化的，这样我们就可以很好地用计算机扩展这些过程，而不是和更多的人在一起。如果你把一个人放在一个枯燥而重复的过程中，你会注意到错误在悄悄地出现。计算机对故障的反应时间也比我们快得多。在我们注意到错误的时间里，计算机已经将流量转移到另一个数据中心，使服务保持正常运行。最好让人们做人们擅长的事情，计算机做计算机擅长的事情。

问：SRE模式背后还有哪些其他方法？

CJ：因为有SRE团队与谷歌的许多服务合作，我们能够将标准化原则扩展到各个产品：例如，最初用于部署新版Gmail的SRE构建工具可能会被推广到更多情况。这意味着每个团队不需要构建自己的方法来部署更新。这确保了每一个产品都能从工具的改进中获益，从而为整个组织带来更好的工具。

此外，软件工程和系统工程知识在SRE中的结合往往会产生综合两种背景的最佳解决方案。Google的软件网络负载均衡器Maglev就是一个例子，它是Google云负载均衡器的底层技术？

CJ：这里有一个故事很好地说明了这一点。2013年夏天，我们将App Engine的所有美国地区从美国的一边搬到了另一边。这一举措没有给我们的客户造成停机时间。

问：怎么做？

CJ：我们关闭了一个应用引擎集群，按照设计，在其上运行的应用程序会自动移动到其余集群。我们已经提前在目标数据中心创建了美国地区高复制数据存储的副本，以便这些应用程序的数据（其中有PB的数据！）已经到位；对数据存储的更改几乎实时地自动复制，以便始终保持最新。当在新位置打开App Engine时，分配给该集群的应用程序会自动从其备份集群迁移，并且其所有数据都已就绪。然后，我们对剩下的集群重复这个过程，直到我们完成为止。

提前准备，再加上广泛的测试和应急计划，意味着我们在出现轻微问题时做好了准备，能够将对客户的影响降到最低。当然，我们还做了一个内部的尸检——SRE工作原理的另一个关键部分——来了解哪里出了问题，以及如何在未来解决问题，而不必指手画脚。我们怎样才能了解更多关于SRE的信息？

CJ：当然。如果你有兴趣了解更多关于谷歌网站可靠性工程的工作原理，包括我们在这一过程中所学到的经验教训，请查看本网站、新书，本周（4月7日至8日）我们还将在SREcon就这一主题进行各种讲座。