观点 | 分布式核心系统混沌测试探索与实践

欢迎金融科技工作者积极投稿！

投稿邮箱：[e-mail]

                                           ——金融电子化

    

文 / 中国农业银行研发中心    王宪刚  孙晓璇

随着银行业分布式核心系统建设不断推进，交易链路变长、分布式事务增多、系统资源故障频发，系统稳定运行面临挑战。通过引入混沌工程的理念、方法、工具，在测试环境开展混沌测试实践，总结了一套将混沌工程（Chaos Engineering）和传统测试相结合开展混沌测试（Chaos Test）的方法与流程，通过具体应用实例阐述了故障场景设计、故障注入和消除、流程编排等方面的实践经验和取得成效。通过混沌测试，提前发现系统潜在风险，提高系统运行稳定性。

现状与挑战

随着IT技术的发展，商业银行逐渐从高成本、高耦合、技术封闭、扩展性差的主机集中式架构演变为开放平台分布式架构。银行信息系统具有业务规模庞大、子系统繁多等特点，在日均交易量高达十几亿的分布式架构下，交易链路变长，分布式事务增多，保证事务的一致性、幂等性更加困难。庞大的规模、多层的架构、子系统间的差异，为运维工作增加难度，硬件单点故障、服务器异常宕机、网络服务异常等基础资源异常随之增加，分布式架构下应用系统稳定运行面临较大挑战。

通过分析历史生产异常事件，系统可靠性缺陷引发的生产事件占比高达17%，仅次于功能和性能。在传统的系统测试中，较多针对应用本身的功能、性能、安全等方面开展测试，而对系统架构设计的弹性容错能力、底层软硬件和关联系统异常后的故障隔离和恢复能力等可靠性测试关注度较低。系统架构的韧性不足，在异常故障发生时，将严重损害业务连续性。

基本概念

混沌工程是一门在分布式系统上进行实验的学科，旨在提升系统的健壮性，将故障扼杀在襁褓之中，以建立对系统抵御意外条件引发混乱的能力和信心。混沌工程实验过程是在经验指导下，在可控范围内注入某些异常故障，验证系统弹性，探查系统未知缺陷，验证应急手段有效性。混沌工程的原则包括建立系统稳定状态的假设、用真实的生产事件做验证、在生产环境进行实验、自动化执行实验、控制最小化爆炸半径。

混沌测试是在测试环境有计划、有预期地注入故障，通过观察系统指标验证系统表现是否符合预期，针对发现的缺陷进行修复，提升系统可靠性。

故障模式影响分析（FMEA）是分析系统中所有可能产生的故障模式及其对系统造成的所有可能影响，并按每一个故障模式的严重程度、检测难易程度以及发生频率予以分类的一种归纳分析方法。

方法与设计

综合金融行业特点，我们没有直接在生产环境开展混沌实验，而是在测试环境开展混沌测试。混沌工程与混沌测试的区别在于：混沌工程是发现系统新信息的实践过程，一般是在生产环境开展探索性实验，常常伴随无法提前预知的结果出现。混沌测试在传统测试基础上汲取混沌工程的理念和方法，在测试阶段对系统有较为明确预期结果地注入故障，是基于特定的条件和变量下验证系统可靠性的方法。

我们结合分布式核心系统的特点，梳理了混沌测试的方法与流程，主要包括七个关键步骤：目标确定、稳态指标制定、故障设计、流程编排、实验执行、结果分析、修复验证。

目标确定阶段需明确混沌测试的目标、范围、预期达到的效果等，为后续各项工作的开展提供总体依据。制定稳态指标则从业务层面和系统层面分析确定应用系统稳定运行时的指标，包括但不限于交易成功率、TPS、响应时间及系统资源使用情况等各项指标，为混沌测试结果分析提供对比依据。故障设计阶段可由开发、测试、运维等人员依据经验，从系统架构、关联系统、数据库、网络、系统资源、云原生、真实生产事件等方面剖析应用系统，确定故障可能发生的位置及预期结果，完成故障场景设计。初步设计的故障场景比较散乱，通过引入可能性和影响性分析图（基于FMEA）对散乱的场景进行优先级排序，优先完成发生可能性高、影响范围大的场景测试。针对不同系统，关注的故障场景有所侧重，例如I/O密集型系统则重点关注磁盘高I/O相关故障对系统的影响，计算密集型系统则重点关注CPU抢占等计算资源对系统的影响。流程编排阶段指将模拟交易流量、故障注入、启动监控、故障消除等各项操作和时序关系编入流水线，流水线可支持多个原子故障并行或串行方式执行故障注入。实验执行阶段则通过调起流水线即可开展故障场景测试自动化执行，通过查看监控结果，分析与稳态指标之间的差异，当结果存在偏差则进行原因分析，确定为程序缺陷、架构设计缺陷的则进行修复后持续混沌测试，直到符合预期结果。

图1  分布式核心系统故障设计视图

实践与成效

本文以分布式核心系统统一接入层网关模块为例说明混沌测试的实践过程和取得成效。统一接入层网关模块作为核心系统交易接入统一入口，主要完成安全控制检查、报文转换和路由转发等功能。在核心系统交易量逐步增长的背景下，新增流量控制功能，用于在“双十一”等交易高峰时段控制流量接入上限，避免在流量洪峰的冲击下对后端服务造成影响。流控功能的实现基于redis集群统计交易量信息，当交易量在一定时间间隔达到阈值上限，交易快速失败并返回提示信息。

基于流控设计方案，设定混沌测试的目标为模拟redis异常宕机场景下网关模块的基本功能是否正常提供服务。系统稳态指标设定为交易成功率、TPS、响应时间、系统资源使用率。故障场景设计为五个阶段，一是系统运行正常未触发流控；二是交易激增触发流控；三是部分redis节点异常故障；四是全部redis节点异常故障；五是redis节点故障消除，系统运行恢复为正常流控状态。根据故障设计的五个阶段，通过混沌测试平台将交易流量模拟、部分redis异常故障、全部redis异常故障、故障消除等具体操作环节和时序关系进行流程编排，编制成可自动化执行的流水线，调起流水线即可完成故障场景的测试执行。通过观察系统稳态指标发现：在系统正常运行状态下，交易成功率保持为100%，当增大交易并发数，达到流控阈值后触发流控时交易快速返回失败，交易成功率下降一段时间后回升，呈现周期性变化；当部分redis注入故障时，注入瞬间交易成功率升高至100%，随后恢复正常流控状态；当全部redis注入故障，按照系统设计预期将跳过流控功能，交易成功率随即升高至100%，但此时交易响应时间与稳态时相比增长明显，不符合预期结果；最后消除故障，流控功能恢复，再次恢复为流控状态。通过分析发现，当redis全部不可用时，系统仍尝试与redis建立连接并超时，同时产生大量错误日志写入磁盘，导致交易响应时间变长。针对此缺陷，系统增加对redis的熔断功能，即当访问redis的请求在一定时间间隔内失败率大于设定阈值时，将redis的访问请求进行熔断处理。优化后，再次通过流水线执行本场景，发现优化后结果符合预期，成功在投产前发现了系统设计存在的问题，避免因redis异常影响核心系统的正常运行。

混沌测试是对传统测试不可替代的有效补充，传统测试验证理想情况下功能是否正确，实际系统并非一直处于理想状态，而通过持续混沌测试可发现基础设施、关联系统等故障发生后系统的弹性容错存在的不足，通过持续改进架构设计和程序质量提高系统运行稳定性。

思考与展望

银行业分布式核心系统建设正在不断推进，其上下游关联依赖关系及底层的部署架构愈加复杂，应用系统稳定运行的不确定性增加。混沌工程通过科学的实验方法解决分布式系统复杂、交易链路长、缺乏弹性的问题，弥补传统测试方法的不足，进一步提升系统的稳定性。

未来将在以下两个方面深度应用混沌工程技术理念。一是提升技术支撑能力，通过建设企业级混沌工程平台进一步提升混沌测试的自动化与智能化水平；二是拓展混沌工程在信息系统建设中实践运用的深度和广度，将混沌工程全面落地并融入到研发交付流程，从技术和管理双视角形成故障预防、故障应对、系统优化的闭环能力，整体提升系统运行稳定性。

（栏目编辑：张丽霞）

往期精选：

（点击查看精彩内容）

新媒体中心：主任 / 邝源  编辑 / 傅甜甜  张珺  邰思琪