告警可执行性：每条告警都应有下一步动作

背景

半夜响起一条“CPU 高”告警，如果不知道用户是否受影响、应该做什么，它只会增加疲劳。告警必须对应可执行动作。

核心判断

1. 定义影响范围、持续时间和责任团队。
2. 优先使用错误、延迟与预算消耗等用户相关信号。
3. 绑定 runbook，说明排查入口、临时缓解、升级条件和恢复标准。

最小示例

下面保留核心逻辑；业务类型、调用入口和环境配置按项目补齐。

- alert: ApiHighErrorRate
  expr: error_rate > 0.02
  for: 10m
  labels: { severity: page }
  annotations: { runbook: "runbooks/api-5xx" }

边界与误区

示例的 error_rate 是需要预先定义的 recording rule，不是内置指标。低流量分母与缺失数据策略要明确，阈值不能直接照搬。

验证方式

回放真实或合成事故，核对触发、恢复与通知路由。让未参与编写的人只依据 runbook 操作一次，检查能否完成有效缓解。

小结

告警必须说明症状、影响、负责人、时间窗口和排查入口，避免只堆数量。