加入收藏 | 设为首页 | 会员中心 | 我要投稿 应用网_丽江站长网 (http://www.0888zz.com/)- 科技、建站、数据工具、云上网络、机器学习!
当前位置: 首页 > 站长资讯 > 评论 > 正文

为什么谷歌的服务从来不会崩溃?

发布时间:2016-04-12 03:01:51 所属栏目:评论 来源:钛媒体
导读:把开发和运维结合起来,乃至把运维融合到代码之中,谷歌以此来调和开发与运维之间的结构性冲突。

谷歌 谷歌服务

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

钛媒体注:本文由钛媒体编译自《连线》文章,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写到。

(编辑:应用网_丽江站长网)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!

推荐文章
    热点阅读