现状：
目前产品有新版本，release测试通过以后，直接放到更新服务器上，做全量用户推送。当发现新版本存在测试未覆盖到的问题时，造成的影响面较大，解决问题的代价也很大。因此可以考虑引入灰度发布。
灰度发布：
新版本准备好时，挑选全量用户中的一小部分用户，先推送新版本功能。过一段时间确认没有大的问题后，再进行全量用户的推送。
灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度。
目前大多主流WEB应用都使用了灰度发布的方式。
扩展：
一种更高明的灰度发布方式是：一些更改比较大、跟原有用户习惯差别很大或者风险比较大的修改，独立出来，可以让用户自己来选择是否更新。
当然，这种灰度发布方式对整个产品和支撑体系提出了更高的要求，很多产品因为自身原因也无法采用这种发布方式。
支撑：
与灰度发布相关的，还需要有完整的灰度用户使用情况收集和统计分析，还有及时的问题响应和解决机制。
对于外部产品，还需要及时收集和响应社交媒体上的用户吐槽，对新产品的问题给出积极的反馈。
扩展阅读：
1.灰度发布 http://enki-ding-yeah-net.iteye.com/blog/1114565
2.实现一套灰度发布系统需要考虑哪些问题?http://www.zhihu.com/question/20584476