灰度发布初始阶段遇到的问题和策略

编辑导语：灰度发布（又名金丝雀发布）是指在黑与白之间，能够平滑过渡的一种发布方式；一个产品是选择全量发布还是灰度发布，需要通过实际情况来定；本文作者对此进行分析，我们一起来看一下。

之前参与了公司一款b端产品的重构项目，结束后就需要面对如何发布的问题，是全量发布还是灰度发布。

这需要根据实际情况来选择，当时我从“用户规模”和“新旧版本差异”两个角度考虑：

1. 用户规模：该产品用户规模大，涉及不同用户版本，不同版本的用户对新版本的接受度不同，可能存在不习惯新版本而导致流失的情况。

2. 新旧版版本差异：该产品重构后新版本相较于旧版本，部分功能缺失（白名单功能），会影响到部分用户的日常工作流程。

通过上述两个角度考虑，直接全量发布切换可能会影响到用户的日常工作和使用习惯，存在流失的风险，所以采取了灰度发布。

确定发布方式后，在选择首批灰度用户名单时，发现了一些存在的问题，本文就想和大家讨论初始阶段遇到的问题以及解决办法。

一、什么是灰度发布

灰色是介于黑色和白色之间的颜色，灰度发布就是介于未发布和完全发布之间的一种发布方式。

假定未发布的版本为A，通常为线上版本；完全发布的版本为B，通常是新版本。

灰度发布可以让一定百分比的用户优先体验版本B，其余用户仍然使用版本A，并且慢慢扩大百分比，最终将所用用户迁移到版本B。

那么为什么要进行灰度发布呢？

从开头我司的案例可以看出，灰度发布有一个隐藏的前提条件，用户规模远大于生产团队的规模；以至于生产团队没有足够的资源来应付全部用户使用新版本后带来的问题，包括不习惯所带来的不适应和线上bug。

而灰度发布可以通过控制发布面积，让使用新版本的用户控制在生产团队可以应付的范围内；将可能出现问题的用户圈定在“部分”用户，这个部分的范围由生产团队评估得出。

我们通过灰度发布，将一部分经过筛选后的用户纳入测试范围，由生产团队和用户共同完成对新版本的验收；主要的目的是检验了用户对于新版本的接受度，规避了因为产品决策冒失、冒进所带来的风险。

同时也可以检验产品质量，是否存在bug，以及在不同设备不同环境下的情况。

二、问题和策略

灰度发布帮助我们选定了一定比例的用户，是一种有效控制风险的发布方式。

但是在其初始阶段，也会存在一些问题，针对不同的问题，我们需要采用不同的策略来对应。

1. 新版本部分功能缺失

在现实场景中，受到了时间、资源和优先级等因素的制约，新版本相比较于老版本存在部分功能缺失的情况，常存在于大型版本迭代更替的过程中。

这种情况下，在选择首批灰度名单的时候会出现一个问题——引入的用户中存在依赖这些缺失的功能，导致用户的日常工作收到了影响。

b端产品的功能是解决用户工作中的问题的，功能缺失会导致用户的工作流不完整，影响到了用户的工作流；会造成用户的损失，也会让用户产生新版本不如“老版本”功能稳定的想法，从而放弃对新版本的使用。

因此，在面对这一问题时，需要我们在选择首批灰度用户时，对用户名单进行过滤和筛选。

具体的做法是：首先对比新版本和老版本的功能差异点，比如老版本有而新版本无的功能等；其次，评估每个差异点所带来的影响，是否真的会对用户的工作流产生影响，只有存在影响用户工作的差异点，才需要被解决；最后，在选择首批名单时剔除这些被影响的用户，同时通过迭代及时补上这些差异点。

案例：

某产品提供了对淘宝店铺的数据统计能力，其中有1个模块是对“预售”商品数据的统计；在最近的一次产品重构中，受限于时间的关系，以及评估“预售”模块是一个周期性的行为，在大促前会被商家频繁使用；平日使用到的商家非常之少，在本次产品重构中，没有做这一功能。

那么对于那些平日里也有“预售”商品，需要查看“预售”数据的商家来说，新版本就是缺失的，并且影响到了他们的日常工作流程，会对新版本产生不满的情绪。

上述的情况，就是出现了“新版本部分功能缺失”的现象，虽然平日使用该模块的商家数量非常少，但是如果引入的灰度名单中有这样的用户；缺失“预售”模块的新版本会影响到用户的正常工作，没有办法对预售商品的数据进行分析了。

这就需要我们在选择名单时剔除这部分用户，并且安排资源迭代“预售”模块

2. 覆盖不了全部用户