很有可能，这种情况根本没有发生过（译注：这是文章是美国人写的）。的确，有时也会出现因为网络连接中断而用不上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如是说。