本文摘要：(公众号：)录：本文来自微信公众号“运维为首”（ID：yunweipai），获得许可公布。

(公众号：)录：本文来自微信公众号“运维为首”（ID：yunweipai），获得许可公布。很有可能，这种情况显然没再次发生过（学术著作：这是文章是美国人写出的）。

的确，有时也不会经常出现因为网络连接中断而用不上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如是说。版权文章，予以许可禁令刊登。下文闻刊登须知。

本文来源：365平台官方版下载-www.jinlunxuanqieji.com