hyb-oa/.trellis/tasks/08-22-wecom-oa-backup-restore-notification-investigation/design.md

企业微信 OA 备份恢复通知异常排查设计

1. 诊断边界

本任务不修改运行系统，只建立“消息状态 → 发送组件 → timer → 运行证据”的可验证映射。消息中的稳定状态和类别是主键，企业微信机器人显示名仅视为展示信息。

2. 证据链

1. 从截图读取稳定状态、类别和时间窗口。
2. 通过 helper allowlist 和各调用方把状态映射到唯一组件。
3. 核对 timer 是否重复、是否存在多机并发，以及最近执行结果。
4. 核对生产备份近期成功记录，排除备份和恢复链路。
5. 从 ARM 对公网 /ready 做有限次数只读探测，判断当前是否持续故障。
6. 对缺少的 root-only 历史明确标注证据限制，不用猜测替代结论。

3. 根因分层

• 已确认：ARM 公网健康探测发生短时 dns_or_connect_failed，之后恢复。
• 已排除：生产备份失败、真实数据恢复、重复生产 timer、两个生产实例重复运行。
• 高概率原因：ARM 单一静态解析/外网连接链路间歇抖动。
• 尚未区分：DNS 解析器无响应、ARM 出口瞬断、目标 TCP 建连失败。现有实现把三者归为同一类别。

4. 建议方案

立即处置

• 保持备份与健康监控运行；当前 OA 与备份均健康，无需紧急停用任务或执行恢复。
• 若再次出现，记录状态、类别和时间，不在群内粘贴原始日志。

后续代码增强（需另行批准）

• 将探测拆分为 DNS、TCP、TLS、HTTP、响应合同阶段，并只保存稳定类别与短期计数。
• 为“恢复通知”增加来源名称，例如“公网健康恢复”，避免被误解为数据恢复。
• 增加抖动窗口策略，例如在短时间内多次告警/恢复时合并通知，但不得削弱持续故障告警。

ARM 配置调整（需另行批准）

• 先取得脱敏诊断证据，再评估增加受控冗余解析入口或本机缓存解析服务。
• 不直接通过提高失败阈值掩盖解析/网络故障。

5. 验证与回滚

• 诊断任务仅运行只读命令，无需回滚。
• 后续代码增强须用无真实 Webhook 的合同测试覆盖 DNS/TCP 分类、降噪、恢复和隐私边界。
• 后续 ARM 变更须先保存原配置摘要，变更后验证解析、HTTPS、timer 和备份 dead-man，异常时恢复原配置；不得触碰备份归档和 Webhook 正文。