背景
上个月我们APP的新首页刚上线，就因某个接口的查询量过高，导致部分用户更新异常。事后团队小伙伴复盘反思，最终决定尽快启用灰度发布。下文是根据几次沟通会议整理的总结，也欢迎有类似经历的小伙伴们留言分享；
什么是灰度发布
在色彩中，灰是介于黑和白之间的中性色，它可以和任意颜色搭配在一起，不用担心犯错。
在产品发布中，灰度是介于旧版本和新版本之间的过渡方案。即先挑选部分用户，只对被测用户开放升级新版本，并通过数据观测和用户反馈及时调整灰度比例。
用好灰度发布，不但提升产品稳定性，还实现快速验证，快速迭代，最重要的是想什么时候发就发，再也不用熬夜了。不过灰度发布通常适用于用户量级相对较大（百万级以上）的或者公司对产品稳定性指标要求比较高（998↑）的产品；
提到灰度发布，做产品的立马会想到A/Btesting，虽然两者在逻辑上有点类似，但区别在于：A/Bt使用者主要是产品经理，是同一时间纬度来观察产品运营层面的数据，以便提高决策的准确度，比如评估2个banner图哪个转化率更高；而灰度发布的使用者主要是运维团队，通过控制产品可访问的用户流量，降低不确定风险，保证产品稳定性。
APP如何实现灰度发布
虽然原生APP拥有较高的用户体验，但投入研发/测试成本很高，因此越来越多的发展中公司或业务驱动型公司会采用hybrid开发，对灰度发布的要求也更个性化，这里分享下我们的灰度方案；
原生APP的灰度方案：上传多个安装包，新版本推送给指定的用户，比如下图，APP版本要从1.1.1升级到1.1.2，由于1.1.2有一些不确定的风险，为了降低线上异常，因此只切25%的流量，小范围试错；对于用户来说，仅25%的用户会提前下载到新版本1.1.2，其他用户无感知；
当然产品经理也可以根据用户属性来挑选用户，由于我们是针对网点内部用户的，因此我们常用的就绿色标记的两类属性；
除了推送安装包给指定用户，2B的产品还可以通过微信群发送灰度版本的下载二维码（企业内部用户的天然优势，除此之外平时还可以维护一些活跃的种子用户群），可以帮助产品更快的获取到相对真实的反馈；
但原生APP的这种灰度方案，一旦需要回滚，就需要再把旧版本重新打包，重新定义新的版本号后再对被灰度到的用户发布更新，才能回滚到旧版本，原因是客户端只能往高版本更新。
针对H5研发后接入的应用菜单，这类的灰度方案跟pc端产品类似。由于我们的产品只有在新老版本切换的时候才会做灰度，因此我们的做法是：前端产品通过本地缓存保存灰度用户种子，运维团队配合做nginx转发，根据随机种子和灰度比例进行新老版本的跳转。
关注公众号【零点零壹】 ，在产品的路上 和玉米大人一起 每天进步一点点；
网友评论