2. 基线核验概念：什么是基线、为什么需要基线核验、基线核验在混沌工程中的角色、基线漂移的危害
2.1 什么是基线
在混沌工程与系统可靠性领域，基线（Baseline） 是指系统在正常、无故障运行状态下的一组可量化的性能指标与行为特征集合。它代表了系统在“健康”状态下的标准表现，是后续所有对比与判断的参照原点。
基线通常涵盖以下维度：
| 维度 | 典型指标 | 采集方式 |
|---|---|---|
| 性能 | P99 延迟、吞吐量（RPS/QPS）、CPU 使用率、内存占用 | APM 工具、Prometheus、Grafana |
| 可用性 | 请求成功率、错误率（5xx/4xx）、健康检查通过率 | 负载均衡日志、SLI 采集 |
| 业务 | 订单转化率、支付成功率、用户登录成功率 | 业务埋点、数据仓库 |
| 资源 | 磁盘 I/O 延迟、网络带宽使用率、连接池水位 | Node Exporter、cAdvisor |
| 依赖 | 下游服务响应时间、缓存命中率、数据库连接数 | 分布式追踪（Jaeger/Zipkin） |
实践要点：基线不是一次性的静态快照。随着系统版本迭代、流量模型变化、基础设施调整，基线需要定期重新校准。建议在每次混沌实验前 24 小时内采集最新基线数据。
2.2 为什么需要基线核验
基线核验（Baseline Verification）是在执行混沌实验之前，确认当前系统状态与已记录的基线一致的过程。其必要性体现在以下三个层面：
- 消除噪声干扰：如果系统在实验前已经处于亚健康状态（如内存泄漏早期、慢连接积累），实验产生的异常将与既有问题叠加，导致无法判断故障的真实影响。
- 确保实验有效性：只有确认系统处于基线状态，实验注入的故障才能被准确归因。否则，实验结论将失去可信度。
- 自动化决策前提：在自助服务场景中，基线核验是实验流程的“门禁”环节——核验不通过则自动中止实验，避免在异常系统上叠加故障造成雪崩。
核心原则：“没有基线，就没有混沌实验。” 基线核验是混沌工程实验流程中不可跳过的前置步骤。
2.3 基线核验在混沌工程中的角色
在混沌工程的完整实验生命周期中，基线核验处于承上启下的关键位置。下图展示了基线核验在实验流程中的具体角色：
基线核验在混沌工程中承担以下具体角色：
- 安全门禁：在实验开始前拦截异常状态，防止在已受损系统上叠加故障。
- 质量闸门：确保实验结论的归因清晰——实验前后的差异完全由注入故障引起。
- 自动化编排节点：在自助服务流程中，基线核验是自动化流水线的决策点，核验结果驱动后续流程分支。
- 漂移检测器：长期运行中，基线核验数据本身可用于发现系统性能的渐进式退化。
2.4 基线漂移的危害
基线漂移（Baseline Drift） 是指系统的正常状态指标随时间推移发生缓慢、渐进式的偏离，而团队未及时更新基线记录的现象。基线漂移是混沌工程实践中极易被忽视但危害极大的问题。
基线漂移的主要成因：
| 成因 | 典型场景 | 检测难度 |
|---|---|---|
| 版本迭代 | 新功能引入额外计算开销，P99 延迟从 50ms 升至 80ms | 低（可通过版本对比发现） |
| 数据增长 | 数据库表从 100 万行增长到 1 亿行，查询延迟持续上升 | 中（需要长期趋势分析） |
| 基础设施老化 | 磁盘 IOPS 因硬件磨损逐年下降，响应时间增加 15% | 高（变化缓慢，容易被忽略） |
| 配置变更 | 连接池参数调整后，资源利用率基线发生偏移 | 中（需关联变更记录） |
| 流量模型变化 | 用户行为从读多写少变为写多读少，缓存命中率下降 | 高（需要业务语义理解） |
基线漂移带来的具体危害：
⚠️ 危害一：实验结论失真
当基线发生漂移而未更新时，混沌实验会将漂移后的状态误认为“正常”。例如：系统 P99 延迟已从 50ms 漂移到 120ms，实验注入故障后延迟升至 200ms，团队可能误判为“故障仅造成 80ms 影响”，而实际影响是 150ms。这种误差会直接导致可靠性决策错误。
当基线发生漂移而未更新时，混沌实验会将漂移后的状态误认为“正常”。例如：系统 P99 延迟已从 50ms 漂移到 120ms，实验注入故障后延迟升至 200ms，团队可能误判为“故障仅造成 80ms 影响”，而实际影响是 150ms。这种误差会直接导致可靠性决策错误。
⚠️ 危害二：假阴性误报
基线漂移可能导致核验环节频繁失败（当前状态与旧基线不匹配），自助服务流程被反复中止，团队产生“狼来了”效应，最终可能绕过核验步骤，使整个混沌工程流程形同虚设。
基线漂移可能导致核验环节频繁失败（当前状态与旧基线不匹配），自助服务流程被反复中止，团队产生“狼来了”效应，最终可能绕过核验步骤，使整个混沌工程流程形同虚设。
⚠️ 危害三：掩盖渐进式退化
如果基线长期不更新，团队会逐渐适应退化后的性能指标，将“慢但稳定”的状态视为正常。当真正的故障发生时，系统可能已经处于临界状态，毫无缓冲余地。
如果基线长期不更新，团队会逐渐适应退化后的性能指标，将“慢但稳定”的状态视为正常。当真正的故障发生时，系统可能已经处于临界状态，毫无缓冲余地。
基线漂移的应对策略：
- 自动基线更新：设置滑动窗口（如过去 7 天或 30 天）自动计算动态基线，而非依赖固定阈值。
- 漂移告警：当当前指标与基线偏差超过 2σ（标准差）时触发告警，提示团队评估是否需要更新基线。
- 版本关联：每次发布新版本后，自动触发基线重新采集，确保基线始终与当前系统版本对齐。
- 定期审计：每月或每季度人工审查基线数据，确认指标变化是否在预期范围内。
自动化实践：在自助服务平台的基线核验模块中，建议实现“基线健康度评分”——综合多个维度的漂移程度给出 0-100 分，低于 80 分时自动触发基线重采集流程，确保核验环节始终基于最新基线运行。