最近在Nginx玩了一把应用的灰度发布,备忘一下。以下为网摘
http://www.3ppt.com/Design/PM/17469.html
在传统软件产品发布过程中(例如微软的Windows7的发布过程中),一般都会经历Pre-Alpha、Alpha、Beta、Release candidate(RC)、RTM、General availability or General Acceptance (GA)等几个阶段(参考Software release life cycle)。可以看出传统软件的发布阶段是从公司内部->外部小范围测试>外部大范围测试->正式发布,涉及的用户数也是逐步放量的过程。
在互联网产品的发布过程中也较多采用此种发布方式:产品的发布过程不是一蹴而就,而是逐步扩大使用用户的范围,从公司内部用户->忠诚度较高 的种子用户->更大范围的活跃用户->所有用户。在此过程中,产品团队根据用户的反馈及时完善产品相关功能。此种发布方式,按照中国特色的叫 法被冠以”灰度发布“、”灰度放量“、”分流发布“。
关于“灰度发布”叫法的来源无从考察。只不过按照中国传统哲学的说法来看,很符合中国人中庸的思维模式:自然界所有的事物总是以对称、互补、和谐的 形式存在,例如黑与白、阴与阳、正与负、福与祸。在二元对立的元素间存在相互过渡的阶段,所谓”祸兮福所倚,福兮祸所伏“。具体到黑与白,在非黑即白中间 还有中间色——灰色。于是出现了很多关于灰色的说法:灰盒测试,灰色管理(极力推荐 任正非:管理的灰度),灰色收入,灰色地带等等。因此对于灰度发布实际上就是从不发布,然后逐渐过渡到正式发布的一个过程。
1、灰度发布的作用
及早获得用户的意见反馈,完善产品功能,提升产品质量
让用户参与产品测试,加强与用户互动
降低产品升级所影响的用户范围
。。。
2、灰度发布的步骤
1)、定义目标
2)、选定策略:包括用户规模、发布频率、功能覆盖度、回滚策略、运营策略、新旧系统部署策略等
3)、筛选用户:包括用户特征、用户数量、用户常用功能、用户范围等
4)、部署系统:部署新系统、部署用户行为分析系统(web analytics)、设定分流规则、运营数据分析、分流规则微调
5)、发布总结:用户行为分析报告、用户问卷调查、社会化媒体意见收集、形成产品功能改进列表
6)、产品完善
7)、新一轮灰度发布或完整发布
3、常见问题
3.1)、以偏概全
1)、问题特征:
a、选择的样本不具有代表性;
b、样本具有代表性,但选择样本用户使用习惯并没有涵盖所有核心功能
2)、解决方案:
样本选择要多样化,样本的组合涵盖大部分核心功能
3.2)、知识的诅咒
”知识的诅咒“的说法来自《粘住》中实验,具体可以自己搜索一下。我们自己对于自己开发的产品极为熟悉,于是乎想当然认为用户也应当能够理解产品的设计思路、产品的功能使用。
1)、问题特征:
a、结果没有量化手段;
b、只依赖于用户问卷调查;
c、没有web analytics系统;
d、运营数据不全面,只有核心业务指标(例如交易量),没有用户体验指标
e、对结果分析,只选择对发布有利的信息,对其他视而不见
2)、解决方案:
a、产品设计考虑产品量化指标
b、结果分析依据量化指标而不是感觉
3.3)、发布没有回头路可走
1)、问题特征:
a、新旧系统用户使用习惯差异太大,没有兼容原有功能
b、新旧系统由于功能差异太大,无法并行运行,只能强制升级
c、新系统只是实现了旧系统部分功能,用户要完整使用所有功能,要在 在新旧系统切换
d、新旧系统数据库数据结构差异太大,无法并行运行
2)、解决方案:
前期产品策划重点考虑这些问题,包括:
回滚方案、 新旧系统兼容方案、用户体验的一致性、用户使用习惯的延续性、新旧系统数据模型兼容性
3.4)、用户参与度不够
1)、问题特征:
a、指望用户自己去挖掘所有功能。对于一个产品,大部分用户经常只使用部分功能,用户大部分也很懒惰,不会主动去挖掘产品功能
b、互动渠道单一
c、陷入“知识的诅咒”,不尊重参与用户意见
2)、解决方案:
a、善待吃螃蟹的样本用户,包括给予参与测试的用户小奖励(例如MS给参与Win7测试用户正版License)、给用户冠以title
b、通过邮件、论坛、社区、Blog、Twitter等新媒体与用户形成互动
c、提供产品功能向导。在hotmail最近的升级后的功能tip,gmail的tip都有类似的产品功能导向。在产品中会提示类似于:你知道吗,xx还提供xx功能,通过它你可以xx 。