本文主要是介绍浅聊灰度发布，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
浅聊灰度发布
1.缘起：
什么是灰度发布？
什么场景下需要灰度发布？
如何进行灰度发布？
2. 灰度发布：灰度很简单，发布很复杂
什么是灰度发布，其要点有哪些？
最近跟几个聊的来的同行来了一次说聚就聚的晚餐，聊了一下最近的工作情况如何以及未来规划等等，酒足饭饱后我们聊了一个话题“灰度发布”。
因为笔者所负责的产品还没有达到他们产品用户的量级上（最低的都在1千万+），也就谈不上灰度发布这一环节，所以只有听的份。
虽然笔者暂时没有涉及到，但在工作中也听过关于灰度发布的一些信息，只不过这一次听他们几个交谈后更是增长了不少知识，为了让自己更加的了解这一个“新”概念，回到住处就在网上慢慢的“啃”起来，下面则是我对“灰度发布”的理解，现分享出来。
我理解的灰度发布，主要是按照一定策略选取部分用户，让他们先行体验新版本的应用，通过收集这部分用户对新版本应用的反馈（如：微博、微信公众号留言或者产品数据指标统计、用户行为的数据埋点）以及对新版本功能、性能、稳定性等指标进行评论，进而决定继续放大新版本投放范围直至全量升级或回滚至老版本。
2.1、什么是灰度发布，有哪些好处？
答：灰度发布（又名金丝雀发布）是指在黑与白之间，能够平滑过渡的一种发布方式。
在其上可以进行A/B testing，即让一部分用户继续用产品特性A，一部分用户开始用产品特性B，如果用户对B没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到B上面来。灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度。灰度期：灰度发布开始到结束期间的这一段时间，称为灰度期。（来源于百度百科）
好处：
- 提前获得目标用户的使用反馈；
- 根据反馈结果，做到查漏补缺；
- 发现重大问题，可回滚“旧版本”；
- 补充完善产品不足；
- 快速验证产品的 idea。
2.2、那么灰度发布的流程是咋样的呢？
相关解释：
- 选定策略：包括用户规模、发布频率、功能覆盖度、回滚策略、运营策略、新旧系统部署策略等
- 筛选用户：包括用户特征、用户数量、用户常用功能、用户范围等
- 部署系统：部署新系统、部署用户行为分析系统（web analytics）、设定分流规则、运营数据分析、分流规则微调
- 发布总结：用户行为分析报告、用户问卷调查、社会化媒体意见收集、形成产品功能改进列表
【某宝的案例.来源网络】
产品需求收集和确定 –>； 技术方案出具和分工协调 –>； 开发编码 –>； 内部服务器环境的测试 –>； 联调（又名预发环境） –>； 小淘宝环境发布，内部员工喷喷喷 –>； 小流量（具体有多少取决于业务影响面）公网测试 –>； 收集数据写反馈 –>； 全量上线。
2.3、灰度发布的方式方法有哪些？
产品Q群、产品微信群、内部用户、app自升级、换量渠道、不会被抓包的小市场，在这些渠道将灰度包放还出去。这里边可控度最强的当属app自升级了。根据时间段，用户版本，升级请求数量，实际升级数等等
2.4、灰度发布三大类型？
- web页面灰度：按照ip或者用户id切流啊。具有随机性，可以控制比例
- 服务端灰度：考验主系分能力了，可以做逻辑切换开关，按照义务相关属性逐渐切流
- 客户端灰度：一般按照用户逐渐推送包，主要是PC端(WIN，MAC)、移动端（安卓，OS）内部大规模内测
2.5、灰度发布时，目标用户选取策略？
即选取哪些用户先行体验新版本，是强制升级还是让用户自主选择等。可考虑的因素很多，包括但不限于地理位置、用户终端特性（如分辨率、性能）、用户自身特点（性别、年龄、忠诚度等）。
对于细微修改（如文案、少量控件位置调整）可直接强制升级，对于类似新浪微博改版这样的大型升级，应让用户自主选择，最好能够提供让用户自主回滚至旧版本的渠道。
对于客户端应用，可以考虑类似Chrome的多channel升级策略，让用户自主选择采用stable、beta、unstable channel的版本。在用户有明确预期的情况下自行承担试用风险。
2.6、A/B测试云服务提供商
海外应用：optimizely
国内应用：AppAdhoc（简单够用）、optimizely（相当强大，尤其在native app A/B测试这块）
2.7、延伸阅读：
2015年5月31日，马化腾在香港大学李兆基会议中心大礼堂举办了一场创业演讲，演讲中爆了一个大料：微信的诞生史。
微信在诞生之前，在腾讯内部有三个团队在同时做微信，主要竞争者为张小龙的e-mail团队和手机QQ团队。做这个产品之前，腾讯内部并没有给这个产品定一个完整的基调，而是让公司内部形成一个激烈的竞争，通过观察用户对产品的喜好程度和产品的实际完成情况决定上线结果。
马化腾的灰度机制是这样的：很多公司在一开始做产品定义时，要么确定它是黑的，要么确定它是白的。但是马化腾发现，互联网产品的定义是有用户投票决定的。在一开始，我们不定义它是黑，还是白，有一个灰度的周期。在这个灰度周期里，让用户的口碑决定它是生是死，是白还是黑。
说的再直接点，这也是马化腾创新上的灰度机制：容忍失败，允许适度浪费，鼓励内部竞争内部试错。马化腾说过，在产品研发过程中，我们还会有一个困惑：自己做的这个产品万一失败了怎么办?
我的经验是，在面对创新的问题上，要允许适度的浪费。怎么理解？
就是在资源许可的前提下，即使有一两个团队同时研发一款产品也是可以接受的，只要你认为这个项目是你在战略上必须做的。
很多人都看到了微信的成功，但大家不知道，其实在腾讯内部，先后有几个团队都在同时研发基于手机的通讯软件，每个团队的设计理念和实现方式都不一样，最后微信受到了更多用户的青睐。
你能说这是资源的浪费吗？我认为不是，没有竞争就意味着创新的死亡。即使最后有的团队在竞争中失败，但它依然是激发成功者灵感的源泉，可以把它理解为内部试错。
2.8 具体内容，请参考：《马化腾致信合作伙伴：灰度法则的七个维度》
- 需求度：用户需求是产品核心，产品对需求的体现程度，就是企业被生态所需要的程度；
- 速度：快速实现单点突破，角度、锐度尤其是速度，是产品在生态中存在发展的根本；
- 灵活度：敏捷企业、快速迭代产品的关键是主动变化，主动变化比应变能力更重要；
- 冗余度：容忍失败，允许适度浪费，鼓励内部竞争内部试错，不尝试失败就没有成功；
- 开放协作度：最大程度地扩展协作，互联网很多恶性竞争都可以转向协作型创新；
- 进化度：构建生物型组织，让企业组织本身在无控过程中拥有自进化、自组织能力；
- 创新度：创新并非刻意为之，而是充满可能性、多样性的生物型组织的必然产物。
这篇关于浅聊灰度发布的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
