# 通知来源与运行证据

## 消息映射

- `FAIL_APP_HEALTH` / `PASS_APP_HEALTH_READY`：ARM 公网 `/ready` 健康探测。
- `FAIL_AUTOMATIC_BACKUP` / `PASS_AUTOMATIC_BACKUP_*`：生产自动备份或新鲜度 watchdog。
- `FAIL_OFFHOST_DEADMAN` / `PASS_OFFHOST_DEADMAN_FRESH`：ARM 异机归档 dead-man。
- `PASS_WITH_FINDINGS` + `quarterly_shadow_restore_due_*`：季度人工影子恢复提醒，不会自动恢复生产。

截图状态明确属于第一类。企微应用显示名“OA 备份告警”是共用群机器人的名称，不能作为故障来源判断依据。

## 状态机证据

- `scripts/check-public-app-health.py:242-268`：任意探测失败累计连续失败次数，达到阈值后才调用告警 helper。
- `scripts/check-public-app-health.py:270-279`：一次成功立即清零，并让 helper 评估健康恢复。
- `scripts/send-wecom-group-alert.py:123-140`：相同故障降噪；故障/提醒恢复后发送一次统一标题的恢复通知。
- ARM 安装合同固定每 5 分钟探测、失败阈值为 2、单次超时为 10 秒。

## 只读运行证据

- 生产自动备份三组 timer 均 enabled/active；两个 SSH 入口属于同一机器的不同账号，不构成重复调度。
- 生产最近 14 天每日自动备份和新鲜度 watchdog 均成功，未发现备份失败或真实恢复行为。
- ARM dead-man 与应用健康 timer 均 enabled/active，最近一次 service 成功。
- ARM 当前额外 5 次 `/ready` 请求全部成功，说明 OA 当前公网就绪。
- ARM 使用一个静态解析入口且未启用本机解析服务；它是当前链路的单点，但现有粗粒度类别仍不能证明当时一定是 DNS 而不是 TCP 连接失败。

## 结论

截图反映的是 ARM 到 OA 公网 `/ready` 的短时解析或连接抖动。它不是备份失败，不是恢复演练，也没有触发数据恢复。消息数量偏多的直接原因是健康探测按“连续两次失败即告警、一次成功即恢复”运行，而链路在告警和健康之间反复切换。

## 证据限制

- ARM 状态和完整 journal 为 root-only，当前入口只能读取 systemd 公共状态。
- 消息类别有意脱敏并合并 DNS/TCP，因此无法从群消息反推出原始异常。
- 历史会话检索器在当前 Trellis 构建中不可用；本结论不依赖该能力。

## 2026-08-23 最终只读复核

- 生产三组自动备份相关 timer 仍为 enabled/active。
- 最近 14 天共记录 14 次每日异机备份成功、14 次新鲜度 watchdog 成功、0 条自动备份失败记录。
- ARM dead-man 与公网健康 timer 仍为 enabled/active，最近一次公网健康 service 结果为 success/0。
- ARM 连续 5 次当前 `/ready` 请求全部成功。
- 本轮未修改代码、systemd、DNS、网络、Webhook 或企业微信配置，未发送测试消息。