当前位置:科学 > 正文

分享一例有意思的灰度设计缺陷,浅谈灰度方案的设计

2023-05-19 13:55:07  来源:技术联盟总坛

崔剑飞(木祎) 阿里开发者 2023-05-18 09:02发表于浙江

阿里妹导读



(资料图片)

灰度很重要,灰度的策略也需要结合实际情况进行灵活的调整,本文跟大家分享了一个前些时间发现的灰度设计bug。

一、案例分享


跟大家分享一个前些时间发现的灰度设计bug,这个bug蛮有意思,看似完美方案,但因为未考虑到一些技术特性,导致存在缺陷。为更通顺的说明,先进行一些名词介绍。

灰度发布:灰度发布是指在黑与白之间,能够平滑过渡的一种方式。AB-test就是一种灰度发布方式,让一部分用户继续用A,一部分用户开始用B,如果用户对B没有什么反对意见,那么逐步扩大范围,把所有用户都迁移到B上面来。灰度发布可以保证整体系统的稳定,在初始灰度的时候就可以发现、调整问题,以保证其影响度。(引用Wiki百科)

安全生产环境:(简称SPE)为保障线上稳定性提供灰度流量生产环境。发布从预发到生产环境前,需要经过SPE进行流量验证。


1.1 案例简述


同一个应用,需要消费同一个topic消息两次,因不同环境的配置不一致,导致消息存在消费遗漏。


1.2 案例背景


需求的主要修改的点是将历史各异的结算模型改成统一结算模型,新老模型相差较大。在notify消息的处理上,原本是想在同一个consumer处理类中改写,但成本较大,且考虑到老模型后续是需要下线的,从代码整洁的角度出现,新写了一个消息处理类,使用另一个group组订阅,最终的结果就是同一个topic消息会被两个group组订阅,并由两个consumer类去消费。


1.3 方案描述


原灰度方案如下:设定一个时间作为灰度生效时间,再通过消息中买家的尾号作为切流条件。当一个消息被接收时,会先判断当前时间是否大于灰度时间,若满足大于灰度时间的条件,则判断买家尾号是否在灰度切流范围中,均满足时,走新的结算流程。若两个条件有一个条件不满足,则走老结算流程。


1.4 方案缺陷分析


上述方案,一般而言,是一个很不错也很完备的方案,但结合本次结算模型迁移的背景,则存在一个缺陷。缺陷的由来即是“双消息”。那么双消息处理是怎么引发问题的呢?原因在于灰度配置文件在安全生产和线上生产间阶梯推进时,需要等待1小时,这一小时会导致部分消息被遗漏。假设当前SPE和线上生产已同步推进至10%,此时SPE的配置推进至20%,线上生产依旧保留10%,那么双消息一条走到SPE,另一条走到安全生产时,即会出现问题,因为SPE的老group实现类只关心80%-100%的流量,而线上生产环境只关心0-10%的流量,中间存在消息遗漏。逻辑如下图:


1.5 案例的特殊之处


1.结算模型的升级,结合业务考虑,引入了双消息消费的方式。

2.新老consumer无差别监听消息进行消费,造成消费遗漏。

3.SPE安全生产停留1小时的机制。


1.6 改进策略


1.灰度时间总开关不变

2.买家尾号的灰度策略改为“尾号为K,区间生产时间为V”的KV对,其中V是一个未来时间,且“V值>系统时间+安全生产停留时间”。如下,从50%流量推至100%,100%的流量配置生效时间是一个未来时间。

[    {        "rate":5000,        "whiteList":[        ],        "activeTime":1682928000000    },    {        "rate":10000,        "whiteList":[        ],        "activeTime":1683795376000  //未来时间    }]

在跟进完上述问题后,我查阅了过去一年部门故障复盘文档,基本所有的故障和资金事件复盘,均有提及灰度手段。而像本案例中,于“不确定行为”进行灰度的控制,是新人们常见的误区。因此,结合自己在交易线的一些经验,谈下我认知中的灰度,并将阐述我理解的MVP版灰度方案,至少需要些什么,灰度设计中需要注意什么。

二、设计一个MVP版的灰度方案



2.1灰度方案是什么?


在聊how的问题前,有必要先讲一下WHAT和WHY。先聊一下WHY,假设没有任何管控流程,代码发布后立即全量上线,又恰巧不幸地出现系统、数据或逻辑等方面的问题,那一场灾难也就随之而来,而且业务体量越大,风险&舆情&资损的敞口也就越大,损失越不可挽回。因此,发布流程需要必要的管控和监督,将风险控制在有限范围内,这样的发布流程即是灰度。平滑过渡是灰度重要特征,这个特征也决定了灰度发布的作用至少有两点:

1.降低发布带来的风险,让少部分用户先使用新功能新版本,提前小范围内发现bug或性能问题,及时做好修复,降低新功能新版本的影响。

2.通过新老版本对比,观察新功能带来的效果,更好起过渡效果。


2.2 MVP版的灰度方案( Minimum Viable Product最小可执行版本)


2.2.1 明确灰度维度

常见的灰度规则有用户尾号(买家或卖家),业务单据id(如商品、订单、结算单、运单)、黑白名单、人群圈选(如定向投放)。黑白名单和人群圈选有点类似A/B-test,能比较精准的用于线上功能测试。一般用于两种场景:

1.风险极大,而功能测试又无法完全覆盖的场景,可以使用白名单和人群圈选做第一步的灰度策略。

2.功能存在争议,beta版功能测试,可以使用此法去收集反馈。

而采用用户id或业务id作为灰度条件,是更为通用的方式,这两种方案的流转模式如下:

尾号id灰度策略一般会与白名单策略组合使用,更稳妥的达到管控效果,结合我目前的项目实践,有一种较为万能的灰度公式分享给大家。

“1.白名单(个别用户)--> 2.买家尾号灰度1% -->3. 尾号3% -->4. 尾号10% -->5. 尾号30% --> 6. 尾号灰度50%-->7. 尾号灰度70%-->8. 尾号灰度100%”。

多数场景下,这一套公式流程是比较适用的。也许有同学会有疑问,是否可以采用“卖家id”灰度维度,多数情况下是可以的,但以卖家id为灰度规则,更容易命中到超大商家,可能带来的影响有两个,1.集中的单据被影响,2.相较买家购买,卖家维度更容易命中爆品热度的商品,引发数据库热点。因此,灰度维度的选择,是一件需要深思的事,我认为有几个原则需要遵守。

1.样本避免以偏概全,尽量保证样本的随机性,近似均匀分布。

这一点很好理解,比如你想统计有多少人坐过杭州地铁,然后你跑到杭州地铁站去做问卷调查,除了得到100%的结果,你一定会得到更多的白眼。同样,在灰度维度选择上,也需要保持样本的随机性。如用户id、商品id,一般就可以较好的满足日常灰度的需要。而像业务的人群id,在筛选时就得严格关注一下样本的随机性。

2.筛选条件需要由严至宽,逐步放开。

举一个例子,是去年进行某支付退款业务的中台升级时,在完成所有验证后,灰度策略里包含了一条,即逐步放开退款单的金额 ,从“控制退款单1元-->退款单10元-->30元-->100元-->300元-->全量放开”。这就是一种典型的风控层面的灰度策略,由严至宽。

2.2.2 做好过程观察和推进

灰度是一个逐渐由白至黑的过程,在这个过程中,“灰度可观察”和“灰度流程管理”,都需要做好。

灰度可观察

灰度过程必须可观察,这样才能及时发现问题,真正发挥灰度的价值。我总结了四个点,是灰度可观察的最小条件集,包括完备的流量日志、核对告警、反馈渠道及时触达和性能关注。以下逐一阐述。

策略一:完备的流量日志

完备的日志对于灰度过程中的问题发现是非常有必要的,将详细的处理逻辑,尤其是报错和异常的日志,是灰度可监控的必要条件。一方面,技术同学可以通过观察日志的错误日志,进行流量健康度的观察,另一方面,也可以结合 sunfire的统计监控能力,对灰度过程的报错做阈值告警。

策略二:核对告警

灰度项目中,核对也是常用的观测策略,无论是新业务的逐步上新或是新老业务的逐渐切换。如一个重资金相关的新业务上线,在逐步的灰度过程中,使用核对是验证非法单据的出现。这也是我日常业务跟进中经常使用的策略,比如RP3迁移灰度时,对打上新逻辑标的订单做校验。完备的日志是从系统处理的角度进行观察,而监控核对是从数据的角度进行另一个维度的观察,相辅相成不可缺少。

策略三:内部反馈渠道&舆情关注

这种策略一般用于白名单灰度的情况,且选中的白名单是与集团服务同学平时沟通较多且友好的商家,在百分比切流前,进行白名单个别商家的试点,关注异常情况。白名单内测后,切流阶段,如果有不可规避的风险,需要技术同学时刻关注客服反馈,必要时需要给客服统一的话术。

策略四:关注灰度过程中的性能问题

灰度不仅应用于功能,也可用于性能观察。灰度过程的流量是逐步增大的,新老功能的差异带来的性能影响,也是逐步放大的。比如一次改动中,新老流量模型中,对于某个信息字段的获取走的不同信息渠道,那么新老模型的性能差异就需要关注。此时不仅是业务的日志监控,应用系统的监控也需要安排上,尤其是灰度范围扩大的一段时间里,尤其需要关注接口性能,包括依赖rt变高,自身rt变高,数据库热点等问题。

灰度流程管理

好的灰度流程,需要具备优雅、可靠的特征。我认为“有序的推进”和“可及时回退”是灰度流程中必要的考虑。

有序的推进

从0到1的灰度过程,是一个边观察边推进的过程,通过日志、核对、自动化等手段做到有效观察后,在积累一定量级的单据后,再进行逐步的放开。需要关注的是如果配置非法状态下,是否保证老逻辑是否仍能正常消费。举例说明,下方伪代码是根据用户的尾号进行判断,在灰度配置平台里进行尾号的数字配置,那么,这一段代码看似正常,但实际隐藏着较大的风险:

//预期从灰度配置文件中读取一个int型的值,但配置中grayRange设置了一个字符串型“50%”,int grayRange = GrayHanlder.getConfig("灰度配置id").getInteger("grayRange");3if(userId mod 100 < grayRange){    //走新逻辑}else{    //走老逻辑}

上述代码在执行时,会报错,导致新老逻辑都不会走到。当然,在实际业务需求中,很少发生这么低级的错误,但我的意思是,依赖于配置的灰度推进,需要确保灰度逻辑进行必要的验证,灰度的推进也需要极其的谨慎。一般而言灰度代码只是一个if+else,但其背后影响却极大。

灰度流程推进的前提,一定有效的流量观察之后,而不是形而上的依据灰度时长,请确保这一点。分享一个真实的故障案例:

案例名:某B系业务的会员子账号id写入错误导致无法处理退款。

故障原因:因修复一个会员登录bug,更新了一个冷门字段的获取逻辑,某B系业务使用此字段做权限控制,导致业务受到影响。

灰度过程:此案例中的发布应用,在发布过程中进行了灰度停留,但灰度时间是晚上,而被影响的B系业务特性决定了晚间时分是流量低谷期,导致灰度过程中的问题未被及时关注,灰度流程未发挥应有的效用。

灰度改进:涉及会员和商家操作的系统,灰度发布时间包含商家操作高峰期(上午8点--10点)。

灰度回退

当上线功能的表现不符合预期时,需要考虑控制灰度回退。一般在灰度的配置文件中,需要引入逻辑开关,值为true或false,命中true后,才会进入更细粒度的灰度命中。所以当结果观察不符合预期后,可以快速推进配置为false,必要时,走紧急审批。确保没有新流量走到灰度流程中。

灰度回退仅能阻止问题的扩大,但已出现问题的单据需要做好妥善处理,一般而言,有两种方案。

1.修订数据:新写修正接口或批量更改Db数据,但需要注意合规问题。

2.快速修复并发布新版本,利用升级来“回退”,覆盖上次灰度发布的修改。


2.3 灰度工具


这里仅讲一下服务端常用的灰度工具,一般都是轻量配置的平台,将配置内容脱离于代码之外,可以清晰快捷的推进,在灰度推进时,仅需做配置更新即可,不用发布代码。配置可以简单成一个String,也可以是一个json,举例如下。

{        "flag": true,           //总开关,true为开启,false为关闭恢复        "buyerAccessFlow": 10,  //用户尾号控制,当前为尾号 0-9用户进入恢复        "amountLimit": 30000    //控制金额,金额小于300元,才进入恢复      }

三、关于灰度其它常见的问题



3.1 机器分批发布不是严格意义上的灰度策略


许多同学对于灰度的认知还不多,认为分批发布也是一种灰度策略。其实严格意义上讲,应用的分批发布更多的是出于对系统稳定性的考虑,而不是灰度验证的考虑。从“可回退”的角度看,分批发布过程中,即使发现了问题,发现了脏数据,那数据也都是随机的,数据无法通过特征来找出数据,也就无法对脏数据进行订正或回滚,所以不是严格意义上的灰度策略。


3.2 灰度设计的一致性原则


灰度意味着线上存在两套处理规则或流程,一条业务单据在两套流程中处理的结果一般也是不一样的,因此确保单据在灰度过程中的一致性非常有必要,否则很可能引发线上问题,这里先举一个真实发生的例子

案例名:某电商业务增加一种退款打款渠道,灰度策略不合理导致双渠道出账的情况。

案例描述:RPC调用退款同意时,第一次命中尾号灰度,走进组合渠道中,但组合渠道里出现调用异常,但此时渠道会进行自身的重试。在重试期间,用户二次点击,此时灰度策略有变化,导致走到了另一个组合渠道,进行了打款并成功。

案例分析:发生的原因在于打款事项的幂等被破坏。两个渠道无法感知对方的打款行为。

案例解决:在申请退款时,即打上标,将灰度行为完全依赖于标识,后续所有的处理依标进行,避免不同调用引起的灰度不一致的行为。后续退款相关的灰度行为,都前移至了申请退款阶段,此时命中灰度规则后,即会给它打上一个灰度标,后续的行为完全按标行走。

上述案例,是一个非常经典的问题,即灰度过程中数据一致性未能做好保证,导致出现两种打款策略组,破坏了幂等。那么怎么样保证灰度一致性原则呢?我认为有以下三个原则需要遵循:

原则一:灰度命中处理只能被一次消费

如上述案例,如果将灰度的判定放在“同意退款”,那就非常容易出现前后两次调用时,走到不同处理流程的尴尬情况,反之,我们可以巧妙的将灰度判定前移至“申请退款”,并打上相应的标,后续“同意退款”则按标进行即可,保证灰度命中处理只被一次消息。“同意退款”是想灰度的功能,但“申请退款”才是真正的灰度对象。所以想灰度的功能跟实现灰度的对象,并不一定要一致。

原则二:确保不同环境的灰度一致性

许多带安全生产环境的应用,从预发到线上前,需要在安全生产环境观察1小时以上,包括应用代码发布或配置发布。这中间的时差,极其容易引发灰度的混乱,比如开头说的那一个case,由于notify无差别的往安全生产和线上生产环境发消息,应用在两个环境中的配置不一致,导致消息被过滤的问题。

这种问题,就像使用原则一的方法进行预先打标处理,也是无法规避的,比较好的处理方法是,制造一个时延周期,确保线上生产和安全生产的一致性。比如推送一个未来的生效时间,且确保生效时间晚于全量发布完成后的时间,这样即可确保两个环境的一致性。

原则三:确保不同应用的灰度一致性

如果灰度流程涉及多个应用,那么灰度逻辑需要确保一致。简而言之,一个形如“A-->B-->C”的链路中,要么保证B系统无视A系统的灰度条件,要么确保灰度逻辑仅在A系统中进行判断。


3.4 前端灰度策略


前文提到的灰度策略,我均是从一个服务端的视角考虑,其实在前端或web端也有一些常用的灰度技巧,这里简单聊一下。

1.CDN资源分流

前端资源放在CDN上,每次发布新版本,资源即增量的传到CDN并指定唯一版本号。在处理请求时,依据前端策略来分流不同用户使用不同版本的CDN,展示不同的样式。此时,相应的后端接口,需要依据参数来控制灰度策略,区分前端不同的请求。一般在类似于账单业务升级时,会用到这种策略。因为前后端都需要灰度,所以需要由前端控制灰度策略,后端进行参数兼容,保证账单的多样性。

2.客户端分流

客户端分流的策略与CDN资源一样,由客户端来控制灰度分流,根据客户端传来的参数和版本号,结合当前的放量策略来决定服务情况。客户端分流的策略也会更多,如用户设备系统、app版本号、app安装渠道、用户ID、设备ID。

四、写在最后


灰度很重要,灰度的策略也需要结合实际情况进行灵活的调整。本文中提到的策略、观点均是本人一得之见。引玉之砖,欢迎大家讨论。



关键词:

推荐阅读

首都新机场叫什么名字 机场是24小时开放的吗?

首都新机场叫什么名字?一般指北京大兴国际机场。北京大兴国际机场定位为大型国际航空枢纽,国家发展新动力源,支撑雄安新区建设的京津冀区 【详细】

什么牌子的插排好 优质的插排应该具备哪些特质呢?

什么牌子的插排好品牌插座有公牛、西门子, TCL, 西蒙, 奇胜, 松下, 施耐德, ABB、朗能,等。为了满足大众对插座的各种需求,各 【详细】

李嘉诚的车是什么 李嘉诚长江塑料厂怎么样?

李嘉诚的车是什么说到李嘉诚,我们肯定会很熟悉。出生于潮汕的他是香港首富,也是中国顶级房地产大亨。根据《福布斯》、2020年发布的数据, 【详细】

飞龙股份002536今日主力资金流向 飞龙股份002536主力控盘分析

飞龙股份002536今日主力资金流向【飞龙股份(002536)】 今日主力资金流向,资金净流入105 11万元,今日超大单净流入296 82万元,大单净流入 【详细】

中国获得诺贝尔奖的人汇总 ​诺贝尔奖介绍

中国获得诺贝尔奖的人汇总截至目前为止,我国获得诺贝尔奖的人一共有十一个1、杨振宁,美籍华人,1957年获诺贝尔物理学奖。2、李政道,美籍 【详细】

相关新闻

关于我们  |  联系方式  |  免责条款  |  招聘信息  |  广告服务  |  帮助中心

联系我们:85 572 98@qq.com备案号:粤ICP备18023326号-40

科技资讯网 版权所有