实现一套灰度发布系统需要考虑哪些问题?

仔细考虑一下灰度发布系统要达到哪些目的,基本就能有答案了。需要注意的是,客户端应用(无论PC端还是移动端)的灰度发布要比Web应用的灰度发布更为复杂,因为应用运行在用户持有的终端上,数据采集和回滚都更为困难(但可采集的数据类型要更加丰富。

注:本人缺乏移动客户端产品的经验,下述内容可能不适用于移动客户端产品。

我所理解的灰度发布系统,主要任务是从产品用户群中按照一定策略选取部分用户,让他们先行体验新版本的应用,通过收集这部分用户对新版本应用的显式反馈(论坛、微博)或隐式反馈(应用自身统计数据),对新版本应用的功能、性能、稳定性等指标进行评判,进而决定继续放大新版本投放范围直至全量升级或回滚至老版本。从上述描述可以得出灰度发布系统需要具备的一些要素

用户标识

用于区分用户,辅助数据统计,保证灰度发布过程中用户体验的连贯性(避免用户在新旧版本中跳变,匿名Web应用比较容易有这个问题)。匿名Web应用可采用IP、Cookie等,需登录的应用可直接采用应用的帐号体系

目标用户选取策略

即选取哪些用户先行体验新版本,是强制升级还是让用户自主选择等。可考虑的因素很多,包括但不限于地理位置、用户终端特性(如分辨率、性能)、用户自身特点(性别、年龄、忠诚度等)。对于细微修改(如文案、少量控件位置调整)可直接强制升级,对于类似新浪微博改版这样的大型升级,应让用户自主选择,最好能够提供让用户自主回滚至旧版本的渠道。对于客户端应用,可以考虑类似Chrome的多channel升级策略,让用户自主选择采用stable、beta、unstable channel的版本。在用户有明确预期的情况下自行承担试用风险。

数据反馈

用户数据反馈:在得到用户允许的前提下,收集用户的使用新版本应用的情况。如客户端性能、客户端稳定性、使用次数、使用频率等。用于与旧版本进行对比,决策后续是继续扩大新版本投放范围还是回滚。
服务端数据反馈:新版本服务端性能、服务端稳定性等,作用与用户数据反馈类似

新版本回滚策略

当新版本灰度发布表现不佳时,应回滚至旧版本。对于纯粹的Web应用而言,回滚相对简单。主要难点在于用户数据的无缝切换。对于客户端应用,如果期待用户自行卸载新版本另行安装旧版本,成本和流失率都太高。可以考虑通过快速另行发布新版本,利用升级来“回滚”,覆盖上次灰度发布的修改。对于移动客户端,新版本发布成本较高,需要Appstore、Market审核。本人没有移动客户端产品的经验,不太确定移动客户端产品如何处理灰度发布及回滚。但尽量将客户端打造成Web App,会更有利于升级和回滚。

产品优化

如果是以产品优化为目的,那么一个比较完善的 A/B 测试系统是必须的,它包括了三大部分:
一个用户分流和功能(灰度)发布系统,可以控制哪些用户看见/体验哪些新功能;
一个在线试验平台,和发布系统结合,可以同时创建和运行多个测试,验证产品的 idea;
一个数据分析系统,帮你科学地分析试验结果,得出正确的结论

灰度系统需要尽可能的灵活,因为其最终目的主要是为了收集前端的用户体验。之前也看到基于后端的灰度方案,其实这个相对来说并不是灰度的本意。灰度系统的使用场景,无非是为了配合高节奏的产品上限频率,没有时间进行传统的穷尽是测试,所兴起的测试方法。所以,灰度系统的灵活性,对现有系统的很小的侵入性,是其最重要的特征。吆喝科技的灰度平台充分的体现了上述特征

你可能感兴趣的:(实现一套灰度发布系统需要考虑哪些问题?)