SRE系列教程 | 孙宇聪：来自Google的DevOps理念及实践（下）
|
副标题[/!--empirenews.page--]
《SRE系列教程 | 孙宇聪：来自Google的DevOps理念及实践（下）》要点： 接下来聊一聊SRE的一些最佳实践,我认为Google做得比较好的几点. SRE的最佳实践建设平台化服务体系首先,Google现在是一个六万人的公司,涉及到的产品线可能一百多个,各个部门之间差距很大,而且Google全球几百个数据中心,有很多机器,它如何管理?如果按照国内公司的方式去管理早就累死了.因为国内很多运维部门从上到下什么都管,从买机器开始,一直到最上面安装服务器、调试,配网络,所以业务线、运维部门经常好几千人.Google做得比较好的一点就是它把一个东西横向切分,因为它很早之前就意识到很多部门或者很多人之间有共性?像现在国内有的公司也开始讲的,运维部门要输出能力,公司内部也要服务化,因为只有服务化才能让每个团队更加专业化. 所以回到Google这个平台上,我认为它实际上是不停的在切分,就是横向切分.首先最底下是所谓的资源供给层,就是相当于把数据中心这件事情真的当成了一个资源,可以服于用户.就是用户需要什么样的机器,配置架构怎么样,怎么设计数据中心,这些东西它都帮用户做好.有一个专门的团队去做这件事情,这个团队也有自己的研发,也有自己的运维,也有自己的operation、PM,什么都有. 往上是技术架构,技术架构是大家经常听说的Borg系统等,让一些比较通用的技术或者通用的架构都能形成平台式的东西. 再往上才是产品线,每一层实际上都有自己的SRE部门、运维部门,都是一个项目.所以把这个平台搭起来之后,上层的人可以越来越少关心底下的细节问题,一定程度的减少了他很多精力、减少了很多官僚主义上的问题.需要计算资源的时候就给资源,不是还要先去审批又买机器,什么样的机器,什么样的配置都不一样,所以整个公司是一个非常同质化的公司,很多业务底下共享的东西很多.工作在越底层的人如果能服务的人越多,就会产生一个所谓的放大效应.可能大公司都是这样的,它有平台化效应,底下的人可以搞出一个世界最好的数据中心,可以同时服务几十个产品线的业务；搞出一个更好的数据库,所有人都可以用,这是Google做得比较好的一点. 容量规划和容量管理然后大家会发现在做一个业务层运维的时候,可以关注更高级的东西,不是关心买什么样机器,而是更多关心到底需要多少容量,这些容量应该在什么地方.在YouTube我们经常在办公室摆一个世界地图,大家经常会讨论这里有一个数据中心,那里有一个数据中心,然后讨论在这边放多少容量,在那边放多少容量,它们之间如何灾备,我们可以考虑这些更高级的、更抽象的东西.这样的好处是可以真正的做到容灾,就是所谓的N+M.就是如果平时需要的峰值流量是N,M是作为灾备流量或者是这个冗余流量.N和M到底是什么?很多公司连自己的N都不知道,从来没有说过我们到底要处理多少流量,有些领导说我们“双11”想来多大量的就来多大量,这怎么能搞好? 这个问题是运维部门独特的功能或者独特的角色,要负责将把这个东西确定下来,我们到底要承担多大的流量,要有多少冗余.接下来就是验证这件事情,到底有没有这样的能力,能不能处理这么大的流量或者这么大的需求? Google有一个内部指标就是130%,比如可以处理1秒交易量是一百万,实际上集群的峰都是按照一百万的130%来处理.130%是负载均衡或者是一些外界波动导致的,它实际上是不平均的.我们可以说它是一百万条交易的负荷,但实际上不可能说一百万零一条这个系统就崩溃了.可以留一下窗口,留一些冗余量来处理一些操作中的未知性,还有一些特殊意外情况,所以130%是一个我们常用的指标. 在Google里面已经很少提灾备这件事情,就是对我们来说我们没有灾备容量,都是平均负载均衡的.可能有一些冗余,比如一个系统只能一千台机器,这一千台机器并不是说我有十台是不接受业务处理的,而是我们所有机器都是接受业务处理,只不过他们处理能力可能没有把所有的资源都用完.这也是Google有很多经验教训,如果一个东西老是不用的话,它就是坏的,你平时再怎么演习、怎么用,一到关键时刻它就过不去、它就是有问题,所以更多的时候压根不讨论灾备的问题,所有东西永远都是在线的,这也是为什么说想把Google.com给弄坏是一件非常困难的事情,得全球几百个数据中心同时出问题,才可能会出现不可用的情况.所以Google全球业务是不可能中断的,不管出现多大的自然灾害,它这个业务都是不可能中断的.可能只有局部地区受损,只有基础设施受损的地方,它才会有一些问题,所以这就是灾备. 实战演习另外一个更关键的一点是做实战演习.刚才也提到了,SRE以业务小组为单位,每周都会做实战演习,整个公司实际上每年也会做一次非常大的实战演习.我可以举几个例子,Google很多地方都有办公室,有一年某个办公室食堂的菜有问题,导致所有人都拉肚子进了医院.这是Google总部啊,一万人、两万人这样.于是我们就提出这样一个问题,说如果这个地方没有人来上班了,网站到底还能不能正常运行啊?我也曾经问过百度、腾讯,他们所有人都在一个大楼里,如果大楼突然断网了,公司还运转不运转?这是一个很大的问题,不管是地质灾害问题、自然灾害、人文灾害,这些虽然听起来好像比较极端,但确实能考验出一个组织的业务持续能力.实际上这是Google做得比较好的一点.刚才说的都是比较夸张的例子,是比较大范围的.一些比较小的例子,比如这个系统就是你这个小组负责,你们这个小组到底有没有单点故障,这个人是不是能休假,如果一旦出现问题是不是所有人都能去解决这个问题.我们经常互相出题去做这种测试,然后去分享一些知识.我想这更多是一种风气吧.首先你认同这个目标,目标当然就是把这个系统建设得更可靠.认同了这个目标,接下来就是不停地去考验还有哪些漏洞,并确保整个团队其他人也有同样的知识,同样的技能去解决这个问题. （编辑：核心网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
