基线定义：系统稳态指标、业务基线、技术基线的概念与重要性

在混沌工程与 GameDay 演练中，基线（Baseline）是判断系统是否健康的“标尺”。没有基线，混沌实验就失去了对比依据，无法区分“系统正常波动”与“故障引发的异常”。本章将系统性地定义三类基线：系统稳态指标、业务基线、技术基线，并阐述它们在混沌基线验收中的核心作用。

1. 三类基线的概念与定位

三类基线分别从基础设施层、应用技术层、业务价值层三个维度定义系统的“正常状态”。它们共同构成混沌实验的验收标准。

2. 系统稳态指标：基础设施的“生命体征”

系统稳态指标描述的是底层基础设施在正常运行时的资源使用模式与健康状态。它们是混沌实验中最先被观测到的信号层。

• 资源饱和度：CPU 平均负载、内存使用率、磁盘空间占用率、网络带宽利用率。这些指标在故障注入后不应超过预设的安全阈值（例如 CPU 不超过 80%）。
• 服务进程状态：关键进程是否存活、容器重启次数、节点健康检查状态。稳态下重启次数应为 0 或极低。
• 网络健康度：节点间延迟、丢包率、TCP 连接数。网络抖动是混沌实验的常见注入对象，稳态指标用于区分“预期抖动”与“网络分区”。

3. 技术基线：应用性能的“黄金信号”

技术基线聚焦于应用层和中间件层的服务质量。它们是混沌实验中最敏感的指标，故障注入后通常最先出现波动。

• 延迟（Latency）：API 端点的 P50/P95/P99 响应时间。技术基线需定义“可接受的延迟退化幅度”，例如故障注入后 P99 延迟不超过基线的 2 倍。
• 错误率（Error Rate）：HTTP 5xx 错误率、业务异常率、超时率。稳态下错误率应接近 0%，混沌实验的验收标准通常设定为“错误率不超过 0.1%”。
• 吞吐量（Throughput）：每秒请求数（RPS）、每秒事务数（TPS）。故障注入可能导致吞吐量下降，技术基线需定义“最小可接受吞吐量”。
• 饱和度（Saturation）：数据库连接池使用率、线程池活跃线程数、消息队列堆积长度。这些指标反映系统是否接近瓶颈。

# 技术基线示例（YAML 格式）
baselines:
  api_gateway:
    p99_latency_ms: 200
    error_rate_percent: 0.05
    min_rps: 500
  database:
    connection_pool_usage_percent: 70
    query_p99_latency_ms: 50
  cache:
    hit_rate_percent: 95
    miss_latency_ms: 10

4. 业务基线：混沌实验的“最终判据”

业务基线直接关联用户体验和商业价值。无论基础设施多么稳定、技术指标多么漂亮，只要业务基线被破坏，混沌实验就应判定为失败。

• 核心交易链路：订单创建成功率、支付成功率、购物车加购成功率。这些是电商、金融等系统的生命线。
• 用户体验指标：首屏加载时间、页面完全渲染时间、关键操作（登录/搜索）的完成率。
• 业务流程完整性：异步任务（如发邮件、生成报表）的完成率、数据最终一致性延迟。

5. 三类基线的联动关系与验收流程

在混沌基线验收中，三类基线不是孤立的，而是形成一条完整的观测链。下面的 SVG 图展示了故障注入后指标的传导路径与验收决策逻辑。

6. 基线的重要性：为什么混沌实验离不开基线？

基线在混沌工程中扮演着不可替代的角色，其重要性体现在以下四个方面：

1. 提供对比基准：没有基线，实验后的指标就是“无源之水”。基线定义了“正常”的边界，让异常变得可量化。
2. 设定验收标准：混沌实验的通过/失败不能凭感觉。基线指标与阈值共同构成自动化的验收断言，避免人工主观判断。
3. 发现隐性退化：有些故障不会导致系统立即崩溃，而是让性能缓慢下降。基线可以帮助发现这种“渐进式劣化”，例如 P99 延迟从 100ms 逐渐上升到 150ms。
4. 支撑自动化回归：在 GameDay 演练中，基线数据可以集成到 CI/CD 流水线，实现混沌实验的自动化执行与结果判定，提升验收效率。

7. 基线与混沌实验的映射关系

不同类型的混沌实验需要关注不同的基线组合。下面的 SVG 图展示了常见实验场景与基线的对应关系。

8. 基线验收的常见陷阱与避坑指南