《北京金融科技产业联盟:2023金融级混沌测试能力平台建设要求研究报告(34页).pdf》由会员分享,可在线阅读,更多相关《北京金融科技产业联盟:2023金融级混沌测试能力平台建设要求研究报告(34页).pdf(34页珍藏版)》请在三个皮匠报告上搜索。
1、金融级混沌测试平台建设能力研究报告北京金融科技产业联盟2023 年 10 月版权声明本报告版权属于北京金融科技产业联盟,并受法律保护。转载、编摘或利用其他方式使用本白皮书文字或观点的,应注明来源。违反上述声明者,将被追究相关法律责任。I编制委员会主任聂丽琴编委会成员王璐张海燕编写组成员崔杰杜昆鹏李博文李振栾琪肖晶王耀强毋文涛张翔叶强林编审黄本涛张蕾参编单位:北京金融科技产业联盟中国建设银行股份有限公司平凯星辰(北京)科技有限公司北京国家金融科技认证中心有限公司北京同创永益科技发展有限公司II摘要摘要混沌工程是通过主动向系统中引入软件或者硬件的异常状态(扰动),制造故障场景并根据系统在各种压力下
2、的行为表现确定优化策略的一种系统稳定性保障手段。应用混沌工程可以对系统抵抗扰动并保持正常运作的能力(稳定性)进行校验和评估,提前识别未知隐患并进行修复,进而保障系统更好地抵御生产环境中的失控条件,提升整体稳定性。本报告以混沌测试工具集为基础,采用开源云原生模式构建自动化混沌工程平台,针对分布式系统的复杂性特点,设计不同层次的故障进行模拟。平台除提供应用层以及实际物理环境故障模拟外,还提供较为完善的故障编排功能,以便监控分布式系统状态,找出项目潜在的风险。本报告所述的混沌工程平台相对完整,可为国内金融行业构建混沌测试验证平台,提供实践经验和可行的参考方案。III目录一、混沌测试平台建设背景与目标
3、.1.1(一)建设背景.1(二)建设目标.2二、混沌测试平台建设要求.3(一)功能要求.3(二)适配性要求.7(三)集成要求.7三、混沌测试平台建设情况.8(一)系统构成.8(二)技术架构.9(三)功能模块.10(四)故障种类.12四、混沌平台测试方案与测试实践.13(一)测试目标.13(二)测试内容.14(三)测试过程.15五、混沌测试平台建设实践.271一、混沌测试平台背景与目标(一)建设背景随着数字化转型,金融行业加快了新一代架构转型的步伐,由传统的 SOA 架构向分布式架构、去中心化发展,当前还进阶到注重云化支持和异构化微服务支持的服务网格模式。系统规模日益庞大,交易链路长、数据流转复
4、杂,微服务架构由于技术异构性、具备弹性伸缩、可扩展性等优势,得到广泛推广;同时微服务架构在使用过程中又面临诸多挑战,由于系统级依赖增多而带来的不确定性风险指数级增长;通过传统手段进行高可用验证、代码健壮性审查、加大测试范围、提高监控敏感度等手段,都无法有效发现系统潜在风险。在微服务架构下,系统的风险管理越来越重要,提高系统韧性成为必然发展趋势。微服务架构转型的驱动下,“混沌工程”实践可以通过规范化,流程化的方案对系统进行一定程度的“随机破坏”,让故障在可控范围内频繁发生,在此过程中可以深入地认知故障和系统,并达到持续改进的效果。混沌工程是通过向系统中引入软件或硬件的异常状态(扰动),制造故障场
5、景并根据系统在各种压力下的行为表现确定优化策略的一种系统稳定性保障手段。其原则是可量化的稳定状态、可反映真实场景,但风险未知的假设、影响最小化。混沌工程利用实验提前探知系统风险,通过架构优化和运维模式的改进来解决系统风险,真正提升系统架构韧性,增强故障免疫力。2混沌工程是在分布式系统上进行实验的学科,首次提出是在2008 年 8 月,由网飞公司(Netflix)提出。2012 年 Chaos Monkey在 Simain Army 项目中开源,Simian Army 成为首个开源的混沌工程工具集。2019 年开始,国内企业纷纷引入并实践混沌工程。混沌工程通过主动向系统中引入软件或者硬件的异常状
6、态(扰动),制造故障场景并根据系统在各种压力下的行为表现确定优化策略。应用混沌工程可以对系统抵抗扰动并保持正常运作的能力进行校验和评估,还可以提前识别未知隐患并进行修复,进而保障系统更好地抵御生产环境中的失控条件。目前国内混沌工程领域主要集中在一些大型互联网企业,应用领域和范围较小,商业化程度不高。金融行业建行、兴业、中原、浦发、招行等国有和商业银行均成立了内部的混沌工程团队,并开展混沌实验。例如,建信金科混沌工程故障演练平台应用于分布式平台相关组件,如应用路由、配置中心、分布式缓存、分布式消息、索引维护服务、分布式数据库等;在场景方面,建信金科在两地三中心多 AZ 故障、银行核心冲正交易异常
7、时序、代收代付慢交易、应用路由服务治理、应用路由堵塞问题模拟等场景中。(二)建设目标1.业务目标1.业务目标为丰富微服务和分布式系统的故障测试手段,解决分布式系统故障高发且难以预测的问题,通过研发自动化水平高、通用性3好、易用性强的混沌工程测试平台,帮助金融机构提升开展混沌实验的效率,降低开展混沌实验的成本,不断提升分布式系统的稳定性和容错能力。在现有研究基础上,重点突破全类型故障模拟、可视化操作、串并行故障编排、自动化监测告警等关键技术,在金融行业不同业务场景开展示范应用,进一步推动混沌工程方法普及,促进软件产业健康发展。混沌实验是指在混沌工程测试平台上面向复杂系统开展故障模拟、故障编排、故
8、障注入、状态监测和故障恢复等一系列操作的集合。2.技术目标2.技术目标研究故障编排引擎、深入底层的故障注入、有效控制最小爆炸半径等关键技术,在混沌测试平台上提供混沌实验设计、实验编排、故障注入、状态检查、监控告警、实验报告等功能,实现高度自动化和可视化的操作,做到故障对应用无侵入,减少组件依赖,构建完整的混沌工程闭环生态。二、混沌测试平台建设要求(一)功能要求主要功能应包括混沌实验模块、故障模拟发压模块、可观测性模块、权限管理模块、专家库模块 5 大部分。混沌实验模块支持对待测底层设施物理机/虚拟机、容器进行管理;故障模拟发压模块支持对混沌实验的过程进行管理,同时还对演练过程混沌实验事件进行标
9、注;可观测性模块支持对实验全过程的监测和分析;权限管理模块支持进行混沌实验人员管理。专家库模块支持4沉淀典型故障业务场景,提供平台人员使用产品的效率。各个功能模块具体如下描述:1.混沌实验模块1.混沌实验模块混沌实验调度组件。该组件基于自定义资源对象 CRD 设计,可以用来创建、配置和管理多种类型的混沌实验,组件接收到混沌实验对象的创建、更新等事件后,获取到具体混沌实验的最新配置。在通过解析调度规则以及实验配置后,执行具体的混沌实验。使用该组件,用户可以通过 YAML 文件的方式自定义混沌实验的目标、攻击对象、调度规则等。组件使用完全云原生的方案,实现完全无侵入的故障注入,并且提供了很强的拓展
10、性,用户可以直接在此组件上增加新的故障注入类型。故障注入组件。组件提供不同类型原子故障的注入和恢复功能,以 DaemonSet 方式运行在每一个物理节点上,在接受来自调度组件的故障注入请求后,按照故障请求的配置,修改具体容器的 cgroup,或者进入具体 Pod 命名空间下,通过 tc、iptables、ipset 等工具干扰具体的网络资源对象。同时该组件使用 eBPF提供了内核故障注入的能力。物理节点(虚拟机)编排引擎。该引擎提供多节点混沌实验编排的能力,用户将目标节点注册到该组件后,可以使用该引擎对已注册的节点执行各类故障注入。用户可以直接使用该引擎自定义混沌实验的步骤,配置检查程序等,并
11、且提供复用已有的混沌实验场景能力。该引擎包含任务定义、任务调度、任务执行模5块,将基于 Kubernetes CRD 事件机制和 Golang 语言开发,将每个可调度的物理节点和编排任务抽象为具体的 CRD 对象并使用 Watch 机制监控任务的具体变化,并实现特有的 controller组件去处理具体的事件变化,并按照具体的配置解析成具体的任务交给任务执行模块,任务由入口任务和节点任务组成,入口任务会被最先调度,后根据入口任务内定义的子任务调度具体的节点任务,直到所有的任务都被执行过后,整个编排任务执行结束。插件系统。不同应用由于环境不同会产生完全不同的故障场景,很难在一个平台中涵盖所有可能
12、的故障。为了能够重复利用社区的力量,以及收集实现世界中可能出现的场景,插件系统提供了用户自定义故障类型能力。用户可以使用此插件系统来定制化自己的混沌故障类型,如 RabbitMQChaos、TiDBChaos 等。插件系统是整个混沌工程生态中关键部分,用户将自定义的插件提交到插件库,这样其他用户可以直接复用此插件,很大程度降低了用户使用混沌实验的成本,避免重复的工作。2.故障模拟发压模块2.故障模拟发压模块故障模拟发压模块以命令行工具方式提供服务,用户可以在物理节点或者虚拟机节点上直接运行相关命令,该工具会根据提供的命令配置,解析成对应的故障规则,随后执行具体操作。使用该组件,用户可以方便的在
13、单物理节点或者虚拟机节点上,随机杀或者暂停指定的进程,模拟各种网络异常,模拟磁盘压力,CPU 繁忙,内存压力等,同时提供历史查询,故障恢复等功能,6方便用户快速的实现故障的模拟。该故障工具基于 Golang 语言和 SQLite3 开发。3.可观测性模块3.可观测性模块可观测性模块进一步降低简化混沌实验的步骤和提供对混沌实验的可观测性,让用户可以通过鼠标和填写简单的表单实现混沌实验和场景的设计,并且在可观测性模块上提供方便的混沌实验检查机制和完整的实验报告。整个可观测性模块包括独立混沌实验的定义,需要支持定义混沌实验范围,实验具体行为,并且支持暂停和恢复操作。可观测性模块还包含设计整个混沌实验
14、场景,需要满足应用状态定义,展示应用监控信息,多个混沌实验场景的编排,以及告警规则设置和报告信息设置等。可观测性模块同时还提供服务监控和健康检查服务。在进行混沌实验过程中,首先需要确认系统的稳态,并且基于稳定状态提出假设。为了简化用户进行混沌实验操作步骤,本方案计划在混沌工程平台中提供定义应用系统稳定状态方式,支持用户在自定义任务通过 HTTP 状态接口或者访问健康系统的指标方式判断系统的稳定状态。具备的应用系统稳态的判断能力,标志着混沌系统平台具备了混沌工程操作闭环的能力。4.权限管理模块4.权限管理模块权限管理模块。混沌实验要求能够有效的控制最小爆炸,并且不同用户之间有一定的隔离,只有提供
15、有效的安全保障,用户才能放心的开展自己的混沌实验。为了达到此目标,权限管理模7块构建自己的权限机制,用户可以根据混沌实验的范围分配实验人员和实验环境的权限,有效的控制混沌实验的范围和保障混沌实验的安全。同时用户可以使用此权限系统进行混沌实验人员管理,可以创建不同角色的实验人员,如可以分配至具有查看权限的观察者角色等。5.专家库模块5.专家库模块专家故障库模块。可以编辑与展示录入实验过程中发现的问题,作为平台的知识积累;具有实验流程说明,可指导进行实验设置与执行演练计划。沉淀各种典型故障测试场景,用户在创建场景时可以直接导入故障场景,降低故障创建复杂度和提供产品使用效率。(二)适配性要求混沌测试
16、平台运行环境应该运行在开放的软硬件平台之上,更加贴近国内客户生产环境需求,适配多种架构与类型分布式数据库,支持 X86、C86、ARM 硬件平台,支持 Windows、统信、麒麟等软件平台。(三)集成要求混沌工程与被测系统、监控系统、上层应用、底层设施等模块的整体集成部署逻辑分为管控组件和执行组件,管控组件需要独立部署,支持集成部署在独立的物理环境和 Kubernetes 环境,执行组件需要部署在应用运行环境,并且与控制组件保持网络互通,测试人员只需要通过控制组件即可完成混沌实验。8三、混沌测试平台建设情况(一)系统构成混沌测试平台各个模块之间通过一定的调用关系来完成每次故障的演练模拟。其中,
17、权限管理模块是一个比较独立的模块,主要管理整个平台的用户权限;场景管理模块是整个故障演练的入口,串联起发压监控、混沌实验一系列故障演练的步骤;对于有价值的故障场景则可以通过推送沉淀到专家库,并开放给所有用户共享使用;实验报告模块为已结束的实验提供了可视化的聚合报告;环境管理模块则是发压监控的前置工作,用户可以在此上传压测脚本、被测环境以及发压插件,保证后续发压步骤的顺利执行。通过打造混沌测试平台,可以实现混沌实验与压测、监控的集成整合,通过专家库中的实际案例沉淀与调用,使混沌实验具备更好的操作性与可观测性,从而达到混沌实验能方便进行常态化全链路压测与监控的目的。整体系统构成情况如下图 1 所示
18、:9图 1:混沌测试平台系统构成图(二)技术架构混沌测试平台基于 Kubernetes 进行部署。主要包含管理系统、监控报表系统、JMeter 发压系统、混沌实验系统和部署在待测系统中的故障注入执行介质和监控代理。其中,管理系统部署在物理机环境,监控报表系统、JMeter 发压系统、混沌实验系统部署在 k8s 集群,故障注入执行介质和监控代理的部署方式则根据待测系统的不同而不同。平台技术架构如下图 2 所示:10图 2:混沌测试平台技术架构图(三)功能模块整个混沌测试平台主要包含权限管理、发压监控、混沌实验、实验报告、专家库五个核心功能模块。1.权限管理1.权限管理对平台的登录进行权限级别、环
19、境使用、混沌实验各个维度的权限管理,大的不同程度的隔离。2.发压监控2.发压监控11发压提供了整个故障演练过程的背景压力用以模拟真实生产环境的流量,监控则对整个发压过程中涉及的服务器资源、压力机资源、业务指标、系统指标、错误信息等各种指标进行实时的监控展示,同时还对演练过程中的混沌实验事件进行标注。3.混沌实验3.混沌实验支持各种常见类型的故障,覆盖物理机/虚拟机、容器不同底层基础设施,同时利用实验编排可以自动定时实现故障的并行/串行/挂起模拟注入以及故障的自我恢复。通过编排的能力可以构造复杂的故障场景而非只能完成单一故障任务的模拟。以串行场景编排为例,可以在该场景的 workflow 中添加
20、多个故障子任务,同时每个子任务又可以嵌套多层的子任务,从而能够更真实地模拟生产环境中遇到的故障。4.实验报告4.实验报告为整个故障演练过程提供了可视化的聚合报告,包含了压测的数据(TPS、响应时间、失败数等),监控数据(CPU、内存、IO、网络等),混沌实验数据(实验事件、执行事件、执行状态等)。5.专家库5.专家库用以沉淀各种高可用典型故障测试场景,用户在创建场景时可直接导入这些典型场景进行演练,降低了故障演练的难度同时提升了故障演练的效率。功能模块如下图 3 所示:12图 3:混沌测试平台功能模块图(四)故障种类混沌工具支持虚拟机/K8s 容器不同底层基础设施的故障模拟,同时覆盖了磁盘、网
21、络、进程、文件、JVM、压力、IO、DNS、内核、HTTP、生命周期等多种故障类型。具体到每种故障类型,又包含了常见的磁盘读写、磁盘填充、杀死进程、CPU 打满、网络延迟、网路丢包等典型故障。混沌工具支持的故障类型丰富,同时还可以借助混沌测试平台的实验编排功能,构建复杂的故障演练场景,满足模拟生产环境中真实复杂场景的需求。故障种类如下图 4 所示:13图 4:混沌测试平台故障种类图四、混沌平台测试方案与测试实践(一)测试目标分布式数据库是重要的基础软件,数据库发生故障所引发的一系列的后果是无法想象的,对于分布式数据库而言,其故障有可能是多种情况组合下才发生,从而引发严重的生产事故。传统的高可用
22、测试,很难对各种情况进行同时或不同排列组合的模拟,难以在测试中进行系统性验证。通过引入混沌测试的方式可以增强和补充整个分布式数据库系统的健壮性。根据分布式数据库产品架构和银行业务交易场景,混沌测试平台针对分布式数据库产品做以下故障验证测试:1.模拟分布式数据库计算和存储节点进程故障。2.模拟分布式数据库数据盘读写负载故障。3.模拟分布式数据库数据节点、控制节点、计算节点网络延迟丢包故障。4.模拟分布式数据库节点 CPU 和内存负载高故障。145.模拟分布式数据库系统负载高故障场景。6.模拟分布式数据库混合故障场景。故障演练平台通过触发预先设置的故障用例,在生产环境发生故障之前把问题暴露出来,分
23、布式数据库产品尽可能提早地处理这类故障,再加上自动化、冗余、回滚策略,以及其他健壮性设计的最佳实践,分布式数据库产品很快就可以让自身的服务,在发生故障时保持正常运行。聚焦在业务指标上来衡量问题发生与否,造成业务问题的事件都应该排查定位,记录触发条件,继而在修复后回归测试,并将修复代码上线到持续运行的混沌测试平台中。(二)测试内容测试内容如表 1 所示。表 1:混沌测试平台测试内容表序号序号测试分类测试分类用例用例1进程故障注入进程被杀故障注入2进程挂起故障注入3磁盘故障注入读写负载过高故障注入4多进程读负载故障注入5写负载过高故障注入6指定目录写负载过高故障注入7指定文件填充过多故障注入8IO
24、 压力高故障注入159网络故障注入网络延迟故障注入10网络包损坏故障注入11网络丢包故障注入12网络抖动故障注入13压力故障注入CPU 耗尽故障注入14内存耗尽故障注入15系统 load 高故障注入16混合场景故障注入混合容量测试17稳定性测试混合编排 workload 长稳测试(三)测试过程1.进程故障注入1.进程故障注入1)进程被杀故障注入检测内容检测内容:分布式数据库在进行账户查询、更新、插入、转账等联机交易业务过程中,数据库计算进程被杀异常故障的自愈性以及对业务的QPSTPS 影响范围和时长。检测流程检测流程:启动银行模拟交易场景程序,模拟账户查询、更新、插入操作;将编排好的进程被杀故
25、障模板加载到故障测试平台,执行测试;测试结束后,统计故障演练期间交易成功率,QPS,平均延迟等指标;生成测试报告。16通过标准通过标准:各步骤执行成功,分布式数据库能够完成自动故障转移,在故障解除后能够恢复完整的服务能力,执行结果符合厂商声明。进程被杀时 QPS 会有下降,延迟有所上升,但不会造成严重影响。在进程恢复后各项指标恢复正常。2)进程挂起故障注入检测内容:检测内容:分布式数据库在进行账户查询、更新、插入、转账等联机交易业务过程中,数据库存储进程挂起异常故障的自愈性以及对业务的QPSTPS 得的影响范围和时长。检测流程:检测流程:启动银行模拟交易程序,模拟账户查询、更新、插入操作;将编
26、排好的进程挂起故障模板加载到故障测试平台,执行测试;测试结束后,统计故障演练期间交易成功率,QPS,平均延迟等指标;生成测试报告。通过标准:通过标准:执行成功,分布式数据库在所描述的故障注入下,能够完成自动故障转移,在故障解除后能够恢复完整的服务能力,执行结果符合厂商声明。进程被杀时 QPS 会有下降,延迟有所上升,但不会造成严重影响。在进程恢复后各项指标恢复正常。2.磁盘故障注入2.磁盘故障注入171)读写负载过高故障注入检测内容:检测内容:分布式数据库在进行账户查询、更新、插入、转账等联机交易业务过程中,读写负载故障的自愈性以及对业务的 QPSTPS 的影响范围和时长。检测流程:检测流程:
27、启动银行交易程序,模拟账户转账操作;将编排好的主机故障模板加载到故障测试平台,执行测试;测试结束后,统计故障演练期间交易成功率,QPS,平均延迟等指标;生成测试报告。通过标准:通过标准:执行成功,分布式数据库在所描述的故障注入下,能够完成自动故障转移,在故障解除后能够恢复完整的服务能力,执行结果符合厂商声明,未出现非预期结果。2)多进程读负载故障注入检测内容:检测内容:分布式数据库在进行账户查询、更新、插入、转账等联机交易业务过程中,多进程读负载故障的自愈性以及对业务的 QPSTPS 的影响范围和时长。检测流程:检测流程:启动银行模拟交易场景程序,模拟账户查询、更新、插入语操18作;将编排好的
28、主机故障模板加载到故障测试平台,执行测试;测试结束后,统计故障演练期间交易成功率,QPS,平均延迟等指标;生成测试报告。通过标准:通过标准:执行成功,分布式数据库在所描述的故障注入下,能够完成自动故障转移,在故障解除后能够恢复完整的服务能力,执行结果符合厂商声明,未出现非预期结果。3)写负载过高故障注入检测内容:检测内容:分布式数据库在进行账户查询、更新、插入、转账等联机交易业务过程中,写负载故障的自愈性以及对业务的 QPSTPS 的影响范围和时长。检测流程:检测流程:启动银行模拟交易场景程序,模拟账户查询、更新、插入语操作;将编排好的主机故障模板加载到故障测试平台,执行测试;测试结束后,统计
29、故障演练期间交易成功率,QPS,平均延迟等指标;生成测试报告。通过标准:通过标准:19执行成功,分布式数据库在所描述的故障注入下,能够完成自动故障转移,在故障解除后能够恢复完整的服务能力,执行结果符合厂商声明,未出现非预期结果。4)指定目录写负载过高故障注入检测内容:检测内容:分布式数据库在进行账户查询、更新、插入、转账等联机交易业务过程中,指定目录写负载故障的自愈性以及对业务的 QPSTPS的影响范围和时长。检测流程:检测流程:启动银行模拟交易场景程序,模拟账户查询、更新、插入语操作;将编排好的主机故障模板加载到故障测试平台,执行测试;测试结束后,统计故障演练期间交易成功率,QPS,平均延迟
30、等指标;生成测试报告。通过标准:通过标准:执行成功,分布式数据库在所描述的故障注入下,能够完成自动故障转移,在故障解除后能够恢复完整的服务能力,执行结果符合厂商声明,未出现非预期结果。5)指定文件填充过多故障注入检测内容:检测内容:分布式数据库在进行账户查询、更新、插入、转账等联机交易20业务过程中,指定目录文件填充过多导致写负载故障的自愈性以及对业务的 QPSTPS 的影响范围和时长。检测流程:检测流程:启动银行交易程序,模拟账户转账操作;将编排好的主机故障模板加载到故障测试平台,执行测试;测试结束后,统计故障演练期间交易成功率,QPS,平均延迟等指标;生成测试报告。通过标准:通过标准:执行
31、成功,分布式数据库在所描述的故障注入下,能够完成自动故障转移,在故障解除后能够恢复完整的服务能力,执行结果符合厂商声明,未出现非预期结果。6)IO 压力高故障注入检测内容:检测内容:分布式数据库在进行账户查询、更新、插入、转账等联机交易业务过程中,数据库存储节点 IO 压力高故障的自愈性以及对业务的QPSTPS 的影响范围和时长。检测流程:检测流程:启动银行交易程序,模拟账户转账操作;将编排好的主机故障模板加载到故障测试平台,执行测试;测试结束后,统计故障演练期间交易成功率,QPS,平均延迟等指标;21生成测试报告。通过标准:通过标准:执行成功,分布式数据库在所描述的故障注入下,能够完成自动故
32、障转移,在故障解除后能够恢复完整的服务能力,执行结果符合厂商声明,未出现非预期结果。3.网络故障注入3.网络故障注入1)网络延迟故障注入检测内容:检测内容:分布式数据库在进行账户查询、更新、插入、转账等联机交易业务过程中,数据库集群存储、计算、控制节点网络延迟故障的自愈性以及对业务的 QPSTPS 的影响范围和时长。检测流程:检测流程:启动银行业务交易程序,模拟账户查询、更新、插入操作;将编排好的主机故障模板加载到故障测试平台,执行测试;测试结束后,统计故障演练期间交易成功率,QPS,平均延迟等指标;生成测试报告。通过标准:通过标准:执行成功,分布式数据库在所描述的故障注入下,能够完成自动故障
33、转移,在故障解除后能够恢复完整的服务能力,执行结果符合厂商声明,未出现非预期结果。2)网络丢包故障注入22检测内容:检测内容:分布式数据库在进行账户查询、更新、插入、转账等联机交易业务过程中,数据库集群存储、计算、控制节点网络包丢失故障的自愈性以及业务的对 QPSTPS 的影响范围和时长。检测流程:检测流程:启动银行业务交易程序,模拟账户查询、更新、插入操作;将编排好网络丢包故障注入异常模板加载到故障测试平台;持续测试 10 分钟;测试结束后,统计故障演练期间交易成功率,QPS,平均延迟等指标;生成测试报告。通过标准:通过标准:执行成功,分布式数据库在所描述的故障注入下,能够完成自动故障转移,
34、在故障解除后能够恢复完整的服务能力,执行结果符合厂商声明,未出现非预期结果。3)网络包损坏故障注入检测内容:检测内容:分布式数据库在进行账户查询、更新、插入、转账等联机交易业务过程中,集群计算、存储、控制节点网络包损失对故障的自愈性以及业务的 QPSTPS 的影响范围和时长。检测流程:检测流程:启动银行业务交易程序,模拟账户查询、更新、插入操作;23将编排好的主机故障模板加载到故障测试平台,执行测试;测试结束后,统计故障演练期间交易成功率,QPS,平均延迟等指标;生成测试报告。通过标准:通过标准:执行成功,分布式数据库在所描述的故障注入下,能够完成自动故障转移,在故障解除后能够恢复完整的服务能
35、力,执行结果符合厂商声明,未出现非预期结果。4)网络抖动故障注入检测内容检测内容:分布式数据库在进行账户查询、更新、插入、转账等联机交易业务过程中,集群计算、存储、控制节点网络通信出现抖动故障的自愈性以及对业务的 QPSTPS 的影响范围和时长。检测流程检测流程:启动银行业务交易程序,模拟账户查询、更新、插入操作;将编排好网络抖动故障异常模板加载到故障测试平台;测试结束后,统计故障演练期间交易成功率,QPS,平均延迟等指标;生成测试报告;通过标准通过标准:执行成功,分布式数据库在所描述的故障注入下,能够完成自动故障转移,在故障解除后能够恢复完整的服务能力,执行结果符24合厂商声明,未出现非预期
36、结果。4.压力故障注入4.压力故障注入1)CPU 耗尽故障注入检测内容:检测内容:分布式数据库在进行账户查询、更新、插入、转账等联机交易业务过程中,集群计算、存储节点出现 CPU 负载过高故障的自愈性以及对业务的 QPSTPS 的影响范围和时长。检测流程:检测流程:启动银行模拟交易程序,模拟账户查询更新操作;将编排好的主机故障模板加载到故障测试平台,执行测试;测试结束后,统计故障演练期间交易成功率,QPS,平均延迟等指标;生成测试报告。通过标准:通过标准:执行成功,分布式数据库在所描述的故障注入下,能够完成自动故障转移,在故障解除后能够恢复完整的服务能力,执行结果符合厂商声明,未出现非预期结果
37、。2)内存耗尽故障注入检测内容:检测内容:分布式数据库在进行账户查询、更新、插入、转账等联机交易业务过程中,集群计算、存储节点出现内存负载过高故障的自愈性以及对业务的 QPSTPS 的影响范围和时长。25检测流程:检测流程:启动银行模拟交易程序,模拟账户查询、更新操作;将编排好的主机故障模板加载到故障测试平台,执行测试;测试结束后,统计故障演练期间交易成功率,QPS,平均延迟等指标;生成测试报告。通过标准:通过标准:执行成功,分布式数据库在所描述的故障注入下,能够完成自动故障转移,在故障解除后能够恢复完整的服务能力,执行结果符合厂商声明,未出现非预期结果。3)系统 load 高故障注入检测内容
38、:检测内容:分布式数据库在进行账户查询、更新、插入、转账等联机交易业务过程中,集群计算、存储节点出现系统 load 负载过高故障的自愈性以及对业务的 QPSTPS 的影响范围和时长。检测流程:检测流程:启动银行交易程序,模拟账户转账操作将编排好的主机故障模板加载到故障测试平台,执行测试测试结束后,统计故障演练期间交易成功率,QPS,平均延迟等指标生成测试报告通过标准:通过标准:26执行成功,分布式数据库在所描述的故障注入下,能够完成自动故障转移,在故障解除后能够恢复完整的服务能力,执行结果符合厂商声明,未出现非预期结果。5.混合场景故障注入5.混合场景故障注入检测内容:检测内容:分布式数据库在
39、进行账户查询、更新、插入、转账等联机交易业务过程中,混合编排注入不同故障的自愈性以及对业务的 QPSTPS的影响范围和时长。检测流程:检测流程:启动银行交易程序,模拟账户转账操作;将编排好的主机故障模板加载到故障测试平台,执行测试;测试结束后,统计故障演练期间交易成功率,QPS,平均延迟等指标;生成测试报告。通过标准:通过标准:执行成功,分布式数据库在所描述的故障注入下,能够完成自动故障转移,且需保证在故障注入后各有效数据节点的数据分布是均匀的;在故障解除后能够恢复完整的服务能力,执行结果符合厂商声明,未出现非预期结果。6.稳定性测试6.稳定性测试检测内容检测内容:分布式数据库在进行账户查询、
40、更新、插入、转账等联机交易27业务过程中,混合编排长时间周期性注入不同故障的自愈性以及对业务的 QPSTPS 的影响范围和时长。检测流程:检测流程:启动银行交易程序,模拟账户转账操作;将编排好的主机故障模板加载到故障测试平台,执行测试;测试结束后,统计故障演练期间交易成功率,QPS,平均延迟等指标;生成测试报告。通过标准:通过标准:执行成功,分布式数据库在所描述的故障注入下,能够完成自动故障转移,且需保证在故障注入后各有效数据节点的数据分布是均匀的;在故障解除后能够恢复完整的服务能力,执行结果符合厂商声明,未出现非预期结果。五、混沌测试平台建设实践总结银行机构在 IT 系统架构转型的同时,都同
41、时面临运行安全保障的巨大压力。实际生产运行过程中,应用级别的生产故障时而发生,对业务连续性和生产安全产生威胁较大。限于银行业务的安全级别及合规要求,难以在生产环境对此类故障场景进行应急处置演练,应急预案无法执行,处置措施的有效性无法验证。银行同业一般采取桌演或者仿真环境演练的方式,提高组织应对应用级故障的能力。金融级混沌测试能力平台在模拟应用级故障方面具有天然优势,平台侧可以模拟及编排各种故障场景,包括:进程故障、主机28故障、磁盘故障、读写负载高故障、网络故障、压力负载故障、混合故障场景等,验证了在业务负载下分布式数据库遇到各类故障对产品冗余处理机制的有效性以及故障对数据库处理能力的影响。平
42、台故障编排和故障注入可以将其作为常态化手段来验证银行业务场景下分布式数据库产品的稳定性,整个故障演练过程和结果符合预期。金融级混沌测试能力平台同样适用于应用系统的开发、测试、上线、运维等各个阶段:在应用系统开发阶段,对非功能性测试的重视程度通常不及功能性测试,一个重要的原因是非功能性测试通常对测试环境的要求较高,利用金融级混沌测试能力平台可以对稳定性、扩展性、弹性缩放部署等非功能性需求是否能够实现进行检验。在新建或经历重大变更后的应用系统上线环节中,为了提升应用系统上线质量,丰富和完善应用上线质量门禁的内容,可利用金融级混沌测试能力平台对目标系统的合规性进行针对性的测试,以确定部署后的应用系统
43、能够满足业务需求,主要测试方向为系统稳定运行能力和抗干扰能力。在资源规范环节中,合理的资源容量是服务性能的保障,利用金融级混沌测试能力平台具备的产生背景访问流量的能力可以协助进行压力测试,或者验证应用正常运行(承载正常访问流量)时所需资源的临界值在运维监控方面,监控能力与指标的覆盖范围直接影响系统异29常或故障的发现与定位能力。可以将金融级混沌测试能力平台作为检验监控系统效能的重要工具,通过控制故障注入的强度和范围发现监控能力方面的不足与缺陷在应急响应方面,通过金融级混沌测试能力平台的故障注入可以不但可以检验告警配置的合理性和有效性,同时能够检验运维团队的应急响应能力与应急处置能力,可以成为应急演练的重要支撑工具。