11 KiB
25 domainCheck 海外单脑控制面上线收口总表
一、这份文档解决什么问题
这份文档不是再讲设计,而是把当前项目进入正式上线前,真正需要收口的事项压成一张总表。
适用场景:
- 海外主机已经作为单脑控制面
- 大陆节点已经开始纳管
- Ops Center / Codex Driver / CLI 都已经接入同一套
opscontract - 目标从“能联调”切换到“能稳定上线、能持续运维”
这份文档优先回答 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 != blockedstack_diagnosis.diagnosis.stack_status != blockedroute_surface_complete=truedriver-feed.automation_coverage.launch_status != blocked- 首屏默认下一步已经明确,不再是模糊人工判断
2. 发布门禁
至少同时满足:
publish_ready=truelaunchpad_status != blocked- 不存在未处理的关键
blocking_reasons - 当前发布主车道已经清晰落在:
review_smart_rollout_previewreview_control_rolloutpublish_latest_workercreate_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_statuspublish_statusblocking_reasonswarningsnext_step_action_codeoperator_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
重点只看:
statusheadlinemissing_itemstooling_itemsruntime.preflight_okruntime.readiness_statusruntime.route_surface_completeruntime.repo_capability_driftruntime.runtime_may_need_restartrecommended_actions
如果这里出现:
runtime.repo_capability_drift=trueruntime.runtime_may_need_restart=true
则优先执行 runtime-refresh-recover,不要先把问题误判成“代码还没写完”。这通常表示:
- 仓库代码已经更新
- 但运行中的
domaincheck-api进程还没重启到这版代码
runtime-refresh-recover 会固定给出:
- 当前是否真的属于运行时版本漂移
- 推荐先跑的
runtime-refresh-recover统一恢复入口 - 重启后应该按什么顺序继续:
stack-diagnosisnode-bootstrap-planstack-nextdoctor-decision
如果你已经不想再手工一条条执行,而是想把“刷新运行时 + 再做总检复核”压成一次操作,直接执行:
bash domain-api/deploy/multi-region/drive_ops_center.sh go-live-recover
它会固定串起:
runtime-refresh-recoverstack-diagnosis summarystack-nextgo-live-check summarydoctor-decision
如果要把这次上线前检查直接导出成一整包证据,而不是手工复制多段终端输出,直接执行:
bash domain-api/deploy/multi-region/drive_ops_center.sh go-live-export
它会统一导出:
env-auditgo-live-check摘要go-live-summarystack-diagnosisdriver-feedcodex-briefrelease-launchpaddoctor-decisiondoctor-exportmanifest.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-reviewdoctor-decisiongo-live-summary / 发布门禁 / launchpad 摘要
所以页面首屏、CLI 与海外 Codex 看到的是同一份最终签字口径。
第一眼重点只看:
signoff_statusheadlinerelease_gateblocked_reasonsattention_reasonsdecision
第 2 步:看总检详情
bash domain-api/deploy/multi-region/drive_ops_center.sh stack-diagnosis
重点只看:
stack_statusissuesnext_stepquick_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_recommendationautomation_coveragerecommended_behaviorfocus
第 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=0bootstrap_runrun_acceptancemanaged_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=falseline_count=0source_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=blockedsurface_status=brokencontracts/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=truelaunchpad_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 已经在同一个驾驶台上工作,而不是各自再拼逻辑。
七、通过标准后的最小上线动作
当上面门禁都通过后,建议最小上线动作顺序为:
- 跑
go-live-check - 看
stack-diagnosis - 复核
driver-feed.automation_coverage - 复核
codex-brief.recommended_behavior - 若进入发布车道,先看
release-launchpad - 对
guarded_auto动作显式确认后再执行
上线前最后一轮建议保留证据:
go-live-summary输出stack-diagnosis输出driver-feed输出codex-brief输出release-launchpad输出- 前端构建成功记录
八、现在这套体系是否已经进入可上线状态
按当前仓库现状,可以认为已经具备:
- 单脑控制面的协议骨架
- 首屏驾驶舱骨架
- 总检与驾驶 contract
- Release Hub / Driver / Node Agent 的联动骨架
- 海外 CLI 单入口
但正式宣称“可以上线”,仍建议每次以这份总表复核,而不是只凭某一个页面截图或某一次联调成功就直接跳过。
这份文档的定位就是:
后续每次上线、值班接手、发布前复核,都先回到这里。
如果你已经准备进入“这次要不要真的发”的最终执行阶段,下一份应直接看:
docs/26_domainCheck_发布前运行验证与交付模板.md