getDomain/docs/23_domainCheck_终局运维架构设计_海外单脑控制面.md

# 23 domainCheck 终局运维架构设计：海外单脑控制面

## 一、先回答最核心的问题：`ops job` 是什么

`ops job` 不是一条 shell 命令，也不是“点一下按钮马上执行”的临时动作。

`ops job` 的本质是：

> 一条可审计、可编排、可回放、可中断、可回滚的运维意图记录。

它表达的是：

- 谁发起了什么目标
- 目标作用到哪些节点
- 按什么策略执行
- 分成哪些步骤
- 每一步执行结果是什么
- 有没有失败
- 失败后是否回滚
- 最终系统是否达成目标状态

也就是说：

- shell 是“执行手段”
- `ops job` 是“运维对象”

最终系统里，不应该由前端、Codex、定时器直接执行 shell。

它们都只能做一件事：

> 创建 `ops job`

然后由专门的执行器去消费这个 `ops job`。

---

## 二、为什么最终不要“直接执行 shell”

因为“直接执行 shell”有 7 个天然缺陷：

### 1. 无法审计

你知道执行了什么命令，但不知道：

- 谁触发的
- 为什么触发
- 是否按预期执行完
- 执行前后的系统状态

### 2. 无法标准化

今天你执行：

- `systemctl restart domaincheck-worker`

明天可能要补：

- 重启前健康检查
- 失败后重试
- 失败后回滚
- 成功后采样验证

如果直接跑 shell，这些逻辑会散落在脚本、前端、人工脑子里。

### 3. 无法并发调度

当节点从 `2` 台增加到 `10` 台，直接 shell 无法优雅表达：

- 先更新 controller
- 再灰度更新一台 worker
- 观察 10 分钟
- 再滚动更新剩余节点

### 4. 无法做回滚

shell 通常只描述“怎么做”，不描述“失败怎么办”。

### 5. 无法限流和保护

比如：

- 同一时间最多更新 1 台 controller
- 同一地域最多重启 2 台 worker
- 正在跑检测的节点禁止强更

这些都不是 shell 擅长的层面。

### 6. 无法与 Codex 协作

Codex 可以判断，但最终必须落到稳定、标准、可追踪的动作模型，否则还是人工时代。

### 7. 无法沉淀成平台

你要的不是“几个脚本”，而是“海外一台机器接管全部大陆机器”的正式运维平台。

平台核心对象必须是 `ops job`，不是 shell。

但这里还有一个非常重要的配套原则：

- 不直接执行 shell
- 不等于只会给出“你再去跑这几条命令”的人工建议

真正终局形态里，还需要一层：

> 组合恢复入口

比如“远端日志回传恢复”这类高频动作，就不应该让人工自己拼：

1. 开关键回传
2. 看 overview 有没有生效
3. 再决定去看哪台节点日志

而应该被固化成正式单入口，例如：

```bash
bash domain-api/deploy/multi-region/drive_ops_center.sh log-sync-recover
```

它表达的不是一条 shell，而是一条标准运维意图：

- 执行恢复动作
- 读取复核结果
- 输出下一跳命令

也就是说，终局平台既不是“裸 shell”，也不是“只有抽象 job 没有现场入口”，而是：

- 底层执行对象是 `ops job`
- 上层驾驶入口是组合意图命令

这样海外单脑控制面、后台按钮、Codex 驾驶员，才能既保持标准化，又保持现场处理效率。

同理，“运行中 API 还是旧代码 / 旧 schema” 这类问题，也不应该再退回到人工只记一条：

```bash
systemctl restart domaincheck-api
```

正式平台里它应该被提升为组合恢复入口，例如：

```bash
bash domain-api/deploy/multi-region/drive_ops_center.sh runtime-refresh-recover http://127.0.0.1:8100
```

如果当前不是只做单点刷新，而是要把：

- 运行时刷新
- 总检复核
- 上线门禁
- 下一跳动作判断

一起串成一条标准联调车道，那么入口应该继续提升为：

```bash
bash domain-api/deploy/multi-region/drive_ops_center.sh go-live-recover http://127.0.0.1:8100
```

它表达的依然不是“直接 shell”，而是：

- 先识别 runtime drift
- 再执行统一恢复
- 再回读 go-live / stack diagnosis contract
- 最后输出主动作与复核动作

这样页面、CLI、Codex 驾驶员就不会再次退回到：

- 人工猜该不该重启
- 人工猜重启完先看哪个接口
- 人工自己拼下一跳命令

而是继续保持“上层是组合意图入口、底层才是执行手段”的正式平台结构。

同样，“节点接管缺口恢复”也不应该拆成散落在脑子里的三四步：

- 先看哪台节点有缺口
- 再看 handover 详情
- 再生成 bootstrap plan
- 再手工整理下一步命令

它同样应该被固化成正式组合入口，例如：

```bash
bash domain-api/deploy/multi-region/drive_ops_center.sh agent-gap-recover
```

它表达的依然不是“直接 SSH 干活”，而是一条标准运维意图：

- 找到首个接管缺口节点
- 读取该节点 handover 状态
- 生成该节点接入方案
- 输出该节点当前 onboarding 阶段
- 输出后续检查与执行建议

为了不让值班同事继续在脑子里手动拼：

- `node-handover`
- `node-bootstrap-plan`
- `onboarding.acceptance`

还应该有一个节点级入口：

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

它负责把单节点当前到底处于：

- 待补资料
- 待生成 bootstrap
- 待执行 bootstrap
- 可进入 `onboarding.acceptance`

统一压成一个节点级结果。

并且当节点已经进入 `acceptance_ready` 时，不应该再让值班同事自己拼 playbook 参数，而是继续直接给出：

```bash
bash domain-api/deploy/multi-region/drive_ops_center.sh node-acceptance-plan http://127.0.0.1:8100 mainland-worker-01
bash domain-api/deploy/multi-region/drive_ops_center.sh node-acceptance-run http://127.0.0.1:8100 mainland-worker-01 ops-center
```

也就是：

- 先看这次验收将创建哪些标准化任务
- 再把验收统一签发进 ops job / playbook run 体系

同理，bootstrap 也不应该只停在“生成脚本块”，还应该有：

```bash
bash domain-api/deploy/multi-region/drive_ops_center.sh node-bootstrap-preview http://127.0.0.1:8100 mainland-worker-01
bash domain-api/deploy/multi-region/drive_ops_center.sh node-bootstrap-run http://127.0.0.1:8100 mainland-worker-01 ops-center
```

这样：

- 需要人工落地脚本时，用 `node-bootstrap-plan`
- 需要纳入标准工单追踪时，用 `node-bootstrap-run`
- 需要 ready 之后做验收时，用 `node-acceptance-run`

再往上还应该有一个真正的节点级自动恢复入口：

```bash
bash domain-api/deploy/multi-region/drive_ops_center.sh node-recover http://127.0.0.1:8100 mainland-worker-01
bash domain-api/deploy/multi-region/drive_ops_center.sh node-recover http://127.0.0.1:8100 mainland-worker-01 confirm ops-center
```

它的职责不是提供新的能力，而是替值班同事做状态分流：

- 当前还在接入阶段，就转向 `node-bootstrap-run`
- 当前已经进入验收窗口，就转向 `node-acceptance-run`
- 默认先预览决策，`confirm` 后再真正执行

这样平台里真正被沉淀下来的就不是“几条应急命令”，而是：

- `log-sync-recover`
- `agent-gap-recover`
- `node-onboarding`
- `node-recover`
- 后续还会继续有 `release-rollout-recover`
- `delivery-queue-recover`

也就是说，终局平台里的高频运维动作，最终都应该沉淀为：

- 组合恢复入口
- 正式 preview / execute contract
- 一次动作只执行一次

特别是 `node-recover` 这类入口，后续必须固定成：

- preview 走 `onboarding/recovery/preview`
- confirm 走 `onboarding/recovery/execute`

如果后端 execute 已经成功接单，CLI / 页面 / Codex 不允许再补跑一次底层：

- `node-bootstrap-run`
- `node-acceptance-run`

因为这已经不是“展示问题”，而是会直接造成重复创建 `ops job / playbook run` 的正式执行错误。

这里再补一个页面落地约束，避免海外单脑控制面首屏继续堆四五套重复摘要：

- Ops Center 首屏必须先有一块
  - `单脑驾驶舱首屏`
- 它不是新的数据源
  - 而是把现有
    - `go-live-summary`
    - `stack-diagnosis`
    - `driver-feed`
    - `codex-brief.automation_coverage`
  统一压成一屏结论

首屏至少应固定展示：

- 上线收口状态
- 发布闸门状态
- 自动化收口状态
- 主处理车道
- 默认下一步
- 后端接管覆盖
- 观察层完整度
- 现场日志覆盖度

并且页面分层必须明确：

- 首屏负责
  - 判断
  - 决策
  - 默认下一步
  - 一键进入处理面板
- 下方详情区负责
  - 解释原因
  - 展开问题清单
  - 展示推荐动作与命令
  - 提供 contract 下钻

也就是说，下方区块不应该再和首屏重复堆一遍相同按钮，而应明确退到“详情 / 复核 / 下钻”角色。

这样值班时第一眼先回答四个问题：

1. 现在能不能上线
2. 现在能不能正式发版
3. 现在是不是已经进入自动化可接管状态
4. 现在默认下一步到底是什么

然后才继续下钻到：

- 问题清单
- 推荐动作
- job / playbook / rollout 细节

也就是说，页面首屏本身就应该体现“海外单脑”的产品形态，而不是只把多个接口原样堆到一起。

> 标准组合恢复入口

而不是重新退化回人工 shell 时代。

这里还要固定一个已经进入实现层的动作口径：

- 如果后端已经把首个缺口节点收敛成 `bootstrap_run`
  - 页面、CLI、Codex 都优先显示“跑接入收口”
- 如果后端已经把首个缺口节点收敛成 `run_acceptance`
  - 页面、CLI、Codex 都优先显示“跑接管验收”
- `fix_managed_nodes`
  - 仅保留为兜底入口
  - 不能再覆盖已经明确收敛的单节点恢复动作

---

## 三、最高级方案的总目标

最终形态不是“海外后台 + 若干工具脚本”，而是：

> 一套以海外控制面为唯一运维大脑、以 `ops job` 为核心对象、以节点 agent 为标准执行器、以 Codex 为智能驾驶员的正式运维平台。

一句话理解：

- 海外控制面负责“决策、编排、发布、审计、汇聚”
- 大陆节点负责“执行、回传、承载业务”
- Codex 负责“分析、建议、触发”

---

## 四、终局架构分层

建议直接按 8 层设计。

### 1. Control Plane 控制面

部署在海外主机。

职责：

- Web UI
- API
- 运维中心
- 节点目录
- 发布中心
- 日志中心
- 审计中心

它是唯一入口。

### 2. Intent Layer 意图层

所有动作先变成意图：

- 新增节点
- 安装节点
- 更新节点
- 重启服务
- 拉取日志
- 采集诊断
- 启动检测
- 暂停检测
- 回滚版本

这些意图统一落成 `ops job`。

### 3. Workflow Engine 工作流层

把一个运维动作拆成步骤和状态机。

例如 `deploy.release`：

1. 预检
2. 下载发布包
3. 校验 checksum
4. 解压到 releases
5. 切换 current
6. 重启服务
7. 健康检查
8. 标记成功
9. 失败则回滚

这层不关心 shell 细节，只关心工作流编排。

### 4. Scheduler 调度层

决定：

- 哪个 job 先执行
- 哪些节点能执行
- 是否需要分批
- 是否需要串行
- 是否超过并发上限
- 是否落在维护窗口

### 5. Executor 执行器层

真正执行动作的不是前端，也不是 Codex，而是执行器。

执行器分 3 类：

- `node-agent executor`
- `release executor`
- `diagnostic executor`

兜底再保留：

- `ssh rescue executor`

### 6. Node Agent 节点代理层

每台大陆节点都跑一个常驻 `domaincheck-node-agent`。

职责：

- 主动注册
- 主动心跳
- 拉取待执行 job
- 本地执行命令
- 采集 stdout/stderr
- 推送结构化结果
- 推送日志和诊断包

### 7. Artifact & Release 发布层

发布必须是不可变版本制。

不能把正式运维建立在：

- 节点直接 `git pull`
- 节点工作区可能脏
- root/www 用户混跑

正式模型应该是：

- 海外控制面构建 release 包
- release 包有版本号和 checksum
- 节点只下载、校验、切换
- 回滚也只是在 release 之间切换

### 8. Observability 观测与审计层

所有动作必须产生：

- 事件
- 日志
- 结构化结果
- 诊断包
- 审计记录

这层既给前端看，也给 Codex 看。

---

## 五、`ops job` 的正式对象模型

### 1. 一个 `ops job` 至少包含这些字段

- `job_code`
- `job_type`
- `requested_by`
- `source`
- `priority`
- `target_selector`
- `execution_policy`
- `desired_state`
- `payload`
- `status`
- `plan`
- `result`
- `created_at`
- `started_at`
- `finished_at`

### 2. `ops job` 的 5 个核心部分

#### A. Intent

用户真正想做什么。

例如：

- `service.restart`
- `deploy.release`
- `node.bootstrap`

#### B. Selector

作用到谁。

例如：

- 指定节点
- 指定 region=mainland
- 指定 role=worker
- 指定 `hybrid=true`

#### C. Policy

怎么执行。

例如：

- 串行
- 每批 1 台
- 失败即停止
- 健康检查失败自动回滚

#### D. Plan

实际拆出来的步骤。

例如：

- 预检
- 执行
- 验证
- 回滚

#### E. Result

最终结果和证据。

例如：

- 成功 / 失败 / 部分成功
- stdout / stderr 摘要
- 健康检查结果
- 诊断包链接

---

## 六、`ops job` 的状态机

建议不要只用简单的 `queued/running/success/failed`。

正式版建议：

- `draft`
- `approved`
- `queued`
- `planning`
- `scheduled`
- `dispatching`
- `running`
- `verifying`
- `partially_succeeded`
- `succeeded`
- `rollback_running`
- `rolled_back`
- `failed`
- `cancelled`
- `timed_out`

这样后续你看后台时，能明确知道卡在哪一层。

---

## 七、`ops job` 不是单步骤，而是 DAG 工作流

最高级方案里，一个 job 不应只是一条线性步骤，而应支持 DAG。

例如“更新大陆两台 worker”：

- 先跑公共预检
- 再更新 `mainland-worker-01`
- 成功后更新 `mainland-controller-01` 的 worker 部分
- 两边都成功后再做集群验证

有些步骤可以并行，有些必须串行。

所以正式设计应支持：

- `ops_job_steps`
- `depends_on_step_id`
- `retry_policy`
- `timeout_seconds`
- `rollback_step_id`

---

## 八、节点不再是“机器”，而是“受控资源”

最高级方案里，要把节点建模成受控资源，而不是一堆 IP。

每个节点建议有：

- `node_code`
- `region`
- `role`
- `capabilities`
- `labels`
- `deploy_channel`
- `agent_version`
- `reachable`
- `maintenance_mode`
- `effective_worker`
- `hybrid_worker`
- `current_release`
- `desired_release`

这样调度器才能按资源能力派发任务。

---

## 九、Node Agent 应该怎样设计

这是整套方案最关键的一环。

### 1. 连接模式

首选：

- Agent 主动连海外控制面
- 长轮询或 WebSocket

不推荐以 SSH 为主链路。

### 2. Agent 的职责边界

Agent 不负责“决策”，只负责：

- 执行
- 回传
- 保持本机状态一致

### 3. Agent 的本地能力

Agent 至少应内置这些执行器：

- `systemd executor`
- `release executor`
- `shell executor`
- `log collector`
- `diagnostics collector`
- `config renderer`

### 4. Agent 的安全限制

Agent 必须执行白名单动作。

不能允许控制面下发任意 shell 就直接执行。

正确方式是：

- 控制面发 `action + payload`
- agent 解析成受控执行

例如：

- `service.restart` -> `systemctl restart xxx`
- `logs.collect` -> 收集指定日志源

shell executor 只能是受限兜底能力，且必须带审批和审计。

---

## 十、发布系统必须独立出来

终局方案里，发布不应该再依赖 git 工作区。

建议正式设计为：

### 1. Release Object

每个发布包都应有：

- `release_id`
- `version`
- `commit_sha`
- `build_time`
- `artifact_url`
- `checksum`
- `migration_version`
- `rollback_to`

### 2. 节点上的目录规范

```text
/opt/domaincheck/releases/<version>/
/opt/domaincheck/current -> /opt/domaincheck/releases/<version>/
/opt/domaincheck/shared/
```

### 3. 更新流程

1. 下载发布包
2. 校验 checksum
3. 解压到新目录
4. 渲染配置
5. 停服务
6. 切 `current`
7. 启服务
8. 做健康检查
9. 失败回滚

这才是正式运维。

---

## 十一、日志体系必须分层

如果日志不分层，后期还是会被日志量拖死。

### 1. Event 事件流

默认长期保留，体量小。

包含：

- 服务启动/停止
- 任务开始/结束
- 检测阶段切换
- 代理异常
- DB/Redis 异常
- 第三方依赖异常

### 2. Job Log 任务日志

和 `ops job` 绑定。

用于看某次动作：

- 执行了什么
- 返回了什么

### 3. Runtime Log 运行日志

业务服务自身日志。

默认不全量常驻上传，只做：

- 游标读取
- 按需拉取
- 临时全量回传

### 4. Diagnostics Bundle 诊断包

故障时一键采集：

- env 摘要
- systemd 状态
- 关键日志
- cluster snapshot
- sync summary
- release info

---

## 十二、Codex 的最高级接管方式

你说的“海外 Codex 作为智能驾驶员”，最高级不是让 Codex 直接 SSH。

最高级方式是：

### 1. Codex 是 Planner + Operator

Codex 拿到的是：

- 控制面所有 API
- 节点状态
- ops jobs
- 结构化日志
- 发布记录

然后它只做两类事：

- 分析
- 创建标准 `ops job`

### 2. Codex 不直接绕过控制面

Codex 不应该：

- 直接登录每台机器
- 直接手搓 root 命令
- 直接破坏审计链

它应该永远走控制面 API。

### 3. Codex 的价值

它的价值不是“替代平台”，而是：

- 自动读状态
- 自动识别问题模式
- 自动建议动作
- 必要时自动创建低风险 job
- 把复杂联调变成结构化流程

---

## 十三、没有 Codex 时也必须完整可用

这点非常关键。

最终平台不能依赖 Codex 才能工作。

没有 Codex 时，后台也必须能：

- 纳管节点
- 发布更新
- 一键重启
- 一键巡检
- 一键采日志
- 一键采诊断包
- 查看执行结果

Codex 只是锦上添花，不是唯一入口。

---

## 十四、最高级方案里的安全体系

正式版必须加入：

### 1. RBAC

区分：

- 观察员
- 运维员
- 发布员
- 超级管理员

### 2. 审批流

高风险动作必须审批：

- 批量更新
- controller 重启
- 清理数据
- 回滚生产版本

### 3. Policy Engine

可以内置规则：

- 正在跑检测的 worker 禁止强更
- 大陆 controller 每次只能更新 1 台
- `busy` 节点默认拒绝重启

### 4. Secrets 管理

不把所有 SSH 密钥和密码散落到脚本里。

正式版建议独立 secrets 管理，例如：

- Vault
- 或最少做控制面统一加密存储

---

## 十五、这套方案为什么是“后续最少返工”的

因为它不是按“当前临时联调”设计，而是按“节点继续增长、功能继续增加、Codex 持续接管”设计。

它天然支持：

- 节点从 3 台扩到 30 台
- 从手工联调升级到一键部署
- 从后台按钮升级到 Codex 自动驾驶
- 从局部脚本升级到平台化运维

也就是说：

> 这是终局骨架，不是过渡补丁。

---

## 十六、我给你的最终建议

如果按最高级、最优秀、后续最少反复修改的标准来做，路线应该明确成：

1. 海外主机做唯一控制面
2. 一切动作先建模成 `ops job`
3. 节点统一由 `node-agent` 执行
4. 发布统一走 release 包，不走 git pull
5. 日志统一做事件流 + 任务日志 + 诊断包分层
6. Codex 只通过控制面 API 接管，不绕过控制面
7. SSH 只保留 bootstrap 与救援，不做日常主链路

这套方案里，`ops job` 就是整个系统的“运维订单”和“执行凭证”。

它不是附属品，而是整套平台的中心对象。

---

## 十七、终局不是“一份大文档”，而是 7 份冻结 contract

真正能让这套体系后续少返工的，不只是理念对，而是：

> 概念层有总架构，执行层有正式 contract。

最终至少要冻结 7 份正式 contract：

### 1. `ops_job_contract`

建议以后直接以 [ops_job_contract.md](/www/wwwroot/getDomain/docs/schemas/ops_job_contract.md:1) 为正式母本。

约束：

- `ops job` 如何创建
- 如何审批
- 如何取消
- 如何派发
- 如何承诺 job / step / event 结构

它定义的是：

> 一切正式运维动作的执行订单模型

### 2. `ops_agent_protocol`

约束：

- Node Agent 如何注册
- 如何心跳
- 如何拉任务
- 如何回传事件
- 如何回传交付队列快照

它定义的是：

> 节点怎样成为“可托管执行器”

### 3. `ops_driver_contract`

约束：

- `overview.driver_recommendations`
- `driver-feed`
- `codex-brief`
- `driver-actions.preview/resolve/execute`
- `activity-stream`

它定义的是：

> 海外控制面、CLI、Codex 驾驶员如何共享同一套判断与动作入口

### 4. `ops_playbook_contract`

约束：

- playbook catalog
- preview
- execute
- playbook run
- playbook events

它定义的是：

> 多步标准作业怎样从“按钮集合”升级成正式编排对象

### 5. `release_hub_contract`

约束：

- Release
- Rollout
- Launchpad
- Default Rollout Gate
- Default Rollout Execution

它定义的是：

> 发布到底能不能发、该怎么发、先灰哪一台、失败怎么停

### 6. `ops overview / inspection / delivery queue` 收口 contract

这块现在虽然散落在 `overview`、`inspection`、`activity-stream`、`delivery-queue` 里，但终局一定要收成稳定协议。

建议以后直接以 [ops_observability_contract.md](/www/wwwroot/getDomain/docs/schemas/ops_observability_contract.md:1) 为正式母本。

至少要固定：

- 执行现场分组：
  - `dispatch_active_nodes`
  - `recent_only_nodes`
  - `standby_nodes`
  - `load_syncing_nodes`
- 巡检收口：
  - 最近 `health.snapshot`
  - 最近 `logs.collect`
  - 最近 `diagnostics.collect`
- 回执队列治理：
  - 节点级摘要
  - `head_only` 头部记录
  - `flush / replay / discard`

它定义的是：

> 海外控制面如何真正看懂现场，而不是只看到几条状态字串

### 7. `ops_stack_diagnosis_contract`

建议以后直接以 [ops_stack_diagnosis_contract.md](/www/wwwroot/getDomain/docs/schemas/ops_stack_diagnosis_contract.md:1) 为正式母本。

至少要固定：

- `stack_status`
- `issues`
- `next_step`
- `recommended_actions`
- `quick_commands`
- `focus_ref`

它定义的是：

> 海外单脑控制面的第一现场总检入口，页面、CLI、Codex 都必须先从这里起步

所以总架构文档的职责不是把所有字段都写死，而是明确：

- 哪 7 份 contract 才是后续实现的正式母本
- 页面、CLI、Codex 都只能复用这些 contract
- 不允许再额外衍生第 8 套逻辑

并且这 7 份 contract 以后不该只存在于文档目录里，还要进入统一 registry：

- `GET /api/v1/ops/contracts`
- `GET /api/v1/ops/contracts/{contract_key}`

这样海外控制面、CLI、Codex 驾驶员才能按同一份 contract graph 导航，而不是继续靠人脑记“哪份协议在哪个 md 里”。

这一步非常关键，因为一旦没有 contract 冻结，你后面就会再次回到：

- 页面自己猜
- CLI 自己拼
- Codex prompt 自己解释
- 节点 agent 再走一套临时语义

那“单脑控制面”就又会退化成“多脑拼接系统”。

---

## 十八、单脑控制面的日常闭环应该固定成 6 段

你后面不应该再按“这次故障怎么处理”临时想流程，而应该把日常路径固定成下面 6 段。

### 1. 接管

- 签发 token
- 生成 bootstrap plan
- 节点注册
- 节点心跳进入托管目录

这里的目标不是“节点能连上”，而是：

> 节点成为正式受控资源

### 2. 验收

- 执行 `onboarding.acceptance`
- 必要时追加 `inspection.standard`
- 确认：
  - service topology 正确
  - agent 在线
  - delivery queue 正常
  - 巡检结果可回看

这里的目标不是“接进来就算完”，而是：

> 接入后立刻进入正式运维

### 3. 观察

- 看 execution scene
- 看 inspection overview
- 看 activity stream
- 看 delivery queue

如果现场异常，优先动作应固定成：

- 开关键日志回传
- 跑标准巡检
- 处理死信 / retrying

而不是重新 SSH 上去抓一遍日志。

### 4. 发布

- 看 Release Launchpad
- 看 Default Rollout Gate
- 先 worker canary
- 再批次推进
- 异常即停
- 必要时回滚

这一步必须始终坚持：

- 节点不 `git pull`
- 发布只认 release artifact
- rollout 只认正式 gate

### 5. 故障

故障时优先路径应固定成：

1. `driver recommendation`
2. `activity-stream`
3. `playbook run detail`
4. `delivery queue`
5. `inspection / diagnostics`

也就是说，先走：

> 结构化现场收口

再决定是否需要更重动作。

### 6. 救援

只有下面场景，才进入 SSH Rescue：

- Node Agent 没注册成功
- Node Agent 已失联
- release 切换中断，当前目录损坏
- systemd / Python 运行环境坏到 agent 无法自救

而且即使进入救援，也应该做到：

- 仍生成正式 `ops job`
- 仍记录执行人、目标节点、动作来源
- 仍把结果写回控制面审计链

这就是“单脑控制面”的关键边界：

- 日常动作走标准 contract
- 标准动作走 agent / playbook / rollout
- 救援动作才进入 SSH

这样以后新增机器、换地域、换发布流程，都只是替换某一层执行器，不需要重写整个体系。