# 当前线上最终 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、并发。