hyb-oa/.trellis/tasks/archive/2026-08/08-22-wecom-oa-backup-restore-notification-investigation/research/notification-source-and-runtime-evidence.md

通知来源与运行证据

消息映射

• 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 或企业微信配置，未发送测试消息。