导读
灰度很重要,灰度的策略也需要结合实际情况进行灵活的调整,本文跟大家分享了一个前些时间发现的灰度设计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最小可执行版本)
常见的灰度规则有用户尾号(买家或卖家),业务单据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元-->全量放开”。这就是一种典型的风控层面的灰度策略,由严至宽。
灰度是一个逐渐由白至黑的过程,在这个过程中,“灰度可观察”和“灰度流程管理”,都需要做好。
灰度过程必须可观察,这样才能及时发现问题,真正发挥灰度的价值。我总结了四个点,是灰度可观察的最小条件集,包括完备的流量日志、核对告警、反馈渠道及时触达和性能关注。以下逐一阐述。
完备的日志对于灰度过程中的问题发现是非常有必要的,将详细的处理逻辑,尤其是报错和异常的日志,是灰度可监控的必要条件。一方面,技术同学可以通过观察日志的错误日志,进行流量健康度的观察,另一方面,也可以结合 sunfire的统计监控能力,对灰度过程的报错做阈值告警。
灰度项目中,核对也是常用的观测策略,无论是新业务的逐步上新或是新老业务的逐渐切换。如一个重资金相关的新业务上线,在逐步的灰度过程中,使用核对是验证非法单据的出现。这也是我日常业务跟进中经常使用的策略,比如RP3迁移灰度时,对打上新逻辑标的订单做校验。完备的日志是从系统处理的角度进行观察,而监控核对是从数据的角度进行另一个维度的观察,相辅相成不可缺少。
这种策略一般用于白名单灰度的情况,且选中的白名单是与集团服务同学平时沟通较多且友好的商家,在百分比切流前,进行白名单个别商家的试点,关注异常情况。白名单内测后,切流阶段,如果有不可规避的风险,需要技术同学时刻关注客服反馈,必要时需要给客服统一的话术。
灰度不仅应用于功能,也可用于性能观察。灰度过程的流量是逐步增大的,新老功能的差异带来的性能影响,也是逐步放大的。比如一次改动中,新老流量模型中,对于某个信息字段的获取走的不同信息渠道,那么新老模型的性能差异就需要关注。此时不仅是业务的日志监控,应用系统的监控也需要安排上,尤其是灰度范围扩大的一段时间里,尤其需要关注接口性能,包括依赖rt变高,自身rt变高,数据库热点等问题。
好的灰度流程,需要具备优雅、可靠的特征。我认为“有序的推进”和“可及时回退”是灰度流程中必要的考虑。
从0到1的灰度过程,是一个边观察边推进的过程,通过日志、核对、自动化等手段做到有效观察后,在积累一定量级的单据后,再进行逐步的放开。需要关注的是如果配置非法状态下,是否保证老逻辑是否仍能正常消费。举例说明,下方伪代码是根据用户的尾号进行判断,在灰度配置平台里进行尾号的数字配置,那么,这一段代码看似正常,但实际隐藏着较大的风险:
//预期从灰度配置文件中读取一个int型的值,但配置中grayRange设置了一个字符串型“50%”,
int grayRange = GrayHanlder.getConfig("灰度配置id").getInteger("grayRange");3
if(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。
四、写在最后
灰度很重要,灰度的策略也需要结合实际情况进行灵活的调整。本文中提到的策略、观点均是本人一得之见。引玉之砖,欢迎大家讨论。
作者:崔剑飞(木祎)
来源:微信公众号:阿里开发者
出处
:https://mp.weixin.qq.com/s/QPYprfHeHBnh38HQBh_K-w