getDomain/docs/ops_center_runtime/TASK_BOARD.md

TASK_BOARD

更新时间：2026-04-19 21:25 CST

2026-04-20 主线切换说明

从这一刻开始，当前工作重心正式切回：

• 先跑通主任务流程
• 先推进 7 个大任务的测试与验收
• 并发、代理、DB 往返、展示层等细节优化先封存，不再抢主线

细节优化不删除，统一视为 backlog：

• worker pool 持续补位
• claimed 回弹压缩
• 高频 DB 更新继续合并
• 代理失败链和等待窗口继续压缩
• 运营视角页面继续细化

这些后续继续做，但不再打断主任务验收顺序。

当前主口径：

1. 大任务 1 真实验收闭环
2. 大任务 2 controller 编排闭环
3. 大任务 3 统一结果状态机闭环
4. 大任务 4 本地控制状态 + syncer/finalizer 闭环
5. 大任务 5 固定 worker pool 落地
6. 大任务 6 时光机一期接入
7. 大任务 7 运营视角面板闭环

21:17 最新补充

刚刚这轮真实 rollout 已经把 mainland worker 的最后一层阻塞拿实：

• mainland-worker-01
  • release_id = 7
  • rollout_id = 6
  • job_id = 211
• 发布链路并不是卡在下载或解压：
  • 发布包 domaincheck_release_20260419_205437 已下载到 /opt/domaincheck/downloads
  • release 已解压到 /opt/domaincheck/releases/domaincheck_release_20260419_205437
  • /opt/domaincheck/current 已切到新 release
• 最终失败点已经明确：
  • restart failed: domaincheck-worker
  • systemd 原因：
    • Interactive authentication required
• 这说明当前 mainland 节点的 domaincheck-node-agent 虽然能写发布目录，但因为以 www 身份运行，无法执行：
  • systemctl restart domaincheck-worker

当前新的唯一主阻塞已经进一步收敛为：

• node-agent systemd 运行身份不对
• 需要把 domaincheck-node-agent 改成 root 运行，发布链最后一跳才能闭环

本轮已在仓库内同步修正：

• domain-api/deploy/systemd/domain-node-agent.service
  • User=root
  • Group=root
• domain-api/deploy/multi-region/fix_mainland_release_base.sh
  • node-agent drop-in 现在也会显式写入：
    • User=root
    • Group=root

21:25 worker rollout 收口

mainland-worker-01 已完成新一轮正式 rollout 收口成功：

• release_id = 7
• rollout_id = 7
• job_id = 214

结果确认：

• job 214 = success
• rollout 7 = completed
• mainland-worker-01 已恢复为：
  • agent_state = online_busy
  • 最近心跳恢复正常

控制面完成证据：

• agent_completed
  • summary_text = release deployed
• restart_results
  • domaincheck-worker.returncode = 0
• health_check.ok = true
• execstart_alignment.mismatched_services = []

这说明 worker 当前已经真正完成：

• 新包下载
• release 解压
• current 切换
• domaincheck-worker 重启
• 健康检查通过

当前关于 mainland rollout 的唯一剩余预防项变成：

• mainland-controller-01 也应该同步把 domaincheck-node-agent 切到 root
• 否则后续 controller 自身执行 deploy.release / service.restart 时还会踩到同类 systemd 权限问题

顶部校正

今天晚上的最新排查已经把当前主阻塞重新定性，之前“大陆两台已经完全进入统一新镜像执行”的判断需要收紧。

当前新增硬结论：

• 最新正式发布包已经重打并签收通过：
  • domaincheck_release_20260419_205437
  • 发布包现在已经确实包含 domainCheck/
• 对 mainland-worker-01 发起正式 smart rollout 后，真实失败原因已经拿到：
  • job 204 / rollout 5
  • 本次失败对应的正式 Release 版本仍是：
    • domaincheck_release_20260419_203933
  • 失败原因：
    • Permission denied: /opt/domaincheck/downloads
  • 该失败已通过正式 agent complete 回写，后台不再是假 running
• mainland-worker-01 当前运行中的 domaincheck-worker 仍是旧进程：
  • Main PID = 635924
  • Active since = 2026-04-19 18:18:50 CST
  • CPU = 18.994s
  • 说明它不是高吞吐新进程，而是老进程长期挂着
• mainland-controller-01 当前运行中的 domaincheck-worker 虽然活跃，但服务启动路径同样是：
  • /opt/domaincheck/domainCheck/detect_worker.py
• 两台 mainland 节点当前 domaincheck-worker 的 systemd 启动路径都不是：
  • /opt/domaincheck/current/domainCheck/detect_worker.py

这意味着：

• 当前 ReleaseHub 的 current -> release_version 切换模型，与线上 mainland 节点的实际服务启动路径不一致
• 即使发布包和签收链已经修好，线上节点也还没有具备“按当前发布模型热切版本”的条件
• 当前唯一主阻塞已经从“并发参数是否下发”切换成：
  • mainland 节点发布权限/目录模型不匹配
  • mainland 节点服务启动路径与发布模型不匹配

当前主批次

唯一主批次：J2-检测执行收口批

目标：

• 不进入新页面
• 不扩展控制面
• 不新增发布动作
• 只收口三件已经缩小到运行面的事情：
  • 大陆节点必须真正进入统一镜像队列，而不是停留在兼容旧链路
  • 后台必须能看到大陆节点的实时运行态与日志
  • 100/50 并发配置要从“已下发”推进到“真实有参与吞吐”

本轮最新状态

20:53 最新阻塞结论

• mainland-worker-01 smart rollout 已真实失败，不再继续误判为执行中
• 失败证据：
  • node-agent 日志：
    • 2026-04-19 20:40:15 [node-agent] loop error: [Errno 13] Permission denied: '/opt/domaincheck/downloads'
  • 发布任务：
    • job 204 = failed
  • 发布批次：
    • rollout 5 = failed
• 当前不应该继续把精力放在前端展示或并发口径微调上
• 当前必须先收口：
  • mainland 节点 deploy.release 所需目录权限
  • mainland 节点 systemd ExecStart 与 /opt/domaincheck/current 的一致性

这轮已经完成从“控制链打通”到“真实执行恢复 + worker 日志回传恢复”的关键跨越。

本轮前端已上线校验

• 检测页 任务日志控制台 已调整到事件列表上方
• 检测事件流 已改成独立滚动区：
  • 表格 max-height = 320
  • 避免事件越积越多把整个页面继续向下撑长
• 已在线上实际静态目录重新构建：
  • /www/wwwroot/getDomain/domain-web/dist
• 已确认线上 Nginx 指向该目录：
  • domaincheck_3201.conf
  • domaincheck_152.53.37.118.conf
• 已通过 http://127.0.0.1:3201/ 返回 200 且加载新资源：
  • DetectView-B9S1WMRT.js
  • DetectView-BFxMNRNR.css

本轮代理链已收口

• 已修复 worker 在“代理配置已下发但尚未开始检测”时长期停留 未刷新 的问题
• domaincheck-worker 现在会在以下时机主动触发代理池刷新：
  • worker 启动后
  • proxy_config / thread_count / node_thread_counts / runtime_settings 更新后
• 当前后台状态已不再误报“未刷新”
• 代理策略已切到：
  • 只去掉过期 / 非法代理
  • 跳过预验证
  • 直接入池执行
  • 真实失败后立即淘汰并补刷
• 最新实测结果已经明确：
  • 原始代理 270 个
  • 预验证 0 个
  • 当前可用代理 270 个
  • 最近状态：
    • proxy_last_refresh_status = 直入池 270 个（跳过预验证）
    • available_proxy_count = 270

本轮已完成

• sync_push_service
  • 已修复 detect_task_ingest 只落 domains、不落本地 detect_jobs/detect_job_items 的缺口
  • controller 现在会为拉回来的海外批次持续创建本地镜像任务：
    • sync-overseas-7380
    • sync-overseas-7383
    • sync-overseas-7392
    • 持续增长中
• mainland-controller-01
  • 已重启 domaincheck-worker
  • 已明确进入真实队列：
    • 从任务队列获取到 800 个需要检测的域名
    • 最大线程数: 100
    • 当前实际线程数量: 1/100 ... 6/100
• mainland-worker-01
  • 已修复 sync-pull 控制消息上下文绑定缺口：
    • detect_worker._set_active_cycle_context 现在会读取
      • target_job_id
      • target_job_code
  • 已重启 domaincheck-worker
  • 已明确进入真实队列：
    • 从任务队列获取到 400 个需要检测的域名
    • 最大线程数: 50
    • 当前实际线程数量: 1/50 ... 3/50
  • 已明确把运行日志回传到 overseas：
    • 开始执行检测任务，来源: redis-control
    • 开始执行域名检测任务，正在加载配置
    • 开始检测，正在刷新代理池
    • 开始创建线程，当前批次域名数: 400，最大线程数: 50
    • 当前实际线程数量: 1/50
    • 当前实际线程数量: 2/50
    • 当前实际线程数量: 3/50
• runtime_projection
  • 已定位 controller domain-api/runtime/detect_runs.json 权限错误
  • 已把 runtime 目录和 detect_runs.json 改回 www:www
  • domaincheck-sync-agent 最新日志已从
    • partial_success
  • 变成：
    • sync_state = success
    • runtime_projection -> 投影推送成功
• 海外控制面 /api/v1/ops/nodes
  • 现已明确看到三台节点都在参与
  • remote_access_ready = 3
  • participating = 3
  • mainland-controller-01.is_current_participant = true
  • mainland-worker-01.is_current_participant = true

当前最关键的新证据

• mainland-controller-01
  • processed_recent = 115
  • processed_per_minute = 7.67
  • detect_runtime.max_threads = 100
• mainland-worker-01
  • processed_recent = 632
  • processed_per_minute = 42.13
  • detect_runtime.max_threads = 50
• overseas-control-01
  • 仍在执行中央原生队列
• 当前判断：
  • 大陆节点已经不是“纸面在线”
  • 已经是真实参与检测执行

当前主判断

本轮新增结论

• mainland-controller-01
  • 已修复“代理数量不足反向限制并发”的热路径问题
  • 当前海外后台已稳定看到：
    • active_threads ~= 99~100
    • max_threads = 100
  • 说明 100 并发不再只是配置已下发，而是已进入真实运行态
• mainland-worker-01
  • 已重新部署同版 detect_worker.py
  • 已重新接收到新的 sync-pull 批次：
    • source_record_id = 7679
    • target_job_code = sync-overseas-7679
  • 已完成代理抽样校验并进入：
    • 开始创建线程，当前批次域名数: 400，最大线程数: 50
  • 当前剩余问题已经缩成：
    • worker 本机已启动新批次并创建线程
    • 但海外后台对 mainland-worker-01.active_threads 的显示仍偏低，和本机进程线程量不完全一致

当前唯一剩余收口点

• 不再是 controller 并发限制问题
• 当前唯一剩余收口点变成：
  • mainland-worker-01 的运行态上报口径仍需继续和真实执行量对齐
  • 以及检测主计数 pending/completed/running 继续推进

已经收口的部分

• 大陆节点不再停留在 pending_bootstrap
• Agent + SSH 接管已经完成
• sync-agent pull_tasks 已经真正生成本地镜像队列
• 两台大陆 worker 已经真正吃到 detect_job_items
• 后台运行态同步链已经恢复

当前剩余问题

• Detect 页面日志窗口已经不再是单节点
• /api/v1/detect/status 已出现：
  • remote_log_node_count = 2
  • remote_log_nodes = ["mainland-controller-01", "mainland-worker-01"]
• 当前剩余问题缩成一个最小点：
  • 检测页主计数 pending/completed/running 还没有跟着这轮大陆执行立即推进
• 前端布局问题已收口，后续不再停留在“页面结构挡住观察”
• 代理链当前也已收口到真实口径，不再停留在“配置有了但没刷新”
• 下一步应继续观察这 270 个直入池代理在真实检测里的淘汰速度与吞吐提升
• 现在更应该同时看：
  • /api/v1/detect/status
  • /api/v1/runtime/debug-events
  • /api/v1/ops/nodes
  • worker current actual threads 日志

下一步唯一主批次

唯一主批次保持为：J2-检测执行收口批

下一步只做：

• 继续观察 Detect 页面主计数是否跟上最新运行态
• 继续确认 detect_result_projection / 结果统计回推是否稳定推进
• 继续收口 mainland-worker-01 的运行态上报，使后台显示与本机真实线程量一致
• 若仍有显示偏差，只修统计/上报口径，不新扩功能

候选批次

Candidate J3

名称：结果计数收口批

进入条件：

• 节点已经真实执行
• 日志窗口已经恢复
• 但 Detect 页面主计数仍不前进

只做：

• 复核 detect_result_projection
• 复核结果统计回推
• 不改控制面结构

Candidate J4

名称：吞吐稳定性观察批

进入条件：

• 页面口径已恢复
• 继续确认大陆两节点吞吐是否稳定，不再回落

只做：

• 继续观察 processed_recent
• 继续观察代理池质量
• 继续观察 active_threads/max_threads

暂停项

以下任务现在不应继续推进：

• 新页面
• 新模块
• 新发布动作
• 新专题文档
• 与检测执行收口无关的控制面增强

关键证据

证据 1：镜像队列已经落地

controller sync-agent 最新 task pull tick 已出现：

• target_job_id
• target_job_code
• queued_count = 200
• worker_start_ok = True

说明：

• controller 现在不是只同步域名
• 而是在本地持续创建可执行队列

证据 2：大陆 worker 已进入真实队列

现场日志已经明确出现：

• mainland-controller-01 -> 从任务队列获取到 800 个需要检测的域名
• mainland-worker-01 -> 从任务队列获取到 400 个需要检测的域名

说明：

• “并发没起来”的主要根因已经修正
• 它们不是在跑旧兼容链路

证据 3：运行态同步已恢复

controller sync-agent 最新日志已经出现：

• sync_state = success
• runtime_projection -> 投影推送成功

说明：

• 后台运行态/日志窗口链路已经不再被权限错误卡死

证据 4：海外 /ops/nodes 已把大陆节点判定为真实参与者

当前海外控制面已经显示：

• mainland-controller-01
  • online_busy
  • is_current_participant = true
  • processed_recent = 115
• mainland-worker-01
  • online_busy
  • is_current_participant = true
  • processed_recent = 632

说明：

• 现在大陆两台都已进入真实参与态
• 下一步不再是接管问题，而是页面口径与吞吐稳定性问题

证据 5：Detect 页面远端日志已恢复双节点

当前 /api/v1/detect/status 已显示：

• remote_log_node_count = 2
• remote_log_nodes = ["mainland-controller-01", "mainland-worker-01"]

最近日志样本已出现：

• mainland-worker-01 -> 从任务队列获取到 400 个需要检测的域名
• mainland-worker-01 -> 开始创建线程，当前批次域名数: 400，最大线程数: 50
• mainland-worker-01 -> 当前实际线程数量: 1/50
• mainland-worker-01 -> 当前实际线程数量: 2/50
• mainland-worker-01 -> 当前实际线程数量: 3/50

说明：

• worker 不再是“只在节点本地运行、页面看不到”
• 检测页日志链已经真正接上 mainland worker

证据 6：full_capture 已开启，但源日志时间没有继续前进

节点现场日志最新可见记录仍停在较早时间：

• mainland-controller-01
  • 最近样本集中在 01:00:23
• mainland-worker-01
  • 最近样本集中在 01:00:35

额外 35 秒观察窗口结果：

• capture_at 没有继续前进
• source_msg 里的源日志时间也没有继续前进

说明：

• 不是“全量日志没开”
• 也不是“日志回传没回来”
• 而是执行进程这段时间确实没有继续产生日志

证据 7：worker 控制消息补偿链已在线上验证生效

之前运行态存在一个真实风险：

• runtime.start_detection 成功只代表“控制消息已发布到 Redis”
• 如果 worker 在线但恰好漏收了 pubsub 消息
• pending 指令只在启动或重连时消费，就可能造成：
  • 页面显示“已启动”
  • 但 worker 实际没有进入新的执行流

当前已完成最小修复：

• 每条控制消息带 request_id
• worker 心跳会主动补偿消费 pending 指令
• worker 真正收到并处理后，会按 request_id 清理 pending

这一步现在已经不再是“待部署假设”，而是已被线上日志确认生效：

• mainland-worker-01 已从 pending 指令恢复执行
• mainland-controller-01 在修正 Redis 环境后，也已重新接受并执行 start_detection

当前结论

当前结论要收敛成一句话：

• 接管链路已基本完成
• 同步链路已至少成功贯通一次
• 当前主阻塞仍是检测执行面没有恢复到“持续产出”
• 但代码级控制链缺口已经闭合
• 当前唯一剩余现场阻塞可以收紧为：
  • mainland-controller-01 代理池可用性为 0
• worker 侧时光机异常仍是次级噪音，不应继续放大

下一步唯一主批次

唯一主批次维持为：J2-检测执行停滞收口批

本批次唯一目标：

• 保持当前不扩功能
• 只围绕 controller 代理池可用性为 0 做收口
• 继续观察修正后的 controller 是否开始产出 domain 级结果
• 若仍无结果增长，则只给出代理层最小补救路径

候选批次

Candidate J3

名称：检测执行恢复验证批

进入条件：

• J2 明确根因后
• 代理或外部站点依赖恢复
• 再观察 domain_* 是否重新增长

Candidate J4

名称：上线签收证据批

进入条件：

• J3 确认检测重新持续产出
• go-live-summary 只剩历史 attention

暂停项

继续暂停：

• 新页面
• 新模块
• 控制面增强
• 发布动作
• 与检测执行停滞无关的工作

下一轮唯一动作

下一轮唯一应该继续做的事情：

• 只做 controller 代理收口：
  • 继续复查 controller domaincheck-worker 日志
  • 观察是否从 当前无可用代理 转为有可用代理
  • 继续复查 /api/v1/detect/job/active
  • 继续复查 /api/v1/runtime/sync-summary
  • 继续复查 recent domain events 是否出现 controller / 新 completed
• 唯一判断问题是：
  • controller 代理池恢复后，completed 是否开始继续增长
  • 是否仍是 近窗吞吐 0
  • 是否仍是 controller 可用代理数 0
  • 代理恢复后 domain_* 是否重新增长