# 企业微信 OA 备份恢复通知异常排查 ## Goal 定位企业微信群中反复出现的“内部 OA 运维告警/恢复通知”的真实发送源和触发原因，判断其是否表示备份或恢复异常，并形成不影响真实备份能力的处置建议。 ## Background - 用户截图显示发送应用名为“OA 备份告警”，但消息状态是 `FAIL_APP_HEALTH` / `PASS_APP_HEALTH_READY`，失败类别是 `dns_or_connect_failed`。 - 同一晚至少出现两轮恢复消息，其中一轮在告警后很快恢复，表现为间歇性故障而非持续不可用。 - 本任务只做诊断和方案建议；未经另行明确批准，不修改生产或 ARM 配置，不停用 timer，不重启服务，不发送测试消息。 ## Confirmed Facts - `scripts/send-wecom-group-alert.py:123` 只在故障/提醒类别变化或从故障/提醒恢复为健康时发送；相同状态应由独立状态文件降噪。 - `scripts/send-wecom-group-alert.py:133` 将所有健康恢复统一命名为“内部 OA 运维恢复通知”。该标题表示监控状态恢复，不表示执行过数据库、附件或整机恢复。 - 截图中的 `FAIL_APP_HEALTH` 只能由 ARM 公网健康探测产生，不来自每日备份、备份新鲜度 watchdog、异机归档 dead-man 或季度恢复提醒。 - ARM 健康探测每 5 分钟运行一次，连续两次失败才告警，一次成功即发送恢复通知。因此每轮告警至少代表约两个连续探测窗口未能完成公网 `/ready` 请求。 - 当前实现把 DNS 解析失败和 TCP 连接失败合并为 `dns_or_connect_failed`，现有消息无法进一步区分两者。 - 生产最近 14 天每日备份和新鲜度 watchdog 均按预期各运行一次且结果成功；未发现生产备份失败、重复调度或真实恢复操作证据。 - 两个生产 SSH 入口落在同一台机器、不同账号上，不是重复部署实例。 - ARM 当前健康探测成功，额外连续 5 次只读 `/ready` 请求全部通过；故障已自行恢复。 - ARM 当前使用单一静态 DNS 解析入口，未运行本机解析服务，解析链路缺少冗余。结合短时失败后恢复的模式，ARM 侧 DNS/外网连接间歇抖动是首要假设。 - 现有 ARM 入口不能读取 root-only 状态历史和完整 journal；若要把原因从“DNS 或连接”进一步精确到某一层，需要额外的 root 只读证据或先增强脱敏诊断。 ## Requirements - 明确区分应用健康告警、备份告警、备份新鲜度告警、异机 dead-man 和季度提醒。 - 用截图、代码、timer、状态和近期只读运行证据解释当前问题。 - 给出最小处置建议，并区分“当前无需紧急动作”“后续代码增强”“ARM 配置调整”三类。 - 不记录 Secret、完整账号、主机地址、原始消息 payload、真实业务数据或完整运维路径。 - 任何代码、部署或 ARM DNS 配置变更均需后续单独批准。 ## Scope - 企业微信截图中的稳定状态、类别和时间窗口分析。 - 公网健康探测、共用告警 helper、自动备份与异机 dead-man 的调用关系。 - 生产及 ARM 相关 timer 的只读状态、近期脱敏结果和当前公网 `/ready` 可用性。 - 诊断结论、证据限制、后续代码增强与 ARM 配置建议。 ## Acceptance Criteria - [x] 能确认截图消息的唯一发送源，并说明“恢复通知”不等于执行恢复。 - [x] 能判断生产备份当前是否正常，是否存在重复 timer 或重复实例。 - [x] 能说明当前可证实的故障边界以及仍无法区分的 DNS/TCP 子原因。 - [x] 给出不影响备份和监控可靠性的分级处置建议、验证方法与回滚边界。 - [x] 全过程不执行未经批准的生产/ARM 写入、任务停用、服务重启或外部消息发送。 ## Out of Scope - 本任务内修改 ARM DNS、网络、systemd timer 或企微机器人配置。 - 停止公网健康监控，或通过提高阈值掩盖真实持续故障。 - 数据库重置、真实恢复、恢复演练或备份数据下载。 - 主动发送测试告警、修改群成员或企业微信应用配置。 ## Test Plan - 用截图状态反查唯一调用方，并与源码 allowlist、状态机和 timer 配置交叉核对。 - 只读检查生产/ARM timer 唯一性、启用状态和最近结果。 - 复核生产最近 14 天自动备份及新鲜度 watchdog 结果。 - 在 ARM 侧执行有限次数 `/ready` 只读请求，只记录成功/失败计数。 - 运行 task validate、Trellis 治理门禁和 `git diff --check`。 ## Deferred Items - 若用户后续要求修复，建议另行批准：先增强探测器，将 DNS、TCP、TLS 和 HTTP 阶段分开，并保留短期脱敏计数；再依据证据决定是否为 ARM 配置冗余解析入口。 - ARM root-only 历史日志采集可进一步确认具体故障层，但不阻塞本任务对“发送源不是备份、当前问题是 ARM 公网健康链路抖动”的判断。