2. 验证环境基线核验的概念
2.1 什么是环境基线
在混沌工程与平台工程的交叉领域中，环境基线是指被测系统在稳定、无故障注入状态下，一组可量化的、可复现的运行时特征集合。它定义了系统在“正常”工况下的行为边界，是后续所有混沌实验的参照坐标系。
环境基线通常包含以下维度：
| 维度 | 典型指标 | 采集方式 |
|---|---|---|
| 性能基线 | P99 延迟、吞吐量、错误率 | APM / 可观测性平台 |
| 资源基线 | CPU 使用率、内存占用、磁盘 IOPS | Node Exporter / cAdvisor |
| 拓扑基线 | 服务依赖图、调用链深度、连接数 | Service Mesh / 分布式追踪 |
| 配置基线 | Pod 副本数、HPA 策略、限流阈值 | Kubernetes API / IaC 仓库 |
| 日志基线 | 日志速率、异常日志占比、关键错误码频率 | Loki / Elasticsearch |
实践要点：环境基线不是一次性快照，而是持续更新的动态基准。平台工程团队应通过 CI/CD 流水线在每次部署后自动触发基线采集，确保基线始终反映当前版本的真实状态。
2.2 基线核验在混沌工程中的定位
基线核验处于混沌实验流程的前置检查阶段，是连接“环境就绪”与“实验执行”的关键质量门禁。其核心定位可概括为：
- 参照系建立：在注入故障前，确认系统处于已知的、可接受的稳定状态，为实验提供“控制组”数据。
- 环境一致性验证：确保实验环境与生产环境或预发布环境在关键维度上保持基线一致，避免因环境差异导致实验结论失真。
- 实验有效性前提：若基线核验失败（如延迟已超标、错误率过高），则当前环境不适合执行混沌实验，需先修复环境问题。
2.3 基线核验与常规测试的区别
基线核验在目的、范围、执行方式和判定标准上，与传统的功能测试、性能测试、冒烟测试存在本质差异。下表从多个维度进行对比：
| 对比维度 | 常规测试 | 基线核验 |
|---|---|---|
| 核心目的 | 验证功能正确性、发现缺陷 | 确认环境处于已知稳定状态，建立实验参照 |
| 测试对象 | 业务逻辑、接口、UI | 运行时特征、资源水位、拓扑结构 |
| 执行时机 | 开发阶段、发布前、回归周期 | 每次混沌实验前、环境变更后、部署后 |
| 判定标准 | 通过/失败（功能正确性） | 在基线阈值范围内/超出基线阈值 |
| 失败处理 | 记录缺陷，修复后重新测试 | 阻止实验执行，触发环境修复流程 |
| 数据依赖 | 测试用例、预期结果 | 历史基线数据、动态阈值模型 |
| 自动化程度 | 高（CI/CD 流水线集成） | 高（需与可观测性平台联动） |
核心差异总结：常规测试回答“功能对不对”，基线核验回答“环境稳不稳”。在混沌工程实践中，环境不稳时执行实验，得到的结论既无法归因于故障注入，也无法指导生产改进——这是平台工程团队必须严格区分的根本原因。
2.4 基线核验的典型执行流程
在平台工程实践中，基线核验通常以自动化流水线的方式执行，包含以下步骤：
- 基线数据加载：从可观测性平台或基线仓库中拉取当前环境的最新基线阈值。
- 实时指标采集：通过 Prometheus / Datadog / CloudWatch 等工具采集当前环境的运行时指标。
- 阈值比对：将实时指标与基线阈值进行逐项比对，计算偏差率。
- 核验判定：若所有指标均在基线阈值范围内，则判定为“通过”；否则为“失败”。
- 结果输出：生成核验报告，包含通过/失败状态、偏差明细、建议操作。
常见陷阱：基线阈值设置过宽会导致核验失去意义（环境已劣化但未被检出）；阈值设置过窄则会导致频繁误报，降低团队对核验结果的信任。建议采用“动态基线 + 静态硬阈值”的双层策略，动态基线基于历史数据自动调整，静态硬阈值用于兜底安全边界。