啄木鸟混沌工程实践——面向分布式架构的故障注入测试

Posted 2021-07-18 我们的开心

文/秦洪岩 舒兆鑫

一、什么是混沌工程

随着微服务、云原生相关技术的发展，分布式系统已经流行在业界各处，但同时也带来了诸多挑战，例如：

（1）分布式系统日益庞大，很难评估单个故障对整个系统的影响。

（2）服务间的依赖错综复杂，配置不合理、单个服务不可用等可能拖垮整个服务。

（3）请求链路长，监控告警、日志记录等不完善，定位问题难。

（4）业务技术迭代速度快，加剧对系统稳定性的影响。

在复杂的分布式系统中，我们应该致力于在异常场景被触发之前，尽可能多地识别风险，然后针对性的进行加固防范。而混沌工程正是以故障注入的方式为切入点，帮助解决以上问题。混沌工程，旨在将故障扼杀在襁褓之中，即通过主动制造故障，测试系统在各种压力下的行为，识别并修复故障问题，避免造成严重后果。北研测试部运用混沌工程实验工具进行故障注入，针对分布式架构系统开展了一系列的测试探索和实践。

二、Chaosbalade混沌工程实验工具

2.1

Chaosblade应用场景

Chaosblade是一款遵循混沌工程（ChaosEngineering）原理的实验执行工具。它建立在阿里巴巴近十年故障测试和演练实践的基础上，并结合了阿里各业务的最佳创意和实践，能够提供丰富的故障场景实现，帮助分布式系统提升容错性和可恢复性。Chaosblade在实际应用中能够解决如下问题：

（1）衡量微服务的容错能力

通过模拟调用延时、服务不可用、机器资源满载等，查看发生故障的节点或者实例是否被自动隔离、下线，流量调度是否正确，预案是否有效。

（2）验证容器编排配置是否合理

通过模拟杀pod、杀节点、增大pod资源负载，观察系统服务可用性，验证副本配置、资源限制配置以及pod下部署的容器是否合理。

（3）验证监控告警的时效性

通过对系统注入故障，验证监控指标是否准确、监控维度是否完善、告警阀值是否合理、告警是否快速、告警接入是否正确、通知渠道是否可用等，提升监控告警的准确和时效性。

（4）测试Pass层是否健壮

通过模拟上层资源负载，验证调度系统的有效性；模拟依赖的分布式存储不可用，验证系统的容错能力；模拟调度节点不可用，测试调度任务是否自动迁移到可用节点；模拟主备节点故障，测试主备切换是否正常。

（5）定位与解决问题的应急能力

通过故障突袭，随机对系统注入故障，考察相关人员对问题的应急能力，以及问题上报、处理流程是否合理，达到以战养战，锻炼定位与解决问题的能力。

2.2

Chaosblade实现原理

Chaosblade在设计初期就考虑了易用性和场景扩展的便捷性，方便大家使用以及根据各自需求扩展更多地实验场景，主要可分为如下几个领域。

图1 Chaosblade异常场景说明

为了更好地理解Chaosblade的实现逻辑，我们获取了开源版本的工具源码，对常用指令，例如CPU故障、磁盘满、网络堵塞、进程假死等方面及其实现原理进行了分析，以CPU故障为例，简要分析如下。

（1）指令说明

表1 CPU故障指令说明

指令示例	CPU满负载	./blade create cpu fullload
	CPU负载百分比	./blade create cpu load --cpu-percent 90
参数说明	fullload	满载
	cpu-percent	百分比，取值范围（0-100）
	cpu-count	指定cpu满载个数
	cpu-list	指定cpu满载的具体核，核索引从0开始

（2）实现原理

在./blade create cpu 命令中，CPU可以设置为满负载，也可以设置具体负载百分比。可以通过--cpu-count来指定CPU满载的内核个数，还可以通过--cpu-list来指定需要的满载的CPU内核编号，可以使用“1，3”这种形式来分别指定编号为1和3的CPU内核满载，也可以使用“0-3”这种形式来指定编号0至3的CPU内核满载。

如果不是直接使用的release版本，而是使用源码，那么在Chaosblade前需要将源码编译，其中就会把exec/bin/目录下的文件编译成chaos_***类型的可执行文件。

图2 Chaosblade源码版本文件目录

通过查看源码，得知chaos_burncpu中实现CPU满载负荷的逻辑就是通过程序让CPU一直运作即可。代码片段如下：

图3 CPU故障代码片段

关闭CPU满载负荷的过程也比较简单，总共分为两步：

第1步： 使用ps -ef | grep … 命令找出chaos_burncpu的pid。

第2步：使用kill -9 pid命令结束它。

如果是直接可运行的release版本，那么可以在bin/目录下面看到这些chaos_***可执行文件。之后在使用./blade create cpu fullload命令的时候其实在内部就转化了，直接调用bin/chaos_burncpu，而blade这个可执行文件只是使用了Cobra来实现的CLI入口。（Cobra既是用于创建强大的现代CLI应用程序的库，也是用于生成应用程序和命令文件的程序。）

图4 Chaosblade release版本文件目录

其他如磁盘故障，其实现原理为使用dd命令实现文件拷贝，模拟磁盘高速读写，通过调整读写的块大小提升I/O负载。磁盘容量不足原理为使用dd命令或fallocate命令，在指定路径下创建文件。网络延迟、网络丢包、网络包重复、网络本地端口占用、网络包重排序在一个源码文件中，根据用户输入的指令对参数classRule进行匹配。实现原理为tc命令，即 traffic control。tc命令用于linux内核的流量控制，主要是通过在输出端口处建立一个队列来实现流量控制接受包。

通过对实现原理的分析，我们能够了解故障产生的底层逻辑，更好的模拟产生业务异常场景。

三、故障注入测试实践

我们使用nginx软负载作为接入层网关模拟分布式业务系统部署架构，使用被动健康检查来检测服务器状态。如果后端实例发生宕机，Nginx负责将宕机节点渐出。在系统稳定时，我们使用Chaosblade工具进行故障注入，并采集故障发生时的交易请求及处理情况，测试整个系统在异常场景下的稳定性和健壮性，系统部署架构如下：

发压客户端为Xmeter，Nginx部署在两台4C8G的PC Server上，主要是做7层反向代理和网关，将交易请求流量分发到后端挡板服务器。

图5 Nginx测试环境部署架构

3.1

测试场景

本次测试选取Chaosblade中CPU、磁盘、网络和进程四个常见基础资源的部分实验场景；参考Nginx测试环境部署架构，故障节点类型选取后端服务器和Nginx服务器；交易请求方面选取常用的get请求和post请求，共计48种测试场景。

表2 测试场景

序号	故障节点类型	请求类型	异常场景类型	异常场景
1	后端服务器/Nginx服务器	get请求/post请求	CPU	CPU高负载
2			磁盘	磁盘高速读IO
3				磁盘空间不足
4			网络	网络延迟
5				网络丢包
6				网络中断
7			进程	进程假死
8				杀死进程

3.2

测试执行

故障场景测试执行前应该设计一个良好的观测指标，用于和实验结果进行对比，从而判断本次实验结果是否符合预期。观测指标应该易于获取并且能够清晰直观的反应分布式架构系统在异常场景下的问题，本次实验对象为分布式架构系统Nginx在运用Chaosblade工具进行故障注入后的系统稳定性，故观测指标选取交易错误率，即设定错误率小于1%为系统的稳定状态，可通过发压工具Xmeter生成。

测试步骤为客户端设置超时时间30秒，并发数为10，Nginx使用健康检查机制推荐参数配置，持续压测10分钟，正常运行3分钟后出现故障。此外，完成故障注入测试后切记对测试环境进行故障销毁。

下面以CPU负载90%为例，对故障注入以及故障销毁执行进行说明。可以利用TOP命令观察CPU占比情况进行故障操作确认。

图6 CPU故障注入

图7 CPU故障注入确认

图8 CPU故障销毁

图9 CPU故障销毁确认

3.3

测试结果分析

在实验过程中，我们设定错误率小于1%为系统的稳定状态，将实验结果与稳定状态进行对比分析：针对本文中所构建的分布式架构，在上述异常场景下，进程假死（故障节点为后端服务器）在错误率方面未达到系统预设的稳定状态，其他情况符合预期。后续需要对进程假死情况进行重点关注，需要进一步分析确认将错误率小于1%设定为系统的稳定状态对进程假死是否合理、为何后端服务器与Nginx服务器存在差别、是否需要进行程序优化等。

表3 测试结果汇总

序号	异常场景	故障节点	请求类型	成功率
1	CPU高负载	后端服务器	get	100%
			post
		Nginx服务器	get
			post
2	磁盘高速读IO	后端服务器	get	100%
			post
		Nginx服务器	get
			post
3	磁盘空间不足	后端服务器	get	100%
			post
		Nginx服务器	get
			post
4	本地延迟1秒	后端服务器	get	100%
			post
		Nginx服务器	get
			post
5	本次延迟3秒	后端服务器	get	100%
			post
		Nginx服务器	get
			post
6	本地延迟10秒	后端服务器	get	100%
			post
		Nginx服务器	get
			post
7	本地丢包30%	后端服务器	get	100%
			post
		Nginx服务器	get
			post	99.9999995%
8	本地丢包70%	后端服务器	get	99%
			post	99%
		Nginx服务器	get	99.75%
			post	99.8%
9	本地丢包100%	后端服务器	get	100%
			post
		Nginx服务器	get	99.9999987%
			post	99.9999981%
10	网络中断	后端服务器	get	100%
			post	99.99999963%
		Nginx服务器	get	99.999999%
			post	99.999999%
11	进程假死	后端服务器	get	95%
			post	85%
		Nginx服务器	get	99%
			post	99%
12	杀死进程	后端服务器	get	100%
			post	99.999985%
		Nginx服务器	get	99.999999%
			post	99.999999%

四、总结与展望

4.1

测试方法总结

运用混沌工程实验工具Chaosblade在分布式架构系统Nginx进行故障注入测试，大致分为十个步骤：

（1）确定初步的实验需求和实验对象

确定进行异常场景测试的分布式架构系统。

（2）通过实验可行性评估，确定实验范围

针对具体的实验需求和实验对象进行细致评估，通常包含以下几个方面：实验指标、实验环境、实验工具、故障注入场景、环境恢复能力等等，从而确定合理的实验范围。

（3）设计合适的观测指标

观测指标的设计是整个实验成功与否的关键之一。系统可观测性已成为一种“强制性功能”，良好的系统可观测性会给测试工作带来强有力的数据支撑，为后续的实验结果解读、问题追踪和最终解决提供坚实的基础。

（4）设计合适的实验场景和环境

实验场景：实际生产中的故障场景多种多样，比如依赖性故障、主机性故障、操作系统故障、网络故障、服务层故障等等，在选择实验场景时要基于自己的实验需求，并且分析哪里可能会存在薄弱环节，从而针对性的为实验对象设计故障场景，做到故障精确。

实验环境：选择实验对象可以应用的实验环境，比如开发、测试、预生产、生产环境。对于非生产环境，可采用模拟生产流量和生产架构的方式，尽量和生产相似，来验证实验场景和工具的可靠性。

（5）选择合适的实验工具

故障注入是异常场景测试的关键步骤，目前主流的故障注入工具有：Netflix的开源混沌工程项目-Chaos Monkey、PingCap的开源混沌工程实践平台-Chaos Mesh，阿里巴巴的开源混沌工程实验工具Chaosblade。

（6）建立实验计划，执行实验过程

实验计划主要目的是确定相关细节，比如客户端如何模拟、服务器的关键参数如何设置、实验运行时长有无要求、故障应在何时发生等等。与实验干系人沟通并建立实验计划后，便可按照实验详细步骤执行实验过程。

（7）收集实验观测指标

收集实验过程中前期设计的观测指标。前文说到观测指标是异常场景测试是否成功的关键因素，至于如何及时并且准确的收集观测指标，应在前期设计观测指标时就确定方法与工具，并进行可行性评估。

（8）待实验完成后，清理和恢复实验环境

实验完成后，务必清理和恢复实验环境，否则故障会一直存在，从而严重影响后续的开发测试工作。本文选取的Chaosblade实验工具，除非在创建实验时设定故障运行时长，否则故障无法自动销毁，都要手动执行故障销毁命令。如若选择其他实验工具，也要严格确认故障销毁方式。

（9）分析实验结果

将“实验观测指标”与“指标的稳定状态”进行对照，“稳定状态”是指系统正常运行时的状态，也可以通过一些指标来定义。分析在故障注入的异常场景下收集的观测指标是否符合稳定状态要求，如若符合，则说明系统健壮性良好，在发生故障时依然可以稳定运行不受影响；如若不符合，则需要分析原因以及后续改进措施。

（10）追踪根源并解决问题

对于故障注入后实验观测指标不符合稳定状态的情况，需要追踪根源并解决问题。对于不符合稳定状态的情况，需要进一步确认稳定状态的合理性。如果确认无误，则根据实际需求情况，针对性的验证在其它异常场景、故障节点、请求类型、交易类型等情况下，是否依然无法达到稳定状态，进行多角度对比分析，从而全方位分析原因找出问题所在。

4.2

展望

目前，如何验证分布式架构系统的高可用原则，如何快速全面的构建分布式架构系统中的异常场景，是测试工作的一个难点。在未来，一是借助类似Chaosblade等混沌工程实验工具，搭建统一的故障演练平台，快速提供覆盖基础资源、Java应用、C++应用、Docker容器、Kubernetes平台等多平台的故障注入能力；二是建立标准化的故障演练流程及故障恢复标准，并能够根据业务系统架构协助生成演练任务，这将是我们的重点研究方向。

作者介绍

秦洪岩：北研测试部平台应用测试组成员，主要负责轻量化云应用研发平台、综合网关平台、外联服务平台等平台的测试工作。

舒兆鑫：北研测试部平台应用测试组职能组长，一直奋战在测试一线，团结带领组员开展太行、轻云、AIR等技术中台以及智能反欺诈平台，数据库平台等系统的测试。深挖测试亮点，为中心开发者乃至全行提供稳定易用的平台，努力为大家创造更多的空间和价值。

往期回顾

13

11

 轮值总编：曹宁

 责任编辑：马琳

 美     编：张娜

  技术支持: 陈曦 李振忠

我们的开心 · 总编辑部

（啄木鸟）

-  

快 乐 生 活 

开 心 工 作 

   

我 们 的 开 心

微信号：abc_kx

■ 本文为“我们的开心”第4544期文章  

■ 转载本号文章请联系我们

■欢迎来稿：请按“作品名-作者-部门”命名，发送到[e-mail]