查看原文
其他

如何优雅进行灰度发布测试?中国工商银行是这样实践的

工行软件开发中心 高效运维 2023-01-27


分享中国工商银行软件开发中心项目组对于灰度发布的测试前移、静态测试、引流策略验证、回退方案验证等方面的测试实践。

作者:中国工商银行软件开发中心珠海开发四部

灰度发布(Gray Release),又名金丝雀发布,是从不发布,逐渐平滑过渡到正式发布的一种发布方式。在黑与白之间能够平滑过渡,得名灰度发布。灰度发布使新旧版本短期并存,新版本只向特定用户发布,产生的问题只影响部分用户,降低新版本上线风险。
如下图所示,通过引流策略将用户引流到灰度版本,可以有效控制爆炸半径,但增加了系统复杂度,需要考虑非灰度版本的兼容,服务连续性等,涉及到应用侧的灰度部署策略的制定和研发,需要开展针对性的测试,避免灰度发布引入新缺陷。
项目组开展灰度发布测试实践已近2年,取得一定实效,下面通过一个具体实例分享灰度发布测试经验。
项目组根据业务重要性、爆炸半径、部署频率确定灰度目标,经专家组评审后,制定灰度设计、实施方案。灰度发布测试主要是验证灰度设计、灰度实施方案是否满足灰度目标的要求,以及灰度方案对程序的改动不影响非灰版本功能。

1、开展测试前移工作

测试人员参与到灰度目标制定、灰度设计中,让灰度相关策略用最小修改成本试出最多缺陷。

(1)分析灰度目标

项目组制定灰度目标,主要包括灰度部署策略持续交付策略的确定。具体策略制定如下图,✅ 为选取的策略。

灰度部署策略:主要有物理灰度逻辑开关两种方式,物理灰度是物理隔离,逻辑开关通过代码增加开关实现。物理灰度安全性高于逻辑开关,但实现难度较大,宜采用物理灰度和逻辑开关结合方式,具体说明如下。

服务节点通过分布式框架自定义路由可实现物理灰度,修改路由控制即可,较简单,可实现物理灰度。但物理灰度可能无法兼容上下游不同的灰度策略,可同时实现逻辑开关。
批量节点、消息节点、大型机所在框架无法支持物理灰度,需自行修改程序,较复杂,选用逻辑开关方式。
数据库节点做物理隔离需数据同步,处理很复杂,可能涉及停机。支持物理灰度,需额外研发一个中间版本,采用逻辑开关方式。由于逻辑开关方式仅有一个数据库实例,表结构的变动涉及修改原分支功能,无法实现完整意义的灰度。

物理灰度节点部署范围:仅服务节点部署灰度节点。

物理灰度部署策略:为降低复杂度,采用单版本发布。要求服务节点旧版本的功能和其他节点新版本兼容,如不能兼容,则放弃物理灰度,仅使用逻辑开关。具体如下。

物理灰度版本发布范围:正式版本、补丁版本均按物理灰度发布。补丁版本的发布策略需根据正式版本所处阶段调整,具体如下。

正式版本阶段

补丁版本解决的问题

补丁版本安装策略

灰度试点

解决灰度试点问题

同正常版本。先安装灰度节点,后续和正式版本一同扩大试点,一同灰转正。

解决存量紧急问题

正式版本立刻灰转正,所有节点安装补丁版本。

解决存量非紧急问题

待灰转正后,所有节点安装补丁版本。

灰转正

/

所有节点安装补丁版本

物理灰度引流策略:使用多规则组合,白名单,渐进式方式引流。

持续交付自动化程度:根据持续交付工具的能力,尽可能自动化。

(2)分析灰度设计

灰度设计主要是引流策略的设计、服务端设计等。根据具体情况举例如下。

引流策略的设计:根据渠道和用户特征设计引流策略,匹配引流功能,避免灰度引流涉及重要客户。按分行、支行、柜员组合进行引流,根据灰度功能灵活配置,可逐步扩大引流范围。如,需要灰度登陆功能,在柜员未登陆的情况下,无法获取对应的支行,引流策略设置为按柜员引流;需要灰度跨支行调拨功能,调出支行在灰度,调入支行在非灰度,版本不兼容,设置为按分行引流。
客户端设计:根据客户端类型明确灰度版本推送下载方式。
服务端设计:通过参数配置灰度引流开关,灰度引流规则,支持灵活修改,实时生效。
数据库设计:根据具体修改评估是否可以物理灰度。
服务连续性设计:采用完全不停机方案,灰度在途功能可以闭环。

2、开展静态测试工作

主要包括整体灰度策略的静态验证和具体功能灰度的静态测试。

  • 对整体灰度策略:
物理灰度节点与普通节点物理隔离,如,灰度节点采用独立的容器模板。
服务节点存在对应的灰度节点。服务节点按功能归类多个节点,非重要功能服务节点,不实现物理灰度。对于命名相似的节点,可采用工具检查,避免混淆。
  • 对项目功能灰度:

从具体功能评估,是否需要灰度,是否可以灰度,以及具体的灰度策略。由于灰度策略限制,某个功能的修改会影响当期版本灰度策略。具体如下。
新增一套功能,新增表结构,不涉及相关通讯区改动,业务部门暂不开展相关业务,那么随正常版本开展灰度策略即可。
修改一套功能,涉及表结构修改,或者上下游通讯区修改,那么当期版本便无法灰度,其他需求如果需要灰度,考虑增加逻辑开关。
修改一套功能,影响比较小,不涉及表结构修改,或者上下游通讯区修改、消息推送等功能。不考虑灰度,随正常版本开展灰度策略即可。

3、开展测试执行工作

测试执行工作主要针对灰度实施开展。灰度实施包括灰度试点、灰转正等,具体过程举例如下。

灰度测试执行工作主要是引流测试、灰转正测试、回退测试、以及非业务功能测试。
引流测试:针对灰度试点工作开展。验证引流规则,以及分流后的功能验证。单独验证重点保障业务对象,强制引流到非灰节点,不受灰度引流策略影响。全链路灰度验证涉及上下游灰度引流策略一致,避免灰度,非灰均报错的情况。

对于灰度试点功能,开发灰度引流测试工具,遍历引流规则并核对结果。灰度试点功能自动化脚本调用引流测试构件,轮询引流规则,根据灰度、非灰节点使用不同版本的断言,实现引流测试自动化核对。通过Jenkins例行调度运行自动化脚本,可快速验证引流策略和灰度试点功能。

对于存量功能,使用工具将存量功能生产日志在灰度、非灰分别运行回放,比对两者结果一致。

灰转正测试:验证在不停机转正场景下,在途业务可以闭环。
回退测试:验证在途业务可闭环,且支持回切。
非业务功能测试:主要包括高可用测试,性能容量测试。

做好灰度发布的质量守护是一个长期的过程,需要我们时刻关注灰度发布的问题,发现改善点,及时提升。以上实践欢迎同仁参考交流。

还不过瘾?还想了解更多精彩?GOPS  2023 · 深圳站要来啦!

早鸟票限时限购中,扫码立刻解锁精彩~

近期好文:

助你快速入门,16 张图教你看懂 Ansible,赶紧收藏~

“高效运维”公众号诚邀广大技术人员投稿

投稿邮箱:jiachen@greatops.net,或添加联系人微信:greatops1118。
点个“在看”,一年不宕机

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存