通知可靠性：维护静默、重复通知与外部心跳#

验证：未记录

适用版本: 未记录
验证范围: 尚未登记验证记录。

前置：SRE 企业订单闭环已运行，具备 curl、jq 和与 Alertmanager 同版本的 amtool。先在独立预生产栈执行；每次记录故障、通知、恢复时间。飞书等适配器要同时检查 HTTP 和业务响应，见飞书通知。

1. 维护静默必须限定范围、自动到期#

以下只静默独立本地栈的 OrdersBacklog；共享环境另加实际 environment、cluster、service 等匹配项，并检查这些标签确实存在。静默抑制通知，不阻止规则评估。

export AM_URL='http://127.0.0.1:9093'
amtool --alertmanager.url="$AM_URL" alert query alertname=OrdersBacklog
export SILENCE_ID=$(amtool --alertmanager.url="$AM_URL" silence add alertname=OrdersBacklog --duration=10m --author='preprod-operator' --comment='CHG-REPLACE: isolated worker maintenance; auto-expire in 10m')
amtool --alertmanager.url="$AM_URL" silence query

保存返回的 silence ID，核对匹配范围及到期时间；缺标签的匹配器可能导致范围错误，不使用 alertname=~.* 全局静默。

按订单闭环暂停 worker 并创建合成订单，等待积压规则进入 Firing。
检查 Alertmanager 告警中的 silencedBy 包含本次 ID，同时本地通知接收器没有新增该告警通知；先记录接收器已有记录，不能把历史消息当新通知。
保持故障至静默到期，等待分组周期后必须收到 firing；另外一次演练用下方命令提前撤销，确认未恢复的故障重新通知。

curl --fail --silent --show-error "$AM_URL/api/v2/alerts" | jq '[.[] | select(.labels.alertname=="OrdersBacklog") | {labels,status}]'
amtool --alertmanager.url="$AM_URL" silence expire "$SILENCE_ID"

到期与主动撤销分别验证，不在同一次测试中提前撤销后声称已验证自动到期。随后恢复 worker、跑通业务并收到 resolved。已发出的通知不会被静默撤回；静默期间已恢复的告警也不应假定到期后补发全部历史消息。官方 amtool 用法。

2. 重试、重复与抑制分别验证#

故障注入	验收
停止本地 receiver	Alertmanager 记录发送失败；恢复后收到重试，不凭 `/healthz` 判断送达
receiver 已接受但响应丢失	允许重复送达，不能承诺恰好一次；通知网关按告警指纹、状态和事件生命周期关联
同一对象 warning 与 critical 同时触发	按抑制规则仅抑制匹配对象的 warning；不同对象仍通知
持续故障	到 repeat_interval 收到重复提醒，恢复后不再重复 firing

本地配置默认重复间隔 1 小时；可在独立实验副本改为 1 分钟测试，检查配置后重启/重载，再恢复原值。repeat_interval 设为 group_interval 的整数倍。send_resolved: true 只允许发送恢复消息，不等于业务自动恢复。

3. 独立故障域的持续心跳#

生产前置：企业已批准的外部心跳平台，提供兼容 Alertmanager webhook 的 HTTPS 接收入口和独立通知渠道。平台与本栈不同故障域，按 monitoring-preprod 固定心跳 ID 配置：预期间隔 60 秒、失联阈值 180 秒、首次心跳未到同样告警。若平台不接收 Alertmanager JSON，应先部署经过验证的协议转换网关，不直接填写普通消息 webhook。

平台只有收到 status=firing、alertname=OrdersMonitoringHeartbeat 的有效请求才刷新心跳；校验认证并拒绝过期 endsAt，防止陈旧重试掩盖中断。请求内容不需要业务指标或凭证。通知不能再依赖当前 Alertmanager。

在工程中新建 sre/heartbeat.yaml：

groups:
  - name: monitoring-heartbeat
    rules:
      - alert: OrdersMonitoringHeartbeat
        expr: vector(1)
        labels:
          environment: preprod
          service: monitoring
          heartbeat_id: monitoring-preprod
        annotations:
          summary: Persistent monitoring pipeline heartbeat

将 sre/prometheus.yaml 的 rule_files 增加 /etc/prometheus/heartbeat.yaml。在 Alertmanager 根 route 的 routes 第一项增加下列路由（保留已有配置）：

routes:
  - matchers: ['alertname="OrdersMonitoringHeartbeat"']
    receiver: external-heartbeat
    group_by: [alertname, heartbeat_id]
    group_wait: 0s
    group_interval: 1m
    repeat_interval: 1m
    continue: false

在 receivers 追加：

- name: external-heartbeat
  webhook_configs:
    - url: https://heartbeat.ops.example.com/alertmanager
      send_resolved: false
      http_config:
        authorization:
          type: Bearer
          credentials_file: /run/secrets/heartbeat-token

替换为批准入口；将 token 以只读 Secret/file 挂载到 Alertmanager 容器的上述路径，不写入 YAML、Git 或日志。若 URL 本身带秘密，应通过 url_file 管理。部署前保存配置快照并检查：

amtool check-config sre/alertmanager.yaml
amtool config routes test --config.file=sre/alertmanager.yaml alertname=OrdersMonitoringHeartbeat heartbeat_id=monitoring-preprod environment=preprod service=monitoring

配置检查应在能读取上述 Secret 路径的受控环境执行。路由结果只能为 external-heartbeat，不能发到普通值班群；完成 Prometheus 规则检查和配置重载，再确认外部平台持续收心跳。

4. 证明监控停掉也能发现#

先连续收到至少三次心跳，再停止本次 Alertmanager；外部平台应在阈值及其检测延迟内报告心跳丢失。
恢复 Alertmanager，确认连续心跳与外部恢复通知。
分别停止 Prometheus、阻断外发网络、配置无效测试 token，重复上述验收；停止 Prometheus 后 Alertmanager 可能继续发送直到告警 endsAt 到期，计入检测预算。
演练“从未收到第一次心跳”，验证预建期望清单能发现未部署/配置错误，而非永远等待首个样本。

故障注入只对独立栈操作，每次恢复并确认后再进入下一项。维护静默需明确排除心跳，或在外部平台独立设置有截止时间的维护窗。保留心跳规则作为常驻配置；结束测试后撤销测试静默、恢复所有服务，核对真实订单和通知链路。