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

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

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

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

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

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

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

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

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

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

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

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

对许多硅谷中的人来说，这并不算什么新鲜的观点。或者这么说，从亚马逊到Box.com，整个科技界基本上都是这么干的。人们称之为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写到。

Chef公司的Jacob则认为，50%的比例并不是那么重要，但他喜欢这种态度。他说：“这就是经济学。我们总需要一些人来做运营的破事儿，人们总有无限的破事儿希望运营人员能够解决。所以，给这些破事儿设个限额是完全合理的。”

在招聘SRE人员方面，谷歌甚至出台了严格的指导方针。约有五成到六成SRE人员是通过工程师的招聘流程进来的，其他人则有“85%到99%”的同等技术能力，再加上“大部分软件工程师缺乏、但对SRE工作非常有用的技术技能”，比如深入了解UNIX操作系统的内部原理或硬件联网协议。这也是为了确保开发和运营保持适当的平衡。

登月计划的启示

从许多方面来看，这是一种新的管理原则。但在进一步的阐述中，谷歌团队用了一个很老的案例。

谷歌SRE原则的精神祖先其实是“代码女神”Margaret Hamilton，她是MIT的程序员，也是数学和电脑科学的先锋，在上世纪六十年代为阿波罗登月计划开发程序。Hamilton描述到，阿波罗项目的文化之一就是“从每个人、每件事上学习，包括你最不抱希望的人和事。”

Hamilton虽身为技术人员，却在运维方面起到了重要作用。当年，她经常把自己的小女儿Lauren带到实验室去。有一天Lauren不小心按下一个按钮，结果把一个用于阿波罗发射前的程序输入到正在运行发射后方案的电脑。这立马使得电脑崩溃，此后Hamilton便尝试给系统加入一个新的错误校验代码，让其能够在真正的飞行中预防这类突发情况的发生。上司对她的想法表示反对，认为宇航员永远不会犯这样的错误。然而，在阿波罗八号的飞行中，宇航员真的发生了这样的状况，所幸Hamilton早在系统文档中加入了一个变通方案。在此后的发射中，她给系统加入了错误校验代码。

“光是指出‘那样做会崩溃的’真的没啥作用。但如果你说，‘那样做会崩溃的，我来告诉你怎么做’，这就非常了不起了。”Underwood是这样解读的，“她看到了程序将会崩溃，并看清了会怎么崩溃，然后设计出了预防方案。”

这就是DevOps，用谷歌的说法就是SRE。听起来没什么大不了，却是非常强大的理念。它已经成就了谷歌。不过，像Underwood这样的哲学家型SRE人士还有更大的雄心。他们设想，在未来的世界里，运维能够更进一步变成代码的一部分。Underwood说：“我们期待着有朝一日，不需要人进行任何管理。”