Files
getDomain/docs/25_domainCheck_海外单脑控制面上线收口总表.md
2026-04-18 23:52:51 +08:00

11 KiB
Raw Permalink Blame History

25 domainCheck 海外单脑控制面上线收口总表

一、这份文档解决什么问题

这份文档不是再讲设计,而是把当前项目进入正式上线前,真正需要收口的事项压成一张总表。

适用场景:

  • 海外主机已经作为单脑控制面
  • 大陆节点已经开始纳管
  • Ops Center / Codex Driver / CLI 都已经接入同一套 ops contract
  • 目标从“能联调”切换到“能稳定上线、能持续运维”

这份文档优先回答 4 个问题:

  1. 现在能不能继续收口
  2. 现在能不能正式发布
  3. 还有哪些阻断项没清
  4. 下一步到底先跑哪条命令

二、上线前统一原则

上线前必须统一成下面这条工作方式:

  • 海外主机作为唯一主驾驶席
  • 页面、CLI、Codex 共用同一套后端判断
  • 默认先看 go-live-summary
  • 真要解释原因时再下钻 stack-diagnosis
  • 真要执行动作时走 driver-resolve / execute-resolved
  • 真要发布或放量时走 Release Hub / rollout

不再推荐:

  • 人工分别登录多台大陆机器拼状态
  • 每次上线都从 journalctl + systemctl + curl 临时组合判断
  • 前端、CLI、Codex 各自维护不同的默认下一步

三、正式上线门禁

1. 收口门禁

至少同时满足:

  • go_live_summary.go_live_status != blocked
  • stack_diagnosis.diagnosis.stack_status != blocked
  • route_surface_complete=true
  • driver-feed.automation_coverage.launch_status != blocked
  • 首屏默认下一步已经明确,不再是模糊人工判断

2. 发布门禁

至少同时满足:

  • publish_ready=true
  • launchpad_status != blocked
  • 不存在未处理的关键 blocking_reasons
  • 当前发布主车道已经清晰落在:
    • review_smart_rollout_preview
    • review_control_rollout
    • publish_latest_worker
    • create_release_rollout_*

3. 运维门禁

至少同时满足:

  • 海外控制面 API 稳定在线
  • 大陆 controller / worker 心跳稳定
  • 节点接管缺口已经收口,或至少首个缺口节点已有明确恢复动作
  • 远端日志回传可按需开启、复核、关闭
  • 运行中心首屏能直接区分:
    • 在线但未参与
    • 正在执行 / 正在领任务

四、真正的起手顺序

每次准备上线、复核、值班接手时,都按这个顺序来:

第 1 步:看上线收口摘要

cd /www/wwwroot/getDomain
bash domain-api/deploy/multi-region/drive_ops_center.sh go-live-check http://127.0.0.1:8100 http://127.0.0.1:8100 summary

如果当前是临时海外控制面联调,也可以把第二个地址替换成海外目标 API。

第一眼重点只看:

  • go_live_status
  • publish_status
  • blocking_reasons
  • warnings
  • next_step_action_code
  • operator_title

如果你怀疑当前是环境本身有漂移,而不是业务链路没收口,先执行:

bash domain-api/deploy/multi-region/drive_ops_center.sh env-audit
bash domain-api/deploy/multi-region/drive_ops_center.sh runtime-refresh-recover
bash domain-api/deploy/multi-region/drive_ops_center.sh go-live-recover

重点只看:

  • status
  • headline
  • missing_items
  • tooling_items
  • runtime.preflight_ok
  • runtime.readiness_status
  • runtime.route_surface_complete
  • runtime.repo_capability_drift
  • runtime.runtime_may_need_restart
  • recommended_actions

如果这里出现:

  • runtime.repo_capability_drift=true
  • runtime.runtime_may_need_restart=true

则优先执行 runtime-refresh-recover,不要先把问题误判成“代码还没写完”。这通常表示:

  • 仓库代码已经更新
  • 但运行中的 domaincheck-api 进程还没重启到这版代码

runtime-refresh-recover 会固定给出:

  • 当前是否真的属于运行时版本漂移
  • 推荐先跑的 runtime-refresh-recover 统一恢复入口
  • 重启后应该按什么顺序继续:
    • stack-diagnosis
    • node-bootstrap-plan
    • stack-next
    • doctor-decision

如果你已经不想再手工一条条执行,而是想把“刷新运行时 + 再做总检复核”压成一次操作,直接执行:

bash domain-api/deploy/multi-region/drive_ops_center.sh go-live-recover

它会固定串起:

  1. runtime-refresh-recover
  2. stack-diagnosis summary
  3. stack-next
  4. go-live-check summary
  5. doctor-decision

如果要把这次上线前检查直接导出成一整包证据,而不是手工复制多段终端输出,直接执行:

bash domain-api/deploy/multi-region/drive_ops_center.sh go-live-export

它会统一导出:

  • env-audit
  • go-live-check 摘要
  • go-live-summary
  • stack-diagnosis
  • driver-feed
  • codex-brief
  • release-launchpad
  • doctor-decision
  • doctor-export
  • manifest.json

其中 manifest.json 会直接标记:

  • 环境审计当前是 ready / attention / blocked
  • 哪些 artifact 成功
  • 哪些 artifact 超时
  • 哪些 endpoint 缺失或返回异常
  • 当前推荐的阅读顺序

现在 Ops Center 首屏也会同步读取最新 bundle / manifest

  • 顶部 总检决策
  • 详情区 总检主决策详情
  • API GET /api/v1/ops/doctor-decision
  • 顶部 交付证据
  • 详情区 交付证据详情
  • API GET /api/v1/ops/go-live-bundle
  • 顶部 正式复核
  • 详情区 正式复核详情
  • API GET /api/v1/ops/go-live-review

如果你想先拿到一句“bundle manifest 正式复核是否通过”的统一结论,而不是直接跳到最终签收,也可以先执行:

bash domain-api/deploy/multi-region/drive_ops_center.sh go-live-review

如果你想在 bundle 基础上直接得到一句“现在能不能签字上线”的统一结论,而不是人工再看多份 JSON直接执行

bash domain-api/deploy/multi-region/drive_ops_center.sh go-live-signoff

或基于已有 bundle

bash domain-api/deploy/multi-region/drive_ops_center.sh go-live-signoff /path/to/go-live-bundle

这里的 go-live-signoff 已经不是另一套独立摘要,而是固定压缩:

  • go-live-review
  • doctor-decision
  • go-live-summary / 发布门禁 / launchpad 摘要

所以页面首屏、CLI 与海外 Codex 看到的是同一份最终签字口径。

第一眼重点只看:

  • signoff_status
  • headline
  • release_gate
  • blocked_reasons
  • attention_reasons
  • decision

第 2 步:看总检详情

bash domain-api/deploy/multi-region/drive_ops_center.sh stack-diagnosis

重点只看:

  • stack_status
  • issues
  • next_step
  • quick_commands

第 3 步:看驾驶主线

bash domain-api/deploy/multi-region/drive_ops_center.sh driver-feed
bash domain-api/deploy/multi-region/drive_ops_center.sh codex-brief

重点只看:

  • top_recommendation
  • automation_coverage
  • recommended_behavior
  • focus

第 4 步:确认默认下一步

如果只是预览:

bash domain-api/deploy/multi-region/drive_ops_center.sh stack-next

如果已经确认要执行:

bash domain-api/deploy/multi-region/drive_ops_center.sh stack-next run confirm

五、当前项目的主处理车道

上线前遇到问题时,不要发散排查,先归到下面 5 条主车道:

1. 节点接管车道

典型信号:

  • remote_access_ready=0
  • bootstrap_run
  • run_acceptance
  • managed_nodes_agent_pending

优先命令:

bash domain-api/deploy/multi-region/drive_ops_center.sh agent-gap-check
bash domain-api/deploy/multi-region/drive_ops_center.sh agent-gap-recover
bash domain-api/deploy/multi-region/drive_ops_center.sh node-onboarding http://127.0.0.1:8100 mainland-worker-01

2. 远端日志车道

典型信号:

  • 首屏显示“现场日志覆盖不足”
  • log_sync_enabled=false
  • line_count=0
  • source_nodes 缺节点

优先命令:

bash domain-api/deploy/multi-region/drive_ops_center.sh log-sync-check
bash domain-api/deploy/multi-region/drive_ops_center.sh log-sync-recover
bash domain-api/deploy/multi-region/drive_ops_center.sh scene-node-log http://127.0.0.1:8100 mainland-worker-01 120 key

3. 总检修复车道

典型信号:

  • stack_status=blocked
  • surface_status=broken
  • contracts / launchpad / activity-stream 缺口

优先命令:

bash domain-api/deploy/multi-region/check_ops_center_stack.sh http://127.0.0.1:8100
bash domain-api/deploy/multi-region/check_ops_contracts.sh http://127.0.0.1:8100
bash domain-api/deploy/multi-region/check_release_hub.sh http://127.0.0.1:8100

4. 检测参与车道

典型信号:

  • 页面显示在线节点多,但真正跑检测的少
  • claimed_by 分布异常
  • 在线但未参与节点过多

优先命令:

bash domain-api/deploy/multi-region/check_worker_participation.sh
bash domain-api/deploy/multi-region/drive_ops_center.sh activity-stream

5. 发布 / 放量车道

典型信号:

  • publish_ready=true
  • launchpad_status 已可进入 Worker / Control rollout
  • 默认下一步已落在 Release Hub

优先命令:

bash domain-api/deploy/multi-region/drive_ops_center.sh release-launchpad
bash domain-api/deploy/multi-region/drive_ops_center.sh codex-focus-preview

六、首屏通过标准

Ops Center 首屏如果要算“可上线收工”,至少应满足:

  • 首屏能同时显示:
    • 上线收口状态
    • 发布闸门状态
    • 自动化收口状态
    • 主处理车道
    • 默认下一步
    • 后端接管覆盖
    • 观察层完整度
    • 现场日志覆盖度
  • 首屏动作条可直接完成:
    • 默认下一步
    • 定位下一步
    • 看契约
    • 复制命令
    • 进入主处理面板
  • 首屏回执条能统一反馈:
    • 打开契约成功
    • 定位成功
    • 复制成功
    • 后端动作执行成功 / 警告 / 失败

如果这些已经稳定,就说明值班同事和海外 Codex 已经在同一个驾驶台上工作,而不是各自再拼逻辑。


七、通过标准后的最小上线动作

当上面门禁都通过后,建议最小上线动作顺序为:

  1. go-live-check
  2. stack-diagnosis
  3. 复核 driver-feed.automation_coverage
  4. 复核 codex-brief.recommended_behavior
  5. 若进入发布车道,先看 release-launchpad
  6. guarded_auto 动作显式确认后再执行

上线前最后一轮建议保留证据:

  • go-live-summary 输出
  • stack-diagnosis 输出
  • driver-feed 输出
  • codex-brief 输出
  • release-launchpad 输出
  • 前端构建成功记录

八、现在这套体系是否已经进入可上线状态

按当前仓库现状,可以认为已经具备:

  • 单脑控制面的协议骨架
  • 首屏驾驶舱骨架
  • 总检与驾驶 contract
  • Release Hub / Driver / Node Agent 的联动骨架
  • 海外 CLI 单入口

但正式宣称“可以上线”,仍建议每次以这份总表复核,而不是只凭某一个页面截图或某一次联调成功就直接跳过。

这份文档的定位就是:

后续每次上线、值班接手、发布前复核,都先回到这里。

如果你已经准备进入“这次要不要真的发”的最终执行阶段,下一份应直接看:

  • docs/26_domainCheck_发布前运行验证与交付模板.md