2. 基线核验概念：什么是基线、为什么需要基线核验、基线核验在混沌工程中的定位
2.1 什么是基线
在混沌工程中，基线（Baseline） 是指系统在正常、稳定、未注入任何故障状态下的一组可量化的运行指标与行为特征集合。它代表了系统在理想条件下的“健康快照”，是后续所有混沌实验的参照原点。
基线通常包含以下维度的数据：
| 维度 | 典型指标 | 采集方式 |
|---|---|---|
| 性能指标 | P99/P95/P50 延迟、吞吐量（TPS/QPS）、错误率 | APM 工具、Metrics 端点 |
| 资源指标 | CPU 使用率、内存占用、磁盘 IO、网络带宽 | 系统监控（Prometheus、CloudWatch） |
| 业务指标 | 订单成功率、支付完成率、用户登录成功率 | 业务埋点、日志聚合 |
| 依赖状态 | 上下游服务连通性、缓存命中率、数据库连接池水位 | 健康检查、链路追踪 |
| 日志与事件 | 错误日志频率、告警触发次数、异常堆栈出现率 | 日志平台、告警系统 |
实践要点：基线数据并非一次性采集即可永久使用。系统版本升级、配置变更、流量模型变化后，基线必须重新校准。建议每次混沌实验前 24 小时内采集一次最新基线。
2.2 为什么需要基线核验
基线核验（Baseline Verification）是对基线数据的有效性、完整性和可重复性进行确认的过程。其必要性体现在以下三个层面：
- 消除实验噪音：没有经过核验的基线可能包含异常波动（如发布中的抖动、定时任务干扰），若直接作为参照，会导致实验结论误判——将系统自身波动误认为故障影响。
- 建立可信参照：混沌工程的核心逻辑是“实验组 vs 对照组”。基线就是对照组。只有经过核验的基线，才能支撑“故障注入后的指标偏差是否显著”这一判断。
- 防止基线漂移：长时间运行的系统中，基线会因资源碎片、连接池老化、缓存预热状态变化而缓慢漂移。核验机制能及时发现这种漂移，避免实验基准失效。
核心公式：
实验结论可信度 = 基线核验通过率 × 实验执行准确率 × 观测数据完整率
实验结论可信度 = 基线核验通过率 × 实验执行准确率 × 观测数据完整率
2.3 基线核验在混沌工程中的定位
在混沌工程的完整生命周期中，基线核验处于实验设计阶段与实验执行阶段之间的关键衔接位置。它不是可选的“锦上添花”，而是决定实验结论是否有效的前置必要条件。
以下架构图展示了基线核验在混沌工程流程中的定位：
从流程图中可以清晰看到：基线核验（红色虚线框）位于基线采集之后、故障注入之前。它承担着“质量门禁”的角色——只有核验通过的基线才能进入后续实验环节；核验不通过则触发重采流程，直至基线满足要求。
2.4 基线核验的判定标准
基线核验通常从以下三个维度进行判定，任何一项不满足即视为核验失败：
| 核验维度 | 判定条件 | 常见失败原因 |
|---|---|---|
| 有效性 | 所有预设指标均成功采集，无缺失值、NaN 或超时 | 监控 Agent 离线、指标路径变更、采集超时 |
| 完整性 | 采集时长 ≥ 预设窗口（通常 10~30 分钟），数据点密度达标 | 采集窗口过短、采样间隔被篡改、数据存储截断 |
| 可重复性 | 连续 3 次采集的指标波动在 ±5% 以内（或业务自定义阈值） | 系统存在周期性抖动、定时任务干扰、流量不稳定 |
常见误区：不要将“基线采集”与“基线核验”混为一谈。采集只是获取原始数据，核验是对数据质量的验证。很多团队采集了基线就直接开始实验，跳过了核验步骤，导致实验结论被系统噪音污染。
2.5 基线核验的产出物
一次完整的基线核验应输出以下内容，作为实验报告的组成部分：
- 基线核验报告：包含核验时间、核验人、核验维度、通过/失败状态、失败原因说明。
- 基线快照：核验通过后的指标数据快照，标记版本号与时间戳，用于后续对比。
- 核验日志：记录核验过程中的异常事件、重试次数、阈值判定细节，便于审计与回溯。
以下示意图展示了基线核验的输入、处理与输出关系：
基线核验的产出物将作为实验报告的附件材料存档，用于后续的审计、复盘与合规检查。在正式的生产环境混沌实验中，基线核验报告是必须归档的交付物之一。