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


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变高,数据库热点等问题 。


推荐阅读