SRE 企业闭环：真实订单、规则测试、告警与恢复

验证：未记录

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

SRE（Site Reliability Engineering，站点可靠性工程）验收必须贯穿业务事件、指标、规则、通知和恢复。本篇复用订单参考工程，提供真实埋点和 sre/ 配套文件；本地通知接收器用于验证路由，不向真实值班群发送消息。

1. 启动与规则单测#

先完成订单工程本地验收。选择批准的 Prometheus / Alertmanager 版本并固定摘要：

export PROMETHEUS_IMAGE='prom/prometheus@sha256:REPLACE_APPROVED_DIGEST'
export ALERTMANAGER_IMAGE='prom/alertmanager@sha256:REPLACE_APPROVED_DIGEST'
docker run --rm --entrypoint promtool -v "$PWD/sre:/work:ro" -w /work "$PROMETHEUS_IMAGE" check rules rules.yaml
docker run --rm --entrypoint promtool -v "$PWD/sre:/work:ro" -w /work "$PROMETHEUS_IMAGE" test rules tests.yaml
docker compose -f compose.yaml -f compose.sre.yaml up -d
curl --fail http://127.0.0.1:9090/-/ready
curl --fail 'http://127.0.0.1:9090/api/v1/query?query=up'

七个规则用例覆盖：抓取失败、目标消失、零流量、counter（计数器）重置、持续错误、真实积压与死信。配置提供双窗口快速错误预算消耗告警：5 分钟及 1 小时同时超过 1.44%，适用于 99.9% 可用性目标的一个告警档位，并要求足够请求量；低流量服务另使用合成事务与绝对失败数，不能只依赖该门槛。

2. 正常业务与租户隔离#

运行 tests/acceptance.py，Prometheus 中确认 http_requests_total、延迟直方图、orders_pending、orders_oldest_pending_seconds。GET/POST 标签只含路由模板，不记录订单 ID、token 或个人信息，避免高基数及敏感信息泄漏。

生产抓取使用内网 ServiceMonitor、TLS（传输层安全）与受限访问；不能公开 /metrics。云上对应私有采集器/托管监控，沿用相同业务定义，不直接把本地 Docker 地址当云配置。

3. 实际积压 → 通知 → 恢复#

docker compose stop worker
# 会创建订单，然后因 worker 停止，在 60 秒后验收失败；这是故障注入预期。
python3 tests/acceptance.py
# 保持 worker 停止，超过 120 秒阈值 + 1 分钟 for + 抓取/分组延迟后：
curl --fail http://127.0.0.1:9090/api/v1/alerts
curl --fail http://127.0.0.1:8089/

必须看到 OrdersBacklog=Firing，以及接收器记录 status=firing。只看到 Pending 或规则存在不算通知成功。恢复：

docker compose start worker
python3 tests/acceptance.py
curl --fail 'http://127.0.0.1:9090/api/v1/query?query=orders_pending'
curl --fail http://127.0.0.1:8089/

pending 最终为 0；等待下一次抓取及分组周期，必须收到 resolved。保存通知时间、最老任务年龄、恢复后业务对账，记录实际检测/恢复耗时。

4. 监控自身与负向验证#

停止 API：OrdersTargetDown 应触发；此时数据库指标抓取失败，不能被视为积压清零。
恢复 API；暂时从 scrape 配置移除目标并重启 Prometheus：超过 2 分钟缺失窗口与 1 分钟 for 后，OrdersTargetMissing 触发；完成后恢复配置。
停止 receiver：检查 Alertmanager 日志与 notification failures 指标，恢复后确认重试到达。配置外部 dead-man（持续心跳）监控，避免整套监控失联无人察觉。
企业接入将 webhook 改为批准的内部通知网关；凭据放 Secret/file，不放 Git。验证值班路由、静默到期、升级策略与恢复通知；不要在实际值班环境直接进行未约定的故障注入。

维护静默、重试/重复与独立故障域心跳按通知可靠性演练执行；规则中的 Runbook 已连接本站排障入口。

5. 升级与清理#

新规则先 promtool test rules 再发布；升级组件在隔离环境检查配置兼容、历史数据可读和通知回路。镜像降级前检查存储格式兼容性。结束后先恢复业务依赖，再停本次监控栈；仅可丢弃的本地环境才 down --volumes，生产证据和时间序列按留存策略处理。

Prometheus 规则单测、Alertmanager webhook。