文 / 上海银行金融科技部副总经理 朱英华

上海银行金融科技部 刘丽 贾弘茹

(资料图片仅供参考)

当前商业银行正处于新一代云原生架构转型期，微服务架构在具备扩展性优、弹性伸缩强等优势的同时，也使得银行的系统在架构设计和运维层面等面临诸多新挑战。例如新一代银行应用架构间的依赖度和耦合度愈发复杂、运维难度的极大增加都会导致系统风险可能性的提升。在当前提高银行系统风险管理的必然趋势下，混沌工程受到越来越多的关注。本文通过对比传统架构和微服务架构模式、传统运维模式和当前业务连续性管理新发展方向，论证混沌工程在银行系统风险管理的必要性；并根据混沌工程实验原理，提出混沌工程实验平台具体方案；同时以研发微服务平台为例，进行故障演练实验案例研究及实验价值分析。

上海银行金融科技部副总经理 朱英华

研究背景与现状

当前，商业银行正加快开展新一代架构转型的步伐，由传统的SOA架构向分布式架构、去中心化发展，当前还进阶到注重云化支持和异构化微服务支持的服务网格模式。

一方面由于技术异构性、具备弹性伸缩、可扩展性等优势，微服务架构得到迅速推广；另一方面，微服务架构在使用过程中又会面临诸多挑战：由于系统级依赖增多而带来的不确定性风险指数级增长；商业银行的核心系统规模日益庞大，交易链路长，数据流转复杂；随着银行数字化转型和分布式技术推动，基础设施多样化、架构多元化导致运维复杂度极大增加。实践发现，通过传统手段进行加强高可用性设计、提高代码健壮性、加大测试范围、提高监控敏感度，都无法有效阻止系统故障的发生。所以在新一代银行微服务架构转型期，系统的风险管理越来越重要，提高系统韧性成为必然发展趋势。

在微服务架构转型的驱动下，“混沌工程”实践方案受到银行界越来越多的关注和探索。它可以通过规范化、流程化的实践方案对系统进行一定程度的“随机破坏”，让故障在可控范围内频繁发生，在此过程中可以深入地认知故障和系统，并达到持续改进的效果。

混沌工程是通过向系统中引入软件或硬件的异常状态（扰动），制造故障场景并根据系统在各种压力下的行为表现确定优化策略的一种系统稳定性保障手段。其原则是可量化的稳定状态、可反映真实场景，但风险未知的假设、影响最小化。混沌实验的具体流程包括实验设计、实验执行和实验结果分析。总结来说，混沌工程就是利用实验提前探知系统风险，通过架构优化和运维模式的改进来解决系统风险，真正提升系统架构韧性，增强故障免疫力，提高企业效益。

新一代银行系统风险管理面临挑战

1.架构层面。当前微服务架构已成为互联网及银行业架构发展的主流模式，它与原先SOA架构的区别是：微服务更强调“业务需要彻底的组件化和服务化”。其特性是：客户端负载均衡、微服务容错保护、API服务网关、分布式链路跟踪等。而传统的非功能测试方法只能覆盖到业务逻辑维度，无法覆盖和测试到上述微服务特性。

而混沌工程与传统测试的不同点为：通常的测试用例会有“期望结果”和“实际结果”，通过将两个结果比较，或者对用户行为的预期，来判断测试通过或失败。而混沌实验类似于“探索性测试”。实验本身没有明确的输入和预期结果，是通过对系统和服务的不同组合干预，来观察系统的“反应”。具体操作时，可以将混沌工程原则融入到测试过程中：在准生产环境小规模模拟系统故障组合并定期自动化执行实验，通过实验结果与正常结果进行比对，观察系统对故障的承受和反应能力。

根据上述对比，我们可以从业务逻辑和系统高可用性两个维度对微服务系统进行观察和测试，将传统测试与混沌工程两种方案结合，形成了一种更全面的实验方案。从而无论是在微服务改造期还是云原生转型期，混沌工程实验都能够有效提前发现生产环境问题，提升系统的容错率和可用性。

2.运维层面。当前银行业的业务连续性管理已经迈入新的方向。以往的业务连续性管理，重点关注监管合规要求，应急管理时多注重事中检测；故障的定位和解决多依赖技术人员的能力。而发展中的业务连续性管理更注重工具能力，在符合监管合规的同时，切实提高业务连续性管理能力，并规避实质性风险。

目前，银行的应急预案与灾备切换方案是存在隐患可能性的：从事件故障发生，到监控平台是否能及时全面的检测到故障并告警、应急处置流程是否有效、各系统灾备切换是否有效、故障修复是否及时有效都存在漏洞可能性。每个步骤的疏漏，都会导致全链路的安全隐患大幅升级。而新一代微服务架构又引入了更多更复杂的系统风险问题，导致系统运维层面的压力大幅增加。凭借原先依赖技术人员个人能力进行事中检查可靠性大幅下降。

引入混沌工程实验，能够更加完善运维的工作体系：事前可以通过混沌工程实验预测故障、组建红蓝双方攻防演练，从而主动发现问题和影响范围，未雨绸缪。例如通过对系统注入故障，验证监控指标是否准确，监控维度是否完善，告警阈值是否合理，告警接收人是否准确等，有效提升事前监控告警的准确和时效性。

事中可以快速故障定位和解决问题，减少经验依赖，缩短应急时间。在实验中，通过故障突袭、随机对系统注入故障，考察相关人员对问题的应急能力，包括问题上报、处理流程是否合理，达到以战养战，锻炼技术人员定位与解决问题的能力。可有效提升应急响应的及时性。

事后可以故障影响分析和修复设计，进行复盘和改进。通过实验模拟调用延迟、服务不可用、机器资源满载等，查看发生故障的节点或实例是否被自动隔离、下线，流量调度是否正确，预案是否有效。可以提升系统容错容灾的健壮性。

应用案例研究

按照上述混沌工程的实验原则及流程，分析银行科技系统风险管理的痛点问题，并结合市场调研，以提高应用系统业务逻辑和运行环境容错能力、增强高复杂应用架构下的系统韧性，最终以提升银行系统的风险防御能力为目标。下文将阐述混沌工程实验平台的设计方案。

1.混沌工程实验平台。如图1所示，混沌实验平台功能包括：故障演练、实验场景库、任务调度、应用管理、实验管理、实验经验库、工作台、监控及数据分析。

图1 混沌工程实验平台功能图

测试技术人员可利用混沌工程实验平台对待实验的系统实施故障演练。根据混沌实验流程，利用混沌工程实验平台可进行如下操作：先分析待实验系统的稳态指标；在实验场景库模块中选择或新增实验故障场景；在实验管理模块中设计实验计划，并在故障演练模块中进行实验执行；在实验管理模块中进行实验结果分析，并进行实验管理。

2.基于混沌工程平台的实验方案设计。（1）实验流程。借助DevOps中的配置中心模块实现混沌工程平台对被实验平台的指令传递，通过Agent应用实现对被实验平台注入实验场景，以应用系统和设备为维度实现权限及爆炸半径管控。实验平台通过和综合诊断分析中心，统一运行监控系统进行关联，实时查看实验时的指标情况，进而从实验准备、实验编排、故障注入、故障恢复、监控验证到生成演练报告，形成一套基本的平台实验流程。

用户整体操作层面，首先确定待实验的应用系统及资源环境，并确认基准“稳定状态”，然后选择混沌实验场景，通过Agent收到实验信息后，开始通过编排步骤对目标注入故障，观察系统及资源等情况的综合反映，识别系统弱点。最后记录实验经验，反馈给应用系统，应用系统修复解决后再次通过混沌实验进行回归验证，验证完毕关闭本次实验。

（2）实验场景。实验场景含容器K8S，主机/虚拟机上的应用和分布式微服务应用，供选择不同场景进行不同实验。

针对容器K8S，主机/虚拟机上应用的场景：涉及CPU资源满载、内存资源负载、磁盘资源负载提升、网络资源异常、应用进程杀死、容器内进程杀死等系统资源类故障场景。涉及延迟、抛异常、数据篡改等JAVA应用类故障场景。

针对特殊的分布式微服务应用的场景：涉及RPC服务故障、API网关故障、配置中心故障、批量任务故障、中间件故障等场景。

（3）实验方案。本次混沌工程测试实验重点围绕研发微服务平台的容器云和微服务组件，结合生产环境IaaS基础设施冗余切换经验，辅助云原生监控手段，验证微服务平台服务间的强弱依赖关系及鲁棒性。

如图2所示，以研发微服务平台为例，故障演练实验如下。

图2 基于研发微服务平台故障场景演练

第一步选定假设，明确对研发微服务平台的哪些场景进行故障注入。系统健壮性实验：测试如进程挂掉、频繁GC时，实验当前应用出现系统级可用性故障时的反应。应用起停顺序：在理想情况下，应用启动应该做到零强依赖启动，但实际情况有可能无法做到需依赖相关服务提供后才能启动对外服务，通过实验服务间起停顺序，来检查系统服务间依赖关系及操作部署。容量评估实验：正常调用链路下的系统容量等是预先设计的，当某个弱依赖挂起时，需注意整体应用的容量变化情况。逃逸实验：当微服务网关、注册中心等重要系统出现某个区域的故障时，能对外服务，并评估容量、切换时间、影响范围等。硬件演练实验：包括对应用平台进行CPU满载、网络限流、主机资源枯竭等相关实验，并评估其硬件抗风险能力。

第二步设定实验范围。根据具体的场景明确对哪些节点实施故障注入，并且评估出现故障时可能受到的影响范围，确保不会造成灾难性的结果。

第三步明确平台健康指标。业务、开发、测试多方合作，明确平台关键运行指标。实验执行故障注入时，重点关注平台是否可在第一时间内发现异常，可感知到异常后，平台是否有可承受此故障打击，最后确认平台是否具备自修复能力。

第四步执行实验及实验结果分析。演练结束后，需要对整个演练进行复盘。首先要分析总结演练是否达到预期，系统是否具备韧性，是否发生预期之外的结果。然后要针对故障演练过程中系统暴露出的问题，进行问题修复和架构优化。

（4）实验价值。通过故障场景建设，从IaaS层到SaaS层逐层叠加故障测试场景，以原子化方式提取故障因子，按需组合注入故障，可验证研发微服务平台的系统健壮性和抗击打能力。以研发微服务平台的系统业务连续性提升为目标开展系统故障演练后发现问题的治理工作。同时，通过故障演练，能考验相关技术人员的应急问题处理能力，丰富研发运维团队经验，增强团队信心。

结论及建议

银行在新一代微服务架构发展背景下，可借鉴混沌工程思想，以模拟生产环境为对象，对系统进行故障模拟，及时发现潜在问题，提升管理能效。同时，对于中小银行，微服务架构还在发展过程中，混沌工程理念和实验平台技术是一个“从无到有”，到“从有到优”的过程。建议先搭建平台，再丰富平台功能及与其他应用的关联调度关系。另外混沌工程当前还是一个比较前沿的领域，商业银行本身要做到管理与技术发展并进，提升和培养技术人员对混沌工程的意识和能力。

（栏目编辑：张丽霞）

责任编辑：Rex_31