与时俱进「风险系统保障质量之路」非同寻常

京东云开发者
• 阅读 277

作者:梁冬冬

风险系统复杂且又庞大,质量如何保障需要我们付出一点一滴的努力来浇灌系统之花

一、大促备战,求有序,求稳定:

大促是每年例行高考,把人和系统的各项能力激发,衡量系统健壮,容错性;凌晨3点的身影就像一束光,夺目耀眼;今年的大促与往年不同,倡导绿色,节能减排,降本增效,把各种资源做到利用最大化,产生更大的价值,让大促备战产生了一丝温度

1)压测备战时间表(统筹整体,从4.21-6.23我们把剧本编制到细枝末节,是一条生命线)

2)服务器扩容缩容计划(节能减排,把资源利用合理化,让价值体现最佳)

3)系统优化清单(风险策略的不断增加、迭代,对系统是实时的挑战,通过不断优化系统,让系统轻松应对大促)

3)压测目标与评估(精准预估流量,通过流量复制形式生成相关压测数据,保证数据的还原程度,压测轮次减少,压测质量不减,反而增强)

4)压测接口清单表(计划压测接口,压测轮次,分层分次,仅仅有条)

5)大促备战准则与规范(备战规范是我们的方向标,准绳,像大海中的指南针指引方向不能偏航)

6)备战注意事项(把常规事项罗列清晰,把事情做到最佳)

7)监控与看板(系统风险的兜底方案,我们监控的有力保障,最短的时间发现、定位、解决问题)

8)备战待办事项清单(把大促工作相关待办项罗列清晰,有条不紊的进行展开)

9)备战会议室与运营(因为疫情,我们把战场分成线上,线下相结合,提前做好准备工作,打一场胜仗)

二、预警监控,求全面,求精准:

预警监控是质量的最后一道关卡,同时也是质量的兜底方案,我们格外重视建设这块的能力。

预警全面性:预警分为业务预警、系统预警、资源预警三大类,业务预警在三层最上端,也是对业务结果的检验检测,经过我们长期对业务数据分析,对预警的阈值不断调优,对预警的等级分层等,业务预警的覆盖度不断显著提升;整体配置预警1000+,业务预警的覆盖度稳步提升,同比去年提升56%左右,整体覆盖了核心场景。

1)梳理业务结果数据(对业务细化,业务熟悉度更高)

2)接入风险洞察系统(通过数据源接入到实时风险洞察实时计算平台)

3)配置数据集(通过sql配置不同的数据加工逻辑)

4)设置相关告警阈值(通过线上数据分析,得出精准的阈值结论)

5)手机相关接受人,预警等级,预警方式,预警信息等(把相关的干系人,预警的等级方式统一配置齐全)

6)测试预警触达(验证预警的有效性)

7)预警启用(启用后,正式运营告警)

8)通过设置预警机器人相关核心预警项,增强预警的监督与及时性(通过机器人运营,把应用负责人跟预警强关联起来,力保发现的线上问题,在最短的时间内通知到干系人,处理以及监督解决)

预警的精准度:提升预警的精准度,是为了及时发现以及精准定位线上问题 以及 降低预警运营成本最有效的方案;通过我们一年多来研究业务预警,把风险系统的业务预警拆分成多层,通过四分算法等机制已经形成了一套标准化、统一化、流程化的预警运营的方案,至今事故级别预警精准度达到100%,准事故级别预警达到99.6%左右,高危级别预警在76%左右。

1)事故级别预警(精准度缺失无法容忍block级别)

2)准事故级别预警(精准度容忍略微缺失,精准度至少在99%以上)

3)高危级别预警(高危级别预警类比系统精细化预警,容忍精准度缺失,讲究覆盖度与精准度的平衡,精准度要求在80%以上)

3)高危级别预警(精细化运营类的告警,容忍有精准度缺失,80%以上)

三、自动化覆盖度,求效率,求变化

在不变中求变,在变化中不变;交付的质量与交付的效率本身是一件冲突的事,可以把冲突的事做成不冲突,要客服种种的困难,不达目的不放弃的精神

移动端篇:设备指纹是风险侧技术能力建设的重要工具以及手段,设备指纹会以SDK或者JS的方式嵌入到业务的app或者页面里,获取相关的风险信息,达成风险识别的能力;设备指纹的自动化涉及到两个方面:

1)设备指纹的稳定性:通过调研线上崩溃的区域,容易发生崩溃orANR的部分多数是来自于数据接口的交互导致崩溃,前期通过对业务的调用链路梳理,把相关崩溃风险的区域,做成了UI自动化,通过脚本控制手机,执行相关的业务逻辑操作,通过循环次数 以及 运行时间控制重复操作来模拟操作,校验是否会出现崩溃等异常情况;这块我们已经通过封装开源的工具,把执行脚本,采集相关logcat相关的崩溃或ANR信息打印到测试报告内,通过发邮件的方式,最终收集相关的报告结果,大大提升了测试的效率的同时提升了设备指纹的稳定性;

2)设备指纹的自动化:设备指纹自动化采用UI模拟方式进行自动化,自动化有主控master通过分发的形式,把测试任务下达给每一台设备,最终形成分布式的执行自动化的效果,大大提升了自动化的执行效率,同时也提升了设备指纹的设备兼容性;

3)接口测试篇:风险系统偏底层服务居多,决策业务的是否有风险之本。在风险侧展开接口自动化是为了更好的支撑业务,同时也是为了保障质量。为了响应公司的号召,为了达成支持业务最大化,今年开始陆续把自建的平台关闭,关停了一些ROI低的工作,把相关的业务自动化测试用例,陆续有条不紊的迁移到更佳优秀的接口测试平台上,把自研开发平台的人力加到业务支撑,接口的自动化今年覆盖度从年初的18%到年中的40%左右,实现了主流程链路的覆盖,业务使用率达到32%左右,从行云里的数据来看,上半年无论是从测试交付的周期还是吞吐量都有较大的改善,真正的做到了自动化赋能业务,业务交付显著增长的结果;

4)精准评估需求影响范围:需求评审、以及测试用例的评审是拉齐研发,测试,产品对需求认知的一场不错的会议,所以今年P0P1级别需求都要求强制用例评审,评审用例的同时,把大家的信息拉通,达成一致;今年,在需求评审会里,增加了一个环节,就是通过我们自研的针对增量代码的(本次需求)链路分析,以及影响的方法范围,产出一份血缘关系图,在需求评审的同时,可以精准的圈定影响的范围,让影响范围更加量化,可度量;

5)度量测试质量:作为质量负责人,更关心的是如何管理好质量,那么质量团队每个人测试质量的好与坏,或许也是需要度量,可把控;今年推进测试代码覆盖率的执行,通过字节码的方式,在测试人员执行用例的同时,可以精准的定位出来,测试用例覆盖代码的行数,来评估测试是否都覆盖全面,事后知道可度量,可追溯;

6)策略测试自动化:策略测试是风险侧独有的一种测试场景,策略是分析师长期积累的结晶,精华,是风险人的智慧,策略质量的好与坏是对系统有牵绊的。今年通过与策略效能组共建测试平台,达成了从策略包测试,自动生成案例,再到策略包接口的流量复制,通过线上天然的流量验证策略配置的准确性,已经形成了一套方法论并落地,今年会加大推广力度实现策略测试一体化,平台化,智能化;

7)混沌工程:混沌工程为大促而生,今年618非同寻常,主战场为线上线下相结合,在各种的不确定性中我们寻求系统的更加的稳定,健壮。今年引入了混沌工程,把一些核心依赖接口的超时,缓存异常,DB宕机,服务器资源各种异常模拟复现,预知了系统风险,大促稳中求稳,不断求新;

8)UI自动化测试篇:UI自动化历经数年,UI自动化已经相对稳定,但业务的日新月异,对前端的不断变更,对UI自动化运营是个不小的难题。综合看,风险测的UI自动化达成的主要是不频繁修改的,主流程的,达成覆盖度100%。非核心场景的,经常变更的,由手工执行,做好UI的用力分层,分类至关重要;

四、质量卡点与风险识别,求全面,求质量

设置质量卡点,是质量体系的线上化的一种方式,说的直白点就是把风险侧质量体系相关的规范准则,通过线上化的形式,设置卡点或者实时预警,通过卡点或及时触达来规避流程、操作风险等

质量卡点是我们重中之重,组之大器,红线,底线,不可逾越。今年我们优化了多处准则规范,为了增强大家的质量意识,形成有效的规范规则,有效的保障质量。

1)上线监控:无论是Jone、jdos、JCI上线都需要走严格的审批上线,杜绝顺风车,AB异常审批,不经过测试等等上线审批异常行为,通过把JDOS审批流信息接入风险洞察系统,配置了相关的实时监控,把异常行为监控一览无余,杜绝踩踏质量红线

2) 效率监控:测试交付的效率,交付的吞吐量是度量测试效率的重要指标之一,需要实时的发现问题,解决问题,做到每一个需求,每个人数据透明化,今年也是把效能交付周期配置了相关预警,当交付周期长时,相关的预警会触达效能小组的相关人,告知效率风险,有人对应跟进分析,给出结果;

3)缺陷与用例监控:测试用例,缺陷都是测试人员的产出物,通过监控分析这些数据,对以后识别系统好与坏,以及测试人员执行的情况最有利的支撑。

4)核心系统上线评审:核心系统上线评审是对系统上线的敬畏,今年核心系统上线,我们都会组织架构师、负责人等相关干系人一起评审业务,代码,以及影响范围;增加一道上线评审,规避质量风险发生;

5)测试用例强制评审:需求评审、以及测试用例的评审是拉齐研发,测试,产品对需求认知的一场不错的会议,所以今年P0P1级别需求都要求强制用例评审;

6)配置相关风险:配置变更、迁移变更、规则修改、策略变更等等,配置类的发布是最容易忽视的区域,也是今年要纳入测试的范畴的点,配置要经过测试并通过审批流程后方可上线;

7)排期风险:资源投入、倒排期、外部依赖、缺陷处理时间等等,都需要我们关注,要保证项目需求进度无风险,按时交付,力保业务;

8)安全合规风险:数据泄露、泄露用户信息、诱导用户、敏感数据等等都是风险合规的重中之重,需要我们在测试业务的过程中识别出来这种风险,提出风险,规避风险;

9)客户自损类风险:风险策略拦截、企业授信放款、AB系统衔接、规则漏洞等等都会产生相关的风险,在系统层面把控风险尤为重要

10)系统风险:系统上线风险、系统不稳定、性能不达标、依赖接口异常等等,在功能测试后,要全面评估系统的影响面影响 的种类,提前做好预发预案;

还有未考虑到的方面,欢迎大家补充交流

点赞
收藏
评论区
推荐文章
blmius blmius
2年前
MySQL:[Err] 1292 - Incorrect datetime value: ‘0000-00-00 00:00:00‘ for column ‘CREATE_TIME‘ at row 1
文章目录问题用navicat导入数据时,报错:原因这是因为当前的MySQL不支持datetime为0的情况。解决修改sql\mode:sql\mode:SQLMode定义了MySQL应支持的SQL语法、数据校验等,这样可以更容易地在不同的环境中使用MySQL。全局s
京东云开发者 京东云开发者
9个月前
京东物流常态化压测实践 | 京东云技术团队
大促备战压测备战时间紧、任务多,压测备战压力较大,在大促备战多专项并行资源紧张情况下,频繁的系统调优给整个大促带来不可控的风险因素。引入常态化压测的手段,通过每周或每月的定期压测行为,持续把控系统性能表现,保证服务稳定性;同时将需求上线引起的性能问题前置暴露,及时定位优化问题;减轻备战压力,提升压测效率。
Wesley13 Wesley13
2年前
FLV文件格式
1.        FLV文件对齐方式FLV文件以大端对齐方式存放多字节整型。如存放数字无符号16位的数字300(0x012C),那么在FLV文件中存放的顺序是:|0x01|0x2C|。如果是无符号32位数字300(0x0000012C),那么在FLV文件中的存放顺序是:|0x00|0x00|0x00|0x01|0x2C。2.  
Easter79 Easter79
2年前
Twitter的分布式自增ID算法snowflake (Java版)
概述分布式系统中,有一些需要使用全局唯一ID的场景,这种时候为了防止ID冲突可以使用36位的UUID,但是UUID有一些缺点,首先他相对比较长,另外UUID一般是无序的。有些时候我们希望能使用一种简单一些的ID,并且希望ID能够按照时间有序生成。而twitter的snowflake解决了这种需求,最初Twitter把存储系统从MySQL迁移
Wesley13 Wesley13
2年前
mysql设置时区
mysql设置时区mysql\_query("SETtime\_zone'8:00'")ordie('时区设置失败,请联系管理员!');中国在东8区所以加8方法二:selectcount(user\_id)asdevice,CONVERT\_TZ(FROM\_UNIXTIME(reg\_time),'08:00','0
Wesley13 Wesley13
2年前
PHP创建多级树型结构
<!lang:php<?php$areaarray(array('id'1,'pid'0,'name''中国'),array('id'5,'pid'0,'name''美国'),array('id'2,'pid'1,'name''吉林'),array('id'4,'pid'2,'n
Wesley13 Wesley13
2年前
Java日期时间API系列36
  十二时辰,古代劳动人民把一昼夜划分成十二个时段,每一个时段叫一个时辰。二十四小时和十二时辰对照表:时辰时间24时制子时深夜11:00凌晨01:0023:0001:00丑时上午01:00上午03:0001:0003:00寅时上午03:00上午0
Stella981 Stella981
2年前
Jenkins 插件开发之旅:两天内从 idea 到发布(上篇)
本文首发于:Jenkins中文社区(https://www.oschina.net/action/GoToLink?urlhttp%3A%2F%2Fjenkinszh.cn)!huashan(https://oscimg.oschina.net/oscnet/f499d5b4f76f20cf0bce2a00af236d10265.jpg)
Wesley13 Wesley13
2年前
MySQL部分从库上面因为大量的临时表tmp_table造成慢查询
背景描述Time:20190124T00:08:14.70572408:00User@Host:@Id:Schema:sentrymetaLast_errno:0Killed:0Query_time:0.315758Lock_
京东云开发者 京东云开发者
9个月前
架构师日记 - 从技术角度揭露电商大促备战的奥秘 | 京东云技术团队
本文从技术角度深入分析了大促备战的背景和重要性,重点介绍了备战期间稳定性保障的相关措施,包括具体的指导方向和落地细节。本文旨在回顾和梳理备战期间的关键步骤,以帮助我们更加从容的应对系统稳定性的挑战。