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