转载

谷歌如何确保自己的服务永远不会宕机？答案是：网站可靠性工程

你上一次需要谷歌服务，但它没有出现，是什么时候？（请忽略天朝现状）

对于上面这个问题，相信绝大多数人在思索了几秒之后发现，这件事儿似乎还真的没有发生过！是的，如果非要说你无法使用谷歌服务的话，除非你的互联网连接有问题，或是被屏蔽了。谷歌最主要的线上服务，包括搜索引擎，Gmail和Google Docs等等，似乎总是随手即可访问。

2015年，根据谷歌自己发布的数据显示，包括Gmail和Docs 在内的Google Apps套件，正常访问率达到了99.97%。大家似乎已经对谷歌这样的表现习以为常了，但这的确是个伟大的现实。但是，全世界数十亿使用谷歌服务的人可能都想问一个问题——他们是如何做到让自己的服务如此稳定？

对于这个问题，谷歌的答案其实只有一个简单的词：网站可靠性工程（SRE：Site Reliability Engineering）。好吧，这个答案可能不是那么吸引眼球，但是谷歌却是在十几年前就提出了这种开创性的理念。它不仅是一种很微妙且极具发散性的哲学理念，更可以归结为一个中心思想：不要让专门运营互联网服务的IT人士去运营你的互联网服务，而是要让软件程序员承担这项工作。如果你这么做了，才能执行谷歌这种开创性的服务理念，软件程序员会构建工具，在节约人力资本的前提下帮助运营。

谷歌运营副总裁本•特雷诺•斯洛斯说道：“我们采用这种方法之后的结果，就是把一帮手工处理无趣运营工作的员工，变成了一帮熟练掌握编程技巧、用软件取代手工作业的程序达人。”

对如今许多硅谷公司来说，这已经成为了一种共识。而且在科技企业里得到了广泛实践，包括亚马逊和Box这些公司。人们把这种模式成为DevOps（英文Development和Operations的组合）是一组过程、方法与系统的统称，用于促进开发（应用程序/软件工程）、技术运营和质量保障（QA）部门之间的沟通、协作与整合），将软件程序员和系统管理员的角色整合在一起。

但DevOps理念（具体体现在像Chef和Puppet这些工具产品上）其实还是落后于谷歌内部推行的网站可靠性工程理念（类似的理念也在亚马逊公司里应用），只是在过去的十多年时间里，谷歌一直非常低调在自己内部践行SRE理念，继而才有了如此高效率的线上运营成绩。不过随着时代的变化，特别是云技术的快速发展，企业会在谷歌庞大的数据中心依赖谷歌服务器设备在云端运行自己的软件，讨论DevOps和SRE的人因此也开始变得越来越多。谷歌也不再低调，在O’Reilly出版社的帮助下专门出了一本《网站可靠性工程》的书。斯洛斯负责了该书第一章的编写工作。如果你希望深入了解DevOps，这会是一本必读之书，即便你不想成为这一领域里的专家，看看这本书的前言，简介和第一章节，也会让你对谷歌如何运营自己庞大的线上帝国有一定了解。

很多科技界人士，甚至是大多数非科技人士眼里，系统管理属于后台类工作，也是计算机科技行业里最无聊的一种工作。但谷歌7/24运营副总裁斯洛斯从另一个角度剖析了系统管理的概念，他认为，“可靠性是任何一款产品的最基本功能”。毕竟，如果一个系统隔三差五地宕机，又何谈其能给用户提供有用的帮助，并带来价值呢？

开发和运营，两个看似对立却又能融合在一起

斯洛斯最先发起的“网站可靠性工程”运动，当谷歌聘用他负责系统运营时，他最先使用了这个属于。“我当时是一个软件工程师，但是接受委派去组建一支系统运营团队，于是就创造出了网站可靠性工程（SRE）这个词，”他说道，“我觉得SRE对我来说很受用，所以希望它也能够设计应用到系统运营团队建设之中。”

托德•安德伍德是现任谷歌网站可靠性工程主管，在他看来，谷歌招募像斯洛斯这样的程序员负责系统管理工作其实很自然。“当谷歌处于婴儿期，很多软件工程师知道系统是如何崩溃，以及工程项目该怎么做才能更好，但却没有人愿意从事枯燥的系统管理工作。” 不过，Chef公司CTO亚当•雅各布认为过去那种对系统运营的误解正在发生转变，特别是将软件开发和运营支持结合在一起之后，过去看上去很难处理的运营问题现在都能得到更好解决。

这种转型特别有趣，因为从传统的角度去看开发和运营往往是对立的。开发想要构建新软件，然后尽快改变，引领趋势；而运营则要确保一些不出错，最好是一切都不要改变。在安德伍德眼里，将开发和运营整合在一起看似不相称，不过一旦这么做了之后，两者反而不会那么对立了，他将这种所谓悖论称之为“黑格尔理论-对立综合体”。

安德伍德承认，能理解这一点的人不多，毕竟了解黑格尔哲学的人是少数。但谷歌正是将开发和运营有效地整合在了一起，并发挥出巨大作用。

误差预算

一个想法是，为了减少运营和开发之间的冲突，公司没有必要追求100%的正常运营时间。斯洛斯认为，在现实中你不需要追求永不宕机的互联网服务。100%的正常运营时间和99.999%的正常运营时间，在用户看来并没有区别（要知道笔记本和Wi-Fi故障，以及互联网服务提供商故障都远不止0.001%）。所以，如果你设置一个合理的、低于100%的有效运营时间（即误差预算），那么就能为开发留出足够的空间来做出改变，尝试试验。

“采用误差预算可以解决开发和网站可靠性工程质检的架构冲突，”斯洛斯说道，“运营中断（宕机）也不再是一件‘坏事’，而是流程创新的一部分，当问题出现之后，开发团队和网站可靠性工程团队不再感到担心害怕，而是能够从管理层面去处理解决。”

谷歌并没有企图用网站可靠性工程去颠覆传统的系统管理，他们规定网站可靠性工程的编程作业时间一般不能占用超过50%的传统运营工作。如果在某个网站可靠性工程团队里，运营工作大量占用了开发工作，谷歌通常会将一部分运营工作分配给其他软件工程师。事实上，50% 这个比例值并不是那么重要。但谷歌这种态度值得称赞，因为总要有人去处理运营那些“破事儿”。无论哪家公司，运营工作人员总是被要求处理无数“破事儿”，而“50%”就像是个保护帽，有效平衡了运营和开发之间的冲突。

在招募网站可靠性工程员工时，谷歌甚至还创建了严格的指引。谷歌工程师除了有一定专业技能之外，还需要有其他能适应网站可靠性功能技术的能力。比如一个负责UNIX操作系统开发的工程师，也需要对硬件网络协议知识有一定了解。谷歌此举的目的，就是要确保开发和运营之间能保持适当平衡。

负责登月项目的代码女神是SRE理念的灵感之源

在很多方面，SRE都是一个全新的理念。但是谷歌却用了一个老例子来阐述自己这一理念。谷歌SRE的精神先驱是代码女神玛格丽特•汉密尔顿，这位麻省理工学院程序员负责为阿波罗11号探月宇宙飞船编写软件。汉密尔顿解释说，阿波罗探月项目文化里里有一部分就是要学习所有人和所有事，包括哪些最不希望发生的事情。

汉密尔顿是一个程序员，但是在运营层面她同样扮演了重要角色。为了说明这个问题，《网站可靠性工程》一书里透露了一个故事。当时汉密尔顿经常带自己的女儿劳伦去计算机实验室，有一次小女儿不小心按了一个按钮，将阿波罗预发射程序导入进一个运行“发射后”场景的计算机里。

出现这个问题之后，汉密尔顿试图在系统里新增加一段错误检查代码，防止在真实飞行中发生类似的事情。但是高层拒绝了汉密尔顿的建议，认为专业的宇航员不会像不懂事的小女孩儿那样按错按键。但事实上，在阿波罗8号发射时，宇航员真的出现了这样幼稚的错误。所幸的是，汉密尔顿在系统文档里加入了解决方案说明，悲剧才得以避免。之后，她在系统内加入了错误检查代码。

安德伍德解释说，“如果你看到了一个问题，并没什么用。但如果你发现了一个问题，并发现问题背后的原因，提供解决问题的方案，才是真正有用的。汉密尔顿发现了问题，并知道是什么导致了问题出现，同时还找到了解决方案，预防问题发生。”

这其实就是DevOps理念，当然，用谷歌的说法是网站可靠性工程，这个词虽然简单，但却是一个非常强大的想法，并且在谷歌公司得到了有效应用。不过，谷歌的网站可靠性工程哲学有着更远大的目标，未来的运营转型甚至会超越软件。“我们期待有一天，”安德伍德说，“没有人负责运营，因为那时，运营这一概念已经融入到每一个生产环节之中了。”（翻译：shark，编辑：picar）

原文 http://www.cyzone.cn/a/20160420/294509.html

正文到此结束