ABTesingGateway —— 新浪的动态策略灰度发布系统-开源中国-微转化
OSChina 开源中国 官方微信账号
屠夫欠了妓女1000元，然后……|教你秒懂经济学
●●●●●●●●●●●
热门公众号Accounts
精彩内容热门推荐
最新最准金融及理财信息,为你提供优质的金融及银行相关服务,打造金融、理财、证券、时事资讯、贷款、信用卡申请等综合信息分享平台
将尘封的历史;照进现实;将湮没的真相;告知公众!
传递有价值的信息!
西昌九龙医院为男性解决健康问题,我们将以您最专业、最及时、最有效的解决方案.我们已开通专家在线,即可与专家免费沟通对话.
wangluo4G3G
有一种新闻叫你不知道;而我已经知道.揭秘奇闻奇事;娱乐八卦;探索未解之谜;灵异事件;让你看到更多不为人知的新鲜奇闻!
cctvnewscenter
xingzuoxiaowu
微信内人气最旺的星座迷你宝典!分享懂你的星座,占星,血型,生肖,测试,心理,明星,运气,改运,性格,命运.星座迷们快快关注哟~
每日分享有爱、有用、有趣的育儿经验、家教知识、专家观点,和孩子一起成长!等你来.......
yinyang200888
健康咨询交流,美图艺术欣赏;男性健康,女性健康,两性私语,夫妻密事,爱爱经验分享,私处的难言之隐;健康养生保健,疾病秘方分享.
RenRenLiShi
每天看点历史常识,做个有文化的中国人.
女人那点事,私密房中术,夫妻那些事.男女必备,你懂的!关爱生活,更关心你!
ABTesingGateway —— 新浪的动态策略灰度发布系统
阅读&25756&发表& 08:48:38
???ABTesingGateway 是一个可以动态设置分流策略的灰度发布系统，工作在7层，基于tengine，采用 ngx-lua 开发，使用 redis 作为分流策略数据库，可以实现动态调度功能。ABTestingGateway
指导下完成，作者是：@bg2bkk 和 @helloyi 。
nginx 是目前使用较多的7层服务器，可以实现高性能的转发和响应；ABTestingGateway 是在 nginx 转发的框架内，在转向 upstream 前，根据 用户请求特征 和 系统的分流策略 ，查找出目标upstream，进而实现分流。
在以往的基于 nginx 实现的灰度系统中，分流逻辑往往通过 rewrite 阶段的 if 和 rewrite
指令等实现，优点是性能较高，缺点是功能受限、容易出错，以及转发规则固定，只能静态分流。针对这些缺点，我们设计实现了
ABTesingGateway，采用 ngx-lua 实现系统功能，通过启用lua-shared-dict和lua-resty-lock作为系统缓存和缓存锁，系统获得了较为接近原生nginx转发的性能。
ABTesingGateway 的架构简图
Features:支持多种分流方式，目前包括iprange、uidrange、uid尾数和指定uid分流动态设置分流策略，即时生效，无需重启可扩展性，提供了开发框架，开发者可以灵活添加新的分流方式，实现二次开发高性能，压测数据接近原生nginx转发灰度系统配置写在nginx配置文件中，方便管理员配置适用于多种场景：灰度发布、AB测试和负载均衡等
分流功能：转发分流是灰度系统的主要功能，目前 ABTesingGateway 支持ip段分流(iprange)、uid用户段分流(uidrange)、uid尾数分流(uidsuffix)和指定特殊uid分流(uidappoint)四种方式。ABTesingGateway 依据系统中配置的运行时信息runtimeInfo进行分流工作；通过将 runtimeInfo 设置为不同的分流策略，实现运行时分流策略的动态更新，达到动态调度的目的。
系统运行时信息设置
系统管理员通过系统管理接口将分流策略policy设置为运行时策略，并指定该策略对应的分流模块名divModulename和用户信息提取模块名userInfoModulename后，系统可以进行分流工作。
系统对用户请求进行分流时，首先获得系统运行时信息runtimeInfo中的信息，然后提取用户特征userInfo，最后分流模块divModule根据分流策略dviDataKey和用户特征userInfo查找出应该转发到的upstream。如果没有对应的upstream，则将该请求转向默认
upstream。 以iprange分流为例 以某个iprange分流策略为例： { &divtype&:&iprange&, &divdata&:[ {&range&:{&start&:1111, &end&:2222}, &upstream&:&beta1&}, {&range&:{&start&:3333, &end&:4444}, &upstream&:&beta2&}, {&range&:{&start&:7777, &end&:8888}, &upstream&:&beta3&} ] }其中divdata中的每个 range:upstream 对中，range 为 ip 段，upstream 为 ip 段对应的后端；range 中的 start 和 end 分别为 ip 段的起始和终止， ip以整型表示。当灰度系统启用iprange分流方式时，会根据用户请求的ip进行分流转发。假如用户请求中的ip信息转为整型后是4000，将被转发至beta2 upstream。分流过程流程图管理功能：
管理功能架构图1. 管理员登入后，得到系统信息视图，运行时信息视图，可以进行策略管理和运行时信息管理
2. 业务接口层向管理员提供
增/删/查/改
3. 适配层将承担业务接口与分流模块的沟通工作
4. 适配层提出统一接口，开发人员可以通过实现接口来添加新的分流方式
管理接口：[策略管理接口]
#分流策略检查，参数为一个分流策略数据的json串
1. /admin/policy/check
#分流策略添加，参数与check接口一致
2. /admin/policy/set
#分流策略读取，参数为要读取策略的policyid
3. /admin/policy/get
#分流策略删除，参数为要删除策略的policyid
4. /admin/policy/del
[运行时信息管理接口]
#设置分流策略为运行时策略，参数为policyid
1. /admin/runtime/set
#获取系统当前运行时信息，无参数
2. /admin/runtime/get
#删除系统运行时信息，关闭分流接口，无参数
3. /admin/runtime/del
tengine-2.1.0LuaJIT-2.1-ngx_lua-0.9.13lua-cjson-2.1.0.2redis-2.8.19
系统部署repo中的utils/conf文件夹中有灰度系统部署所需的最小示例1. git clone /SinaMSRE/ABTestingGateway
2. cd /path/to/ABTestingGateway/utils
#启动redis数据库
3. redis-server conf/redis.conf
#启动upstream server，其中stable为默认upstream
4. /usr/local/nginx/sbin/nginx -p `pwd` -c conf/stable.conf
5. /usr/local/nginx/sbin/nginx -p `pwd` -c conf/beta1.conf
6. /usr/local/nginx/sbin/nginx -p `pwd` -c conf/beta2.conf
7. /usr/local/nginx/sbin/nginx -p `pwd` -c conf/beta3.conf
8. /usr/local/nginx/sbin/nginx -p `pwd` -c conf/beta4.conf
#启动灰度系统，proxy server，灰度系统的配置也写在conf/nginx.conf中
9. /usr/local/nginx/sbin/nginx -p `pwd` -c conf/nginx.conf灰度系统使用demo管理功能 1. 部署并启动系统
2. 查询系统运行时信息，得到null
0& curl 127.0.0.1:8030/admin/runtime/get
{&errcode&:200,&errinfo&:&success &,&data&:{&divModulename&:null,&divDataKey&:null,&userInfoModulename&:null}}
3. 查询id为9的策略，得到null
0& curl 127.0.0.1:8030/admin/policy/get?policyid=9
{&errcode&:200,&errinfo&:&success &,&data&:{&divdata&:null,&divtype&:null}}
4. 向系统添加策略，返回成功，并返回新添加策略的policyid
以uidsuffix尾数分流方式为例，示例分流策略为：
&divtype&:&uidsuffix&,
&divdata&:[
{&suffix&:&1&, &upstream&:&beta1&},
{&suffix&:&3&, &upstream&:&beta2&},
{&suffix&:&5&, &upstream&:&beta1&},
{&suffix&:&0&, &upstream&:&beta3&}
添加分流策略接口 /admin/policy/set 接受json化的policy数据
0& curl 127.0.0.1:8030/admin/policy/set -d '{&divtype&:&uidsuffix&,&divdata&:[{&suffix&:&1&,&upstream&:&beta1&},{&suffix&:&3&,&upstream&:&beta2&},{&suffix&:&5&,&upstream&:&beta1&},{&suffix&:&0&,&upstream&:&beta3&}]}'
{&errcode&:200,&errinfo&:&success
the id of new policy is 0&}
5. 查看添加结果
0& curl 127.0.0.1:8030/admin/policy/get?policyid=0
{&errcode&:200,&errinfo&:&success &,&data&:{&divdata&:[&1&,&beta1&,&3&,&beta2&,&5&,&beta1&,&0&,&beta3&],&divtype&:&uidsuffix&}}
6. 设置系统运行时策略为 0号策略
0& curl 127.0.0.1:8030/admin/runtime/set?policyid=0
{&errcode&:200,&errinfo&:&success &}
7. 查看系统运行时信息，得到结果
0& curl 127.0.0.1:8030/admin/runtime/get
{&errcode&:200,&errinfo&:&success &,&data&:{&divModulename&:&abtesting.diversion.uidsuffix&,&divDataKey&:&ab:test:policies:0:divdata&,&userInfoModulename&:&abtesting.userinfo.uidParser&}}
8. 当访问接口不正确返回时，将返回相应的 错误码 和 错误描述信息
0& curl 127.0.0.1:8030/admin/policy/get?policyid=abc
{&errcode&:50104,&errinfo&:&parameter type error for policyID should be a positive Integer&}分流功能在验证管理功能通过，并设置系统运行时策略后，开始验证分流功能
1. 分流，不带用户uid，转发至默认upstream
0& curl 127.0.0.1:8030/
this is stable server
2. 分流，带uid为30，根据策略，转发至beta3
0& curl 127.0.0.1:8030/
-H 'X-Uid:30'
this is beta3 server
3. 分流，带uid为33，根据策略，转发至beta2
0& curl 127.0.0.1:8030/
-H 'X-Uid:33'
this is beta2 server压测结果：压测环境下灰度系统与原生nginx转发的对比图压测环境下灰度系统与原生nginx转发的数据对比如图所示，用户请求完全命中cache是理想中的情况，灰度系统在理想情况下可以达到十分接近原生nginx转发的性能。产生图中压测结果的场景是：用户请求经过proxy server转向upstream server，访问1KB大小的静态文件。proxy server的硬件配置：CPU：EGHz 16核Mem：24GBNic：千兆网卡，多队列
线上部署简图：ABTestingGateway
指导下完成，作者是：@bg2bkk 和 @helloyi 。＝＝＝＝ OSC 职位推荐 ＝＝＝＝坐标：北京 公司：乐视网JAVA系统架构师 ￥20K-40K 高级JAVA开发 ￥14K-28K更多职位请登录：job.oschina.net
评论Comments
微信公众号北京-4月27日直播课程 4月14日已结束北京-5月10日
阅读（1597）
来人人都是产品经理【起点学院】，BAT实战派产品总监手把手系统带你学产品、学运营。
商用发布并不是一句“做完了就发上去吧”这么单纯而简单的事情。也许大家在使用手机软件的时候觉得，不就是到应用市场上下个软件装一下的事情么，能有啥复杂的呢？
暂不说商用发布是标准的渠道经理和渠道专员进行落地执行安排的，由专业的测试发布人员完成。就产品经理规划如何发布，版本的发布流程都是一件需要斟酌的重要阶段。
先确定一下一款全平台产品有多少种发布渠道。
1. Android客户端：
（1）国内浏览器应用市场：手机百度、百度浏览器、QQ浏览器、UC浏览器、360浏览器、搜狗浏览器、猎豹浏览器……
（2）国内应用市场客户端：应用宝、百度手机助手（原91助手）、360手机助手、安卓市场、安智市场、豌豆荚、小米应用商店、华为应用市场……
（3）电视盒子应用市场：当贝市场、沙发管家、360电视助手……
2. iOS客户端：
（1）官方应用市场：AppStore
（2）非官方应用市场：海马苹果助手、PP助手、同步推、91助手……
3. WP客户端
（1）微软应用商店
4. 自有发布
（1）软件内自动/手动检测升级
（2）自有官网下载，包括WWW、WAP
（3）友站下载
如果只是一款单纯无需数据埋点也无广告结算的软件，只需要规划一下新版本发布的顺序及时间。但如果软件涉及到数据，尤其是多方结算数据，那么这些版本都需要带有渠道号，还要考虑首发及相关更新推广上的计划。这么多细微琐碎的事情凑到一起看起来就很混乱的样子，所以发布的规划要一步步设定。
规划产品商用发布的七步走
第一步：规划产品版本介绍素材、风格及时间。
其中素材需要有指定页面截图及设计，宣传文案和主要介绍内容，这里的时间指准备好所有上线商用资料的时间。还要规划筹备运营人员要在官方微博、微信公众号、合作媒体中要发布的广告及推广软文。
第二步：确定产品上线的渠道及先后顺序。
哪个渠道首发，哪个渠道先行（是否长期合作），是否先做灰度发布，试探一下市场效果，先发布的渠道可不可获取到相关的推荐位。
第三步：产品自动升级规则制定。
已安装产品的用户如何升级，需用户手动检测，是否自动提示，提示后下载安装还是跳转至指定应用市场或弹出浏览器安装。如果不安装新版本，是否每次打开客户端都要提示。
第四步：发布前的数据维度确定。
这里的数据单纯指运营数据，比如新版本上线了一些新的功能或运营位，这些数据的埋点是否与运营协商过，监测的是哪些数据的变化，除了普通的新增用户、活跃用户、日开机次数、每次停留时长之外，还有指定关键页面的跳出率，页面点击路径、功能使用频率等等。
第五步：各渠道的安装包里渠道号的设置规则。
初级产品中可能未涉及渠道号的问题，但随着产品用户的增加，渠道资源的引入，各个渠道可以置换一些推荐位，有些可以联合做活动，那每个渠道的下载量，用户使用、付费等等都是靠渠道号来统计的。渠道号的设置规则规范化，以便平台上的结算。
第六步：iOS客户端总要独立应对。
不论是iPhone还是iPad客户端，不能跟Android客户端一并规划，AppStore的上线规则是独立的，所以发布的时候一定要记住几个没有明确文档说明的“地雷”：
有用户体系互联网产品一定要可完成独立注册登录的闭环操作；
如有跳转网页必须软件内跳转不可弹出跳转；
付费、充值必须采用指定付费方式，其中虚拟物品必须使用iTunes付费；
使用广告等嵌入SDK必须是苹果认可的，积分商城原则上是不允许出现的；
不可有明显超链形式，不可捆绑安装其他客户端；
不可自动获取用户信息，含本机号、邮箱、系统版本号，IMEI号等都不允许埋点获取。
测试版、非完整版本、常规功能中存有待开启功能等情况，都无法通过审核。
全新产品上线会有一个月的新品推荐周期，这段时间如何用于运营推广。
iOS审核一般情况下是一周等待审核，一周时间在审核，至少要等上半个月，如果未能通过还要继续等待两周，遇到有重大付费更改的版本等待两个来月未有任何反应也是常见的。
第七步：规划应急筹备与回滚预警。
这个工作虽说是由测试团队来落实执行的，但在规划时，产品经理也要进行前期的判定，什么情况需要应急措施，那些问题需要进行版本回滚，应急修改时间是多久，回滚的后续弥补的工作有哪些，回滚到再发布的时间规划，都需要跟技术、测试、渠道、运营人员提前商议确认。
商用发布会随着版本的升级而变得越来越复杂，细节越来越多，在多方市场多渠道推广的情况下，专业的渠道发布人员会大大提高产品的推广力度，优秀的商用发布是运营的有效补充，产品一炮而红的强劲助力。
本文由 @开言扯空-为产品经理（公众号：kaiyanchekong-PM） 原创发布于人人都是产品经理 ，未经许可，禁止转载。
有人回复时邮件通知我
从业8年以上产品经理：聊关于做产品的事。
人人都是产品经理（）是中国最大、最活跃的以产品经理为核心的学习、交流、分享社群，集媒体、教育、招聘、社群活动为一体，全方位服务产品经理，微信公众号woshipm。成立5年以来举办线上活动500余场，线下活动数百场，覆盖北京、上海、广州、深圳、杭州、成都等10余城市，在互联网业内得到了广泛关注和高度好评。社区目前拥有300万忠实粉丝，其中产品经理占比50万， 中国75%的产品经理都在这里。| 时间排序
能否指点一下，判断用户请求是否符合灰度策略使用的是什么机制吗？比如使用的是什么软件或者框架？
能否指点一下，判断用户请求是否符合灰度策略使用的是什么机制吗？比如使用的是什么软件或者框架？
我记得有做AB test的平台，忘记名字了
我记得有做AB test的平台，忘记名字了
后台预先设置好灰度用户策略，每个用户请求过来后判断一下是否满足灰度策略，如果是就走灰度逻辑，否则走正常逻辑。
后台预先设置好灰度用户策略，每个用户请求过来后判断一下是否满足灰度策略，如果是就走灰度逻辑，否则走正常逻辑。
&a href=&///?target=https%3A///boylegu/regal& class=& wrap external& target=&_blank& rel=&nofollow noreferrer&&boylegu/regal · GitHub&i class=&icon-external&&&/i&&/a& 推荐你这个 灰度发布智能分流引擎
推荐你这个 灰度发布智能分流引擎
刚好最近有关注，海外应用用optimizely，国内应用可以考虑AppAdhoc，AppAdhoc简单够用，optimizely相当强大，尤其在native app A/B测试这块，具体自己用用就知道了。
刚好最近有关注，海外应用用optimizely，国内应用可以考虑AppAdhoc，AppAdhoc简单够用，optimizely相当强大，尤其在native app A/B测试这块，具体自己用用就知道了。
释放bug时 把一半用户的vim删掉 然后看用户反映
释放bug时 把一半用户的vim删掉 然后看用户反映
iOS比较麻烦，由于审核机制以及iOS本身对权限的控制，我们通常是选择越狱版本渠道来进行灰度，然后才是正式版本灰度。&br&在Android上可以直接通过渠道控制来进行灰度，具体做法是先在各个不同渠道包中设置一个标识号，在服务器受到号后根据渠道策略返回不同值
iOS比较麻烦，由于审核机制以及iOS本身对权限的控制，我们通常是选择越狱版本渠道来进行灰度，然后才是正式版本灰度。在Android上可以直接通过渠道控制来进行灰度，具体做法是先在各个不同渠道包中设置一个标识号，在服务器受到号后根据渠道策略返回不同值
1.圈定用户推送&br&2.小渠道发布
1.圈定用户推送2.小渠道发布
大家好像对于页面和android的灰度发布比了解。&br&虽然和bat无缘。不过还是来补充一下移动端的灰度发布方式。&br&android： 使用指导渠道、版本或者tag的方式来进行定量升级。&br&iOS：官方的测试平台有Testflight，已经被苹果收购，但是整个内测用户邀请的方法流程还是没有打通，邀请用户成本比较高，是通过添加用户邮箱的方式，收到邀请邮件后还需要用户按步骤下载tf，下载应用等，没有一套教学视频普通用户还是难以接受。但非常适合在新产品发布前使用一些运营手段去建立这个用户群。用户一旦完成第一次操作，以后更新就像appstore一样简单。对开发者来说，操作也是和appstore一样的。比较方便。&br&且一个公司有多款产品的话，使用这个成本也会稍低一些，不过最大的问题还是灰度的用户量，和后期用户的消亡管理和扩充&br&&br&还有一个是如果有打不同的iOS渠道包（除了appstore还有其他越狱渠道）或者其他tag的话，也可以通过升级配置来指定灰度发布。&br&&br&不知道大家有使用什么更好的方法来进行灰度的，来一起交流下经验哈x_x
大家好像对于页面和android的灰度发布比了解。虽然和bat无缘。不过还是来补充一下移动端的灰度发布方式。android： 使用指导渠道、版本或者tag的方式来进行定量升级。iOS：官方的测试平台有Testflight，已经被苹果收购，但是整个内测用户邀请的方法流程还是…
1.web页面灰度。按照ip或者用户id切流啊。具有随机性，可以控制比例&br&2. 服务端灰度。考验主系分能力了，可以做逻辑切换开关，按照义务相关属性逐渐切流&br&3.app。一般按照用户逐渐推送包，主要是安卓。iso内部大规模内测&br&没有不能灰度的业务，只有不能灰度的设计
1.web页面灰度。按照ip或者用户id切流啊。具有随机性，可以控制比例2. 服务端灰度。考验主系分能力了，可以做逻辑切换开关，按照义务相关属性逐渐切流3.app。一般按照用户逐渐推送包，主要是安卓。iso内部大规模内测没有不能灰度的业务，只有不能灰度的设计
ios不了解，我就说下Android app。&br&首先灰度发布本身是比较简单的，对于app来说就是新增/升级版本的流量控制，找到那些可控的渠道，逐步放量出去，就是灰度发布了。&br&然而要将灰度带来的信息价值最大化，要做的事情就多了。灰度的信息一方面是用于技术迭代，一方面可用于业务改进，我们就说下技术方面。&br&&br&1. 用户不是QA，即使灰度流程再完善，我们也要拿出稳定的版本之后再发灰度。因此单元测试，自动化测试平台，Testin，这些黑白盒测试每天都要跑，发现问题马上修复。&br&2. 异常反馈机制。Android app比较严重的两种异常即FC（强制关闭）和ANR，灰度主要目的也是监控这类异常。具体到异常的收集，可以用第三方SDK，比如百度crab，友盟SDK等，更好的方式是自己搭一套，这样我们才能做到更细致的控制。举几个例子：&br&&ul&&li&&i&一些异常可以直接吃掉不影响使用view not attached to window&/i&&/li&&li&&i&除了机型固件cpu等基础信息，可以根据产品需求上报一些其他异常相关的关键数据&br&&/i&&/li&&li&&i&我们可以根据异常信息，决定下一步操作，如直接吃掉，关掉这个功能，提示用户升级等等&/i&&/li&&li&&i&我们可以针对特定机型出现的异常做特定的修改，并精确推送到这类机型上&/i&&/li&&/ul&&p&3. 灰度发布。找到那些可控的渠道，产品Q群，内部用户，app自升级，换量渠道，不会被抓包的小市场，在这些渠道将灰度包放还出去。这里边可控度最强的当属app自升级了。根据时间段，用户版本，升级请求数量，实际升级数等等，预先定好协议，在灰度时该如何组合条件就看你心情了：）&/p&&p&4. 灰度时间。如果条件允许，我们应该时刻都在灰度。Android的版本分裂+各种莫名其妙的rom，适配起来妥妥要人命。所以灰度的时间越长，越能碰到消灭一些难以置信的bug，而灰度最不希望看到的也是适配问题，一旦出现常常意味着你要在没有对应机型固件的情况下修复他们……尼玛。时刻都在灰度，并不是分分钟就把svn上的最新代码当灰度发布出去，而是一种敏捷迭代的方式。每次灰度的版本，都应该是经过封测的分支，是否能实现主要还是受制于开发资源啦。&/p&&br&&p&好了，以上希望对需要的同学有所帮助。&/p&
ios不了解，我就说下Android app。首先灰度发布本身是比较简单的，对于app来说就是新增/升级版本的流量控制，找到那些可控的渠道，逐步放量出去，就是灰度发布了。然而要将灰度带来的信息价值最大化，要做的事情就多了。灰度的信息一方面是用于技术迭代，一…
web 区分区域、时间端、人群做灰度&br&iOS 对比模块同时存在，云端控制模块的关闭和开启&br&Anroid，云端控制升级弹窗&br&PC client 粉丝群、论坛、不同的下发渠道做灰度
web 区分区域、时间端、人群做灰度iOS 对比模块同时存在，云端控制模块的关闭和开启Anroid，云端控制升级弹窗PC client 粉丝群、论坛、不同的下发渠道做灰度
前前厂&br&&br&&ol&&li&web切小流量观察，逐步扩大&/li&&li&iOS提交审核同时发布到越狱渠道，发现重大bug则撤包重提或抓紧修复提新包&/li&&li&Android，先App内小数量级弹窗引导升级，根据数据情况，再全量上线市场渠道，最后App全量弹窗引导升级&/li&&li&PC client先上官网渠道（新老版本同时有），根据情况，逐步增加上线市场渠道，最后全量上线，最最后客户端内弹窗引导升级，最最最后服务端下发指令强制升级。&/li&&/ol&
前前厂web切小流量观察，逐步扩大iOS提交审核同时发布到越狱渠道，发现重大bug则撤包重提或抓紧修复提新包Android，先App内小数量级弹窗引导升级，根据数据情况，再全量上线市场渠道，最后App全量弹窗引导升级PC client先上官网渠道（新老版本同时有），根…
附上我司流程（画的不好，勿喷）&br&&img src=&/b677b66c0a3f847aec07_b.jpg& data-rawwidth=&1565& data-rawheight=&1051& class=&origin_image zh-lightbox-thumb& width=&1565& data-original=&/b677b66c0a3f847aec07_r.jpg&&&br&&br&注：如果iOS版本在提交App Store审核期间，发现重大问题时，反馈给项目组成员。如果评估5~7天的审核期内能修复，由PM（版本负责人）确认是否重新提交新版本审核；假如评估5~7天无法修复，由PM（版本负责人）确认是否暂时撤销提交审核，如审核通过，同样由PM（版本负责人）确认是否暂时在或不在AppStore上线。&br&&br&补充一点：android 是可以局部灰测（指定特定用户）
附上我司流程（画的不好，勿喷）注：如果iOS版本在提交App Store审核期间，发现重大问题时，反馈给项目组成员。如果评估5~7天的审核期内能修复，由PM（版本负责人）确认是否重新提交新版本审核；假如评估5~7天无法修复，由PM（版本负责人）确认是否暂时撤销…
如果你是指的web页面产品的发布的话，那很简单。app发布的话很难做到严格控制的灰度，除非是H5实现的。&br&&br&首先取决于你页面的影响度，如果一个页面统共就1万日pv，可能就是一个很简单的快速切换。如果是淘宝网首页的改版，那么可能是非常长的一个切换周期。&br&&br&其次取决于你产品发布的形式，是全新产品的发布?还是说现存产品的改版？如果是改版的话，是交互改版？还是为某个活动或者节日特别订制的皮肤？也有可能外表看起来完全一样，背后的算法完全不同了，比如搜索算法、推荐算法，都可能在你完全不知道的情况下做了很大改变。&br&&br&从产品经理的角度来看：淘宝的发布流程一般是这样的，首先产品经理说服老板、老板的老板、开发Leader、开发成员、测试、设计师、BI等等我们要做的这个产品是牛逼而且有价值的。然后确认改版的设计并完成开发。开发后的版本会在内部工程用的服务器上（需要指向特定 URL）可以看到，然后是时间1周~2个月的测试，测试完成验收达到设计目标和发布标准后，会进行内部发布。内部发布后的版本，阿里巴巴内网上淘宝看到的就都是新版本了，这叫做“小淘宝”发布。这个阶段可能持续1天~1个月，内部员工会看到新的页面并吐槽或发现bug并提交修改。&br&&br&然后根据产品的不同，会有一个逐步上线切换的过程，比如先切5%全网流量，这个时候可以收集到真实的用户数据了，这个阶段性相当于AB test，通过AB我们知道产品的表现是否达到了设计时吹的牛逼。如果牛逼能够圆上，并且没有出bug，那么就会逐步加码流量直到50%-100%。淘宝有非常完善的工具链可以让产品经理实时地看到不同版本bucket下的PV UV 引导成交等指标性数据。&br&&br&不同产品的AB控制是不同的，有的是在web服务器层，有的是接口层，算法产品则更有非常完善自动化的工具链，可以做到新的算法开发通过验收后瞬间发布并进行灰度。灰度数值填写后瞬间生效瞬间看到数据。一天多的情况下可以进行多达10轮AB test并且支持超过10个算法同时跑在线上赛马看哪个稍微不傻逼一点。&br&&br&发布流程主要是为了保障一个淘宝这样大而复杂的产品服务不要出现问题和故障，我想B或者T也有类似的机制。首先你要测试，测试，再测试，每次发布必须走一遍完整的测试回归，如果是跨团队的产品那么每个关联的产品团队都会测试回归一次这个改动。发布完之后，产品经理也必须拿出数据来证明这个改动的价值（当然，哥每次都能证明这一点，脸皮不是白长的）。本人曾经两次参加“紧急发布”，就是会有特殊的产品功能会为了赶某个特定的时间点而必须加班加点地改动发布出来。一个很简单的发布也会有非常长的流程来保障。&br&&br&总结下来，发布流程是这样的：&br&&br&产品需求收集和确定--&技术方案出具和分工协调--&开发编码--&内部服务器环境的测试+联调（又名预发布环境）--&小淘宝环境发布，内部员工喷喷喷--&小流量（具体有多小取决于业务影响面）公网测试--&收集数据写反馈--&全量上线。&br&&br&大致就是这样。
如果你是指的web页面产品的发布的话，那很简单。app发布的话很难做到严格控制的灰度，除非是H5实现的。首先取决于你页面的影响度，如果一个页面统共就1万日pv，可能就是一个很简单的快速切换。如果是淘宝网首页的改版，那么可能是非常长的一个切换周期。其…
答案很简单，&br&因为逻辑思维的号经过第三方开发了，&br&他用关键字跳转的方式，&br&使粉丝得到的回复实际是从第三方跳转过来的。&br&&br&至于原因吗，&br&我是这样想的，&br&罗辑思维的粉丝量确实很大，&br&但是应该比外表看上去的少不少，&br&而且他选择了每天推送，&br&所以致使打开率即便高也不一定能超过50%，&br&&br&由此即可推论出这样一种可能：&br&就好比你一直认为一个人富可敌国，&br&但真正了解了却发现他有点小钱，&br&只能算是个小康水平的话，&br&那种落差，以及由此产生的‘被骗感’是会产生颠覆效应的。&br&你可以想想，&br&这种结果如果是用户看明白了则罢了，&br&如果是广告主看明白呢？&br&&br&这也正是微信开放阅读数之后，&br&许多之前非常活跃、天天忽悠的所谓大号销声匿迹的原因。&br&&br&但不得不说，&br&罗振宇是很有远见的，&br&因为他一直坚持这种模式，&br&使大家早已习以为常，&br&反而以为其更加高大上了呢。&br&你说是不？&br&&br&个人之见，仅供参考。&br&——————————————————&br&吴明毅&br&营销人、媒体人。&br&原创微信公众号：吴话不谈&br&微信号：wuhuabt
答案很简单，因为逻辑思维的号经过第三方开发了，他用关键字跳转的方式，使粉丝得到的回复实际是从第三方跳转过来的。至于原因吗，我是这样想的，罗辑思维的粉丝量确实很大，但是应该比外表看上去的少不少，而且他选择了每天推送，所以致使打开率即便高也不…
仔细考虑一下灰度发布系统要达到哪些目的，基本就能有答案了。需要注意的是，客户端应用（无论PC端还是移动端）的灰度发布要比Web应用的灰度发布更为复杂，因为应用运行在用户持有的终端上，数据采集和回滚都更为困难（但可采集的数据类型要更加丰富）。&br&&br&注：本人缺乏移动客户端产品的经验，下述内容可能不适用于移动客户端产品。&br&&br&我所理解的灰度发布系统，主要任务是从产品用户群中按照一定策略选取部分用户，让他们先行体验新版本的应用，通过收集这部分用户对新版本应用的显式反馈（论坛、微博）或隐式反馈（应用自身统计数据），对新版本应用的功能、性能、稳定性等指标进行评判，进而决定继续放大新版本投放范围直至全量升级或回滚至老版本。&br&&br&从上述描述可以得出灰度发布系统需要具备的一些要素：&br&&br&&b&用户标识&/b&&br&&br&用于区分用户，辅助数据统计，保证灰度发布过程中用户体验的连贯性（避免用户在新旧版本中跳变，匿名Web应用比较容易有这个问题）。匿名Web应用可采用IP、Cookie等，需登录的应用可直接采用应用的帐号体系。&br&&br&&b&目标用户选取策略&/b&&br&&br&即选取哪些用户先行体验新版本，是强制升级还是让用户自主选择等。可考虑的因素很多，包括但不限于地理位置、用户终端特性（如分辨率、性能）、用户自身特点（性别、年龄、忠诚度等）。对于细微修改（如文案、少量控件位置调整）可直接强制升级，对于类似新浪微博改版这样的大型升级，应让用户自主选择，最好能够提供让用户自主回滚至旧版本的渠道。&br&&br&对于客户端应用，可以考虑类似Chrome的多channel升级策略，让用户自主选择采用stable、beta、unstable channel的版本。在用户有明确预期的情况下自行承担试用风险。&br&&br&&b&数据反馈&/b&&br&&br&用户数据反馈：在得到用户允许的前提下，收集用户的使用新版本应用的情况。如客户端性能、客户端稳定性、使用次数、使用频率等。用于与旧版本进行对比，决策后续是继续扩大新版本投放范围还是回滚。&br&&br&服务端数据反馈：新版本服务端性能、服务端稳定性等，作用与用户数据反馈类似。&br&&br&&b&新版本回滚策略&/b&&br&&br&当新版本灰度发布表现不佳时，应回滚至旧版本。对于纯粹的Web应用而言，回滚相对简单。主要难点在于用户数据的无缝切换。对于客户端应用，如果期待用户自行卸载新版本另行安装旧版本，成本和流失率都太高。可以考虑通过快速另行发布新版本，利用升级来“回滚”，覆盖上次灰度发布的修改。&br&&br&对于移动客户端，新版本发布成本较高，需要Appstore、Market审核。本人没有移动客户端产品的经验，不太确定移动客户端产品如何处理灰度发布及回滚。但尽量将客户端打造成Web App，会更有利于升级和回滚。（不过苹果对纯Web App类的App有较强的限制，好像已经不允许在Appstore上发布这类应用了？）&br&&br&&b&新版本公关运营支持&/b&&br&&br&对于改版级别的大型升级，需要配合公关运营支持，用于及时处理用户在微博、博客等渠道给出的“显式反馈”。对比通过隐式数据反馈得到的结论后，综合考虑应对策略。
仔细考虑一下灰度发布系统要达到哪些目的，基本就能有答案了。需要注意的是，客户端应用（无论PC端还是移动端）的灰度发布要比Web应用的灰度发布更为复杂，因为应用运行在用户持有的终端上，数据采集和回滚都更为困难（但可采集的数据类型要更加丰富）。注…
已有帐号？
无法登录？
社交帐号登录