3. 故障注入分类：基础设施、应用层与数据层
在生产环境中进行故障注入时，必须根据故障发生的层次进行系统化分类。不同层次的故障对系统的影响范围、检测手段和恢复策略截然不同。本章将故障注入分为三大类：基础设施故障、应用层故障和数据层故障，并分别阐述其注入方法、预期影响与验证要点。
核心原则：故障注入应遵循“由外向内、由下至上”的渐进策略。先验证基础设施的韧性，再验证应用层的容错，最后验证数据层的完整性。切勿跨层同时注入，以免无法定位根因。
3.1 基础设施故障（CPU / 内存 / 磁盘 / 网络）
基础设施故障是混沌工程中最基础、最常用的注入类型。它们直接作用于物理或虚拟化资源，模拟硬件故障、资源耗尽或网络分区等真实场景。
3.1.1 故障类型与注入方法
| 故障类型 | 典型注入工具 | 注入参数示例 | 预期系统行为 |
|---|---|---|---|
| CPU 压力 | stress-ng, chaosblade | --cpu 4 --timeout 60s | CPU 使用率飙升，服务响应延迟增加，触发 HPA 或限流 |
| 内存耗尽 | stress-ng, memhog | --vm 2 --vm-bytes 2G | OOM Killer 触发，Pod 重启，内存溢出导致进程崩溃 |
| 磁盘 I/O 阻塞 | blktrace, dd, chaosblade | --delay-read 100ms | 日志写入阻塞，数据库 checkpoint 延迟，应用线程 hang |
| 磁盘空间满 | dd, fallocate | dd if=/dev/zero of=/tmp/fill bs=1M count=10240 | 写入失败，服务降级，监控告警触发 |
| 网络延迟 | tc, chaosblade | --delay 200ms --offset 50ms | RPC 超时，重试风暴，连接池耗尽 |
| 网络丢包 | tc, iptables | --loss 30% | 请求失败率上升，客户端熔断，服务降级 |
| 网络分区 | iptables, chaosblade | --drop-port 8080 | 服务不可用，集群脑裂，选举超时 |
生产环境建议：基础设施故障注入应优先在非核心业务实例上进行，并设置自动熔断机制（如注入时长超过阈值自动恢复）。建议配合可观测性平台实时观察 CPU / 内存 / 网络指标曲线。
3.1.2 基础设施故障注入流程（SVG）
下图展示了基础设施故障注入的标准流程，从故障定义到恢复验证的完整闭环：
3.2 应用层故障（延迟 / 异常 / 超时）
应用层故障模拟的是服务内部或服务间调用过程中的异常行为。这类故障通常比基础设施故障更难排查，因为它们可能表现为间歇性、非对称性或仅在特定请求路径上触发。
3.2.1 故障类型与注入方法
| 故障类型 | 注入方式 | 典型工具 | 影响范围 |
|---|---|---|---|
| 接口延迟 | 在服务 A 调用服务 B 时注入固定/随机延迟 | chaosblade, Envoy fault injection | 调用链下游超时，上游线程池阻塞 |
| 业务异常 | 模拟特定接口返回 500 / 403 / 自定义错误码 | chaosblade, Hystrix fallback | 客户端触发重试或降级，错误率上升 |
| 调用超时 | 设置 RPC 调用超时时间缩短或服务端响应超时 | chaosblade, gRPC deadline | 连接池快速耗尽，熔断器打开 |
| 请求限流 | 模拟服务端主动拒绝请求（429 Too Many Requests） | chaosblade, Sentinel | 客户端退避重试，流量倾斜到其他实例 |
| 依赖降级 | 强制让某个下游依赖返回默认值或空结果 | chaosblade, 自定义 Mock | 业务逻辑走降级分支，数据一致性可能受影响 |
风险提示：应用层故障注入时，务必确保熔断器、重试策略和超时配置已经过单元测试验证。否则，一次简单的延迟注入可能引发“重试风暴”，导致整个集群雪崩。
3.2.2 应用层故障传播路径（SVG）
下图展示了应用层故障在微服务调用链中的传播路径，以及熔断器如何阻断故障扩散：
3.3 数据层故障
数据层故障是最危险的故障类型之一，因为它直接影响数据的持久性、一致性和可用性。数据层故障注入的目标是验证系统在数据库不可用、主从切换、数据损坏或一致性冲突时的行为。
3.3.1 故障类型与注入方法
| 故障类型 | 注入方法 | 典型场景 | 验证要点 |
|---|---|---|---|
| 数据库连接中断 | iptables 阻断端口 / 关闭数据库进程 | 应用无法获取数据库连接 | 连接池耗尽后是否快速失败，是否触发降级 |
| 主从切换 | 手动触发 MySQL / PostgreSQL 主从切换 | 主库故障，从库提升为主 | 切换时间、数据丢失量、应用重连机制 |
| 慢查询注入 | 执行长时间运行的 SQL（如 SELECT SLEEP(30)） | 慢 SQL 占满数据库线程池 | 数据库连接池是否被打满，应用是否超时 |
| 数据损坏 | 直接修改数据库文件或写入脏数据 | 磁盘坏道、程序 bug 导致数据错乱 | 校验和机制是否生效，备份恢复流程 |
| 缓存穿透 / 击穿 | 清空 Redis 缓存或设置大量不存在的 key | 大量请求直接打到数据库 | 数据库是否扛住，缓存重建策略是否有效 |
| 分布式事务冲突 | 在 TCC / Saga 事务中注入参与者失败 | 跨服务数据一致性场景 | 补偿事务是否正确执行，最终一致性是否达成 |
关键指标：数据层故障注入时，必须重点监控以下指标：
• RTO（恢复时间目标）：从故障发生到服务恢复的时间。
• RPO（恢复点目标）：故障发生时允许丢失的数据量。
• 数据一致性延迟：主从同步延迟或最终一致性窗口。
• RTO（恢复时间目标）：从故障发生到服务恢复的时间。
• RPO（恢复点目标）：故障发生时允许丢失的数据量。
• 数据一致性延迟：主从同步延迟或最终一致性窗口。
3.3.2 数据层故障隔离架构（SVG）
下图展示了一个典型的数据层故障隔离架构，包含多级缓存、读写分离和灾备切换：
3.4 三类故障的对比与选择策略
在实际的混沌工程实验中，需要根据实验目标和系统架构选择合适的故障类型。下表从多个维度对比三类故障：
| 对比维度 | 基础设施故障 | 应用层故障 | 数据层故障 |
|---|---|---|---|
| 影响范围 | 全局性，影响所有上层服务 | 局部性，影响特定调用链 | 全局性，影响所有数据读写操作 |
| 恢复难度 | 低（资源释放即可恢复） | 中（需重置状态或重启进程） | 高（可能需要数据修复或回滚） |
| 检测手段 | 系统指标（CPU/内存/网络） | 应用指标（延迟/错误率/吞吐量） | 数据指标（一致性/延迟/复制状态） |
| 推荐实验顺序 | 第 1 阶段 | 第 2 阶段 | 第 3 阶段 |
| 风险等级 | 中 | 中高 | 高 |
实验策略建议：
• 首次进行故障注入时，优先选择基础设施故障中的 CPU 压力和网络延迟，因为它们影响可控、恢复简单。
• 应用层故障建议在基础设施韧性验证通过后再进行，且先从单实例、单接口开始。
• 数据层故障必须在有完整备份和回滚方案的前提下进行，且建议在预发环境先演练一次。
• 首次进行故障注入时，优先选择基础设施故障中的 CPU 压力和网络延迟，因为它们影响可控、恢复简单。
• 应用层故障建议在基础设施韧性验证通过后再进行，且先从单实例、单接口开始。
• 数据层故障必须在有完整备份和回滚方案的前提下进行，且建议在预发环境先演练一次。
3.5 本章小结
故障注入分类是混沌工程实验设计的基石。本章详细介绍了三大类故障的注入方法、预期影响和验证要点：
- 基础设施故障：模拟硬件和资源层面的异常，是验证系统弹性的第一道关卡。
- 应用层故障：模拟服务间调用的异常行为，重点验证熔断、降级和重试策略。
- 数据层故障：模拟数据存储和一致性相关的异常，是验证数据可靠性的最后防线。