2. 基线核验概念：系统基线、核验必要性与混沌工程定位
基线核验是混沌工程实验的“校准锚点”。在注入任何故障之前，必须明确回答三个问题：系统正常时是什么状态？、如何证明当前状态是正常的？、故障注入后的偏差是否在可接受范围内？。本章从概念、必要性、定位三个层次展开。
2.1 什么是系统基线
系统基线（System Baseline）是指在无故障、正常负载、标准配置下，系统各项可观测指标与行为特征的集合。它既是混沌实验的参照系，也是故障排查的“健康标准”。
| 维度 | 基线内容示例 | 采集方式 |
|---|---|---|
| 性能指标 | P99 延迟 ≤ 200ms，吞吐量 ≥ 5000 req/s | APM 工具（如 Prometheus + Grafana） |
| 资源利用率 | CPU ≤ 70%，内存 ≤ 80%，磁盘 IO ≤ 60% | 系统监控（如 node_exporter） |
| 错误率 | HTTP 5xx 错误率 ≤ 0.1% | 日志聚合（如 ELK） |
| 依赖健康 | 下游服务超时率 ≤ 0.5%，数据库连接池空闲连接 ≥ 10 | 分布式追踪（如 Jaeger） |
| 业务指标 | 订单创建成功率 ≥ 99.9%，支付回调延迟 ≤ 1s | 业务埋点 + 实时数仓 |
实践要点：基线不是静态的。每次发布新版本、变更配置、扩缩容后，都应重新采集基线数据。建议将基线采集自动化，作为 CI/CD 流水线中的一个环节。
2.2 为什么需要基线核验
基线核验（Baseline Verification）是对系统基线进行确认、校准与持续验证的过程。其必要性体现在以下四个层面：
- 消除“假阳性”与“假阴性”：没有基线，无法区分故障注入导致的异常与系统本身存在的波动。例如，某服务 P99 延迟在无故障时已达 500ms，注入故障后变为 600ms，若基线未核验，可能误判为故障影响严重。
- 提供故障排查的“健康锚点”：当故障注入后出现异常，排查人员需要快速对比“当前状态”与“基线状态”，定位偏差来源。基线核验确保了锚点的准确性。
- 量化故障影响范围：通过基线核验，可以定义“故障影响度”指标，如延迟偏移率、错误率增量、吞吐量下降百分比等，使混沌实验结果可度量、可比较。
- 满足合规与审计要求：在金融、医疗等强监管行业，混沌实验需要提供“实验前系统正常”的客观证据。基线核验报告是合规审计的关键输入。
关键公式：故障影响度 = (实验期指标值 - 基线指标值) / 基线指标值 × 100%。基线核验的准确性直接决定了该公式的可信度。
2.3 基线核验在混沌工程中的定位与价值
在混沌工程实验流程中，基线核验处于“实验设计”与“故障注入”之间的关键衔接环节。其定位可用下图表示：
常见误区：不要将“基线采集”等同于“基线核验”。采集只是获取数据，核验还包括数据校验、异常值剔除、与历史基线对比、确认系统处于稳态等步骤。缺少核验环节的基线，可能包含噪声甚至错误数据，导致整个混沌实验结论不可信。
2.4 基线核验的典型输出
一次完整的基线核验应产出以下内容，作为混沌实验报告的组成部分：
- 基线指标快照：包含所有关键指标在核验时间窗口内的均值、P50、P95、P99、最大值、最小值。
- 基线健康声明：明确声明“系统在核验期间处于健康状态”，并列出健康判断依据（如所有指标在阈值范围内）。
- 基线偏差记录：若发现指标偏离历史基线，需记录偏差值及初步原因分析（如发布变更、流量波动等）。
- 核验时间戳与操作人：确保基线核验过程可追溯。
自动化建议：使用工具（如 Chaos Mesh、LitmusChaos）的“基线检查”插件，或自建脚本定期执行基线核验，并将结果写入时序数据库。混沌实验触发时，自动拉取最近一次核验结果作为实验基线。