logo资料库

互联网产品灰度发布流程.docx

发布时间：2022-05-30 发布人：admin 分类：说明书 资料大小：1.07M 资料格式：docx 举报 版权申诉
第1页 / 共22页
第2页 / 共22页
第3页 / 共22页
第4页 / 共22页
第5页 / 共22页
第6页 / 共22页
第7页 / 共22页
第8页 / 共22页
资料共22页，剩余部分请下载后查看
    互联网产品灰度发布
    1. 前言
    2. 灰度发布定义
    3. 灰度发布作用
    4. 灰度发布步骤
    5. 灰度发布测试方法
    6. 灰度发布引擎
    7. 灰度发布常见问题
    8. 让产品具有灰度发布能力
    9. 采取灰度发布的案例
    互联网产品灰度发布 关于 2016 年 5 月 15 日，DevOps 成都站｜架构与运维峰会活动总结 1. 前言 互联网产品有 1 个特点，就是不停的升级，升级，再升级。1 般采取敏捷开发的团队，基 本上保持每周 1 次的发布频率，系统升级总是伴随着风险，新旧版本兼容的风险，用户使 用习惯突然改变而造成用户流失的风险，系统 down 机的风险.....为了不这些风险，很多产 品都采取了灰度发布的策略，其主要思想就是把影响集中到 1 个点，然后再发散到 1 个面， 出现意外情况后很容易就回退。 很长时间，我们都 1 直在改进搜索引擎的排序算法，尽可能让最好的商品出现在 搜索结果 的第 1 屏。我们尝试了很多种算法，不断调剂各个排序因子所占的比重。但是我们没法确 信我们的排序结果能满足所有用户的需求。所以我们采取了灰度发 布，选取几个 1 级商品 类目，在其中利用不同的排序算法，比如在女装类目中，我们把卖家信誉所占的比率调剂到 60%，在珠宝类目中，我们把销售量所占的比率 调剂到 60%.. 然后发布出去，搜集用户反 馈，终究选择 1 种大部份人认为好的算法。 在传统软件产品发布进程中（例如微软的 Windows 7 的发布进程中），1 般都会经历 Pre-Alpha、Alpha、Beta、Release candidate(RC)、RTM、General availability or General Acceptance (GA)等几个阶段（参考 Software release life cycle）。可以看出传统软件的 发布阶段是从公司内部->外部小范围测试>外部大范围测试->正式发布，触及的用户数也 是逐渐放量的进程。
    在互联网产品的发布进程中也较多采取此种发布方式：产品的发布进程不是一挥而就，而 是逐渐扩大使用用户的范围，从公司内部用户->虔诚度较高的种子 用户->更大范围的活跃 用户->所有用户。在此进程中，产品团队根据用户的反馈及时完善产品相干功能。此种发 布方式，依照中国特点的叫法被冠 以”灰度发布“、”灰度放量“、”分流发布“。 关于“灰度发布”叫法的来源无从考察。只不过依照中国传统哲学的说法来看，很符合中 国人中庸的思惟模式：自然界所有的事物总是以对称、互补、和谐的情势存 在，例如黑与 白、阴与阳、正与负、福与祸。在 2 元对峙的元素间存在相互过渡的阶段，所谓”祸兮福 所倚，福兮祸所伏“。具体到黑与白，在非黑即白中间还有中 间色——灰色。因而出现了 很多关于灰色的说法：灰盒测试，灰色管理（极力推荐 任正非：管理的灰度），灰色收入， 灰色地带等等。因此对灰度发布实际上就是从不发布，然后逐步过渡到正式发布的 1 个进 程。
    2. 灰度发布定义 灰度发布是指在黑与白之间，能够平滑过渡的 1 种发布方式。AB test 就是 1 种灰度发布方 式，让 1 部份用户继续用 A，1 部份用户开始用 B，如果用户对 B 没有甚么反对意见，那末 逐渐扩大范围，把所有用户都迁移到 B 上面 来。灰度发布可以保证整体系统的稳定，在初 始灰度的时候就能够发现、调剂问题，以保证其影响度。 3. 灰度发布作用 a.尽早取得用户的意见反馈，完善产品功能，提升产品质量 b.让用户参与产品测试，加强与用户互动 c.下降产品升级所影响的用户范围 d.规避 1 定的发布风险 e.避免停服发布给用户带来不便 f.具有容灾能力 4. 灰度发布步骤 1）、定义目标 2）、选定策略：包括用户范围、发布频率、功能覆盖度、回滚策略、运营策略、新旧系 统部署策略等 3）、挑选用户：包括用户特点、用户数量、用户经常使用功能、用户范围等 4）、部署系统：部署新系统、部署用户行动分析系统（web analytics）、设定分流规则、
    运营数据分析、分流规则微调 5）、发布总结：用户行动分析报告、用户问卷调查、社会化媒体意见搜集、构成产品功 能改进列表 6）、产品完善 7）、新 1 轮灰度发布或完全发布 5. 灰度发布测试方法 灰度发布于互联网公司经常使用 A/B 测试似乎比较类似，老外似乎并没有所谓的灰度发 布的概念。依照 wikipedia 中对 A/B 测试的定义，A/B 测试又叫：A/B/N Testing、 Multivariate Testing，因此本质上灰度测试可以算作 A/B 测试的 1 种特例。只不过为了术 语上不至于同等弄混淆，谈谈自己理解的二者的差异。 灰度发布是对某 1 产品的发布逐渐扩大使用群体范围，也叫灰度放量 A/B 测试重点是在几种方案当选择最优方案 关于 A/B 测试可以参考这篇文章：A/B 测试终极指南 6. 灰度发布引擎 对一般的小系统其实不需要单独的灰度发布引擎，可以参考 A/B 测试中做法，在页面 javascript 或服务器端实现分流的规则便可。但对大型的互联网利用而言，单独的用于管理 用户分流的发布引擎就很有必要了。“钱掌柜”分流发布模式 提到了原来阿里软件所使用 的灰度发布引擎，设计思路具有普遍性，可以供参考
    下面是 1 个灰度发布的架构示意图： 7. 灰度发布常见问题 7.1. 以偏概全 7.1.1. 问题特点： a 选择的样本不具有代表性；
    b 样本具有代表性，但选择样本用户使用习惯并没有涵盖所有核心功能 7.1.2. 解决方案： 样本选择要多样化，样本的组合涵盖大部份核心功能 7.2. 知识的诅咒 “知识的诅咒”的说法来自《粘住》中实验，具体可以自己搜索 1 下。我们自己对自己开 发的产品极其熟习，因而乎想固然认为用户也应当能够理解产品的设计思路、产品的功能使 用。 7.2.1. 问题特点： a 结果没有量化手段； b 只依赖于用户问卷调查； c 没有 web analytics 系统； d 运营数据不全面，只有核心业务指标（例如交易量），没有用户体验指标 e 对结果分析，只选择对发布有益的信息，对其他视而不见 7.2.2. 解决方案： a 产品设计斟酌产品量化指标 b 结果分析根据量化指标而不是感觉 7.3. 发布没有回头路可走 7.3.1. 问题特点： a 新旧系统用户使用习惯差异太大，没有兼容原有功能 b 新旧系统由于功能差异太大，没法并行运行，只能强迫升级 c 新系统只是实现了旧系统部份功能，用户要完全使用所有功能，要在 在新旧系统切换 d 新旧系统数据库数据结构差异太大，没法并行运行
    7.3.2. 解决方案： 前期产品策划重点斟酌这些问题，包括：回滚方案、 新旧系统兼容方案、用户体验的 1 致性、用户使用习惯的延续性、新旧系统数据模型兼容性 7.4. 用户参与度不够 7.4.1. 问题特点： a 期望用户自己去发掘所有功能。对 1 个产品，大部份用户常常只使用部份功能，用户大部 份也很怠惰，不会主动去发掘产品功能 b 互动渠道单 1 c 堕入“知识的诅咒”，不尊重参与用户意见 7.4.2. 解决方案： a 善待吃螃蟹的样本用户，包括给予参与测试的用户小嘉奖（例如 MS 给参与 Win7 测试用 户正版 License）、给用户冠以 title b 通过邮件、论坛、社区、Blog、Twitter 等新媒体与用户构成互动 c 提供产品功能向导。在 hotmail 最近的升级后的功能 tip，gmail 的 tip 都有类似的产品 功能导向。在产品中会提示类似于：你知道吗，xx 还提供 xx 功能，通过它你可以 xx 。 8. 让产品具有灰度发布能力 8.1. 灰度机制的 7 个维度 8.1.1. 需求度 用户需求是产品核心，产品对需求的体现程度，就是企业被生态所需要的程度; 8.1.2. 速度 快速实现单点突破，角度、锐度特别是速度，是产品在生态中存在发展的根本;
    分享到：
    赞 收藏

    相关推荐

    资料库

    开发技术

    共收录19306份资料，累计14个分类，关注成员有19位，主要包括：Actionscript,Javascript,PHP,VB,Perl,Delphi,Python,C#,C,Java,C++,Web开发,硬件开发,其它

    热门标签

    Actionscript Javascript PHP VB Perl Delphi Python C# C Java C++ Web开发 硬件开发 其它

    最新资料