3. 故障注入基础：定义、类型与分类
故障注入是混沌工程的核心执行动作，也是基线核验中验证系统韧性假设的直接手段。在评审故障注入方案时，首先需要统一对故障注入的定义理解，并掌握完整的故障类型分类体系，才能确保注入方案覆盖全面、风险可控。
3.1 故障注入定义
故障注入（Fault Injection）是指在受控环境下，通过人为方式向系统引入预定义的故障状态，以观察系统行为、度量韧性指标、验证容错与恢复机制是否按预期生效的工程方法。
核心三要素：
- 受控性——注入范围、时长、强度均预先定义，具备回滚与中止能力；
- 可观测性——注入前后均有监控、日志、链路追踪数据采集；
- 可复现性——同一故障可在相同条件下重复注入，用于回归验证。
在混沌基线核验场景中，故障注入不是破坏性测试，而是验证性实验。其目标不是“看系统会不会崩溃”，而是“确认系统在已知故障下仍能维持基线承诺的可用性与性能”。
3.2 故障类型分类体系
故障注入的覆盖范围决定了基线核验的置信度。按故障发生的层次与对象，可将故障类型分为四大类：硬件故障、软件故障、网络故障和依赖故障。下表给出了每类的典型场景与注入示例。
| 故障大类 | 子类 | 典型注入场景 | 基线核验关注点 |
|---|---|---|---|
| 硬件故障 | CPU | CPU 满载、核离线、频率降级 | 限流降级、调度重平衡 |
| 内存 | 内存耗尽、ECC 错误注入 | OOM 保护、内存隔离 | |
| 磁盘/IO | 磁盘写满、IO 延迟抖动、设备移除 | IO 超时重试、存储切换 | |
| 软件故障 | 进程/线程 | 进程 Kill、线程死锁、协程阻塞 | 进程守护、健康检查恢复 |
| 函数/方法 | 方法抛出异常、返回错误码、超时 | 熔断、重试、降级逻辑 | |
| 配置/状态 | 配置项篡改、状态机异常跳转 | 配置热加载、状态一致性 | |
| 网络故障 | 延迟 | 单向/双向延迟增加 500ms~5s | 超时配置、客户端重试 |
| 丢包/中断 | 随机丢包 10%~50%、网卡 down | 连接池重建、会话保持 | |
| 分区/隔离 | 节点间网络完全隔离 | 脑裂防护、仲裁机制 | |
| 依赖故障 | 外部服务 | 下游 API 返回 500、超时、限流 | 熔断器状态转换、降级响应 |
| 中间件 | Redis/MQ 主从切换、队列堆积 | 数据一致性、消费积压处理 | |
| 基础设施 | DNS 解析失败、证书过期 | 缓存降级、备用端点切换 |
3.3 故障注入分类关系图
下图展示了四大故障类型之间的层次关系与典型注入路径，帮助评审人员快速建立故障覆盖的全局视角。
3.4 故障注入的层次与粒度
在基线核验评审中，除了分类覆盖，还需要关注故障注入的层次与粒度。同一类故障在不同层次注入，对系统的影响范围和恢复路径差异显著。
- 基础设施层：宿主机、虚拟机、容器、网络设备级别的故障注入，影响面最大，恢复依赖基础设施自愈能力。
- 平台层：中间件、数据库、消息队列等平台组件的故障注入，影响面集中在服务依赖链路上。
- 应用层：进程、线程、函数、配置等应用内部故障，影响面最可控，但需要应用代码具备容错逻辑。
评审建议：在基线核验的故障注入方案中，建议按“基础设施层 → 平台层 → 应用层”的顺序逐层设计注入用例。每层至少选择 2 个故障类型，确保从底层到上层的韧性假设都能被验证。
3.5 故障注入的典型模式
根据注入时机与系统状态，故障注入可分为以下三种典型模式，评审时需确认方案是否覆盖了这些模式。
| 注入模式 | 说明 | 适用场景 | 基线核验价值 |
|---|---|---|---|
| 稳态注入 | 系统处于正常负载时注入故障 | 验证系统在无压力下的容错能力 | 确认基础容错机制是否生效 |
| 压力注入 | 系统处于高负载或极限压力时注入故障 | 验证系统在资源紧张时的故障处理能力 | 确认限流、降级、熔断是否按预期触发 |
| 连锁注入 | 在已有故障基础上叠加新故障 | 验证系统在多重故障下的韧性边界 | 确认故障隔离与恢复优先级是否合理 |
3.6 故障注入的评审检查清单
在混沌基线核验的故障注入评审环节，建议使用以下清单逐项核对注入方案的完整性。
- 定义对齐：方案中的故障注入定义是否包含受控性、可观测性、可复现性三要素？
- 分类覆盖：是否覆盖硬件、软件、网络、依赖四大类？每类是否至少包含 2 个子类型？
- 层次完整：是否覆盖基础设施层、平台层、应用层三个层次？
- 模式多样：是否包含稳态注入、压力注入、连锁注入三种模式？
- 风险可控：是否定义了注入范围、时长、中止条件与回滚方案？
- 观测配套：注入前后是否有对应的监控指标、日志采集与链路追踪？
常见评审漏洞：许多故障注入方案只覆盖了网络延迟和进程 Kill 两类常见故障，忽略了配置篡改、磁盘 IO 抖动、依赖服务限流等“软故障”。这些软故障在微服务架构中往往比硬件故障更频繁出现，是基线核验中必须覆盖的盲区。