产品发布过程演进——移动贴吧分级发布实践

标签: 贴吧技术 灰度测试 线上测试 | 发表时间:2012-07-05 18:56 | 作者:editor
出处:http://stblog.baidu-tech.com

Tag 分级发布、线上测试、TIP

摘要

为了达到“在产品发布过程中,通过及时有效的发现和控制新引入线上缺陷的影响范围,保护用户体验,提升上线质量”的目的,我们在吸收和借鉴Facebook灰度发布等技术的基础上,探索出符合产品线现状的“分级发布”方案,并在移动贴吧产品线的实施中验证和改良。本文主要介绍贴吧分级发布的背景、方案、实施过程、实施效果和后续展望。

 

一、             背景

作为贴吧这样上亿PV的产品线,一旦有bug遗留到线上,影响的将是成千上万的用户,对产品形象有很大的伤害;对工程师来说,在各种高优先级的修复项目间疲于奔命,也在一定程度上挫伤士气,降低了效率。

那么有没有一种方法可以让我们“在既有的开发测试水平下,更快发现线下测试难以找出的bug,以有效控制产品缺陷的影响范围,提高产品质量呢?”

 

名词解释:

分级发布:在本文中是指把产品发布过程划分为多个级别,每个级别限制一定的流量和用户范围,并在每个级别对产品进行部署和验证的迭代过程。

TIP: Test In Product,即对线上产品进行验证(功能、性能等),本文特制对发布过程中的线上产品进行验证。

二、             需求和目标   

2.1.  需求概述

目前大部分产品线的发布方式是:一股脑把所有代码发布到线上机器集群,然后再由QA进行线上验证。其实代码也是分节点逐步部署的,但RD、QA都无法把请求命中到部署新模块的机器进行验证,RD通常只是在期间观察下错误日志,而这种方法很难有效发现线上bug,因此分节点发布其实对于控制质量风险也没有什么意义。

为了能对发布的代码做到心里有底,工程师们希望找到一种方法,能够在产品没有完全发布前进行有效验证,验证服务正常后再扩大部署的范围。

我们下文的“分级发布“方案,既是脱胎于这么朴素的需求。

2.2.  需求详述

在对Facebook灰度发布等业界比较领先的发布方案进行了深度调研之后,结合自身的特点,我们拟定了贴吧“分级发布“的需求。

从上文可以看出,要做到分级发布,有两个关键的过程:

1、  首先要能做到新产品可以分成多级逐步发布到线上

2、  然后就是对于新发布的产品,能够在线上进行及时有效的验证

 

分级发布在移动贴吧产品线实施的需求如下所示:

1、  分级流程:发布过程分为对内发布、小流量发布、全流量发布三级

2、  分流层次:只通过Webserver实现PHP UI层次的分流

3、  机器维度:对内1台UI机器,小流量1组x台UI机器;对WAPUI单机群划分

4、  流量维度:对内发布环境只有内部流量,小流量环境为内部流量+线上流量

5、  时间窗口:作为发布验证的必要条件,需要在相邻两级之间有约10分钟的暂停时间;为了不影响上线效率,C级项目总发布时间需要在半小时左右

6、  质量保证应用:以线上自动化和监控为主,人工check为辅

三、             贴吧分级发布方案

从质量保证角度出发,和传统的线下测试相比,分级发布带来了什么呢?

分级发布就像放慢镜头一样,把以往一次性的发布过程拉长了,系统地切分成了多个阶段,每个阶段控制了发布的范围,并可以单独进行验证。

拉长的发布时间,为发现和消灭bug带来了可能性;

而分级发布的过程,还带来了:

l  真实的环境:真实线上环境的功能验证(自动化、手工)

l  真实的流量:真实流量下的性能监控

l  真实的用户:核心用户众测(因为管理成本及时间周期暂未采用)

这些特性是线下测试无法获得的宝贵资源,也因为缺乏这些资源,即使拥有非常有经验的研发和测试工程师,也不能完美的控制线上缺陷。

3.1.  总体架构

要实现分级发布,需要多个平台和系统的配合,如下图所示:

1)         上线平台:实现新代码的分级部署

2)         TIP平台:部署完成后,驱动线上测试工具,验证每级服务是否正常

3)         分流系统:对测试流量和线上流量进行正确分流

对每个级别的发布流程可以描述为:

1)         首先通过上线平台将新代码发布到某一级机器集群

2)         然后通知TIP平台部署完毕

3)         TIP平台驱动测试系统和监控系统对新服务进行线上验证

4)         测试流量通过分流系统正确命中新部署服务

5)         工程师根据TIP平台收集的报表进行决策并反馈给上线平台

6)         上线平台根据反馈决定是否进入下一级发布

 

从技术实现上,主要需要解决流控基础设施(分流系统)和平台交互两大部分的问题:

3.2.  分流系统

分流层是实现分级发布“流量可控”这一目标最重要的基础设施。贴吧的解决方案是在Nginx中通过扩展开发实现分流,判断条件如下图所示:

1)         内网IP+pub_env=1(自定义cookie)的请求会强制命中对内环境

2)         内网IP+pub_env=2的请求会强制命中小流量环境

3)         普通线上流量基于一致性分流规则分流到小流量环境和其他线上环境

 

3.3.  平台交互

主要指上线平台和TIP平台之间的交互,迭代进行部署、验证的过程,如下图所示:

四、             方案实施

4.1.  关键任务

要实现分级发布,需要多个部门的紧密合作,任务表可划分为三个层次,如下所示:

1)         基础设施:通过Nginx和页面的改造,实现分流系统,作为分级发布的基础

2)         平台支持:上线平台和TIP平台开发,实现分级部署和验证反馈

3)         应用层:线上测试体系和发布流程建设

 

4.2.  实施收益

完成一期的开发工作之后,分级发布在移动贴吧试行三周(5.7~5.25),印证了分级发布对质量提升的确有立竿见影的作用,简述如下:

l  结果维度:

n  触发2次 小流量回滚(1次因为性能,1次因为功能)

n  触发1次 对内环境回滚(功能问题)

l  过程维度:

n  对内发布阶段发现3个功能问题,1个编译脚本问题

n  小流量发布阶段发现1次性能问题

n  其中1个功能问题属线下漏测;其余功能、性能问题需在线上真实环境、真实流量下才能发现

五、             关键技术

实施分级发布,涉及角色众多也需要大量的开发工作,本节对部分关键技术进行阐述,希望对计划实施分级发布的其他产品线提供一些帮助。

1、  运维节点划分 & 跨机房访问

           在线上部署为双机房的情况下,若把UI集群划分为:对内、小流量、全流量jx,全流量tc四个节点;那么这种只保留一个小流量节点的方案,违背了运维的一个重要原则——不要跨机房访问!当某个机房宕掉需要切机房的时候会出现白页。

 

考虑到双机房冗余及切机房服务的操作,正确的节点划分应保证每个机房有一个小流量节点,如下所示:

 

2、  一致性分流 & 负载均衡

分级发布拉长了上线的时间,我们必须保证在发布过程中UI层异构期间,用户的一致性体验是不受影响的:

1)       在发布过程中,用户不会一会儿访问到新产品,一会儿访问到老产品

2)       当新产品有缺陷时,只会影响到少量相对稳定的用户群,而不会波及所有用户

需要满足用户访问一致性,意味着不能再在Webserver层使用随机分流;而Webserver层的分流策略在满足用户访问一致性的同时,也必须考虑负载均衡。以Nginx的ip-hash策略为例,虽然能够保证用户一致性,但却可能造成UI层负载不均衡(某些大型机构的出口IP含有大量请求)。

综合考虑一致性和负载均衡,应选择类似baiduid这样具备更加离散特征的cookie项来做分流。

3、  配置入库 & 一键部署

因为OP的分级发布部署平台是以一键部署为基础的,所以产品线要做到分级发布,一个重要的前提就是被部署的模块(对贴吧来说是PHP UI模块)能够被一键部署;而要做到一键部署,就要先做到配置模板入库,然后在部署过程中将模板变量替换为真实的线上配置。这对于一些比较复杂的产品线来说,可能需要较大的改造代价,当然,对于已经实现持续集成上线的产品线,这就不是一个问题了。

4、  平台支持

在产品线的基础改造完成后,线上部署平台和TIP平台的实现和稳定运行,对于整个方案的实施,就有着至关重要的作用了。前者专注于分级部署和回滚;后者管理整个发布过程,并对TIP(Test In Product)提供支持。

5、  线上自动化

为了能够自动验证线上服务,需要把自动化case迁移到线上运行,并结合cookie的使用以令验证流量命中到正确的线上环境。

与在线下测试环境中运行自动化case相比,有一些特别需要注意的地方:

1)         设置cookie才能命中新发布代码的线上机器,case结束后需要取消cookie

2)         频繁登陆会被pass封禁

3)         规避antispam,验证码等问题

4)         线上提交流量对case验证及稳定性的影响

运行效率:可以考虑利 用分布式系统等方案提升自动化的运行效率

by  Chenjie&Zhouren&Zhulei

相关 [产品 移动 贴吧] 推荐:

产品发布过程演进——移动贴吧分级发布实践

- - 搜索研发部官方博客
Tag 分级发布、线上测试、TIP. 为了达到“在产品发布过程中,通过及时有效的发现和控制新引入线上缺陷的影响范围,保护用户体验,提升上线质量”的目的,我们在吸收和借鉴Facebook灰度发布等技术的基础上,探索出符合产品线现状的“分级发布”方案,并在移动贴吧产品线的实施中验证和改良. 本文主要介绍贴吧分级发布的背景、方案、实施过程、实施效果和后续展望.

移动产品设计之设计

- crystal - 互联网的那点事
移动产品设计最大的差异点在于用户使用场景的变化,场景的变化引发了交互方式巨大的变化,从而也使得信息呈现方式有所不同,再加上硬件设备的差异,最终使得2者千差万别了. 所以,移动产品设计之设计应该首先从用户的使用场景出发,同时考虑用户的硬件设备差异,综合以上2点去帮助用户完成某个任务. 按照我的理解,场景、任务、用户可以称之为设计的三要素,每一个设计实际上都是试图去帮助用户在某个场景下完成某个任务的.

移动产品设计新思路

- - 互联网的那点事
随着时代的变迁,移动产品的设计也有了更多的变化. 用户的需求越来越多、使用的场景也更加复杂. 也因此移动产品就有了更多设计的新思路. 当然,手机的玩法虽然不再被局限在有限的领域,但是对于那些更喜欢用手机拍核桃、钉钉子以及起瓶盖的各位童鞋,还是看看本次由朱坤 @kentzhu 分享的移动产品设计真正的新思路.

【365UCD】移动客户端产品——杂谈

- - 一个产品经理的博客...
365UCD的移动客户端项目部最近成立了,来分享一篇PD的感悟:. 2011年,是互联网产品大爆发的一年. 各种类型的互联网产品,营运而生. 各行各业都在赶,只要别人有的产品自己有条件的也要有,面对这样的一个环 境,产品变得华而不实,这类产品到底有怎么样的市场价值,是不是适合公司发展及产品的功能及定位有什么前景等等问题,变成了空白.

移动平台上的产品设计

- - 雷锋网
【编者按】本文由 @淘宝UED 团队所撰. 随着智能手机的产生,人们对它们的使用时间与粘性迅速加大,移动互联网的发展越来越迅猛,越来越多的PC端产品开始把注意力集中在转移到方寸之间的屏幕之上时,有如潮水般汹涌. 我们需要的就是适应在移动平台设计一个好的APP,以此获得自己的席位. 当下的移动互联网产业,已经从单纯的以实现单一功能为主,到平台的转移,再到各个APP之间的产业链的形成,还有广告植入的各种运营手段产生各种盈利.

» 产品过程管理 小威的世界——移动互联网产品经理 无线产品经理

- Temp - www.xwcool.com
产品部确实遇到了问题,但看到的还是积极解决的一面,产品部不是设计部,不再是个只会画原型的设计师,而应该对产品长期规划负责,对产品市场负责. 宁愿多做一点,少一点问题,而不应该由市场牵着东拼西凑出来的产品,更不是由每个不相关人员提出一个问题就应该为之解决的傀儡,产品经理需要强势,需要对整个产品强势,对于整个产品管理过程负责.

“智能手表”将融入惠普移动产品族

- Alex - 爱范儿 · Beats of Bits
Fossil Meta Watch ——这不是第一款“智能手表”,在它之前早已有了 Palm OS 的 AU5005,连微软和索尼爱立信也推出过试验型的产品. 但 Meta Watch 仍然带有鲜明的特色:它将完全融入惠普(HP)的移动设备产品族,减少信息流通的障碍,为大家描绘了一幅未来的移动互联网应用场景.

移动产品设计之硬件能力

- mornlee - 所有文章 - UCD大社区
如果你想猎杀一只虎你得首先搞清楚了虎的习性与弱点,不然就好比是绣花枕头的屠龙术. 同样的道理,如果你想做好移动产品的设计,你得首先搞清楚移动设备的基本属性. 知道移动设备有哪些能力才能驾驭这些能力并创造出优雅的体验. 在移动设备里,常见可以被利用的硬件包括:话筒、GPS、距离感应器、环境光感应器、影像传感器、磁阻传感器、重力感应器、方向感应器、加速感应器、三轴陀螺仪、RFID、NFC、裸眼3D、温度计、震动感应器等等.

经济学人:移动电子产品正超越PC

- kong - cnBeta.COM
10月8日出版的英国《经济学人》杂志特刊发表封面文章称,移动电子产品正在超越传统的PC,并将对整个社会产生深远的影响.