互联网产品的灰度发布

阅读更多

    在传统软件产品发布过程中(例如微软的Windows 7的发布过程中),一般都会经历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 。

 

互联网产品的灰度发布_第1张图片

4、灰度发布  VS.  A/B测试

    灰度发布于互联网公司常用A/B测试似乎比较类似,老外似乎并没有所谓的灰度发布的概念。按照wikipedia中对A/B测试的定义 ,A/B测试又叫:A/B/N Testing、Multivariate Testing,因此本质上灰度测试可以算作A/B测试的一种特例。只不过为了术语上不至于等同搞混淆,谈谈自己理解的两者的差异。

    灰度发布是对某一产品的发布逐步扩大使用群体范围,也叫灰度放量

    A/B测试重点是在几种方案中选择最优方案

   关于A/B测试可以参考这篇文章:A/B测试终极指南

5、灰度发布引擎

   对于一般的小系统并不需要单独的灰度发布引擎,可以参考A/B测试中做法,在页面javascript或服务器端实现分流的规则即可。但对于大型的互联网应用而言,单独的用于管理用户分流的发布引擎就很有必要了。“钱掌柜”分流发布模式 提到了原来阿里软件所使用的灰度发布引擎,设计思路具有普遍性,可以供参考

互联网产品的灰度发布_第2张图片

6、参考文档

  “钱掌柜”分流发布模式

   百度百科:灰度发布

   A/B testing

   A/B测试终极指南

Technorati 标签: 灰度发布 , 灰度放量 , A/B Testing , A/B 测试 , 分流发布

复杂事件处理(Complex Event Processing)入门1

    一个新产品需要重点考虑业务风险控制。关于风险控制系统整体的技术方案可以参考 支付系统风控系统建设思考 。此方案尽管能够满足业务需求,但对于海量交易数据分析、风险事件的实时处理、大量的风险规则处理上,在实时性、性能、架构的可扩展性上都不是很理想,有必要重新从架构上考虑一下实现方案。

   一般而言,风险控制系统标准的软件架构如下:

互联网产品的灰度发布_第3张图片

 

1、风控系统实现的几种方案

   1)、数据库方案:将风险规则、交易数据等都采用关系数据库存放。正如 支付系统风控系统建设思考 所 提到的方案,交易库和风险库一般分别部署在不同的服务器上,在事件触发上可以采用数据库触发器、消息队列事件等方案。此种方案技术实现相对简单,但在进行 海量交易数据查询以及大量风险规则处理时候,数据库系统查询性能及扩展性成为一个较大的瓶颈。很难满足风险事件实时分析的要求。

   2)、内存数据库方案:由于对海量交易数据的查询、分析极其消耗数据库资源,可以采用内存数据库方案来替代关系数据库,保证风险事件实时处理的性能。 但目前开源的内存数据中VoltDB、H2、MonetDB、FastDB、Berkeley DB、SQLite等在大规模的业务场合应用的成熟度尚待考察,而Oracle TimesTen、MCObject eXtremeDB、Altibase价格太高。

   3)、分布式缓存方案:采用Memcached等NOSQL的分布式缓存来缓存交易数据、风险规则等,但由于NOSQL解决方案并不擅长数据间的关系逻辑处理,需要在程序中大量维护业务处理逻辑,远不如关系数据库或内存数据库方案方便。

  以上方案,都可以通过规则引擎(例如drools)来完成风险规则的管理和维护,避免了风险规则维护的繁琐及规则间复杂关系处理。

 

2、Complex Event Processing (复杂事件处理)

    Complex Event Processing (复杂事件处理)是一种新兴的基于事件流的技术,它将系统数据看作不同类型的事件,通过分析事件间的关系,建立不同的事件关系序列库,利用过滤、关联、聚 合等技术,最终由简单事件产生高级事件或商业流程。CEP适合的场景包括实时风险管理、实时交易分析、网络诈欺、网络攻击、市场趋势分析等等。

互联网产品的灰度发布_第4张图片

    CEP的几大特点:

  • 基于数据流
  • 时间序列
  • 实时
  • 复杂

互联网产品的灰度发布_第5张图片

                   数据库方案与CEP方案 对比(摘自Sybase CEP方案)

 

3、开源项目

Esper – Complex Event Processing

    http://esper.codehaus.org/

JBoss – Drools Fusion

    http://www.jboss.org/drools/drools-fusion.html

Open ESB IEP SE

    http://wiki.open-esb.java.net/Wiki.jsp?page=IEPSE

ActiveInsight

    http://www.activeinsight.net/

    其他产品或开源项目,可以参考:Complex Event Processing Vendors

  其中Esper和Drools Fusion很值得考虑,后续作为重点研究对象。

 

4、参考资料

    深入浅出复合事件处理(CEP)

    轻松理解复合事件处理

    Esper:CEP Engine

    Complex Event Processing:An attempt at clarity on an often confusing topic

    Sybase CEP:新颖的数据流分析平台

 

Technorati 标签: CEP , 复杂事件处理 , Complex Event Processing , Event Stream Processing , ESP , 风险控制

你可能感兴趣的:(互联网,软件测试,Sybase,数据挖掘,NoSQL)