在如今的互联网时代，大厂都是采用灰度发布的策略进行应用线上部署的。如果身在小公司的测试同学想进入大厂，那么灰度发布就是大家必须要了解的知识点了！希望通过本文能够帮助大家快速的理解什么是灰度发布，并让大家了解研发，运维，测试，运营是如何在这一策略下开展实际工作的。

灰度发布定义

灰度发布（又名金丝雀发布）是指在黑与白之间，能够平滑过渡的一种发布方式。在其上可以进行A/B testing，即让一部分用户继续用产品特性A，一部分用户开始用产品特性B，如果用户对B没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到B 上面来。灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度。

马化腾的灰度机制是这样的：很多公司在一开始做产品定义时，要么确定它是黑的，要么确定它是白的。但是马化腾发现，互联网产品的定义是有用户投票决定的。在一开始，我们不定义它是黑，还是白，有一个灰度的周期。在这个灰度周期里，让用户的口碑决定它是生是死，是白还是黑。

灰度发布具体流程

灰度发布具体流程如下所示：

灰度发布流程细节如下：

1.在灰度发布开始后，先启动一个新版本应用，但是并不直接将流量切过来，而是测试人员对新版本进行线上测试，启动的这个新版本应用，就是我们的金丝雀。

2.如果测试没有问题，那么可以将少量的用户流量导入到新版本上，然后再对新版本做运行状态观察，收集各种运行时数据，如果此时对新旧版本做各种数据对比，就是所谓的A/B测试。

3.当确认新版本运行良好后，再逐步将更多的流量导入到新版本上，在此期间，还可以不断地调整新旧两个版本的运行的服务器副本数量，以使得新版本能够承受越来越大的流量压力。直到将100%的流量都切换到新版本上，最后关闭剩下的老版本服务，完成灰度发布。如果在灰度发布过程中发现了新版本有问题，就应该立即将流量切回老版本上，这样，就会将负面影响控制在最小范围内。具体流程如下图所示：

为什么做灰度发布

1、灵活选择用户参与产品测试。

2、规避一定的发布风险，降低产品迭代升级所影响的范围。

3、快速获取用户的反馈意见，完善产品功能，提升产品质量。

4、避免停服发布给用户带来不便。

5、具有容灾能力：降低全量发布引起的服务器崩溃等风险，逐步发布产品，逐步控制服务器压力。

灰度发布重点

定义目标

1.新功能验证（看这个新功能的指标是否能达到预期，或者是否会对产品造成损失，大多数是这个目的）

2.新功能尝试（看这个功能是否符合用户需求，不符合则下线）

选定灰度策略

用户选择：地理位置、使用终端

功能覆盖度：逐步功能开放还是全部功能开放

提供用户数据反馈入口，让运营人员能够及时了解用户反馈

公关运营

筛选用户

用户范围：内部用户 >活跃用户 >所有用户。

灰度发布上线

设定分流规则

灰度发布新版本

运营数据采集分析

分流规则微调

灰度发布>产品完善>新一轮灰度发布>完整发布

灰度发布问题

1、以偏概全

选择的样本不具有代表性，样本用户使用习惯并没有涉及所有升级的核心功能。

2、无法定量分析

结果没有量化手段，只依赖用户问卷调查，没有分析灰度系统。

运营数据不全面，只有核心业务指标，没有用户体验指标等。

3、用户参与度不够

如果用户参与度不够就很难对灰度版本的优劣进行分析评价

具体实施

运维同学

方式一，利用nginx配置负载控制

方式二，使用http头信息判断+权重（灰度值）

http请求传输过程中，会自动带上User-Agent,Host,Referer,Cookie等信息。我们需要分析ip地址段，用户代理，Cookie中的信息。根据Cookie查询version值，如果该version值为v1转发到host1，为v2转发到host2，都不匹配的情况下转发到默认配置。

方式三，使用灰度发布工具

从长远来看需要使用工具作灰度发布，业界相关工具包括：阿里acm、NepxionDiscovery、Istio

研发同学

1.版本控制

通过切换不同分支来选择上线的版本并制定打版回退策略

2.代码开关

一套代码，通过代码开关控制新功能上线与否。利用代码中的功能开关来控制发布逻辑，一般不需要复杂的发布工具和智能 LB 配合，是一种相对比较低成本和简单的发布方式。研发人员可以灵活定制和自助完成的发布方式。实现过程如下：

功能开关发布需要一个配置中心，通过配置中心，运维或研发人员可以在运行期动态配置功能开关的值。

新功能和老功能在同一套代码中，新功能隐藏在开关后面，如果开关没有打开，则走老代码逻辑，如果开关打开，则走新代码逻辑。

应用上线后，开关先不打开，然后运维或研发人员通过配置中心打开新功能，经过流量验证新功能没有问题，则发布完成；如果有问题，则随时可以通过配置中心切回老功能逻辑。

运营同学

监控新功能使用情况，是否使用频繁

用户满意度的监控，带来了新用户？导致老用户卸载？

测试同学

除了正常功能以外，还要确保每一台服务器上的应用功能都是可用的（灰度时验证，全部上线时还需验证）