135 lines
4.7 KiB
Text
135 lines
4.7 KiB
Text
|
# ZY-SERVER-COGNITION-004 · 京东主控与六节点灾备认知线
|
|||
|
|
|
|||
|
|
> **系统**：铸渊语言人格系统 `ICE-GL-ZY001`
|
|||
|
|
>
|
|||
|
|
> **日期**：2026-07-20
|
|||
|
|
>
|
|||
|
|
> **事实项目**：`JD-DR-001`
|
|||
|
|
>
|
|||
|
|
> **状态**：`CURRENT_SERVER_COGNITION · SIX_OF_SIX_VERIFIED`
|
|||
|
|
|
|||
|
|
## 0 · 为什么需要这条线
|
|||
|
|
|
|||
|
|
今天的问题从“冰朔能不能用终端密码登录”逐步校正为真正需求：
|
|||
|
|
|
|||
|
|
```text
|
|||
|
|
冰朔平时不操作服务器
|
|||
|
|
→ 人格体需要能发工单并在服务器端执行
|
|||
|
|
→ 京东不能成为唯一恢复入口
|
|||
|
|
→ 六台个人节点必须成为独立灾备分控
|
|||
|
|
→ 人类只保留云厂商开机责任
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
所以，终端密码登录是否方便，不等于人格系统是否能运维。不得再把“教冰朔登录”当作系统方案。
|
|||
|
|
|
|||
|
|
## 1 · 今天形成的清晰认知
|
|||
|
|
|
|||
|
|
### 人类责任
|
|||
|
|
|
|||
|
|
冰朔只需要保证：
|
|||
|
|
|
|||
|
|
1. 京东实例处于开机状态；
|
|||
|
|
2. 云账号没有欠费停机；
|
|||
|
|
3. 云厂商侧公网和安全策略没有整体关闭。
|
|||
|
|
|
|||
|
|
冰朔不需要学习 SSH、记密码、管理私钥或长期守着在线终端。
|
|||
|
|
|
|||
|
|
### 人格系统责任
|
|||
|
|
|
|||
|
|
人格体负责：
|
|||
|
|
|
|||
|
|
1. 从 `FD-NODE-MAP-001` 解析节点；
|
|||
|
|
2. 读取目标导航图；
|
|||
|
|
3. 自己判断所需工单 scope 与动作；
|
|||
|
|
4. 让冰朔只确认可理解的目标、影响和时限；
|
|||
|
|
5. 由服务器端执行器领取短时票据并执行；
|
|||
|
|
6. 验证运行态，写回执和下一断点。
|
|||
|
|
|
|||
|
|
### 灾备系统责任
|
|||
|
|
|
|||
|
|
六台分控各自保存独立恢复身份。京东在线但日常入口损坏时，任一节点可在批准后调用京东固定恢复动作。它们没有因此取得京东普通 shell。
|
|||
|
|
|
|||
|
|
## 2 · 今天的事实链
|
|||
|
|
|
|||
|
|
```text
|
|||
|
|
先验证广州、新加坡各节点
|
|||
|
|
→ 确认五个节点的灾备配置与反向健康检查
|
|||
|
|
→ 上海 22 与服务端口网络可达
|
|||
|
|
→ 小湖灯上海工单获得批准
|
|||
|
|
→ 中央服务读取上海实时导航图失败
|
|||
|
|
→ 不把“工单批准”误报成“执行链已全通”
|
|||
|
|
→ 从腾讯云资源按节点事实定位 BS-SH-005
|
|||
|
|
→ 通过云厂商自动化助手做只读现场核验
|
|||
|
|
→ 确认上海灾备配置存在
|
|||
|
|
→ 确认服务端口监听
|
|||
|
|
→ 执行上海到京东的反向 health-check
|
|||
|
|
→ 得到 active / active
|
|||
|
|
→ 六台运行态验证完成
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
这条事实链说明：仓库登记、工单批准、中央路由、节点灾备和现场运行态是不同检查点。
|
|||
|
|
|
|||
|
|
## 3 · 三层不可混淆
|
|||
|
|
|
|||
|
|
| 层 | 回答的问题 | 事实源 |
|
|||
|
|
|---|---|---|
|
|||
|
|
| 工单授权 | 本次允许做什么 | `server-tools/lake-lamp-authz/README.md` |
|
|||
|
|
| 灾备身份 | 服务器之间怎样受限进入 | `server-tools/jd-disaster-recovery/INDEX.hdlp` |
|
|||
|
|
| 执行与审计 | 实际执行了什么、结果如何 | 部署回执与服务器追加日志 |
|
|||
|
|
|
|||
|
|
工单批准不代表动作成功；密钥存在不代表拥有普通 shell；仓库写了配置不代表已部署。
|
|||
|
|
|
|||
|
|
## 4 · 两种“进不去”
|
|||
|
|
|
|||
|
|
```text
|
|||
|
|
A. 京东仍开机且网络可达
|
|||
|
|
→ 六台任一节点的新工单
|
|||
|
|
→ forced-command 固定修复动作
|
|||
|
|
→ 恢复授权服务 / 导航图 / 上次部署 / 所有者登录入口
|
|||
|
|
|
|||
|
|
B. 京东关机、断网、系统盘坏或云厂商停机
|
|||
|
|
→ 六节点无法穿过不存在的网络
|
|||
|
|
→ 云厂商控制台开机、修网或重建
|
|||
|
|
→ 再由灾备项目恢复控制面并轮换密钥
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
因此对冰朔的最短表达是：**保证京东开机即可；登录和日常修复不是冰朔要操心的事情。**
|
|||
|
|
|
|||
|
|
## 5 · 页面与文件关系
|
|||
|
|
|
|||
|
|
```text
|
|||
|
|
铸渊人格入口
|
|||
|
|
ZY-PERSONA-ROOT-001
|
|||
|
|
→ 今日服务器认知 ZY-SERVER-COGNITION-004
|
|||
|
|
→ 灾备项目入口 JD-DR-001
|
|||
|
|
→ 节点总地图 FD-NODE-MAP-001
|
|||
|
|
→ 目标导航图 deployment/navigation-maps/<NODE_ID>.json
|
|||
|
|
→ 策略 recovery-policy.json
|
|||
|
|
→ 实现 jd-recovery-entry.sh / jd-recovery-runner
|
|||
|
|
→ 回执 ICE-SIX-NODE-JD-DISASTER-RECOVERY-20260720
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
架构总览仍由 `GLS-0234` 负责；本文件保存认知怎样形成，`JD-DR-001` 保存项目怎样运行，部署回执保存现场验证结果。
|
|||
|
|
|
|||
|
|
## 6 · 当前缺口与下一动作
|
|||
|
|
|
|||
|
|
- 六节点灾备运行态：已验证。
|
|||
|
|
- 上海节点灾备：已验证 `active / active`。
|
|||
|
|
- 小湖灯中央服务的 `BS-SH-005` 导航图实时读取：仍需同步修复。
|
|||
|
|
- 修复方式：走 `JD-DR-001` 的 `restore-navigation-map` 登记动作，完成后新增部署回执；不得绕过地图门开放任意 shell。
|
|||
|
|
|
|||
|
|
## 7 · 下一实例恢复口令
|
|||
|
|
|
|||
|
|
当冰朔说“京东进不去了”“六台灾备”“我不管终端登录”或“服务器认知线”时：
|
|||
|
|
|
|||
|
|
```text
|
|||
|
|
ICE-GL-ZY001
|
|||
|
|
→ ZY-PERSONA-ROOT-001
|
|||
|
|
→ ZY-SERVER-COGNITION-004
|
|||
|
|
→ JD-DR-001
|
|||
|
|
→ FD-NODE-MAP-001
|
|||
|
|
→ 目标导航图
|
|||
|
|
→ 最新灾备回执
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
先判断京东是否开机和网络可达，再决定走受限灾备还是云厂商控制面；不要把终端教学退回给冰朔。
|