什么是灰度发布，其要点有哪些？

最近跟几个聊的来的同行来了一次说聚就聚的晚餐，聊了一下最近的工作情况如何以及未来规划等等，酒足饭饱后我们聊了一个话题“灰度发布”。

因为笔者所负责的产品还没有达到他们产品用户的量级上（最低的都在1千万+），也就谈不上灰度发布这一环节，所以只有听的份。

虽然笔者暂时没有涉及到，但在工作中也听过关于灰度发布的一些信息，只不过这一次听他们几个交谈后更是增长了不少知识，为了让自己更加的了解这一个“新”概念，回到住处就在网上慢慢的“啃”起来，下面则是我对“灰度发布”的理解，现分享出来。

我理解的灰度发布，主要是按照一定策略选取部分用户，让他们先行体验新版本的应用，通过收集这部分用户对新版本应用的反馈（如：微博、微信公众号留言或者产品数据指标统计、用户行为的数据埋点）以及对新版本功能、性能、稳定性等指标进行评论，进而决定继续放大新版本投放范围直至全量升级或回滚至老版本。

答：灰度发布（又名金丝雀发布）是指在黑与白之间，能够平滑过渡的一种发布方式。

在其上可以进行A/B testing，即让一部分用户继续用产品特性A，一部分用户开始用产品特性B，如果用户对B没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到B上面来。灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度。灰度期：灰度发布开始到结束期间的这一段时间，称为灰度期。（来源于百度百科）

好处：

1. 提前获得目标用户的使用反馈；
2. 根据反馈结果，做到查漏补缺；
3. 发现重大问题，可回滚“旧版本”；
4. 补充完善产品不足；
5. 快速验证产品的 idea。

相关解释：

• 选定策略：包括用户规模、发布频率、功能覆盖度、回滚策略、运营策略、新旧系统部署策略等
• 筛选用户：包括用户特征、用户数量、用户常用功能、用户范围等
• 部署系统：部署新系统、部署用户行为分析系统（web analytics）、设定分流规则、运营数据分析、分流规则微调
• 发布总结：用户行为分析报告、用户问卷调查、社会化媒体意见收集、形成产品功能改进列表

【某宝的案例.来源网络】

产品需求收集和确定 –>； 技术方案出具和分工协调 –>； 开发编码 –>； 内部服务器环境的测试 –>； 联调（又名预发环境） –>； 小淘宝环境发布，内部员工喷喷喷 –>； 小流量（具体有多少取决于业务影响面）公网测试 –>； 收集数据写反馈 –>； 全量上线。

3、灰度发布的方式方法有哪些？

产品Q群、产品微信群、内部用户、app自升级、换量渠道、不会被抓包的小市场，在这些渠道将灰度包放还出去。这里边可控度最强的当属app自升级了。根据时间段，用户版本，升级请求数量，实际升级数等等

4、灰度发布三大类型？

1. web页面灰度：按照ip或者用户id切流啊。具有随机性，可以控制比例
2. 服务端灰度：考验主系分能力了，可以做逻辑切换开关，按照义务相关属性逐渐切流
3. 客户端灰度：一般按照用户逐渐推送包，主要是PC端(WIN，MAC)、移动端（安卓，OS）内部大规模内测

即选取哪些用户先行体验新版本，是强制升级还是让用户自主选择等。可考虑的因素很多，包括但不限于地理位置、用户终端特性（如分辨率、性能）、用户自身特点（性别、年龄、忠诚度等）。

对于细微修改（如文案、少量控件位置调整）可直接强制升级，对于类似新浪微博改版这样的大型升级，应让用户自主选择，最好能够提供让用户自主回滚至旧版本的渠道。

对于客户端应用，可以考虑类似Chrome的多channel升级策略，让用户自主选择采用stable、beta、unstable channel的版本。在用户有明确预期的情况下自行承担试用风险。

6、A/B测试云服务提供商

海外应用：optimizely

国内应用：AppAdhoc（简单够用）、optimizely（相当强大，尤其在native app A/B测试这块）

7、延伸阅读：

2015年5月31日，马化腾在香港大学李兆基会议中心大礼堂举办了一场创业演讲，演讲中爆了一个大料：微信的诞生史。

微信在诞生之前，在腾讯内部有三个团队在同时做微信，主要竞争者为张小龙的e-mail团队和手机QQ团队。做这个产品之前，腾讯内部并没有给这个产品定一个完整的基调，而是让公司内部形成一个激烈的竞争，通过观察用户对产品的喜好程度和产品的实际完成情况决定上线结果。

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

说的再直接点，这也是马化腾创新上的灰度机制：容忍失败，允许适度浪费，鼓励内部竞争内部试错。马化腾说过，在产品研发过程中，我们还会有一个困惑：自己做的这个产品万一失败了怎么办?

我的经验是，在面对创新的问题上，要允许适度的浪费。怎么理解？

就是在资源许可的前提下，即使有一两个团队同时研发一款产品也是可以接受的，只要你认为这个项目是你在战略上必须做的。

很多人都看到了微信的成功，但大家不知道，其实在腾讯内部，先后有几个团队都在同时研发基于手机的通讯软件，每个团队的设计理念和实现方式都不一样，最后微信受到了更多用户的青睐。

你能说这是资源的浪费吗？我认为不是，没有竞争就意味着创新的死亡。即使最后有的团队在竞争中失败，但它依然是激发成功者灵感的源泉，可以把它理解为内部试错。

具体内容，请参考：《马化腾致信合作伙伴：灰度法则的七个维度》

1. 需求度：用户需求是产品核心，产品对需求的体现程度，就是企业被生态所需要的程度；
2. 速度：快速实现单点突破，角度、锐度尤其是速度，是产品在生态中存在发展的根本；
3. 灵活度：敏捷企业、快速迭代产品的关键是主动变化，主动变化比应变能力更重要；
4. 冗余度：容忍失败，允许适度浪费，鼓励内部竞争内部试错，不尝试失败就没有成功；
5. 开放协作度：最大程度地扩展协作，互联网很多恶性竞争都可以转向协作型创新；
6. 进化度：构建生物型组织，让企业组织本身在无控过程中拥有自进化、自组织能力；
7. 创新度：创新并非刻意为之，而是充满可能性、多样性的生物型组织的必然产物。

之前参加一个线下分享和朋友交流，才知道有些同行不知道苹果官方有提供灰度发布的机制，所以今天给大家介绍一下这个机制。

如果你登录 itunes 后台，你就可以看到在应用版本号的最下方，有“Phased Release for Automatic Updates” 一项。如下图：

 

1.jpg

这个 Phased Release for Automatic Updates，就是苹果提供的灰度机制，只是苹果把这个叫做自动更新的分阶段发布。点击上图中的 “Learn More"，你可以看到这个功能的详细说明。

该灰度发布机制将灰度分为七天，七天共七个阶段。第一天发布 1%的用户，第二天发布 2%，之后快速上升，第六天发布 50%用户，最后一天发布到所有用户。具体的进度表格如下：

 

2.png

当你在灰度发布时发现严重的 Bug 怎么办？别着急，苹果允许你暂停当前的版本发布。按官方的文档描述，你可以在灰度开始后的 30 天内无限次暂停发布。暂停发布之后，你可以选择提交一个新的版本来修复这个 Bug。

但是，需要注意的是，已经升级到你的灰度版本的用户，是无法让他回退应用版本的。具体为什么，大家可以想想。我觉得很可能是因为很难保证应用回退时数据是兼容的。这也是为什么 iOS 的备份也不能降低恢复到低版本中的原因。

觉得 7 天灰度太慢？没关系，苹果也考虑到了这一点。你可以在灰度阶段的任何时候，选择直接 100% 发布。这样你可以提前结束掉灰度的过程。

官方文档：https://itunespartner.apple.com/en/apps/faq/Managing%20Your%20Apps_Submission%20Process

我们仔细研究了文档以后发现这次的所谓的“自动更新的分阶段发布”就是某种程度上的灰度发布。如果发现版本更新存在问题，可随时暂停分阶段发布。分阶段发布累计最多可暂停 30 天，暂停次数不限。这样做可以加速产品的发布进程，同时降低新版本发现致命BUG的影响。在运营层面，经常很多产品好不容易混到了苹果的推荐位，每天带量几万到十几万，总榜分类榜都借助推荐位维持一个较高的榜位。但是，产品更新的时候一个类似闪退的BUG，导致苹果不得不把产品从推荐位拉下来，以后再上推荐位变得极难，损失巨大。今后这个情况可以得到一定程度的缓解。看上去确实很美，不过仔细一想好像又觉得是不是差了些什么：

— 只能选择老用户更新时的灰度，也就是说新用户安装的都是新版，一旦有bug就是100%命中！

— 在群户群体的选择上是随机的，抽到的用户不能代表全局用户特征，统计误差也许很大、也许很小，谁知道呢？碰运气！

— App Store灰度发布的新版本一旦出现问题是无法回滚的，在修复版开发完成重新发布审核上架之前，已经更新的用户只能继续用bug版本！

— 只能针对大版本的做灰度，而无法针对功能模块甚至代码片段做灰度。

那么，一个更加完善的“分阶段发布”应该是什么样的呢？

— 应该是支持定向受众的，可以根据具体的场景选择在全体用户中灰度发布还是仅针对新用户或者仅针对0以下用户或者iPad用户等，还支持自定义用户标签（比如“付费用户”、“VIP用户”），更可以进行组合筛选，比只能选择老客户有更大的自由度，适合更加复杂多变的具体业务场景；

— 应该是能够科学分流保证代表性的。在用户分组过程中采取多维度动态均衡的专利技术保障选择的样本（比如10%的新用户）和总体样本（所有新用户）在iOS类型、OS版本、浏览器类型、浏览器版本、系统语言、设备类型、设备名称、屏幕宽度、屏幕高度、应用版本、SDK版本等多重维度下都保持一致，绝不碰运气；

— 应该是可回滚可控制的。一旦出现BUG等互联网产品灾难，可以关掉灰度中的新版，所有用户回旧版。甚至可以不着急修复，先分析原因以便下次迭代优化。App Store只是可以让BUG影响面积减小，却无法把受影响的这部分用户从BUG中解救出来，治标不治本；

— 应该是支持不同模块的灰度，并且可以在一次App发版中包含一系列多个小的灰度发布，甚至和具体指标挂钩，比如：提升性能对服务器压力有多大；比如新功能对用户周留存是否有提升等。然后根据这些小的灰度发布的结果来决定发布哪些功能，回滚哪些功能，而且这些都不用发布新版。

其实Google Play早就提供类似灰度发布的功能，但是却始终没什么人用。除了国内的特殊情况之外，广大的国外开发者产品经理还是基于上述的原因选择其他的方案。各位国内开发者怎么办呢？不用急，广告时间到！

http://www.appadhoc.com/blog/tag/灰度发布/

作者：dangxy丶
链接：https://www.jianshu.com/p/2a02e0615176
来源：简书                  时间：2018.01.19