431 lines
11 KiB
Markdown
431 lines
11 KiB
Markdown
# 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 步：看上线收口摘要
|
||
|
||
```bash
|
||
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
|
||
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
|
||
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
|
||
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
|
||
bash domain-api/deploy/multi-region/drive_ops_center.sh go-live-review
|
||
```
|
||
|
||
如果你想在 bundle 基础上直接得到一句“现在能不能签字上线”的统一结论，而不是人工再看多份 JSON，直接执行：
|
||
|
||
```bash
|
||
bash domain-api/deploy/multi-region/drive_ops_center.sh go-live-signoff
|
||
```
|
||
|
||
或基于已有 bundle：
|
||
|
||
```bash
|
||
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
|
||
bash domain-api/deploy/multi-region/drive_ops_center.sh stack-diagnosis
|
||
```
|
||
|
||
重点只看：
|
||
|
||
- `stack_status`
|
||
- `issues`
|
||
- `next_step`
|
||
- `quick_commands`
|
||
|
||
### 第 3 步：看驾驶主线
|
||
|
||
```bash
|
||
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
|
||
bash domain-api/deploy/multi-region/drive_ops_center.sh stack-next
|
||
```
|
||
|
||
如果已经确认要执行：
|
||
|
||
```bash
|
||
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
|
||
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
|
||
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
|
||
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
|
||
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
|
||
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`
|