灰度发布（灰度测试）概念

如果软件要在不久的将来推出一个全新的功能，或者做一次比较重大的改版的话，要先进行一个小范围的尝试工作，然后再慢慢放量，直到这个全新的功能覆盖到所有的系统用户，也就是说在新功能上线的黑白之间有一个灰，这种方法也通常被称为灰度测试。类似于我们通常所说的内测。

灰度测试就是将自己的产品首先拿出来给一部分目标人群使用，通过她们的使用结果和反馈来修改产品的一些不足，做到查漏补缺，完善产品的功能，使产品的质量得到提高。这样产品尽早的与用户接触能为以后产品的正式发布打下基础。

灰度发布，又名金丝雀发布，或者灰度测试，是指在黑与白之间能够平滑过渡的一种发布方式。

在其上可以进行A/B testing，即让一部分用户继续用产品特性A，一部分用户开始用产品特性B，如果用户对B没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到B上面来。

灰度发布是对某一产品的发布逐步扩大使用群体范围，也叫灰度放量。灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度。

灰度发布的意义

现在的许多互联网产品的用户规模都是非常大的，版本更新也比较频繁，每当有新版本进行更新或者上线的时候，新的版本都是要承受非常大的压力，而灰度测试则可以很好的规避这种存在可能性非常大的风险问题。

灰度发布能及早获得用户的意见反馈，完善产品功能，提升产品质量，让用户参与产品测试，加强与用户互动，降低产品升级所影响的用户范围。

灰度发布流程

灰度期：灰度发布开始到结束期间的这一段时间，称为灰度期。

• 1、定义目标
  选用了灰度发布这个方法，就首先要确定目标是什么，比如通过让一部门用户先使用产品，从而通过试用结果和用户的反馈来找出产品的不足，从而想办法来提升产品的品质，还有的除了这个目的之外可能还想要借此机会来推广自己的产品。

• 2、选定策略
  根据产品的规模和功能的多样性来确定互联网灰度发布试用用户的规模和发布的频率，这样才可以提高用户的参与度，全方位的试用产品，这样才能反馈出一个比较全面的结果。包括用户规模、发布频率、功能覆盖度、回滚策略、运营策略、新旧系统部署策略等。

• 3、筛选用户
  用户的选择一定要具有代表性，要选择一部分的新用户和一部分的老用户来交替使用产品，还有就是选择的用户要具有敢问好问的精神，善于发现才能发现问题。选择完用户就是产品系统的部署，然后就是对用户参与的结果进行数据分析，找出产品存在的问题。对用户的筛选包括用户特征、用户数量、用户常用功能、用户范围等。

• 4、部署系统
  部署新系统、部署用户行为分析系统（web analytics）、设定分流规则、运营数据分析、分流规则微调。

• 5、发布总结
  用户行为分析报告、用户问卷调查、社会化媒体意见收集、形成产品功能改进列表

• 6、产品完善

• 7、新一轮灰度发布或完整发布
  上述步骤全都完成之后，互联网产品的灰度发布就基本上是完成了，后续最重要的事情就是全身心的投入对产品的改进中，对产品的不足进行完善，如果产品的漏洞比较大，可以进行再一轮的灰度发布，如果只是一些小问题，那么在修改之后就可以正式的发布了。

灰度测试的要点注意

1、精确的流量分发控制

流量分发控制是一切的核心。从运行和维护风险控制的角度来看，有必要在一个精确的范围内控制受影响的流量。在上线前就知道哪部分用户会有问题，而不是真出问题谁受到影响都不知道。一个常见场景是新版本只允许公司内的员工访问它，然后推送到一个城市再到一个省。

从产品的角度做A/B测试，需要控制测试样本，其中用户是版本A，哪个用户是版本B，应该在发布后修复，而不是一会访问A，一会访问B。传统的负载均衡器策略只能实现粗略的比例分配，并且没有细粒度的流量规则控制。
理想的灰度发布系统应具有非常细粒度的流量规则，例如匹配Android用户，匹配特定区域中的用户，甚至组合多个条件以匹配特定人员。

2、监控系统的支撑

准确的流量分配只是第一步，获得关键指标的多个版本更为重要。对于操作和维护，可能需要查看系统级指示器，例如错误率，吞吐量，延迟和CPU内存消耗这些系统层面指标。对于产品，可能是由于pv，uv等业务指标的变化。这些需要能够收集和显示数据，以方便后续决策：完全推送还是回滚？使用方案A或B？否则，灰度版本不会带来更多业务推广，也不能更好地了解业务状态和用户行为。

3、灵活的发布系统

灰度发布不是短暂的过程并且可能持续很长时间。
例如：主要框架或系统更新可能会持续很长时间。有可能整个服务在几个月内都是新旧并存，甚至可能需要分别进行两个版本的迭代。从产品的角度来看，它可能更灵活。很可能在线上有五到六个程序来收集数据。每天有了一些新想法都要上一些小版本看效果，每个版本上线后可能都要再各自做优化调整观察效果。这种情况可能线上就永远不会有一个统一的版本灰度反而是个常态来应对不断变化的需求和挑战。

而发布系统也需要做相应的调整，不在把每个服务看成一个单一版本的运行体，只在更新的短时间内出现多版本共存，只允许全量推和回滚这种粗粒度策略。相反，多版本共存应被视为正常状态，允许迭代每个版本，并且可以在版本之间区分相应的监视日志信息，从而可以将灵活的发布系统与灵活的灰度策略相结合。