Google 是如何做到从不宕机的？

很有可能，这种情况根本没有发生过（译注：这是文章是美国人写的）。的确，有时也会出现因为网络连接中断而用不上 Google 的情况；但是 Google 的基础性在线服务——从搜索引擎到 Gmail 再到 Google Docs 等等——几乎永远垂手可及。根据 Google 官方的数据，2015 年该公司旗下的 Google App 套件在 99.97% 的时间里都处于可用状态。也许我们认为这是理所当然的，但它的确是一个了不起的事实；而全世界数十亿的 Google 用户似乎从来没有停下来想想：Google 是如何把一件如此激动人心的事情处理得如此波澜不惊的。 

Google 用了这三个词来解释这个问题：Site Reliability Engineering（中文可译为：网站可靠性工程，后文简称 SRE）。也许这三个词听起来并不是特别性感，但它们确实是（名字听起来更不性感）的 Google 在 10 年前就已经秉承的核心理念。这个理念很难用一两句话说清楚，不过可以归结到一个中心思想：让码农而非那些专门从事网络服务的 IT 人士来运营网络服务。如果这个思想得以执行，那么码农们就会开发出一种不需要人为介入的工具来帮助完成运营工作（这里所说的运营，主要是指维护服务的稳定和性能）。

" 我们通过这种方法建立这样一个团队：大家都比较厌倦自己亲自动手去完成任务，而是通过写出软件来取代此前需要人工完成的事情。" 一位名叫 Ben Treynor Sloss 的 Google 员工在一篇文章中写道。

对于硅谷的很多人来说，这似乎已经成为一个常识；从亚马逊到 Box.com，这种方法已经被整个科技圈所采用。人们称其为 DevOps（Development 加上 Operations）模式，意即通过某种努力将软件开发者与系统管理员联系起来。但是以 Chef 和 Puppet 为代表，自从 DevOps 模式从 Google 的 SRE 渐渐衍生出来之后已经发生了很大的改变。只不过 Google 在过去的十年里一直对 SRE 默不作声，但是过去它在应对大规模高效率的网络操作时的确是这么做的。

不过目前 Google 已经进入到一个新的阶段，它更愿意讨论 SRE 的相关问题了。（这主要是因为 Google 想推销自己的云服务，以便外界公司能够用上自己的软件服务。）不仅如此，Google 还专门写了一本书来探讨关于 SRE 的问题。

好吧，这本书的名字就是 Site Reliability Engineering。此书刚刚被 O ’ Reilly（译注：一个专注于科技类书籍的出版公司）出版，而来自 Sloss 的那篇论文被作为此书的第一章。如果你对 DevOps 感兴趣，那么此书在必读之列；即使不感兴趣，这本书的开头——序言、介绍以及第一章——也足以让我们了解到 Google 这个全世界最大的网络帝国的驱动之道。

对于很多科技公司——其实也可以是科技圈之外的所与人——而言，系统管理（或者说运作，随你怎么称呼）是收尾工作，是计算机科技最烦人的一个方面之一。但是 Sloss，也就是外界所知道的 Google 内部负责 " 不间断运行 " 的副总裁，却把这个问题反过来看，辩称网站可靠性 " 是所有产品最基础的功能 "，毕竟，" 如果一个系统不能工作，那么它一点用处都没有。"

黑格尔的对立统一理论

Sloss 就是 SRE 的原点。早年 Google 招他来负责公司的运营项目时，他创立了这个项目。" 当你要求一个软件工程师去设计一个运作团队的时候，SRE 就产生了 "，他说，" 我设计并管理这个团队；这个团队运作起来就像我自己是一个 SRE 一样。"

Todd Underwood 目前是 Google 的一个 SRE 总监；他认为 Google 雇佣 Sloss 这样的码农是一件非常自然的事情。" 当 Google 还处于早期发展阶段时候，就已经有软件工程师很清楚地意识到哪里会出问题以及如何解决这些问题，但是他们中没有人愿意亲自去处理这些事情。"

这其实是一件麻烦事。但是 Chef 的 CTO（首席技术官）Adam Jacob 也认为要想成长为一个大体量的公司，做出这种转变也是应该的。" 将软件开发和实际运营连接在一起是一件非常自然的事情，你不可能将两者自然分开；尤其是当你历史地看待这个问题的时候，你可能会更加意识到这一点。"

考虑到在传统意义上开发和运营是完全不搭界的两个层面，你会觉得这种转变非常有意思。开发人员致力于写出一个新的软件，然后修改，最后再尽可能快地将软件推向大众用户；而运营人员则是保证不出差错，而最好的方式是将变化减少到最小。" 这些本来是毫不相干的目标 "，Underwood 说，" 不过开玩笑的是，当你把开发和运营联系起来，你就开始消弭他们之间的竞争目标了 "。

Underwood 称之为 " 黑格尔的对立统一理论 "；不过当他这么说的时候，没有人买账。" 人们都不再读黑格尔了 "，他自嘲说。不过这种描述方式说到点子上了。一旦这种准备就绪，Google 就加快了将所有的好想法都付诸这种模式的进程。

开发与运营之间的平衡

有一个很重要的想法是：为了减少开发和运营之间的冲突，Google 并不要求 100% 的正常运行时间。正如 Sloss 在书中所写，实际上并不需要保证网络服务 100% 的时间里处于可用状态。用户也并不能真正区分出 100% 和 99.999% 的区别（实际上他们的笔记本、WiFi、电量掉线的时间远远超过 0.001%）。如果你在 100% 之下设置一个合理的在线时间比例——误差预算——那么你将会足够的时间做出改变并且调试完毕。

" 误差预算的运用消解了开发工作和 SRE 工作之间的冲突诱因 "，Sloss 说，" 一次中断不再是一件坏事。它存在于一个创新过程中的可预期范围之内；这样一来，开发部门和 SRE 部门都能够解决这个问题，而不会感到害怕。"

与此同时，Google 公司也推出一些相应的规定来保证 SRE 不会演变为老式的系统管理。原则上，SRE 不允许花费 50% 以上的时间在传统的运营工作（与编程相抵触）上。如果在一个 SRE 团队中，运营的优先权已经超过了开发，Google 就会将一些运营人员调配到普通的软件开发工作中去。" 有意识地调节开发和运营之间的平衡，能够保证 SRE 们有足够的空间去投入到有创造性的、自动化的工程中去，"Sloss 说，" 当然，他们同时也得听取运营部门的意见。"

Chef 公司的 Jacob 认为这里所提到的 50% 的比率并没有那么重要，但是他喜欢这种态度。他说 " 那是业务，总要有人去处理运营工作；而且运营工作几乎是无穷无尽的，所以你硬要给他们扣上一顶帽子也是可以理解的。"

在雇佣 SRE 时，Google 甚至制定了严格的规范。在招募的人员中，有 50% 到 60% 的人员会通过像其他所有 Google 工程师那样的严格考核，剩下的需要拥有 85% 到 99% 的 Google 工程师技能，加上一些特殊适用于 SRE 但是大多数软件工程师不具备的技能——比如说对于 UNIX 操作系统和硬件网络协议了如指掌等。这些都是为了保证开发和运营之间能够保证一个恰当的平衡。

SRE 的雄心

从多种层面上而言，这是一种全新的理念。但是在他的书中，当他们试图描述这种理念的时候，Google 团队却选用了一个比较老旧的例子。Google SRE 的精神先行者是一个来自 MIT 的名为 Margaret Hamilton 的程序员，她在六十年代为阿波罗飞船编写了登月程序。正如 Hamiltion 自己说的那样，阿波罗项目中衍生出的部分文化是向所有人和所有事物学习，包括那些看起来学不到什么的人和事。

虽然 Hamilton 是一个码农，但她在运营中承担重要角色。为了证明这一点，这本书中讲了一个故事：她经常带她的女儿 Lauren 进入到计算机实验室，有一天，Lauren 恰好碰到一个按钮，然后把阿波罗的预发射程序植入到一个正在运行 " 发射后场景 " 程序的计算机中去。

这一下让整个系统卡死；Hamilton 试图在系统中添加一段错误监测代码，以便在真实的飞行过程中能够阻止这种错误。她的上司否决了整个想法，辩称宇航员绝不会犯这种错误；但是在阿波罗 8 号中，宇航员的确犯了这么一个错误。幸运的是，Hamilton 在系统文档中加入了一个变通方案。在后续工作中，她还是加入了这段错误监测代码。

如果你过来跟我说 " 它会死机 "，那没有什么用；但是如果你说 " 它会死机，让我来告诉你怎么解决 "，那你就很棒了—— Underwood 说。" 而在我们这里，会有人既知道会出现一些问题，也知道问题出在哪里，并且能找出方案防止问题发生。"

这就是 DevOps，或者用 Google 的话说，SRE。这三个词听起来没什么，但是它的确是一个非常强大的想法。通过它，Google 已经诞生了，但是对于某些像 Underwood 这样富有哲学思维的 SRE 来说，他们有着更大的雄心。在他们的构想中，运营本身比开发前进得更快。

" 我们希望长久以后，没有人再做运营了。"Underwood 如是说。