加入收藏 | 设为首页 | 会员中心 | 我要投稿 开发网_开封站长网 (http://www.0378zz.com/)- 科技、AI行业应用、媒体智能、低代码、办公协同!
当前位置: 首页 > 服务器 > 安全 > 正文

SRE系列教程 | 孙宇聪:来自Google的DevOps理念及实践(上)

发布时间:2021-01-09 13:14:27 所属栏目:安全 来源:网络整理
导读:副标题#e# 《SRE系列教程 | 孙宇聪:来自Google的DevOps理念及实践(上)》要点: 本文介绍了SRE系列教程 | 孙宇聪:来自Google的DevOps理念及实践(上),希望对您有用。如果有疑问,可以联系我们。 SRE(Site Reliability Engineering)是最早由Google提出,
副标题[/!--empirenews.page--]

《SRE系列教程 | 孙宇聪:来自Google的DevOps理念及实践(上)》要点:
本文介绍了SRE系列教程 | 孙宇聪:来自Google的DevOps理念及实践(上),希望对您有用。如果有疑问,可以联系我们。

SRE(Site Reliability Engineering)是最早由Google提出,又经由Google发展完善的一个崭新运维理念.如今SRE已成为一个涵盖运维理念、思路、组织架构和具体实践的完整体系.数人云推出SRE系列教程,由SRE经验丰富的技术大牛们为大家分享运维一线的独家干货,揭示SRE背后的秘密.

今天为系列教程第一期,我们邀请了前Google SRE、《SRE Google运维解密》的译者孙宇聪与大家进行了线上分享.本文为上篇,讲述了SRE的基本概念和核心原理.与孙老师本人一样风趣幽默的文章,小数希望大家阅读愉快:)

今天与大家分享的内容是关于最近我翻译的这本书,据说反响还不错,今天借这个机会聊一聊书中的内容,并与大家分享一下我回国两年多以来,Google经验在国内的一些思考和落地实践.

什么是SRE?

很多时候国内把DevOps的范围定得有点狭窄,DevOps这件事情在国外更多是整个行业内的一个趋势.DevOps是一种模式,主要是让IT相关的东西与商业结合得更紧密一些,迭代速度变得更快一些,所以它适用于各个行业.今天说的SRE,我认为也是在运维行业上的一部分.

概括来说,我认为《SRE Google运维解密》这本书是一个文集.GoogleSRE全球一千多人,这个组织在公司里相对比较小众,但又是一个比较重要的部门,整个Google所有业务线的运维环境都由SRE来负责.SRE是一个非常分散的组织,每个业务线、每个部门其实都有自己的SRE小团队.这本书里共有一百多个作者联合写成,其中也包括我以前所在的团队,我们做过的一些Project也在书中也有提到,所以它是一本文集.我与原著的三个编辑聊天时,他们说成书最大的难处就是删减内容,当时征集来的内容大概有一千多页,最后删到了五百多页.这也是这本书比较有意思的一个花絮.

回到这本书的宗旨,SRE到底是什么?SRE是Google发明的一个词语或者新定义的一个职业.以前这个运维角色,大家叫运维,美国叫Operation.现在Google把这个职位扩展为SRE,就是用软件工程师的方法和手段,招了一些软件工程师来解决运维的难题,这是SRE的官方定义.

传统运维模式的弱点

现在传统的计算机行业的运维方式,大部分都是采用系统管理员的模式.大家最熟悉的运维方式是这样:招聘一些系统管理员,他们有负责采购机器的,有负责维护数据中心的,也有专门维护数据库的等等.系统管理员模式有几个特点,他们只是把一些现成的组件组装起来,并不会自己开发和创造新的系统,比如拿了MySQL把它跑起来,或是研发部门开发出来的新代码组装成之后提供这样一个服务.这是运维部门的一个特色,负责把这个东西运行好.

举一个例子,在美国的时候我们经常自嘲,说自己是流水线上的工人.因为这个流水线实际上是别人设计出来的,总得有人去操作这个机器,而我们就是一线的操作流水线的工人.又比如,我们好像是发电站里的工作人员,又或者是飞机驾驶员.飞机驾驶员就是开别人造出来的飞机,这和运维部门的职责很像.

那么这样一个运维部门的职责包括哪些呢?首先最重要的是应急事件的处理,这是重中之重,也是最唯一的职责.其次是常规更新,现在的业务发展越来越快,每周都有新的东西上线,比如说今天要买新机器,明天要改IP地址,大家可能80%的投入都是在这些事上,这就是系统管理员或者是现在运维行业的工作模式.

但是系统管理员模式有一个最大的弊端,按照传统的组织架构模式或者是这种运维模式运行会导致这个团队持续扩张,业务越来越多,需要不停的招人去应付各种各样的事.刚开始接手生产的时候,也许一周就出一次事或者是需要更新一次.因为人的沟通能力总是有限的,招了五个人之后,这五个人之间的传达问题就形成了一个困难.当你把一个精神传达给这五个人,他们事后执行出来的结果都不一样,这就是传统模型一直想要解决的问题.但是这种模型也有好处,就是市场招聘比较容易.

Google有几个比较重要的特点,首先它的部署规模非常大.Google到今天已经十八年了,刚开始前几年公司所有的人平时写代码,周末去机房接机器.因为它扩展速度特别快,部署规模非常大.如果按照传统的系统管理员的那种模式操作,这个机柜归你,这个机柜归他,再下一个归另外一个人,那么Google招人的速度一定赶不上机器增加的速度,所以Google是被逼迫创造了这样的职位,因为没有办法安排团队做如此大规模的运维.

传统的运维模式还有一个更大的问题,它过于强调专业化.比如一个人是做网络的,他只做网络其他都不管,全公司可能只有他懂网络,因为他不停的在网络上投入时间,集中力气把这个事情做好.这样一个结果就是会发现运维部门没人能休假,一出事只有一个人能解决问题.不仅仅是网络,特殊硬件、一些第三方服务都存在这个问题.这就导致了知识没法共享,人灵活性受到限制,整个组织的灵活性也受限制.这个问题,我认为它最终形成了一个负反馈的循环,每个人之间越是互相隔离,越是没有办法提高,导致服务质量上不去.最大的问题是,招来更多的人其实也不解决问题,因为这个部署规模不断扩大,人之间的知识不能共享,所以招来的人只能运维新的设备,旧的设备还是这些人在做.

这是一个怪圈.回国之后我与很多公司的朋友都聊过这个问题.以前大家讲Oracle这样的公司存在老DBA,说老DBA都是难得一见的,深居简出,但是你有什么问题,只有他能解决,其实这在Google这个语境里这是一个比较不健康的状态.SRE的一大特点就是想请假的时候随时请假,每一个人都可以请假;当出现紧急情况的时候,当天值班的人真的可以处理他负责的这个服务所有的问题.

Google SRE的起源与特点

(编辑:开发网_开封站长网)

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

热点阅读