基线核验概念
在混沌工程实践中，系统基线是衡量系统健康状态的基准参照系。没有基线，混沌实验就失去了判断“系统是否正常”的客观标准。本节将系统阐述基线的定义、必要性、在混沌工程中的定位以及分类体系。
什么是系统基线
系统基线（System Baseline）是指在正常生产负载下，系统各项关键指标所呈现的稳定统计分布。它不是单一数值，而是一个包含均值、P99、波动范围、趋势斜率的多维参考模型。
核心公式： 基线 = f(正常时段指标采样) → {均值, 标准差, 百分位阈值, 趋势斜率}
基线通常通过以下方式建立：
- 历史数据回放： 取过去7~30天同一时间窗口的指标数据
- 压力测试标定： 在预发环境模拟峰值流量，记录系统极限
- 持续学习更新： 随系统迭代和流量变化自动调整基线窗口
为什么需要基线核验
基线核验是混沌实验的前置条件和结果判官。没有基线核验，混沌工程将退化为“随机破坏+人工观察”的原始模式，无法形成可复现、可量化的工程体系。
| 场景 | 无基线核验 | 有基线核验 |
|---|---|---|
| 实验前 | 不知道系统当前是否健康，可能对已故障系统注入故障 | 确认系统处于基线范围内，实验起点一致 |
| 实验中 | 凭经验判断“好像变慢了”，无法量化影响 | 实时对比基线偏差，精确量化故障影响半径 |
| 实验后 | 人工检查日志，结论主观 | 自动比对恢复后指标是否回归基线，判定实验通过/失败 |
| 长期趋势 | 每次实验独立，无法积累系统韧性数据 | 基线漂移可追踪，系统退化可预警 |
实践要点： 基线核验应在混沌实验的 Pre-Check 和 Post-Check 阶段自动执行。Pre-Check 失败则中止实验并告警；Post-Check 失败则标记实验为“未通过”并触发回滚流程。
基线核验在混沌工程中的定位
在混沌工程实验生命周期中，基线核验处于承上启下的关键位置。它连接了稳态定义与实验验证两个核心环节。
基线指标的分类
基线指标按关注维度分为三大类：性能基线、可用性基线和业务基线。三类基线共同构成系统健康度的完整视图。
1. 性能基线
关注系统在正常负载下的响应速度和吞吐能力，是混沌实验中最敏感的指标。
- 延迟指标： P50、P90、P99、P999 响应时间（单位：ms）
- 吞吐指标： QPS（每秒查询数）、RPS（每秒请求数）、TPS（每秒事务数）
- 资源指标： CPU 使用率、内存使用率、磁盘 IOPS、网络带宽
- 连接指标： 活跃连接数、连接池等待时间、线程池活跃线程数
2. 可用性基线
关注系统的服务连续性和错误容忍度，直接关联 SLA/SLO 承诺。
- 成功率指标： 请求成功率（200/5xx 比例）、健康检查通过率
- 错误指标： 错误率（5xx/4xx 占比）、超时率、熔断触发次数
- 可用性指标： 服务可用时间百分比（SLA 99.9%/99.99%）、MTBF（平均无故障时间）
- 容错指标： 降级触发阈值、限流触发次数、重试成功率
3. 业务基线
关注用户感知和业务价值，是混沌实验的最终评判标准。
- 转化指标： 下单转化率、支付成功率、注册完成率
- 流程指标： 核心业务流程完成时间、购物车加购成功率
- 数据指标： 数据一致性校验通过率、消息队列积压量、数据库主从延迟
- 体验指标： 首屏加载时间、页面白屏率、用户操作响应时间
| 基线类别 | 典型指标 | 混沌实验关注点 | 核验频率 |
|---|---|---|---|
| 性能基线 | P99延迟、QPS、CPU使用率 | 故障注入后延迟是否超出P99阈值 | 每次实验前后 |
| 可用性基线 | 请求成功率、错误率、SLA达标率 | 故障期间是否触发熔断/降级，恢复后错误率是否回归 | 每次实验前后 + 持续监控 |
| 业务基线 | 转化率、订单量、核心流程完成率 | 故障是否影响用户核心操作，业务指标是否偏离统计区间 | 每次实验前后 + 每日趋势校验 |
重要提醒： 三类基线必须联合使用，不能只关注性能而忽略业务。例如：P99延迟正常但转化率下降，说明系统可能存在逻辑错误而非性能瓶颈。混沌实验的“通过”标准应同时满足三类基线的回归要求。
基线核验的工程落地要点
在实际 GameDay 编排中，基线核验需要工具化、自动化。以下是推荐的落地实践：
- 基线存储： 使用时序数据库（如 Prometheus、InfluxDB）存储历史基线，支持按时间窗口查询
- 核验脚本： 编写可复用的基线核验函数，输入为当前指标快照，输出为通过/失败及偏差详情
- 阈值策略： 采用动态阈值（如 3-sigma、移动平均）而非固定阈值，适应系统正常波动
- 告警联动： 基线核验失败时自动触发告警，并阻断后续混沌实验流程
- 基线漂移监控： 定期（如每周）对比基线变化趋势，发现系统退化或容量瓶颈
GameDay 实战建议： 在首次 GameDay 演练前，至少收集 7 天 的基线数据。对于新系统或大版本上线后的系统，建议先运行 1 周 的“基线采集模式”，不执行任何故障注入，仅建立基线模型。基线数据越充分，混沌实验的结论越可靠。