为未确认的告警配置自动升级

概述

告警系统默认第一位值班人员会确认，升级机制用于处理未确认的情况。这个假设常常静默失效：手机静音、webhook 指向已下线的集成、通知被淹没在繁忙频道中，从监控侧看都毫无区别。解决办法是带可度量计时的两级策略：主值班先收到呼叫，五分钟未确认则通知备值班，十五分钟仍未确认则通知负责人。每一级都必须实际测试，而不只是完成配置。

步骤

1. 按严重级别路由，并为严重告警设置较短的重复间隔：

route:
  receiver: chat
  group_by: [alertname, service]
  group_wait: 30s
  group_interval: 5m
  repeat_interval: 4h
  routes:
    - matchers:
        - severity="critical"
      receiver: pager
      repeat_interval: 15m
receivers:
  - name: chat
    webhook_configs:
      - url: https://chat.example.com/hooks/alerts
  - name: pager
    webhook_configs:
      - url: https://events.pagerduty.com/v2/enqueue
        send_resolved: true

2. 在告警平台配置升级策略：主值班立即、备值班 5 分钟、负责人 15 分钟。

3. 维护时使用带范围的静默，而不是关闭频道：

amtool silence add alertname=~"DiskPressure.*" \
  --duration=2h --comment="node pool upgrade"

4. 事故后复盘告警时序，找出无人看到的呼叫：

amtool alert query --alertmanager.url=http://alertmanager:9093

验证

严重告警应立即触发呼叫，并在未确认时按 15 分钟间隔重复；模拟不确认后，备值班应在 5 分钟内收到通知，负责人应在 15 分钟内收到。静默应显示操作者、匹配规则与到期时间，并在到期后自动恢复通知。amtool alert query 应能看到告警的触发与当前状态，用于判断首次通知是否被确认。

注意事项

• 升级机制无法修复损坏的呼叫集成，必须用死信告警监控通知链路本身。
• 分组过粗会把多个服务的告警打包成一条，掩盖真正可处理的那一条。
• 重复间隔过短会造成告警疲劳，最终导致频道被静默。
• 告警平台的值班表与 Alertmanager 路由必须一致，否则会通知到错误的人。
• 静默应带明确原因与到期时间，长期续期的静默说明告警规则本身有问题。