专访刘宇:探秘新浪CDN系统的代码发布机制

原创
运维 系统运维
今天,我们邀请到了新浪CDN运维部的刘宇,来谈谈他们那里的代码发布机制、监控机制和故障响应机制。本文是采访的第一部分,介绍其代码部署机制。新浪公司级别的代码发布主要是SVN,而CDN这边主要使用Git结合puppet来做发布。

【51CTO专访】在之前的一次专访中,淘宝仲明简单介绍了阿里运维部的代码发布机制、监控机制和故障响应机制。今天,我们邀请到了SinaEdge平台运维主管刘宇,来谈谈他们那里的相关机制。本文是采访的***部分,介绍其代码部署机制。

[[105787]]

SinaEdge平台运维主管 刘宇(守住每一天)

刘宇网名是守住每一天,大家可以在微博上跟他交流。同时,他也是LinuxTone.org的创造人之一,在自动化运维方向有一定的研究。另,他现在在招人,需要中高级运维,感兴趣的同学们可以去私信他。

以下为采访实录。

51CTO:刘宇你好,感谢您接受我们的采访!那么,先请你聊聊新浪CDN的代码发布机制是什么样的,使用了哪些工具,走的哪些流程。

刘宇:公司级别的代码发布的话,正常来讲是有两块,但我们这边主要用的是Git,然后Git去结合puppet这套来做发布。这是我们组专门做的,就相当于自己的一套比较简单的代码发布系统。

但是公司有一定的要求,就是代码是要在公司里面去存档的。公司那级别用的SVN。因为我们做代码的话呢,会先要在公司的SVN里面去走一遍。这一块其实也没什么,update上去就完了,就相当于是一个存档了。然后我们这块主要就是通过Git去发布。

51CTO:相当于一个代码库同时走Git和SVN。

刘宇:对。代码库是这样去存的。但是我们每一次的代码发布的话,会把它打成一个包。目前我们的仓库管理的话,主要是基于yum,因为我们线上大部分的设备都是CentOS,因此我们都通过yum去管理这个代码的版本。然后每次打版本的时候,如果不是重大的那种变更的话,比方说现在的版本是v1.1.1,那我们在发布一个新版本的时候呢,会把它打成v1.1.2,然后同时会打一个v1.1.3。这相当于一个回滚的机制。我打包是v1.1.1,然后我要升级的包是v1.1.2,我会把原来的v1.1.1的包,打成v1.1.3。

51CTO:相当于单数的是一支,然后双数的是另一支。

刘宇:对,就是相当于一种回滚机制。比方说,我要是说小范围的,因为这个时候发现v1.1.2有问题,我在回滚的时候没法去回滚到v1.1.1嘛。

51CTO:Git好像是可以回滚的吧?

刘宇:没有,这个回滚指的是在线上发布的时候。如果只是代码级别的回滚的话,那很容易去操作,我Git clone出来一个分支,check out这个分支,立马就可以回滚回去。我们也可以采用开源的capistrano来实现代码级别的发布。

但是如果你在生产环境中把它打包了,然后上线,要有一个逐步生效和配置的过程,因为有可能你的一个生产周期,不知道什么时候会有一个大的bug。这个时候回滚的时候,我们会有两个包。

一般上线变更,公司会要求有三个梯度。

所谓梯度,是按照重要级别去做的。不同的梯度,一个是审核的长度不一样。然后,如果你的是非常非常重要的一个代码发布,那么走的梯度,除了线上的一些流程之外,还会有些线下的流程,包括人工的审核,两个人的互相配合,两个人去做代码review,然后两个人去做上线的review等等。

51CTO:这个梯度是怎么决定的?

刘宇:根据影响范围,和上线的范围,包括我这个上线的代码的核心度,会影响到哪些主要的功能,然后会开一个小圆桌会议去讨论一下。通常它影响的范围会包括开发和运维,然后包括我们的boss会在一起去讨论。

51CTO:就比如说,微博,它的聊天功能要做一个修改。你们怎么决定它是三级中的哪一级?

刘宇:打个比方,比方说前端我们要做一些URL的合并,让来自一个用户访问10个的URL,如果是同一个App ID或者是同一个ID的内容,我们就把这个URL做一些合并,这样我们回源去取数据的时候可以只取一份。通常来说很多软件是不具备这种功能的,所以我们要自己要去开发,这就是一种功能。

在我们来讲,这是一个代码模块。那我们把这个模块上线的话,至少是一个***级别的变更。

51CTO:***级别?为什么呢?

刘宇:因为你不知道这个URL是不是会回源成功,是不是会回源去取真正的数据,有可能你会回源取不到数据,或者说这个URL会请求失败,对用户的影响,就是比方说5:1的比例能够出现一个故障。因为它直接面对用户。因为是用户的URL请求的时候在回源去回数据,那么有可能这个用户,你合并的时候出现了问题,或者说你没有合成功。没有合成功也好,你就单独回去取数据,但是你不知道的原因,就是你有可能合了,但是你回源没有取数据,对吧。或者说你在合的时候这个地方判断失误。

51CTO:这种就属于级别***的了。

刘宇:嗯,可以把它列为级别***的。在判断它是不是级别***的时候,其实没有特别鉴定的标准,最重要的是根据影响来的。根据它对用户的影响。

51CTO:那如果是一个比较冷僻的产品,或者只是某些性能上的调整,可能级别就低一些?

刘宇:低级别的话,可能我只是上线一个测试的一个模块,对线上影响是几乎没有的,我们可以把它定义为不是非常重要的变更。

51CTO:相当于是由技术经理来做一个初步的判断。

刘宇:对,我们做一个初步的判断。

51CTO:那这个部署的时候也是先从一台服务器开始,再部署十分之一,再推送这样么?

刘宇:目前我们的部署,我觉得不是很智能,还没做到那种像Akamai他们那种级别,或者像Facebook他们那种BT的部署方式,我觉得是很牛叉的。我们目前部署的话,至少可以做到程序员他们那边自己的代码程序,在线上是经过一轮测试的。他们自己的一轮测试是不需要我们运维去干预的,因为这块时间是可以省下来的。他们自己会有单独测试的环境。

51CTO:从开发提交到运维组,中间会有一轮测试么?

刘宇:这个地方目前是没有人员介入的,会自动完成。所以说,它的这个版本,开发在自己的环境里面测试稳定了,才会去提交这个版本的发布。这个版本发布的时候,***个梯度上线的情况下,我们是不需要去干预的。它会先上线到我们提供的一台不是很重要的一个服务器上去,只是一台,然后这台监控的话力度是跟其他的不一样的,它的力度比较大。

一方面它的监控力度会比较大,另外每次也会根据它的功能去调整。如果说缺少某一项功能,那么在没有旧功能的情况下,就会去增加,开发自己也会去做一些,因为开发对它这个功能的模块是比我们运维要熟悉的。因此,它会在这个层面上面去做一些二十四小时的监控,以及一些人为的查看,以保证它的稳定性。一般我们的这个时候的周期一般在一两天。

然后,开发会提代码上线的需求,这个时候会走一些流程,然后我们就会进行一些判断,比方说它是重要级别是多少,比方是一二三,三级别就是重要级别,那我们就会让他去说,你这个上线周期可能会要到一个月。

我们按灰度上线,***的灰度其实是有一个月,有时甚至是有三到五个月。因为我们出现过那种变更,潜伏了个把月,然后再爆发出问题的。

51CTO:这是有可能。

刘宇:所以说公司对于这种灰度级别的重要变更,这些事情把握得比较严;但一年来说,一个平台也就那么一到两回。

如果是特别重要的那种,架构改变的情况下,那是另外一套单独的审批流程。

51CTO:那个比级别三还要高?

刘宇:对,那个都不在代码发布系统里面了,公司会有专门的架构评审,组织委员会对架构进行评审,各个细节的,更加复杂了。因为公司,反正从微博弄一直到现在,出了N多故障,其实是很正常的对不对。这其中可能有百分之九十几,都是变更造成的。要不就是我变更的时候你没有确认,然后完了,我就不管了。行,今儿没问题,明儿没问题,后天啪——全挂了。

51CTO:意思是开发变更的时候,运维没确认?

刘宇:对,要不就是运维A变更了,运维B没有跟进,会出现类似于这样的事情;要不就是运维变更完了,开发没有确认。因此公司为了杜绝这个事情,会要求每次变更的时候,灰度一级别的情况下,你不需要干预,做就行了;到达高一层级别的,就必须要有两个人做这个变更,一个做一个review。到达***级别的情况就更不用提了,更多人会参与进来。

我说没有做到像Facebook那种级别,就是因为人家改代码上线是在全球的,那种BT发布系统,并且采用了一个算法,把变更推送给体验用户,只有体验的用户才会看到这个变更;有可能你不是体验用户,那我给你看到的不是新版。我看到的是新版,我有问题,我会根据后台的一个界面,然后反馈所有的bug,然后提交上去。所以说,我们现在还不是这种牛逼的级别,因为这种东西一般会针对客户端,而在于CDN厂商来讲的话,一般来讲要做得这么细致的情况下,可能会是发散到全国各个机房,每个机房里面去做一台服务器的变更,然后这个没有变更,这个没有问题了,然后再扩充。我们现在只是到一台服务器,然后再到一个节点,一个节点确定没问题之后,然后再做灰度的慢慢逐步上线。这个变更的周期也是根据梯度来的。

51CTO:你们这边做测试时用什么工具?

刘宇:我们代码review都是叫开发自己做,我们不需要再做代码的review。开发那边会有开发的一套代码review的流程,除了开发人员之外,还有开发经理在做。

我们更多的是关注于它的稳定性,它是不是有一些重大的bug,或者安全漏洞,然后会不会有一些很低级的那种错误,比方说它不规范,我们都会打回去。类似于这样的情况。

51CTO:比如注释做的不全之类的?

刘宇:对,这种都会。

51CTO:能不能具体说说,每个梯度需要多少人,或者是什么级别的人来审核?

刘宇:***级别的灰度比较低,通常两个人审核就够了,一个是开发主管,一个是运维主管,两个人作为审核,交叉审核,交叉审核之后依然没什么问题情况下,就会有一个人去实施,这样的一个流程就够了。所以实施就是运维一个开发一个,也就是说干活的人有两个,审核的人有两个,这个级别相对还是比较容易的,不会有太大问题。

往上一个级别后,会多一个经理进来,也就是开发主管和运维主管的上级。

第二级别的变更,其实是根据它上线的这个代码的功能情况去做判断,一般来讲会根据它的影响范围,判断它是灰度几,就是看它上线的这个东西会对用户有多大的影响。

未知的更不用说了,如果都不知道会有什么样的影响,那么就对不起了。每次上线的时候开发都必须跟我们去讲,讲明白这个东西是做什么用的,然后运维根据它这个需求去查一些相关的资料,去看一下可能会对线上造成什么影响。因为并不是所有的领域每个人都很精通嘛,我们只要把握在我们的关注点就行了,对我们而言,稳定***。

第三级别的话就是说,如果它上线的这个模块,对用户的影响是我们可以评估出来的,我们就会直接走到我们的部门总监那里,在部门总监那边走审批。部门总监那把握度就会不一样了,它那个级别的话,除了走线上的流程,还会走一些线下的流程。线下的流程可能就是一个指示单,然后会有一些协议,然后这个时候参与人员会变成运维两个,开发两个,就是在真正实施的时候,除了刚才我们说的局部到全局慢慢上线的之外,然后实施人员会变成四个,实施周期会变成至少一个月。

51CTO:这个周期是指上线之后还有监控观察的周期?

刘宇:对,比方说我上线了一台服务器,这个一台服务器你至少要观察七天,相当于一周。然后,你在上线到一个节点的时候,必须要观察两周,就类似于这样的情况。然后观察完成之后,你再逐步再上线,直至上线完成。一般情况下,至少是一个月,很少说在一个月能全部都上线完成的。总监一般会跟进一下这个事情。

51CTO:那比如说我部署到一个节点,然后出了问题,会怎么处理?

刘宇:因为在每一个环节,我们每更新一个,然后会通告,然后在一周之后汇报一下这个情况,如果ok,没有问题,然后再说明我在继续下一步,会做什么事情。然后到下一步之后,如果说出现问题了,在出现问题的情况下,就会走最开始我们说的那个版本回滚的机制。也就是说,现在它的版本已经更新到***版本了,我们在puppet只需要在后台去改一下,然后可以立马实施生效的,回滚非常的快,直接就完成回滚了。

51CTO:这相当于v1.0.2变成v1.0.3。

刘宇:没错,这相当于我们小版本往前走了两个版本,实际上v1.0.3和v1.0.1是一样的,实际上做变更是没有做,但是至少我们通过这样的方式就已经保证它的运行,并且回滚的非常快。

51CTO:对,而且这样你就能知道中间做了什么。

刘宇:没错,毕竟我知道这个v1.0.2里面有什么问题,它有哪些bug,等等。如果这个时候再想要变更,那这个时候就要等到v1.0.4和v1.0.5了。我觉得在我们大平台来讲,这是个比较新颖的方式。

 

责任编辑:yangsai 来源: 51CTO.com
相关推荐

2013-07-24 15:21:32

CDN故障响应

2013-07-22 13:51:24

监控CDN服务器刘宇

2015-08-03 17:29:11

个推

2014-08-25 09:03:44

HuluSpark On Y

2023-06-07 15:25:19

Kafka版本日志

2012-08-28 17:04:27

2021-01-06 09:01:05

javaclass

2009-08-25 15:30:55

DataGrid We

2014-10-21 09:52:35

智能硬件智能家居

2013-08-28 17:35:35

监控故障告警雅虎

2012-12-25 16:26:40

Linux运维趋势

2010-03-29 16:48:18

Nginx内核优化

2009-03-11 10:29:23

代码契约.NETCLR

2010-02-07 14:54:13

Android

2011-12-23 15:56:02

2015-09-02 15:26:13

环信

2009-07-09 18:15:42

JDBC事务处理

2015-04-24 11:32:40

腾讯手游运维

2012-05-30 17:34:01

2010-09-08 08:55:00

后台架构数据库SNS网站
点赞
收藏

51CTO技术栈公众号