ChaosBlade 在工商银行混沌工程体系中的应用实践

简介: ChaosBlade 在工商银行混沌工程体系中的应用实践



互联网金融时代下,金融产品和服务模式不断创新,交易量大幅攀升。面对互联网金融的全新发展态势,传统的单体 IT 架构暴露出很多不适应的地方,为此业界广泛应用云计算、分布式等新技术,构建分布式架构和运维体系,以支撑金融业务的快速发展。这些新技术的应用使得基础设施复杂性日益增加,不可预见的用户行为和事件交织在一起,对系统、应用架构的可靠性提出了更高要求。为解决分布式系统的不确定性,确保生产稳定运行,混沌工程应运而生。根据《Chaos Engineering》书中的定义:混沌工程是在分布式系统上进行实验的学科,目的是建立系统抵御生产环境中湍流条件的能力。通常来说,混沌工程指对分布式系统中的服务器随机注入不同类型的故障,发现并修复系统中的潜在问题,从而提升整个分布式系统的高可用能力。

传统系统高可用测试的痛点


中国工商银行从 2015 年启动了 IT 架构转型工程,基于分布式、云计算初步构建了开放平台核心银行系统,目前分布式体系已承载 150 余个应用,累计部署容器超过 2 万套,日均服务调用量超 70 亿,消息发送峰值每秒逾 150 万笔,实现了远超主机性能容量的集群处理能力。但与此同时,在分布式体系下支撑服务的底层技术架构和平台系统日益复杂,生产运行不确定因素相较于主机明显增多,网络异常、磁盘 IO 夯等系统层面故障导致的生产问题呈现增长趋势。由于传统项目测试人员针对系统高可用相关场景的测试意识和能力相对缺乏,且目前该领域暂无统一的测试工具,测试人员需耗费较高的学习成本去筛选和学习各类测试工具,导致项目测试主要集中在业务功能测试,缺乏对系统可用性的测试。  

故障注入工具选型


为提升工行分布式体系的稳定性,降低测试人员学习和使用相关工具的门槛,我们着重分析了 Chaosblade、Litmus、Choas Monkey 等优秀开源工具在各类故障注入场景中的能力。这些故障注入工具既有专用于云平台环境,也有适用于操作系统层面,还有针对如服务异常等应用层面的故障注入。但这些工具大多仅提供了基本的故障注入能力,还需进一步扩展完善,实现企业级的平台能力。

表 1  业界主流故障注入工具能力情况
ChaosBlade 支持目前主流的故障注入场景,相对其他几个故障注入工具,ChaosBlade 故障注入覆盖的场景最全,支持四大类、几十种常用的故障注入能力,且提供了统一的 CLI 交互界面,学习成本相对较低,其技术栈与我行分布式体系和云计算体系兼容性也较好。

图 1  ChaoBlade 故障注入能力
因此,ChaosBlade 各方面基本满足我行技术体系的需求。为保障故障注入工具能力的可扩展性,实现与上层调度平台的解耦,降低调用方的使用难度,我们基于 ChaosBlade 进行了二次开发,扩展了 ChaosBlade 的故障注入能力。

  • 一是将故障注入的调用能力封装成 Rest 接口(当时 ChaosBlade 还不支持通过 http 与之交互)。

 

  • 二是增加服务器系统指标收集模块,可实时收集服务器的 CPU、内存、网络等系统硬件使用情况。

 

  • 三是增加了故障注入任务解析模块,该模块可将混沌工程故障演练管理平台下发的故障演练任务解析成多个故障注入事件,然后根据各个故障注入事件的开始和结束时间分别调用 ChaosBlade 故障注入工具实施故障注入和撤销操作。


基于 ChaosBlade 的系统高可用测试解决方案


基于 ChaosBlade 故障注入工具,我们建设了一套功能完备的企业级混沌工程故障演练平台。

1. 平台架构


平台主要由门户、任务调度框架、故障注入介质、高可用专家库四部分组成。
门户提供各类混沌实验任务的编排和配置服务,借助演练流程编排面板,用户可以便捷地管理各类混沌实验任务;混沌实验开始实施后,用户可通过任务进度条、服务器指标展示图等实时查看混沌实验任务的进度和服务器各项系统指标情况;混沌实验执行结束后,门户会收集混沌实验过程中的所有数据,并对数据进行分析和加工,生成混沌工程实验报告供后续分析和归档。
任务调度框架负责门户和故障注入介质之间的交互,核心功能是实现混沌实验任务的批量下发和调度,该模块可以快速批量下发各种类型的混沌实验,支持失败重发、超时重发、高并发等机制。
故障注入介质负责接收门户下发的任务,并实施相应的故障注入事件。
高可用专家库是混沌工程测试人员根据平时混沌测试总结得到的高可用测试模型,基于高可用专家库用户可以根据演练场景自动关联对应的故障注入事件,并为用户提供一键生成演练流程的能力。

图 2  工行混沌工程故障演练平台架构

2. 故障演练过程详解


工程师对目标服务器进行故障注入时,涉及环境准备、故障注入任务编排、实施故障注入、终止故障注入任务等一系列操作。

1)环境准备


在实施故障演练之前,需要在混沌工程故障演练平台添加将要实施故障注入的目标服务器。如果实施目标是容器,则无需用户维护,系统可以自动关联 PaaS 平台查询各应用的容器。

2)故障演练任务编排


用户登陆故障演练平台后,选择故障演练环境。创建一个故障演练流程,每个故障演练流程至少添加一个故障演练任务,每个故障演练任务可以有一个或多个故障演练事件,每个故障演练任务可以关联一台或多台服务器。常用的故障演练事件包括对 CPU、内存、磁盘、网络、数据库、服务调用、JVM 等注入各类故障。

3)实施故障注入


用户完成故障注入任务编排后,即可开始实施故障演练。用户点击安装按钮之后,混沌工程故障演练平台就会将故障注入介质下发至目标服务器,并执行用户预先编排好的故障演练任务。
此外,故障注入介质还可实时收集服务器在混沌实验运行期间的性能状态,如系统层面的 CPU、内存、网络、磁盘使用情况,并将这些系统指标回传至混沌工程故障演练管理平台,以图形化的方式进行展示,以验证在执行混沌实验期间系统状态是否达到预期效果。

4)终止故障注入任务


故障演练任务被用户手动停止或者正常执行结束后,平台会自动调用虚机管理平台或 PaaS 管理平台的接口,将故障演练销毁命令下发至各目标服务器,恢复之前注入的故障并销毁故障注入介质。

实际效果


1. 节点管理模块


支持用户根据故障演练具体需求,在工行混沌工程故障演练平台定义不同的故障演练环境,并为各环境添加对应的目标服务器列表。

图 3  工行混沌工程故障演练平台节点管理模块

2. 演练管理模块


演练管理模块负责维护故障演练任务,支持用户选择需要实施故障演练的目标服务器以及需要执行的故障注入事件。

图 4  工行混沌工程故障演练平台演练管理模块

3. 演练监控模块


演练监控模块主要通过故障注入介质收集故障演练过程中各目标服务器当前系统层面的关键指标信息,并在工行混沌工程故障演练平台进行实时展示。

图 5  工行混沌工程故障演练平台监控管理模块

4. 高可用专家库


我们通过对历史生产问题的排查经验进行总结,并结合在大量混沌测试实践中归纳得到的高可用测试模型,建立了工行混沌工程故障演练平台高可用专家库,共包含六大类一百多种测试案例,涵盖了应用层、数据库层、平台层、中间件层、路由层、缓存层等主流的应用高可用测试场景。为降低混沌测试门槛,高可用专家库支持应用基于自身架构自动匹配测试案例,达到一键生成故障演练任务的目的。

图 6  工行混沌工程故障演练平台高可用专家库

5. 其他能力


此外,为方便混沌测试人员使用混动工程故障演练平台对测试案例和测试结果的管理,平台也提供了测试案例管理,问题管理等附加模块。同时对于一些 ChaosBlade 暂时还不具备的故障注入能力如 IO 夯住,我们也自行研发了相关功能并集成至故障注入介质当中。

6. 实践情况


我们根据分布式技术体系生产运维中的“痛点”:

  • 一是全行应用众多,高可用测试的场景和规模庞大,基于故障注入工具通过手动输入命令的方式实施故障演练效率十分低下。

 

  • 二是工行分布式系统底层架构非常复杂,涉及容器、虚机、物理机等多类设施,单一故障注入工具无法满足不同场景的故障演练需求。


因此我们建设了工行混沌工程故障演练平台,将服务器系统故障和 JVM 故障这两大类作为主要切入点,基于工行混沌工程故障演练平台高可用专家库,率先在行内快捷支付、聚合支付等一些重点业务线进行落地试点,通过注入上下游调用异常、线程池异常、磁盘 IO 夯等多种类型的故障,在各业务线的平台层、消息中间件层、应用层、数据库层、路由层均发现了一些传统测试难以发现的高可用设计等方面的问题。例如:通过对支付类交易实施混沌实验,模拟双活应用的单园区网络断连然后再恢复,发现该过程中支付链路存在一些底层故障场景下交易失败的架构设计缺陷,并在投入生产之前对支付系统架构进行了重新设计和升级。截止目前全行已对七十多各应用开展常态化故障演练测试,共实施故障演练七千余次,发现并解决了一百多个应用系统层面的高可用问题,有效避免了在生产环境触发这些问题。

未来展望


后续,工行将持续全面推广混沌工程文化,在大型活动前期进行专项大规模混沌测试,并根据各应用的测试结果,制定应用高可用水平量化评估体系。此外,随着混沌工程故障演练在测试环境的不断推进,平台应用可靠性不断增强,除了不断扩大演练半径外,下一步计划将混沌工程故障演练逐步从测试环境向生产环境推移,对全行重要产品线编排实施各种类型的演练,以确保整个平台能应对业务高峰极端条件下的压力,全面提升全行开放平台应用服务水平,为工商银行系统架构的持续优化、产品的快速创新提供坚实支撑。

相关文章
|
3月前
|
Cloud Native Devops 持续交付
云原生之旅:从混沌到秩序
在数字化浪潮中,云原生技术如同搭建现代软件架构的乐高积木,让企业能够灵活、快速地适应市场变化。本文将通过一个虚构的故事,讲述一家传统企业如何拥抱云原生,实现从技术债务累积的混沌状态到高效、自动化的秩序转变。我们将一探究竟,云原生技术是如何一步步引领这场变革,并为企业带来前所未有的灵活性和创新能力。
|
测试技术 调度 C++
六年打磨!阿里开源混沌工程工具 ChaosBlade
减少故障的最好方法就是让故障经常性的发生。通过不断重复失败过程,持续提升系统的容错和弹性能力。今天,阿里巴巴把六年来在故障演练领域的创意和实践汇浓缩而成的工具进行开源,它就是 “ChaosBlade”。如果你想要提升开发效率,不妨来了解一下。
11957 0
|
6月前
|
tengine 算法 安全
ChaosBlade 是阿里巴巴开源的混沌工程工具
【2月更文挑战第23天】ChaosBlade 是阿里巴巴开源的混沌工程工具
130 1
|
6月前
|
Kubernetes 监控 容器
K8S故障注入混沌工程开源平台ChaosMesh
总之,ChaosMesh作为一个Kubernetes混沌工程平台,为用户提供了测试和验证Kubernetes集群的可靠性的工具和框架,有助于提高系统的稳定性和性能。
236 0
|
消息中间件 Kubernetes Cloud Native
蚂蚁集团自动化混沌工程 ChaosMeta 正式开源
ChaosMeta 介绍ChaosMeta 是一款面向云原生、自动化演练而设计的混沌工程平台。它是蚂蚁集团内部混沌工程平台 XMonkey 的对外开源版本,凝聚了蚂蚁集团在公司级大规模红蓝攻防演练实践中多年积累的方法论、技术能力以及产品能力。经过公司内部多年复杂故障演练场景的驱动,XMonkey 在混沌工程领域沉淀了很多独特经验,是蚂蚁集团研发、测试、质量、SRE 等人员进行历史故障演练和挖掘系统
405 0
蚂蚁集团自动化混沌工程 ChaosMeta 正式开源
|
缓存 Kubernetes Cloud Native
混沌实施工具ChaosBlade实践
项目介绍 ChaosBlade 是阿里巴巴开源的混沌工程原理和混沌实验模型的实验注入工具。 ChaosBlade 使用比较简单,而且支持丰富的实验场景,场景包括: 基础资源:比如 CPU、内存、网络、磁盘、进程等实验场景; Java 应用:比如数据库、缓存、消息、JVM 本身、微服务等,还可以指定任意类方法注入各种复杂的实验场景; C++ 应用:比如指定任意方法或某行代码注入延迟、变量和返回值篡改等实验场景; Docker 容器:比如杀容器、容器内 CPU、内存、网络、磁盘、进程等实验场景; 云原生平台:比如 Kubernetes 平台节点上 CPU、内存、网络、磁盘、进程实验场景,Pod
226 0
|
监控 负载均衡 Cloud Native
【DevOps】什么是混沌工程?
测试您可以预测的事故是必不可少的。但是随着数字化转型和云原生架构带来的复杂性,团队需要一种方法来确保应用程序能够承受生产的“混乱”。混沌工程满足了这一需求,因此组织可以提供在任何条件下都可以正常运行的强大、有弹性的云原生应用程序。
《阿里云总监课第五期第二节:可靠性探索–利用混沌工程理念提高工程可靠性》电子版地址
阿里云总监课第五期第二节:可靠性探索–利用混沌工程理念提高工程可靠性
142 0
《阿里云总监课第五期第二节:可靠性探索–利用混沌工程理念提高工程可靠性》电子版地址
|
监控 容灾 Cloud Native
被你质疑价值的混沌工程,阿里巴巴已落地实践了9年
无可讳言,对于混沌工程的价值,目前在业内还没有一个明确的度量标准,但是可以通过简单的例子来有效佐证。据中亭介绍,一方面可以先选定一个场景,从结果上看,混沌工程可以保证场景不劣化;另一方面,如果度量组织进行突袭,不管系统架构和人员架构怎么变,监控结果都在合理的范围内。总体而言,混沌工程的核心就是增强信心,保证系统在某个场景下的能力不退化。只要这个组织有度量“特定场景下能力是否退化”的指标,混沌工程的价值就显而易见了。
758 3
被你质疑价值的混沌工程,阿里巴巴已落地实践了9年
|
容器 Cloud Native Perl
面向云原生的混沌工程工具-ChaosBlade
作者 | 肖长军(穹谷)阿里云智能事业群技术专家   导读:随着云原生系统的演进,如何保障系统的稳定性受到很大的挑战,混沌工程通过反脆弱思想,对系统注入故障,提前发现系统问题,提升系统的容错能力。ChaosBlade 工具可以通过声明式配置执行混沌实验,简单高效。