4. 实验设计原则：假设驱动实验、控制变量法、实验组与对照组设计、实验计划模板
混沌工程不是随机破坏，而是有组织的科学实验。本章聚焦实验设计的四大核心原则，确保每一次故障注入都能产出可量化的基线偏移与根因线索。
4.1 假设驱动实验：从“猜”到“证”
每次实验必须始于一个可证伪的稳态假设。假设描述系统在故障注入后应表现的行为边界，而非笼统的“系统应该稳定”。
| 假设类型 | 错误示例 | 正确示例 |
|---|---|---|
| 延迟假设 | “数据库不会变慢” | “当 user-db 注入 200ms 延迟时，用户登录接口 P99 延迟 ≤ 800ms” |
| 熔断假设 | “熔断器会工作” | “当 payment-svc 连续返回 5 个 5xx 后，熔断器在 3s 内打开，降级返回缓存结果” |
| 容量假设 | “CPU 高不会影响” | “当 order-svc CPU 飙至 90% 时，订单创建吞吐量不低于 200 tps” |
基线核验要点： 假设中的指标阈值必须来自实验前的基线采集（参见第 3 章），不能凭空设定。假设失败 = 发现稳态盲区。
4.2 控制变量法：隔离扰动，锁定变量
一次只改变一个变量，否则无法区分故障影响与噪声干扰。控制变量法在混沌工程中的落地规则：
- 单一故障注入：一次实验只注入一种故障类型（如只注入网络延迟，不混入 CPU 压力）。
- 固定负载：实验组与对照组的请求速率、并发数、数据分布保持一致。
- 环境同构：实验组和对照组运行在相同硬件规格、相同软件版本、相同网络拓扑的节点上。
- 时间窗口对齐：对照组与实验组在同一时间窗口内并行采集，避免日间/夜间流量差异。
常见陷阱： 在 Kubernetes 环境中，如果实验组 Pod 被调度到不同 NUMA 节点或共享了 CPU 核，即使没有注入故障，性能基线也可能偏差 5%-15%。务必使用
nodeSelector 或 topologySpreadConstraints 固定拓扑。
4.3 实验组与对照组设计：AB 对比，量化偏移
对照组提供“无故障”参考基线，实验组暴露“有故障”行为。两者对比得出稳态偏移量，这是根因定位的起点。
实践建议： 对照组和实验组应使用相同的监控采集端点（Prometheus target + metric relabel），避免因采集路径不同引入测量偏差。推荐在实验前先运行 5 分钟“空注入”验证两组基线一致（偏移 < 2%）。
4.4 实验计划模板：结构化执行清单
标准实验计划模板确保每次实验可复现、可审计、可回溯。以下模板可直接用于故障注入实验设计：
| 阶段 | 字段 | 填写示例 |
|---|---|---|
| 1. 假设 | 稳态假设 | 当 user-svc 注入 500ms 延迟时，登录接口 P99 ≤ 1.2s，错误率 ≤ 0.1% |
| 实验目标 | 验证超时重试 + 熔断降级是否按预期生效 | |
| 风险等级 | L2（影响范围 ≤ 1 个非核心服务） | |
| 2. 环境 | 实验组标识 | staging-cluster / namespace: chaos-exp / pod: user-svc-v2-abc |
| 对照组标识 | staging-cluster / namespace: chaos-exp / pod: user-svc-v2-xyz | |
| 负载配置 | 100 req/s, 1:1 读写比, 数据量 10k 用户 | |
| 3. 注入 | 故障类型 | HTTP 延迟注入（500ms, jitter ±50ms） |
| 注入范围 | user-svc → user-db 的出站连接（端口 3306） | |
| 持续时间 | 180s（含 30s 预热 + 120s 稳态 + 30s 恢复） | |
| 4. 观测 | 关键指标 | P99/P50 延迟、错误率、吞吐量、熔断器状态、CPU/内存 |
| 观测工具 | Prometheus (15s scrape) + Grafana dashboard + 链路追踪 (Jaeger) | |
| 5. 判定 | 通过标准 | 实验组 P99 ≤ 1.2s 且错误率 ≤ 0.1% |
| 回滚条件 | 错误率 > 1% 或 P99 > 3s 持续 30s 立即停止注入 |
4.5 实验计划模板的完整执行流程
将上述模板转化为可操作的流水线步骤，确保实验从设计到复盘闭环：
- 假设编写：基于基线数据写出可量化的稳态假设，填入模板阶段 1。
- 环境准备：使用
kubectl label或 Terraform 标记实验组/对照组资源，确保拓扑固定。 - 基线快照：在注入前采集 60s 对照组与实验组的联合基线，确认两组一致。
- 故障注入：使用 Chaos Mesh / Litmus 执行注入，同时启动观测采集。
- 实时判定：每 15s 检查一次通过标准与回滚条件，触发回滚时自动停止注入。
- 偏移分析：计算实验组 vs 对照组的指标偏移量，标记超出假设边界的指标。
- 根因追溯：对偏移量最大的指标，结合链路追踪和日志进行根因定位。
- 实验报告：输出假设验证结果、偏移量热力图、根因结论与改进项。
基线核验关键动作： 步骤 3 的基线快照必须包含与实验组完全相同的指标集和标签维度。如果基线采集遗漏了
istio_requests_total{response_code=~"5.*"}，实验后无法判断错误率上升是故障导致还是基线本身就有波动。
4.6 常见设计反模式与避坑
| 反模式 | 问题 | 正确做法 |
|---|---|---|
| 假设模糊 | “系统应该稳定”无法量化验证 | 写出具体指标阈值，如 P99 ≤ 500ms |
| 多变量同时注入 | 无法区分延迟 vs 丢包的影响 | 一次只注入一种故障类型 |
| 对照组与实验组环境不同 | 基线偏差掩盖真实故障影响 | 使用 nodeSelector / topologySpread 固定拓扑 |
| 无回滚条件 | 故障扩散后无法快速止血 | 设定硬性回滚阈值，自动化执行 |
| 忽略预热期 | JIT 编译、连接池初始化导致数据失真 | 注入前运行 30-60s 预热流量 |