故障排查场景设计原则：场景设计的五大原则

混沌工程基线核验的核心在于构造真实、可控且安全的故障场景。场景设计必须遵循五大原则，确保实验既能暴露系统脆弱点，又不会对生产环境造成不可逆影响。以下逐一展开每个原则的定义、关键要求与常见反模式。

3.1 五大原则总览

五大原则构成一个相互制约的闭环：真实性保证实验价值，可控性保证实验安全，可观测性保证实验可分析，可复现性保证实验可验证，安全性保证实验底线。任何一条缺失都会导致实验失效或失控。

原则	核心问题	关键要求	反例
真实性	场景是否反映真实故障？	基于历史故障、生产指标、用户行为建模	模拟“CPU 100%”但实际从未发生
可控性	能否随时中止或回滚？	注入粒度可调、有熔断开关、有超时机制	直接 kill 进程且无守护进程恢复
可观测性	实验数据是否完整可追溯？	指标、日志、链路追踪全覆盖	只记录注入时间，无系统响应数据
可复现性	相同条件能否复现相同结果？	环境一致、参数固定、依赖版本锁定	依赖外部第三方服务状态
安全性	是否具备爆炸半径控制？	隔离环境、白名单、人工审批、自动熔断	直接在生产全链路注入延迟

3.2 真实性（Fidelity）

场景必须模拟真实世界中可能发生的故障，而非凭空构造的“完美故障”。真实性要求场景设计基于以下三类输入：

• 历史故障数据：从 P0/P1 事故中提取故障模式，如网络分区、磁盘 IO hang、依赖超时。
• 生产指标异常：根据延迟 P99 突增、错误率飙升、CPU throttling 等指标反推故障类型。
• 用户行为模型：模拟真实流量特征，包括读写比例、热点 Key、突发峰值。

3.3 可控性（Controllability）

实验必须在全生命周期内处于可管理状态。可控性包含三个维度：

维度	要求	实现方式
注入粒度	支持按实例、按接口、按比例逐步注入	配置化注入参数，如延迟 100ms → 500ms 步进
熔断机制	异常时自动停止注入并恢复	设置错误率阈值、延迟阈值、超时时间
回滚能力	一键恢复至实验前状态	记录变更快照，提供原子化回滚脚本

3.4 可观测性（Observability）

没有可观测性的混沌实验等于盲人摸象。场景设计时必须预先定义观测指标：

• 黄金信号：延迟、流量、错误、饱和度（USE 方法）。
• 依赖追踪：注入点上下游的调用链数据，包括超时、重试、熔断状态。
• 实验元数据：注入开始/结束时间、注入参数、目标实例列表、实验编号。

# 可观测性检查清单示例
实验前：
  - 确认目标服务的 Prometheus 指标已接入
  - 确认 Jaeger 链路采样率 ≥ 1%
  - 确认日志采集无延迟

实验中：
  - 实时监控注入点延迟 P50/P99
  - 实时监控依赖服务错误率
  - 记录每次注入的精确时间戳

实验后：
  - 导出实验期间所有指标时序数据
  - 导出关联的链路追踪 Span
  - 生成实验报告并归档

3.5 可复现性（Reproducibility）

同一场景在相同条件下应产生相同结果。可复现性依赖以下要素：

要素	说明	反例
环境一致性	使用相同版本的操作系统、内核参数、依赖库	两次实验分别使用 Ubuntu 20.04 和 22.04
参数固定	注入参数、流量模型、数据规模保持一致	第一次注入 200ms 延迟，第二次注入 500ms
依赖版本锁定	中间件、SDK、Sidecar 版本不变	Redis 客户端从 3.x 升级到 4.x 未通知
随机种子固定	涉及随机选择实例时使用固定种子	每次随机选择不同实例导致结果偏差

3.6 安全性（Safety）

安全性是混沌工程的底线，也是基线核验能否在生产环境执行的前提。安全性设计包含四个层次：

1. 爆炸半径控制：默认限制在单个可用区、单个实例组、非核心业务。
2. 白名单机制：仅允许在预定义的实例、服务、接口上执行实验。
3. 人工审批：高危场景（如全链路延迟、数据删除）必须经过 SRE 负责人审批。
4. 自动熔断：当错误率超过基线 2 倍或延迟超过 5 倍时，自动停止实验并恢复。

3.7 五大原则的权衡与落地

实际场景设计时，五大原则之间可能存在冲突。例如：

• 真实性 vs 安全性：最真实的故障往往最危险。解决方案是先在隔离环境验证，再逐步扩大爆炸半径。
• 可控性 vs 可复现性：精细的控制可能引入人为变量，影响复现。解决方案是使用自动化编排工具，减少人工干预。
• 可观测性 vs 性能开销：全量观测可能影响系统性能。解决方案是采样 + 关键路径全量追踪。