为什么谷歌的服务从来不会崩溃？

谷歌的全套应用似乎总是坚如磐石，稳固可靠。

钛媒体注本文由钛媒体编译自《连线》文章，Joyce/编译。

对于身处墙外以及自备科学上网技能的你，还记得上一次是什么时候，你想上谷歌搜索点什么结果网页崩溃了吗？

真相是，这个答案本身就不成立，因为谷歌似乎一直都在那里，从来没有宕机过，除非你连不上网。而除了搜索引擎，谷歌提供的各种线上服务，无论是Gmail、Google Docs还是其他，都似乎是同样地稳定可靠。根据谷歌提供的统计数字，在2015全年99.97%的时间里，你都能畅通无阻地使用包括Gmail和Docs在内的全套谷歌应用。

似乎全世界的用户都对此习以为常，但这完全称得上是非常了不起的成绩，只是使用谷歌的我们很少会去思考，这家公司是怎样把“奇迹”变成日常的。

谷歌只用了短短三个词来解释网站可靠性管理（Site Reliability Engineering，简称SRE）。

听起来没什么厉害的，但谷歌在十几年前就提出了这一影响深远的设想。这种管理哲学其实意蕴深厚且适用范围广泛，简而言之，可以归结为这么一个中心思想

不要让擅长管理网络服务的IT人员来管理你司的网络服务。让编写软件的程序员自己来管理。

这么做的话，程序员就会自己开发有助于程序运作的工具，而不需要其他人花力气找bug。

“我们期待着有朝一日，不需要人进行任何管理。”

——TODD UNDERWOOD，谷歌网站可靠性主管

谷歌工程副总裁Ben Treynor Sloss在新近的一篇文章里写到“我们的方法呈现出来的效果是，整个团队的成员都会对手动执行任务很快地产生厌倦，也都掌握了编写程序的能力来代替之前的手动操作。”

对许多硅谷中的人来说，这并不算什么新鲜的观点。或者这么说，从亚马逊到Box.，整个科技界基本上都是这么干的。人们称之为DevOps，即开发（development）和运维（operation）的合并，整合编程人员的技术与系统管理员的目标。不过，这场DevOps运动的发展虽然源自谷歌内部的SRE管理体系和亚马逊内部类似的管理原则，但也大有不同并自成一体。只是谷歌一直都秘而不宣，就像人们好奇谷歌高效的线上运维是怎么实现的时候，他们还是保持低调行事。

但谷歌已经进入了新时期，现在的它比以前更愿意对这类话题开门见山展开讨论，很大一部分原因在于谷歌想借此推广自家的云服务，以引进更多外部的公司，在谷歌的数据和机器网络之上运行他们的软件，甚至还出了一本专门论述SRE内功心法的书，就叫《网站可靠性管理》（Site Reliability Engineering）。

无论是科技业的从业人士还是圈子外的每一个小白，系统管理或曰运维都是计算机技术领域最无趣的一个方面，往往出了问题才会事后诸葛亮。，负责谷歌日常运作的副总裁Sloss可不这么认为。恰恰相反，他认为网站可靠性是“任何一款产品最基础的特性”，毕竟“如果没人能用得上，这个系统就毫无用处。”

从无到有的SRE

Sloss算是这场SRE运动的“发起人”。一开始，谷歌把他招进来负责运维，正是他后来提出了SRE这个词。“SRE就是你让一个软件工程师去设计一个运维团队，”他说，“我假设自己就是一个SRE系统，并按着那样的方式来设计并管理我的团队。”

而对Todd Underwood来说，公司聘请Sloss这样的程序员是再自然不过的事。他向《连线》杂志表示，“当谷歌还处于创业阶段的时候，其实还有很多其他的优秀软件工程师，他们更清楚问题可能以怎样的形式出现，也更明白整个工程该怎么做好。但没有人真的想去亲手落实。”

这是非常“谷歌”的一种现象。配置管理工具Chef的首席技术官Adam Jacob非常同意Underwood的看法并解释道，当线上的运营成长到足够大的体量时，这是一种意料之中的转型。“把软件开发和实际运营结合起来，乃至让二者密不可分，这是很自然要讨论的问题。全面地看问题才能有更好的产出。”

若联想到开发和运维原本是两个“死对头”，这种转型就显得格外有趣了。开发团队希望开发新软件，并尽可能快地让公众得到不同的体验，但运维人员更希望确保万事俱备、毫无差错，最好的办法就是尽可能减少变化。

“这是不相称的两个目标。”Underwood说。

窍门就在于，把开发和运维结合起来，消除这种对立。

Underwood把这称为“黑格尔式的正题-反题综合体”。他也承认，这种说法没人会真正买单，因为“没人还会读黑格尔了”，他打趣道。但这种说法恰恰正中命门，谷歌正是在这样的哲学思想指导下，把其他的业务都结合起来，加速了整个SRE的转型进程。

把犯错概率编入预算

其中一个重要的观点是，为了减少开发和运维之间的冲突，公司不会苛求正常运作时间达到100%。Sloss在文章中写到，真实情况是用户并不需要网络服务达到百分百可用。退一步说，用户也分不清正常运作时间达到100%和99.999%的区别（手提电脑、WiFi、电力和ISP宕机的概率可远远大于0.001%）。如果设定好一个合理的、低于100%的正常运作时间目标，也就是“错误预算”，你就有了更大的空间来调整变化，进行试验。

“引入’错误预算’解决了开发和SRE目标之间的结构性冲突问题，”Sloss写道，

“‘停电’再也不是坏事，而是创新过程可预见的一部分，也是开发团队和SRE团队可以管理并且无需畏惧的正常现象。”

与此，谷歌也制定了配套的制度，为的是确保新的SRE成员不会沦落成以前的系统管理员角色。大体上，谷歌规定了SRE组的成员不能把超过一半的时间用在开发之外的传统运营上。如果运营的部分开始大于开发，谷歌就会把一些运营工作交给一般只负责开发软件的团队，也就是软件工程师。“有意识地保持运营和开发工作的平衡，让我们得以确保SRE团队的工作带宽，能够投入开发创造性的自动化工程，保留在运维工作中手机得来的经验智慧。”Sloss写到。