混沌测试-chaos

赵建永

于 2024-07-06 15:54:21 发布

阅读量249

点赞数

文章标签：性能优化

原文链接：https://mp.weixin.qq.com/s?__biz=Mzg2NTkxOTEzMw==&mid=2247488321&idx=1&sn=db4cf60cea40cdaf2b8b02cbba87ef01&chksm=ce539ab3f92413a5e7d3cd97bbb9fafb2f12c2f150bb428dfa33f68aa564424f3213d26d3985&cur_album_id=3464972998652624897&scene=189#wechat_redirect

版权

自动化测试技术23：混沌测试ChaosBlade应用实战

一、混沌工程基础

混沌工程是一种将混沌理论应用于工程领域的方法，旨在通过模拟和制造系统中的故障和不稳定因素，来测试和提高系统的可靠性和健壮性。它通过对生产环境进行有意制造的故障和异常方式，来验证系统对这些故障的反应和恢复能力，以此来发现和解决系统存在的弱点，从而降低系统的风险和成本。它的基本思想是通过有计划、有目的地注入故障，来验证系统在故障情况下的表现。这种故障可以是硬件故障、服务故障、软件故障等。

引入混沌工程原因

随着分布式系统的建设，单体应用迁移到分布式架构中，对系统的可靠性和容错性提出了更高的要求。为防止服务因为微小故障而产生雪崩效应，引发系统大面积崩溃，通过在分布式系统上进行受控实验，观察系统行为并及时发现问题，提升系统健壮程度。

混沌测试

混沌测试顾就是在系统中“制造混沌”，来验证系统鲁棒性和可靠性的一种方法。基于模拟实际环境中故障发生的场景，混沌测试可以挑战系统在异常情况下的反应，检验系统的性能、可靠性、安全性等，并且将混沌测试与自动化测试相结合，能够大大简化测试工作。混沌测试的目标是帮助发现潜在的问题和风险，提高和优化系统的鲁棒性，以确保系统在面对复杂的环境和工作负载时能够保持正确的运行状态。

混沌测试主要场景包括但不限于：模拟网络故障、磁盘损坏、服务器宕机等。

混沌工程测试与传统测试比较

传统测试：面向的是局部的。比如说某一个功能点、某一个场景是否满足要求；

混沌工程测试面向的是整体：

1.某一个故障在整体系统中的影响；

2.从故障产生到恢复的时间，评估的是应急响应是否健全、有效，保障机制是否可靠、正确的运行，不仅仅是技术上的测试；

具体如下：

混沌工程的重要原则是尽量在生产环境上进行实验，因为越接近生产环境，模拟故障越真实，越能发现系统问题，以最准确的方案来优化系统。但是前期系统存在较大的不稳定性，直接在生产环境进行实验，会产生较大的风险和事故。因此，我们建议前期在测试或者预发环境进行实验，待不断地演练和优化系统后，再从小规模到大规模逐步回归到生产环境进行实验。

混沌工程试验流程

混沌工程的实验流程通常包括8个步骤：

定义假设：首先需要明确实验的目的和假设，即需要验证哪些方面和条件，以及想要得到哪些结果和结论，验证系统在负载高峰期的稳定性等。
定义稳定性指标：需要围绕稳定性去展开，因此需要提前定义稳定性指标，例如系统的可用性、响应时间等，根据具体业务场景和需求定义相应的指标。
设计实验：根据实验假设，设计实验方案，包括实验的类型、注入的故障和异常类型、实验的持续时间等。确定实验的影响范围和影响程度，以确保实验过程的爆炸半径和安全性。
准备实验：在实验开始前，需要准备好实验环境和实验工具，并确保实验的安全性和稳定性。
执行实验：按照实验方案模拟故障和异常，并对系统进行实时监控和记录。建议在一个安全和可控的环境下，模拟一些异常情况。例如模拟系统崩溃、网络故障等，观察系统的反应和恢复能力。按照实验方案逐步引入故障，观察系统的响应能力，记录故障发生的情况和对系统稳定性指标的影响。
结果分析：混沌工程需要收集演练过程中的数据，包括但不限于响应时间、错误率、故障恢复时间等。实验结束后，需要对实验结果进行分析和评估，根据实验数据和记录的信息，分析系统在故障情况下的表现和响应能力，找出潜在的问题和改进点，包括系统的响应和恢复能力、系统的容错性和健壮性等。
优化改进：根据实验结果，提前发现系统问题和性能拐点，并优化实验方案和实验工具，最后优化系统的设计和实现。
持续实验：混沌工程不是一次性买卖，需要通过持续的实践和改进，不断提高系统的健壮性和可靠性，并逐步完善混沌工程实验流程，以适应不断变化的系统和环境。

混沌工程验证测试工具

ChaosBlade 阿里巴巴的开源混沌工具，提供了各种场景、协议和应用程序的故障模拟
Gremlin 一款用于模拟故障的SaaS工具，提供了各种故障场景和操作系统的支持
Pumba 一个基于Docker 的混沌工具，可以模拟网络故障、容器宕机等

混沌工程原则

第一条：”建立一个围绕稳定状态行为的假说“，其包含两个含义，一个是定义能直接反应业务服务的监控指标，需要注意的是这里的监控指标并不是系统资源指标，比如 CPU、内存等，这里的监控指标是能直接衡量系统服务质量的业务监控。举个例子，一个调用延迟故障，请求的 RT 会变长，对上层交易量造成下跌的影响，那么这里交易量就可以作为一个监控指标。这条原则的另一个含义是故障触发时，对系统行为作出假设以及监控指标的预期变化。
第二条指模拟生产环境中真实的或有理论依据的故障场景，比如依赖的服务调用延迟、超时、异常等。
第三条建议在生产环境中运行实验，但也不是说必须在生产环境中执行，只是实验环境越真实，混沌工程越有价值，但如果知道系统在某个故障场景下不具备容灾能力，不可以执行此混沌实验，避免资损发生。
第四条，持续的执行才能持续的降低故障复发率和提前发现故障，所以需要持续的自动化运行试验。
最后一个，混沌工程很重要的一点是控制爆炸半径，也就是试验影响面，防止预期外的资损发生，可以通过环境隔离或者故障注入工具提供的配置粒度来控制。

二、某行基于ChaosBlade 建设混沌工程的实践案例

先看两个混沌工程的实践案例，在看工行基于ChaosBlade 建设混沌工程建设的实践。

1、两个混沌工程的实践案例

此拓扑图来自于阿里云 AHAS 产品架构感知功能，可自动感知架构拓扑，并且可以展示进程、网络、节点等数据。这个分布式服务 Demo 分三级调用，consumer 调用 provider，provider 调用 base，同时 provider 还调用 mk-demo 数据库，provider 和 base 服务具有两个实例，在 AHAS 架构拓扑图上，我们点击一个实例节点，可以到非常清晰的调用关系。我们后面结合这个 Demo 去讲解实践。

案例一

案例一，我们验证系统的监控告警性有效性。按照前面提到的混沌工程实施步骤，那么这个案例执行的实验场景是数据库调用延迟，我们先定义监控指标：慢 SQL 数和告警信息，做出期望假设：慢 SQL 数增加，钉钉群收到慢 SQL 告警。接下来执行实验。我们直接使用 ChaosBlade 工具执行，可以看下左下角，我们对 demo-provider 注入调用 mysql 查询时，若数据库是 demo 且表名是 d_discount，则对 50% 的查询操作延迟 600 毫秒。我们使用阿里云产品 ARMS 做监控告警。大家可以看到，当执行完混沌实验后，很快钉钉群里就收到了报警。所以我们对比下之前定义的监控指标，是符合预期的。但需要注意的是这次符合预期并不代表以后也符合，所以需要通过混沌工程持续性的验证。出现慢 SQL，可通过 ARMS 的 链路追踪来排查定位，可以很清楚的看出哪条语句执行慢。

案例二

前面讲了一个符合预期的案例，我们再来看一个不符合预期的。此案例是验证系统异常实例隔离的能力，我们的 Demo 中 consumer 调用 provider 服务，provider 服务具有两个实例，我们对其中一个注入延迟故障，监控指标是 consumer 的 QPS，稳态在 510 左右。我们做的容错假设是系统会自动隔离或下线出问题的服务实例，防止请求路由的此实例，所有 QPS 会有短暂的下跌，但很快会恢复。这个案例，我们使用阿里云 AHAS 混沌实验平台来执行，我们对 demo-provider-1 注入延迟故障，基于此平台可以很方便的执行混沌实验。执行混沌实验后，QPS 下跌到 40 左右，很长时间没有自动恢复，所以不符合预期，我们通过人工的方式对该异常的实例做下线处理，很快就看到，consumer 的 QPS 恢复正常。所以我们通过混沌工程发现了系统问题，我们后面需要做就是记录此问题，并且推动修复，后续做持续性的验证。

2、某行基于 ChaosBlade 的系统建设高可用测试解决方案

ChaosBlade介绍

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 夯等多种类型的故障，在各业务线的平台层、消息中间件层、应用层、数据库层、路由层均发现了一些传统测试难以发现的高可用设计等方面的问题。例如：通过对支付类交易实施混沌实验，模拟双活应用的单园区网络断连然后再恢复，发现该过程中支付链路存在一些底层故障场景下交易失败的架构设计缺陷，并在投入生产之前对支付系统架构进行了重新设计和升级。截止目前全行已对七十多各应用开展常态化故障演练测试，共实施故障演练七千余次，发现并解决了一百多个应用系统层面的高可用问题，有效避免了在生产环境触发这些问题。