68 行
4.9 KiB
Markdown
68 行
4.9 KiB
Markdown
# 企业微信 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 公网健康链路抖动”的判断。
|