告警规则

定义基于用户可见症状而非内部噪声的告警规则，带清晰阈值和归属。

为什么

告警是契约：若它触发，一个人会被叫醒，且那人会放下手头事去调查。每个无用户影响就触发的告警破坏契约并训练工程师忽视 page，真实宕机就这样被漏 40 分钟。好告警规则基于症状（SLO 在燃烧）而非原因（CPU 高），因为症状直接映射用户痛苦而原因常是噪声。经验法则：若你无法为告警写 runbook，删掉它 — 无 runbook 的告警是每次浪费 20 分钟调查的 page。

何时使用

在你有 SLO 和 runbook 之后。绝不对你无法绑到用户影响或无法写 runbook 的指标告警。

如何做

1. 从 SLO 出发，非指标
   - "错误预算燃烧率 > 2x over 1h" → page（症状：用户在失败）
   - 非"CPU > 80%"（原因：可能没事，可能坏事，无用户信号）

2. 先写 runbook 再写告警
   - 若你无法为告警写"做 X，再 Y，再 Z"，说明你不懂它 → 别告警
   - Runbook 在稳定 URL；告警链接它

3. 阈值设在燃烧率上，非原始值
   - 快燃：2x over 1h → page（抓急性宕机）
   - 慢燃：1x over 6h → 工单（抓慢性退化不 page）
   - 这给你快检测和长窗口覆盖而不双重 page

4. 每个告警打归属团队 + 严重性标签
   - 路由到能修的团队，非通用队列
   - 严重性来自影响：SEV1（收入降）→ page；SEV3（退化）→ 工单

5. 月度测量并修剪告警噪声
   - "每值班班告警数" — 若 >5 page/班，你有疲劳
   - 每个无行动就触发的告警：删掉或转工单

示例

# Prometheus 告警规则 — SLO 燃烧率（基于症状）
groups:
  - name: checkout-slo
    rules:
      - alert: CheckoutSLOBurnRateFast
        expr: |
          (1 - (sum(rate(http_requests_total{service="checkout",status!~"5.."}[5m]))
               / sum(rate(http_requests_total{service="checkout"}[5m]))))
          / (1 - 0.999) > 2  # 燃烧 >2x 99.9% SLO
        for: 2m
        labels: { severity: page, team: payments, runbook: "https://rb/checkout-slo-burn" }
        annotations:
          summary: "checkout SLO 燃烧 >2x（用户在失败）"
          dashboard: "https://grafana/d/checkout"

# 坏（基于原因、无用户信号、会疲劳）：
#   - alert: HighCPU
#     expr: cpu_usage > 0.8
# Runbook：https://rb/checkout-slo-burn
#   1. 打开仪表盘链接
#   2. 按路由查错误分解 — 哪个端点在失败？
#   3. 若最近 30m 有新部署 → 回滚（runbook：rollback-checkout）
#   4. 否则 → 在服务图查下游依赖

常见问题

⚠对 CPU/内存 >80% 告警 — 高利用率常是健康的（你物有所值）；改对延迟/错误 SLO 燃烧告警。
⚠告警载荷无 runbook 链接 — 值班工程师花 15 分钟搞清告警含义才能调查。
⚠对瞬时值告警无 'for' 窗口 — 10 秒突增在凌晨 3 点 page 人处理自恢复打嗝；要求 'for: 2m' 最小。
⚠所有告警路由到通用 ops 队列 — 能修问题的团队从看不到，ops 队列变被忽视 page 的坟场。

最佳实践

✓对 SLO 燃烧率（症状）告警非资源利用率（原因）— 症状映射用户痛苦且少误报。
✓每个告警规则要求 runbook URL；代码审查拒绝无 runbook 的告警规则 — 无 runbook = 无告警。
✓用多窗口多燃烧率告警（快：2x/1h page，慢：1x/6h 工单）抓急性和慢性问题而不双重 page。
✓月度审查告警噪声：数每值班班 page 数，删或降级每个无用户可见行动就触发的告警。