灰度测试方案

背景

通常对于已经上线的项目进行迭代的时候，会有一个灰度的过程，具体是将新功能部署到一部分的系统环境中进行测试，观察其性能和稳定性，这种方式主要是为了能在全面上线之前发现并修复潜在的问题，从而降低上线的风险。

案例场景

淘宝首页需要上线双十一的内容，但由于淘宝的用户量比较大那么在全面上线之前先进行部分灰度，例如总用户的1%，然后在灰度期间观察该部分功能的接口性能、错误率、投诉量等用户的声音，当观测到一定程度额时候就可以在此基础上进行增加，例如增加至总用户量的50%，以此类推最后全量上线。

实现方案

作为服务端后端开发，我们需要关注的就是如何实现灰度的控制，并且在灰度过程中如何监控接口的性能、稳定性，通常的是实现方式有以下几种：

一、用户id

也是在测试过程中经常使用到的，通过配置来进行保存用户id，然后在请求灰度功能时判断当前请求的用户是否在灰度配置中，如果在则返回新的接口数据，否则直接拦截忽略。
在用户id的基础上又可以对某些用户群里进行打标，比如将一部分打上灰度用户的标，然后下一次需要进行对这部分用户进行灰度的时候直接对该标签进行灰度即可，达到复用的效果，如果再加上批量打标的话那么就能大大提高效率。

二、设备id

是用设备id主要还是在客户端的情况下使用，主要是获取用户的mac地址来作为唯一标识，实现方式也是和用户id类似，但是在web端的时候无法获取mac地址的情况下不太适用。

三、客户端版本

如果是有客户端版本的情况下可以使用客户端版本号进行灰度控制，客户端在请求服务端接口的时候携带上当前的客户端版本即可，通常使用的方式有以下几种：

1. 指定版本，例如置顶9.51.03N 
2. 指定版本范围，例如最小版本 9.1.0，最大 9.5.0
3. 指定最小最大版本，通常情况下置顶最小版本适用于新功能上线，指定最大版本适用于老功能下线

四、百分比

这个方式也是我在工作中遇到最多的灰度测试，通常情况下使用用户百分比进行灰度，也会用到设备灰度。
场景案例：上线了某个模块，那么前端进行适配通过灰度接口来获取是否需要灰度，需要灰度的话前端展示灰度内容，并且调用灰度功能。

五、IP

还有一种就是公司内网访问的白名单IP设置方式，在大厂叫做安全生产环境，目的是为了在公司内网的环境下模拟真实的线上环境，这个环境介于预发与生产之间。

通常情况下在代码正式发布到生产环境时，需要在安全生产把本次发布的代码跑到至少50%的代码覆盖量才允许继续发布线上，也可以理解为线上的回归测试，这个环境有效的避免了一些预发无法发现的问题，大大的降低了由新发布的代码上线造成系统异常。

线上真实投放节奏

首先在测试阶段确认没有问题，代码和配置上线后，收集小部分商家进行灰度，这个过程很短也就半天的时间。这部分商家灰度完之后开始按照百分比进行灰度，灰度的节奏为：第一天百分之1，第二天百分之10，第三天百分之30，第四天百分之60，第五天全量。

通常情况下小功能的灰度在一周左右，如果是上线大需求一般在2周到4周，最长不超过4周，有问题在这期间能够及时恢复，一般在灰度之前测试都测试的差不多了，灰度更多的是产品和运营收集用户的“声音”。