告警与值班响应

值班响应主路径

  [ 告警触发 / 页面升级 ]
        │
        ▼
  ┌─────────────┐     认领：谁在处理、预计下次更新时间
  │  确认与分级  │──── 对照 SLO / 客户影响 / 是否在变更窗口内
  └─────────────┘
        │
        ▼
  ┌─────────────┐     Runbook：依赖检查、特征查询、近期发布与配置
  │  定位与缓解  │──── 缓解优先：限流、降级、扩容、回滚、开关
  └─────────────┘
        │
        ▼
  ┌─────────────┐     状态广播：内部频道 + 必要时外部状态页模板
  │  沟通与升级  │──── 超阈值或权限不足：二线 / 管理层 / 厂商
  └─────────────┘
        │
        ▼
  ┌─────────────┐     稳定后：解除告警、记录时间线、开事后项
  │ 恢复与复盘  │──── 与指标、日志、追踪交叉验证根因假设
  └─────────────┘

告警路由与降噪

路由决定「谁、在哪个渠道、以什么优先级」收到通知：按服务所有权、租户层级、环境（prod/stage）与客户合同分流；Pager 与聊天机器人应指向当前 on-call 轮值，而不是静态个人。

Prometheus 告警规则完整 YAML 示例：

# prometheus/alerts/payment-svc.yml
groups:
  - name: payment-svc-slo
    interval: 30s
    rules:
      # P1: SLO 违约 - 错误率高
      - alert: PaymentHighErrorRate
        expr: |
          sum(rate(http_requests_total{job="payment-svc",code=~"5.."}[5m]))
          / sum(rate(http_requests_total{job="payment-svc"}[5m]))
          > 0.01
        for: 5m
        labels:
          severity: "P1"
          team: "payments"
          slo: "availability"
        annotations:
          summary: "Payment API error rate {{ $value | humanizePercentage }} exceeds SLO"
          description: "Error rate has been above 1% for 5 minutes. Current: {{ $value | humanizePercentage }}"
          runbook_url: "https://wiki/runbooks/payment-svc/high-error-rate"
          dashboard_url: "https://grafana/d/payment-golden-signals"

      # P2: 延迟告警
      - alert: PaymentHighLatency
        expr: |
          histogram_quantile(0.99,
            sum(rate(http_request_duration_seconds_bucket{job="payment-svc"}[5m]))
            by (le)
          ) > 0.5
        for: 10m
        labels:
          severity: "P2"
          team: "payments"
        annotations:
          summary: "Payment p99 latency {{ $value | humanizeDuration }} exceeds 500ms"
          runbook_url: "https://wiki/runbooks/payment-svc/high-latency"

      # 基础设施告警（磁盘）
      - alert: DiskSpaceLow
        expr: |
          (node_filesystem_free_bytes{mountpoint="/"}
          / node_filesystem_size_bytes{mountpoint="/"}) < 0.15
        for: 5m
        labels:
          severity: "P2"
          team: "infra"
        annotations:
          summary: "Disk space below 15% on {{ $labels.instance }}"

Alertmanager 分级路由与降噪配置：

# alertmanager.yml
global:
  resolve_timeout: 5m

route:
  group_by: ['alertname', 'team']   # 按团队分组，相同告警合并
  group_wait: 30s                    # 等待 30s 以聚合同组告警
  group_interval: 5m                 # 同组告警每 5min 发送一次
  repeat_interval: 4h               # 持续告警每 4h 重复通知
  receiver: 'default-webhook'

  routes:
    # P0/P1 → PagerDuty 立即唤醒
    - match_re:
        severity: "P0|P1"
      receiver: 'pagerduty-critical'
      group_wait: 10s
      repeat_interval: 30m          # P0 每 30min 提醒一次

    # 支付团队 → 支付 slack 频道
    - match:
        team: payments
      receiver: 'slack-payments'
      continue: true                 # 同时继续匹配其他路由

    # 基础设施 → infra 团队
    - match:
        team: infra
      receiver: 'slack-infra'

# 抑制规则（降噪：上游故障时抑制下游告警）
inhibit_rules:
  - source_match:
      severity: P0
      team: infra
    target_match:
      team: payments          # 基础设施 P0 时，抑制支付团队的告警
    equal: ['env', 'region']

receivers:
  - name: 'pagerduty-critical'
    pagerduty_configs:
      - routing_key: '${PAGERDUTY_INTEGRATION_KEY}'
        description: '{{ .GroupLabels.alertname }}: {{ .CommonAnnotations.summary }}'
        severity: '{{ if eq .CommonLabels.severity "P0" }}critical{{ else }}error{{ end }}'

  - name: 'slack-payments'
    slack_configs:
      - api_url: '${SLACK_WEBHOOK_URL}'
        channel: '#oncall-payments'
        title: '[{{ .Status | toUpper }}] {{ .GroupLabels.alertname }}'
        text: '{{ range .Alerts }}{{ .Annotations.summary }}\n{{ .Annotations.runbook_url }}{{ end }}'

• 静默与维护：计划内变更用带起止时间与原因的静默窗口；禁止「永久静默」无工单跟踪。
• 升级阶梯：未认领 N 分钟、严重级别上调、或客户渠道已报障时，自动升到二线或电话。

SLO 与燃尽率

面向用户的 SLO（可用性、延迟、错误率）应驱动告警：不仅看瞬时阈值，还要看错误预算燃尽率——在短窗口内消耗预算过快，意味着若在长窗口末仍如此，将违约。

• 常见做法：多窗口（如 1h + 6h）燃尽率告警，兼顾突发与持续劣化；页面级告警写明对应 SLO 名称与剩余预算比例。
• Agent 写 SKILL 时要求标注：该告警对应的 SLI、SLO 目标、以及「触发时建议先看哪张图 / 哪条查询」。
• 非 SLO 类基础设施告警（磁盘、证书）仍须绑定业务上下文或服务树节点，便于路由到正确团队。

On-call 升级策略配置示例（PagerDuty / OpsGenie 等价配置）：

# PagerDuty 升级策略（等价的 OpsGenie escalation policy）
# 配置思路：YAML 描述，实际在 PagerDuty UI 或 Terraform 中配置

escalation_policy:
  name: "Payment Service On-call"
  num_loops: 2              # 未认领时循环 2 次后升级管理层

  rules:
    # Level 1: 第一响应人（立即通知）
    - escalation_delay_in_minutes: 0
      targets:
        - type: schedule
          id: "payment-oncall-schedule"  # 当前值班工程师

    # Level 2: 未在 15min 内认领 → 升级到 L2 专家
    - escalation_delay_in_minutes: 15
      targets:
        - type: user
          id: "payment-tech-lead"
        - type: schedule
          id: "payment-backup-schedule"

    # Level 3: 30min 后仍未解决 → 通知管理层
    - escalation_delay_in_minutes: 30
      targets:
        - type: user
          id: "engineering-manager"

# Alertmanager 对应配置（通过 repeat_interval 实现升级效果）
# 配合 PagerDuty 的 escalation_policy 使用

告警详情页（Alert page）

监控或事件系统中的告警详情页是 on-call 的第一块屏幕：应在同一视图内聚合判断所需信息，减少在多个标签间跳转。

• 标题与摘要：一句话说明「什么坏了、相对什么基线」；附告警规则名、标签（env、region、tenant）。
• 关联面板：对应 SLO/SLI 趋势、相关 dashboard、近 24h 部署与配置变更时间线、相似历史事件链接。
• Runbook 入口：内联或一键打开当前告警类型的操作步骤；预留「一键复制值班摘要」给聊天与工单。

Runbook 与升级

每条关键告警绑定 Runbook：前置检查（依赖服务、近期发布）、缓解动作（扩容、降级、切流）、回滚或开关位置，以及何时升级二线或管理层。

• 明确「单人可执行」与「必须拉人」的边界；升级条件写清（如：影响付费租户、数据面写入失败持续 > 5 分钟）。
• 事实记录：时间线、影响范围、已尝试操作与当前状态，便于交接与事后报告。

值班摘要一句生成

用于频道置顶、工单标题或状态页草稿：填写下方字段后生成一条可读的中文摘要，便于快速同步现状。