【51CTO专访】在之前的一次专访中，淘宝仲明简单介绍了阿里运维部的代码发布机制、监控机制和故障响应机制。今天，我们邀请到了SinaEdge平台运维主管刘宇，来谈谈他们那里的相关机制。本文是采访的***部分，介绍其代码部署机制。
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了。我觉得在我们大平台来讲，这是个比较新颖的方式。
