SLO 违约基础：指标类型、阈值设定与检测机制
在 Serverless 平台控制面中，SLO（Service Level Objective）是衡量组件健康状态的核心契约。当组件行为偏离 SLO 时，系统需要快速感知并触发 Leader 选举等自愈动作。本节将系统梳理 SLO 的三大指标类型、阈值设定原则以及违约检测机制，为后续选举处置奠定基础。
2.1 SLO 指标类型
控制面组件的 SLO 通常围绕三个核心维度定义：延迟、可用性和错误率。每个维度对应不同的用户感知和系统行为。
| 指标类型 | 定义 | 典型度量方式 | 控制面示例 |
|---|---|---|---|
| 延迟 | 请求从发出到收到响应的时间间隔 | P50 / P95 / P99 分位延迟 | 函数调度请求 P99 ≤ 200ms |
| 可用性 | 服务在给定时间窗口内正常响应的比例 | 成功请求数 / 总请求数 × 100% | 控制面 API 月度可用性 ≥ 99.99% |
| 错误率 | 返回错误状态码的请求占总请求的比例 | 5xx 错误数 / 总请求数 × 100% | 组件内部 RPC 错误率 ≤ 0.1% |
关键认知：三个指标并非孤立存在。高延迟往往伴随错误率上升，而可用性下降可能是延迟超时累积的结果。SLO 设计需要三者联动监控，而非单一指标驱动。
2.2 违约阈值设定原则
阈值设定是 SLO 工程中最具挑战的环节。阈值过松会掩盖真实故障，过紧则导致频繁误触发，引发不必要的 Leader 选举震荡。以下为经过生产验证的四大原则：
- 基于历史基线，而非静态数值
使用过去 7~30 天的 P95/P99 延迟作为动态基线，阈值设定为基线的 1.5~2 倍。避免使用固定值（如 200ms），因为不同时段、不同地域的延迟天然存在波动。 - 多窗口滑动检测
单一时间窗口容易受瞬时毛刺干扰。建议采用 短窗口（30s）+ 长窗口（5min） 组合：短窗口快速感知，长窗口确认趋势，两者同时违约才触发选举。 - 错误预算消耗速率
将 SLO 转化为错误预算（Error Budget），监控预算消耗速率。当消耗速率超过预期线性消耗的 150% 时，视为违约预警。这比单纯看错误率值更敏感。 - 分层阈值，避免一刀切
不同组件、不同 API 路径应有差异化阈值。例如：
- 控制面 API 网关：P99 延迟 ≤ 100ms
- 函数调度器：P99 延迟 ≤ 500ms
- 状态持久化组件：P99 延迟 ≤ 50ms
实践建议：在初始上线阶段，阈值可适当放宽（如基线 2.5 倍），运行稳定后逐步收紧至 1.5 倍。每次调整需记录变更原因，并观察至少一个完整业务周期。
2.3 违约检测机制
检测机制决定了从 SLO 违约发生到系统感知的时间差。在控制面场景中，检测延迟每增加 1 秒，可能意味着数千个函数调用受到影响。以下是三种主流检测机制及其对比：
| 检测机制 | 原理 | 检测延迟 | 适用场景 |
|---|---|---|---|
| 拉取式（Pull） | 监控系统定期轮询组件暴露的 /metrics 端点 | 10s ~ 60s | 非关键路径、低敏感度组件 |
| 推送式（Push） | 组件主动将指标推送到聚合器（如 StatsD、Prometheus Pushgateway） | 1s ~ 5s | 高吞吐、需要快速感知的组件 |
| 事件驱动式（Event-Driven） | 组件在关键路径上埋点，通过消息队列实时上报异常事件 | < 1s | Leader 选举触发、熔断决策等高敏感场景 |
注意：事件驱动式虽然延迟最低，但会引入额外的消息队列依赖和资源开销。建议仅在 Leader 选举、熔断等关键决策路径上使用，日常监控仍以推送式为主。
2.4 检测机制选型对比
在实际控制面架构中，三种检测机制往往混合使用。以下从资源开销、运维复杂度、检测精度三个维度进行对比，帮助架构师做出合理选择：
| 维度 | 拉取式 | 推送式 | 事件驱动式 |
|---|---|---|---|
| 资源开销 | 低（仅需 HTTP 端点） | 中（需聚合器 + 网络带宽） | 高（消息队列 + 消费者） |
| 运维复杂度 | 低（Prometheus 原生支持） | 中（需维护 Pushgateway 或 StatsD） | 高（需管理 Topic、消费者组） |
| 检测精度 | 低（受轮询间隔限制） | 中（秒级延迟） | 高（毫秒级延迟） |
| 推荐场景 | 非关键组件、大盘监控 | 核心组件日常 SLO 监控 | Leader 选举、熔断决策 |
架构建议：在 Serverless 控制面中，建议采用 推送式为主 + 事件驱动式为辅 的混合方案。推送式覆盖 90% 的 SLO 监控场景，事件驱动式仅用于 Leader 选举、熔断等需要亚秒级响应的关键路径。拉取式可作为兜底方案，用于非关键组件的健康检查。
2.5 违约检测的常见陷阱
- 陷阱一：单一窗口误判
仅使用 1 分钟窗口检测，容易因 GC 暂停、网络抖动等瞬时事件触发误报。解决方案：采用多窗口 AND 逻辑，短窗口 + 长窗口同时违约才判定。 - 陷阱二：指标采集盲区
组件自身故障导致指标无法上报，监控系统可能误判为“一切正常”。解决方案：引入心跳机制（Heartbeat），心跳超时直接视为违约。 - 陷阱三：阈值滞后性
使用固定阈值应对流量突增，导致 SLO 违约检测延迟。解决方案：采用自适应阈值，基于过去 1 小时的 P99 延迟动态调整。 - 陷阱四：忽略冷启动影响
Serverless 控制面组件在冷启动阶段延迟天然偏高，不应触发选举。解决方案：组件启动后设置 30~60 秒的“预热期”，期间不参与 SLO 违约判定。
最佳实践：在控制面中为每个组件配置
slo_grace_period_seconds 参数，用于定义组件启动后的预热时间。同时，在违约判定逻辑中加入 min_data_points 检查，确保窗口内有足够的数据点后再做决策。