getDomain/docs/当前线上最终Runbook.md

当前线上最终 Runbook

最后更新：2026-04-26 18:12 左右
适用节点：mainland-controller-01

这份文档的目标很简单：
后面不再靠聊天记录回忆，也不在多份文档里来回翻。
只看这一份，就知道：

1. 当前线上到底跑在什么基线上
2. 现在先看什么数
3. 什么情况继续观察
4. 什么情况才值得继续动刀

1. 当前结论

当前这套线上方案，已经从：

• 线程忙但不出结果

推进到了：

• 线程忙，同时持续产出 completed

所以现在的正确策略不是继续乱改参数，而是：

先稳住，先观察，确认这套已经验证有效的配置能不能持续出结果。

2. 当前线上基线

当前基底版本

• current 指向： /opt/domaincheck/releases/domaincheck_release_20260424_220158

说明：

• 当前不是纯旧 release 原样运行
• 真实线上状态是： 220158 基底 + 多轮已热补代码 + 已生效 env

当前服务状态

• domaincheck-worker.service = active
• domaincheck-sync-agent.service = active
• domaincheck-api.service = active

3. 当前已确认生效的关键参数

这些参数是已经在运行进程环境里确认过的，不是只改了文件。

单机性能与爱站相关

• DOMAINCHECK_REGISTER_SINGLE_MACHINE_MODE=1
• DOMAINCHECK_SINGLE_MACHINE_AIZHAN_DIRECT_FIRST=1
• DOMAINCHECK_AIZHAN_REMOTE_DISCONNECT_DEGRADE=1
• DOMAINCHECK_AIZHAN_EXTERNAL_FAST_DEGRADE=1
• DOMAINCHECK_PROXY_STEP_MAX_ATTEMPTS_AIZHAN=2
• DOMAINCHECK_PROXY_STEP_MAX_SECONDS_AIZHAN=10
• DOMAINCHECK_AIZHAN_TIMEOUT_PROXY=1.8
• DOMAINCHECK_AIZHAN_TIMEOUT_DIRECT=2.4

Wayback 相关

• DOMAINCHECK_PROXY_STEP_MAX_ATTEMPTS_WAYBACK=2
• DOMAINCHECK_PROXY_STEP_MAX_SECONDS_WAYBACK=8
• WAYBACK_CDX_TIMEOUT=3
• WAYBACK_SNAPSHOT_TIMEOUT=2
• WAYBACK_RETRY_COUNT=1
• WAYBACK_DOMAIN_CONCURRENCY=1
• WAYBACK_MAX_RECORDS=2
• WAYBACK_TRANSIENT_BACKOFF_SECONDS=0.5

4. 当前已确认上线的代码方向

调度 / 分发侧

• 预补货提前触发
• 预补货时不再让补货 worker 先独吞下一批
• pipeline 推进和主动 pull_tasks 做了共享锁
• session_replaced -> queued_before_start 这条重复唤起链已压住
• claim / finalize / release 这些本地 DB 重链已经做过减重

外部步骤侧

• 注册检测保留单机性能模式
• 百度、360、爱站都不再是早期那套过于激进的超时口径
• 爱站 当前已经具备：
  • 首轮可直连优先
  • RemoteDisconnected 可直接降级
  • 外部依赖异常可快速降级继续
• wayback 当前已经具备：
  • latest_cdx transient 时不再硬打额外 records_cdx
  • backoff 已收短
  • 主要剩下 web.archive.org 本身慢/拒绝连接

5. 当前已经验证出来的效果

5.1 机器已经真正吃起来

已观察到：

• 60 个节点全在线
• 多次快照里 51 ~ 56 个 worker 有真实线程
• 真实线程和长期在 3.8 万 ~ 4.2 万

所以当前不是“进程活着但没干活”，而是确实在跑。

5.2 内存高位问题先被压下来

滚动重启释放旧 RSS 后，现场出现过一轮明显回落：

• Mem used ≈ 31Gi
• available ≈ 93Gi
• 60 个 worker 总 RSS ≈ 23.9Gi

说明“旧 RSS 不退”这层已经先被压住。

5.3 当前真正最重要的验证结果

观察窗：2026-04-25 17:17:18 到 17:29:23

• completed_total: 50786 -> 51298，净增 512
• aizhan_completed: 7718 -> 7936，净增 218
• wayback_completed: 3068 -> 3362，净增 294
• 这段窗口里：
  • aizhan_failed = 0
  • wayback_failed = 0

这说明：

• 现在已经不是“压住 failed，但 completed 不动”
• 而是“failed 被压住，同时 completed 持续增长”

6. 当前最该看的数

后面观察时，优先级固定按这个顺序：

1. completed_total
2. aizhan_completed
3. wayback_completed
4. aizhan_failed
5. wayback_failed
6. running / claimed / pending

顺序不要反过来。

原因：

• claimed / pending 在 domain_pipeline 下天然会波动
• completed 才是最真实的产出

7. 当前正确的判断方法

7.1 什么叫“继续观察就行”

只要看到下面这种趋势，就先不要再改：

• completed_total 持续增长
• aizhan_completed 持续增长
• wayback_completed 持续增长
• aizhan_failed / wayback_failed 维持低位或归零

这说明：

• 当前主链是通的
• 当前配置方向是对的
• 现在最应该做的是稳住，不是继续乱调

7.2 什么叫“又卡住了”

只有出现下面这些情况，才值得继续下刀：

情况一

completed_total 在 30 ~ 60 分钟窗口里基本不动

说明：

• 虽然线程在跑
• 但结果没有真正落地

情况二

aizhan_failed 或 wayback_failed 又明显抬头

说明：

• 当前“快速降级继续”的策略还不够稳

情况三

running 长时间很高，但 aizhan_completed / wayback_completed 不再增长

说明：

• 新的主瓶颈又出现了

8. 当前建议观察窗口

建议至少继续看 30 ~ 60 分钟。

正确做法：

1. 记录一组起始值
2. 每隔 10 ~ 15 分钟看一次
3. 至少看 3 ~ 4 个点

不要只看一两个瞬间。

9. 当前先不要再碰的东西

在这轮观察结束前，先不要继续改：

• worker 进程数
• 每进程线程数
• claim 批量
• backlog 批量
• 爱站超时
• wayback 超时
• 其他步骤的重试窗口

原因很简单：

• 现在已经进入“开始稳定产出”的阶段
• 再频繁改参数，只会把已经验证有效的窗口打碎

10. 当前一句话执行原则

先稳住，先看 completed 能不能持续增长；只要结果还在持续出来，就先不要再乱改。

11. job 876 尾项释放的当前判断

观察时间：2026-04-26 18:12 左右

当前不是“又卡死了”，而是：

• idx_detect_job_items_release_node_job 还没转成 valid=1
• 但它已经稳定进入 index validation: scanning table
• 最新验证进度已经到 229991 / 6197384

codex-job876-tail-watch.service 这条后台链当前是活的，而且在连续记进度：

• 18:09:51 -> 126725
• 18:10:52 -> 169564
• 18:11:52 -> 210067
• 18:12:22 -> 227856

同时现场另外两组状态也正常：

• job 876 = running
• worker 已恢复到：
  • base=active
  • templated=199
  • node_agent=active

这次现场更准确的判断应该是：

• 已经从“卡住”切成“后台验证扫描中”
• 当前最合理的动作不是再人工乱动
• 应该继续让索引自己扫完

一旦 idx_detect_job_items_release_node_job 转成 valid=1，codex-job876-tail-watch.service 就会自动继续释放 876 的尾项。

12. 如果后面还要继续优化，下一刀顺序

只有在更长观察窗口里确认又卡住时，才按这个顺序继续：

1. 先看 completed_total 为什么不涨
2. 再看 aizhan_completed / wayback_completed 哪个先停
3. 再决定是继续打外部链，还是回头查回写 / 聚合语义

不要一上来就回去改线程、claim、并发。