测试——混沌工程详解

一、混沌工程与高可用测试区别

1. 目标一致性

• 高可用性测试：通过模拟故障场景，验证系统在故障发生时的表现和恢复能力，确保系统在不可预见的故障中仍能正常运行。
• 混沌工程：通过有计划地引入随机故障，验证系统的整体韧性，发现潜在问题并优化系统的容错能力。
• 共同目标：提升系统的可靠性和稳定性，确保系统在面对故障时仍能提供高质量的服务。

2. 测试方法

• 高可用性测试：
  • 通常针对特定的故障场景（如节点宕机、网络中断等），验证系统的高可用性设计是否有效。
  • 测试场景较为固定，侧重于已知的故障模式。
• 混沌工程：
  • 通过随机引入故障（如网络延迟、磁盘损坏、服务中断等），验证系统在未知故障下的表现。
  • 测试场景更具随机性和探索性，侧重于发现未知的薄弱环节。

3. 测试范围

• 高可用性测试：
  • 通常聚焦于系统的关键组件和高可用性设计（如主从切换、负载均衡、数据一致性等）。
  • 测试范围相对集中，针对性强。
• 混沌工程：
  • 覆盖系统的整体架构，包括基础设施、应用服务、网络、存储等多个层面。
  • 测试范围更广，更具全局性。

4. 测试流程

• 高可用性测试：
  • 通常按照预定的测试计划和场景执行，步骤较为固定。
  • 测试结果主要用于验证系统的高可用性设计是否符合预期。
• 混沌工程：
  • 强调持续性和迭代性，通过不断引入新的故障场景，逐步优化系统的韧性。
  • 测试结果用于发现潜在问题并推动系统改进。

5. 工具支持

• 高可用性测试：
  • 使用专门的测试工具或脚本，模拟特定的故障场景。
  • 例如：故障注入工具、负载测试工具等。
• 混沌工程：
  • 使用混沌工程平台（如 ChaosBlade、ChaosMesh、LitmusChaos 等），支持自动化和随机化的故障注入。
  • 例如：模拟网络延迟、磁盘损坏、服务中断等。

二、混沌工程的核心指标

混沌工程的核心指标用于衡量系统在故障注入期间和恢复后的表现，主要包括以下几个方面：

1. 服务可用性（Availability）：

   • 定义：系统在故障注入期间和恢复后，服务是否仍然可用。
   • 指标：可用性百分比（如 99.9%）。
   • 示例：在 Redis 主节点故障期间，从节点能否继续提供服务。

2. 故障恢复时间（Recovery Time Objective, RTO）：

   • 定义：系统从故障发生到完全恢复正常服务的时间。
   • 指标：恢复时间（如 5 分钟）。
   • 示例：Elasticsearch 节点故障后，集群重新平衡的时间。

3. 数据一致性（Consistency）：

   • 定义：系统在故障期间和恢复后，数据是否保持一致。
   • 指标：数据一致性状态（如一致、部分一致、不一致）。
   • 示例：Redis 主从节点之间的数据同步是否正常。

4. 性能指标（Performance）：

   • 定义：系统在故障注入前后的性能变化。
   • 指标：响应时间、吞吐量、延迟等。
   • 示例：在 Kafka 集群中引入网络延迟后，消息生产者和消费者的吞吐量是否下降。

5. 故障检测时间（Fault Detection Time）：

   • 定义：从故障发生到系统检测到故障的时间。
   • 指标：检测时间（如 10 秒）。
   • 示例：监控系统是否能够及时发现节点宕机。

6. 告警准确性（Alert Accuracy）：

   • 定义：监控系统是否能够准确发出告警。
   • 指标：告警的准确率和及时性。
   • 示例：在 MySQL 主从同步失败时，监控系统是否能够及时发出告警。

7. 用户影响（User Impact）：

   • 定义：故障对用户的影响程度。
   • 指标：用户请求失败率、用户体验评分等。
   • 示例：在网关节点故障期间，用户请求的成功率是否下降。

三、混沌工程的目的

混沌工程的核心目的是通过引入故障，验证系统的韧性，并发现潜在问题，从而优化系统的可靠性和稳定性。具体目的包括：

1. 发现系统中的薄弱环节：

   • 通过引入故障，发现系统中可能存在的单点故障、性能瓶颈、数据一致性问题等。
   • 示例：在 Kafka 集群中引入网络分区，发现消息丢失或重复的问题。

2. 验证系统的容错能力：

   • 验证系统在故障发生时的表现，确保其能够自动恢复或降级运行。
   • 示例：验证 Redis 主节点故障后，从节点能否自动提升为主节点。

3. 优化故障恢复机制：

   • 通过测试结果，改进系统的故障检测、恢复和自愈能力。
   • 示例：优化 Elasticsearch 集群的重新平衡算法，缩短故障恢复时间。

4. 提升系统的整体韧性：

   • 通过持续演练，逐步提升系统在复杂故障场景下的表现。
   • 示例：在分布式系统中引入随机故障，验证其在高负载、网络抖动等复杂场景下的稳定性。

5. 验证监控和告警系统的有效性：

   • 确保监控系统能够及时发现故障，并发出准确的告警。
   • 示例：验证 Prometheus 是否能够准确检测到节点 CPU 过载。

6. 增强团队对故障的应对能力：

   • 通过演练，提升团队对故障的识别、分析和解决能力。
   • 示例：在演练中模拟数据库主从同步失败，训练团队快速定位和解决问题。

7. 降低生产环境的风险：

   • 通过在测试环境中引入故障，减少生产环境中发生类似故障的可能性。
   • 示例：在测试环境中模拟磁盘损坏，验证数据备份和恢复机制。

四、混沌工程的流程

1. 设置混沌工程演练

1. 确定演练目标：

   • 明确演练的目的，例如验证中间件在故障场景下的高可用性、性能表现和故障恢复能力。这个目标可以根据业务图和架构图进行分析得到。
   • 举例：对于 Elasticsearch，目标是验证在节点故障、网络分区等情况下，搜索服务的可用性和响应时间是否在可接受范围内。

2. 选择故障注入点：

   • 根据中间件的组件和架构特点，选择合适的故障注入点。
   • 举例：
     • Redis：主节点故障、从节点故障、网络延迟、命令执行超时等。
     • Elasticsearch：节点宕机、磁盘故障、网络分区等。
   • 方法：使用工具模拟网络延迟或手动关闭节点。

3. 确定故障注入方式：

   • 手动注入：适用于初期探索性演练，由运维人员通过命令行工具或脚本直接操作。
   • 自动注入：使用混沌工程工具（如 Chaos Mesh）自动注入故障，并进行监控和数据收集。

4. 制定演练场景：

   • 设计多个故障场景，覆盖可能出现的各种情况。
   • 举例：
     • Redis：主节点故障后从节点自动提升为主节点、多个从节点同时故障、网络分区导致部分节点不可达等。
     • Elasticsearch：单个节点故障、多个节点同时故障、索引损坏、查询超时等。

5. 确定演练时间和频率：

   • 根据中间件的重要性和业务需求，确定演练的时间和频率。
   • 举例：对于关键业务的中间件，可以每月进行一次演练，选择业务低峰期以减少影响。

2. 检验标准

1. 服务可用性：

   • 检查中间件在故障注入期间和恢复后，服务是否仍然可用。
   • 举例：
     • Redis：通过执行 GET、SET 等命令检查响应是否正常。
     • Elasticsearch：通过发送搜索请求检查结果是否正确。
   • 设定可用性指标，例如在故障期间，服务可用性不能低于 99%。

2. 性能指标：

   • 监测中间件在故障注入前后的性能变化。
   • 举例：
     • Redis：命令执行时间、吞吐量等。
     • Elasticsearch：查询响应时间、索引速度、吞吐量等。
   • 设定性能阈值，例如 Redis 命令执行时间不能超过一定毫秒数。

3. 故障恢复时间：

   • 记录中间件从故障发生到完全恢复正常服务的时间。
   • 举例：
     • Redis：从节点提升为主节点的时间不能超过一定分钟数。
     • Elasticsearch：集群重新平衡的时间不能超过一定时间。

4. 数据一致性：

   • 检查中间件在故障期间和恢复后，数据是否保持一致。
   • 举例：
     • Redis：检查主从节点之间的数据同步是否正常。
     • Elasticsearch：检查索引数据是否完整，是否存在丢失或损坏。
   • 方法：对比故障前后的数据快照或使用数据校验工具。

5. 监控和告警：

   • 验证中间件的监控系统是否能够及时发现故障并发出准确告警。
   • 方法：模拟故障场景，检查监控系统的响应时间和告警准确性。

五、云原生场景下常用的测试工具

1. ChaosBlade

• 简介：ChaosBlade 是阿里巴巴开源的混沌工程工具，遵循混沌工程原理，用于模拟常见的故障场景，帮助提升分布式系统的可恢复性和容错性。
• 特点：
  • 支持多种故障场景，包括基础资源、多语言应用服务和 Kubernetes 平台。
  • 易于扩展，遵循混沌实验模型。
  • 在阿里巴巴内部经过多年实践验证，具有较高的实用性和可靠性。
• 适用场景：分布式系统的故障测试和演练。

2. ChaosMesh

• 简介：ChaosMesh 是 PingCAP 开源的云原生混沌工程平台，提供丰富的故障模拟类型和强大的故障场景编排能力。
• 特点：
  • 支持图形化操作，基于 Kubernetes 的自动化能力，系统易用性强。
  • 涵盖分布式测试体系中的大多数故障场景。
  • 被腾讯、美团等公司使用，用于 Apache APISIX、RabbitMQ 等系统的测试。
• 适用场景：云原生环境的混沌工程。

3. LitmusChaos

• 简介：LitmusChaos 是一个具有跨云支持的云原生混沌工程框架，适用于多种云环境。
• 特点：
  • ChaosHub 托管了大量混沌实验，实验高度可调且具有声明性。
  • 支持跨云和多用户环境。
  • 被多家企业和组织使用，适用于多种云环境。
• 适用场景：跨云环境的混沌工程。

六、测试工具对比

工具名称	ChaosBlade	ChaosMesh	LitmusChaos
简介	遵循混沌工程原理的实验工具，用于模拟常见故障场景，提升系统的可恢复性和容错性。	开源的云原生混沌工程平台，提供丰富的故障模拟类型和强大的故障场景编排能力。	具有跨云支持的云原生混沌工程框架，适用于多种云环境。
故障场景丰富度	高	高	中高
场景支持	1. 基础资源（CPU、内存、网络、磁盘等） 2. 多语言应用服务（Java、C++等） 3. Kubernetes 平台（Container、Pod、Node 等）	1. 丰富的故障模拟场景，涵盖分布式测试体系中的大多数场景。	ChaosHub 托管了大量混沌实验，实验高度可调且具有声明性。
环境要求	1. k8s 环境（版本不低于 1.16） 2. 主机环境安装	1. golang 版本不低于 v1.15 2. docker、gcc、helm（版本不低于 v2.8.2） 3. nodejs 和 yarn（用于开发 Chaos Dashboard）	1. k8s 1.17 或更高版本 2. 20G 持久卷
架构平台支持	支持 x86_64 和 arm64	支持 x86_64 和 arm64	支持 x86_64 和 arm64
图形化支持	支持	支持	支持
易用性和扩展性	较好（遵循混沌实验模型，易于扩展）	系统易用性强（图形化操作，基于 Kubernetes 的自动化能力）	较好
跨云支持	不支持	不支持	支持
多用户支持	不支持	不支持	支持
专注领域	分布式系统的故障测试和演练	云原生环境的混沌工程	跨云环境的混沌工程
实战案例	阿里巴巴近十年故障测试和演练实践	被腾讯、美团等公司使用，用于 Apache APISIX、RabbitMQ 等系统的测试	被多家企业和组织使用，适用于多种云环境

七、ChaosBlade 梳理

1. 业务产品中间件产品组件

• 元数据管理（zk、etcd、mysql等）：
  • 破坏场景：元数据管理平台挂掉。
  • 影响：存量业务理论上不受影响，但存量业务的变动受影响。
  • 高可用方案设计：确保元数据管理平台的高可用性。
• 集群分片自动均衡：
  • 破坏场景：增加/减少数据节点。
  • 影响：验证集群分片自动均衡能力。
• 网关（网络流量转发）：
  • 破坏场景：网关节点故障。
  • 影响：验证网关的故障转移和恢复能力。
• 数据面（主从数据同步、数据持久化、定期备份、快速恢复）：
  • 破坏场景：主从数据同步失败、数据持久化异常、备份失败。
  • 影响：验证数据一致性和恢复能力。
• 负载均衡（LB /HAProxy）：
  • 破坏场景：负载均衡节点故障。
  • 影响：验证负载均衡的故障转移能力。
• HDFS、S3、minio：
  • 破坏场景：存储节点故障。
  • 影响：验证数据存储的高可用性。
• 数据迁移：
  • 破坏场景：数据迁移过程中节点故障。
  • 影响：验证数据迁移的一致性和完整性。
• 个性化（ES）master选举：
  • 破坏场景：主master挂掉。
  • 影响：验证重新选主的能力。
• 故障转移：
  • 破坏场景：网关节点故障。
  • 影响：验证自动下线或恢复故障节点的能力。
• 数据节点故障：
  • 破坏场景：主分片挂了或从分片挂了。
  • 影响：验证从分片升级为主分片或重新建立副本的能力。
• 数据写入：
  • 破坏场景：写主成功，写从失败。
  • 影响：验证数据一致性和异常处理能力。
• 网络断开后自动连接：
  • 破坏场景：网络断开。
  • 影响：验证自动重连能力。
• 个性化（Redis）Redis 缓存过期：
  • 破坏场景：缓存过期。
  • 影响：验证缓存失效后的处理能力。
• 缓存内存限制：
  • 破坏场景：缓存内存达到限制。
  • 影响：验证内存管理能力。
• 数据分片：
  • 破坏场景：主分片不可用。
  • 影响：验证从分片提升为主分片的能力。
• 数据迁移：
  • 破坏场景：数据迁移过程中节点故障。
  • 影响：验证数据一致性和迁移能力。
• 哨兵模式：
  • 破坏场景：哨兵节点故障。
  • 影响：验证哨兵模式的故障检测和恢复能力。

2. 平台

• Kubernetes（k8s）Node故障：
  • 破坏场景：单node或多node故障。
  • 影响：验证k8s的节点故障恢复能力。
• CPU类异常：
  • 破坏场景：node CPU负载过高。
  • 影响：验证CPU资源管理能力。
• 进程类异常：
  • 破坏场景：杀进程或暂停进程。
  • 影响：验证进程管理能力。
• 磁盘类异常：
  • 破坏场景：node磁盘填充或磁盘IO负载过高。
  • 影响：验证磁盘资源管理能力。
• 内存类异常：
  • 破坏场景：node内存占用过高。
  • 影响：验证内存资源管理能力。
• 网络类异常：
  • 破坏场景：网络延迟、丢包、包损坏、DNS篡改等。
  • 影响：验证网络故障恢复能力。
• Pod删除pod：
  • 破坏场景：删除pod。
  • 影响：验证pod的自动重建能力。
• CPU、内存、磁盘、网络异常：
  • 破坏场景：pod CPU满载、内存占用过高、磁盘IO负载过高、网络延迟等。
  • 影响：验证pod的资源管理能力。
• 进程异常：
  • 破坏场景：杀进程或暂停进程。
  • 影响：验证pod的进程管理能力。
• 云舰平台网关（控制面）：
  • 破坏场景：网关节点故障。
  • 影响：验证网关的故障转移能力。
• 商业平台（地域可用区、账号权限、登录）：
  • 破坏场景：商业平台节点故障。
  • 影响：验证商业平台的高可用性。
• ingresscontroller（域名访问）：
  • 破坏场景：ingresscontroller节点故障。
  • 影响：验证域名访问的高可用性。
• minio、hub、gdns、passcluster（底座mysql、redis、kafka、es、etcd）：
  • 破坏场景：底座组件节点故障。
  • 影响：验证底座组件的高可用性。

3. 基础资源

• CPU：
  • 破坏场景：CPU负载模拟。
  • 影响：验证CPU资源管理能力。
• 内存：
  • 破坏场景：内存占用模拟。
  • 影响：验证内存资源管理能力。
• 网络：
  • 破坏场景：网络延迟、丢包、断网、包损坏、DNS篡改等。
  • 影响：验证网络故障恢复能力。
• 磁盘：
  • 破坏场景：磁盘IO负载、磁盘填充。
  • 影响：验证磁盘资源管理能力。
• 进程：
  • 破坏场景：杀进程或暂停进程。
  • 影响：验证进程管理能力。
• 脚本：
  • 破坏场景：函数执行延迟或退出。
  • 影响：验证脚本的异常处理能力。
• 时间：
  • 破坏场景：系统时间偏移。
  • 影响：验证时间同步能力。