3. 基线核验定义
在混沌工程体系中，基线（Baseline）与核验（Validation）是故障注入前必须完成的两项前置工作。基线定义了系统在正常状态下的行为特征与性能指标，核验则确保这些特征可被观测、可被度量、可被复现。二者共同构成故障注入实验的“参照系”，是判断实验是否通过的根本依据。
3.1 基线（Baseline）在混沌工程中的含义
基线是系统在无故障注入、无异常负载、无配置变更条件下，通过持续观测所获得的稳定运行状态快照。它并非单次采样，而是经过统计收敛后的“正常区间”。
| 维度 | 基线内容 | 典型指标示例 |
|---|---|---|
| 性能 | 请求延迟、吞吐量、错误率 | P99 延迟 ≤ 200ms，QPS ≥ 5000 |
| 可用性 | 服务健康状态、熔断/限流触发阈值 | 健康检查通过率 100% |
| 资源 | CPU、内存、磁盘、网络带宽使用率 | CPU 使用率 ≤ 60%，内存 ≤ 70% |
| 依赖 | 下游服务响应、中间件连接池水位 | Redis 连接数 ≤ 80% 上限 |
| 业务 | 核心业务流程完成率、数据一致性 | 订单创建成功率 ≥ 99.9% |
基线采集原则：基线数据应在业务低峰期连续采集至少 7 天，剔除异常波动后取 P50/P95/P99 作为参考区间。单次采样不能作为基线。
3.2 核验（Validation）的目的
核验是对基线数据的有效性、完整性、可观测性进行确认的过程。其核心目的包括：
- 确认观测能力就绪：确保监控系统、日志系统、链路追踪系统能够正确采集基线指标，不存在数据断点或采集盲区。
- 确认指标阈值合理：验证基线阈值是否覆盖了系统关键行为，避免因阈值过宽导致故障注入后“假通过”。
- 确认实验可复现：确保在相同条件下重复执行基线采集，结果波动在可接受范围内（通常 ≤ 5%）。
- 确认故障注入影响可量化：只有基线清晰，才能将故障注入后的指标偏移量归因于注入本身，而非系统自然抖动。
常见陷阱：基线核验不充分时，故障注入后出现的指标异常可能被误判为“实验通过”，实际是基线本身已存在未被发现的性能瓶颈或监控盲区。
3.3 基线核验与故障注入的关系
基线核验与故障注入并非先后顺序的线性关系，而是闭环迭代的依赖关系。下图展示了二者在 GameDay 自动化流程中的交互逻辑：
上图展示了四个核心环节的闭环流程：
- 基线采集：在无故障环境下持续采集多维度指标，形成稳定参考区间。
- 基线核验：确认基线数据有效、观测能力完备、阈值合理。核验不通过则返回修复观测能力。
- 故障注入：在核验通过后，按实验设计注入指定故障类型与强度。
- 结果对比：将故障注入后的指标与基线进行对比，判断是否在预期范围内。
基线核验与故障注入的依赖关系可进一步归纳为以下对比：
| 对比维度 | 基线核验 | 故障注入 |
|---|---|---|
| 执行时机 | 故障注入之前，且每次实验前必须重新核验 | 基线核验通过后立即执行 |
| 目标 | 确认“正常状态”可观测、可度量、可复现 | 验证系统在异常条件下的行为是否符合预期 |
| 失败后果 | 实验无法开始，需修复观测能力 | 实验失败，需分析根因并修复系统 |
| 数据用途 | 作为故障注入后的对比参照 | 产生新的指标数据与基线对比 |
| 自动化程度 | 可完全自动化，通过断言脚本核验 | 可完全自动化，通过编排引擎执行 |
关键结论：没有经过核验的基线，故障注入实验的结果将失去参照意义。基线核验是混沌工程实验的“准入条件”，也是实验结论可信度的根本保障。